Policy Maker
Policy Maker is Teleskope's declarative policy engine for defining and enforcing automated governance across scanned or crawled data sources. It allows organizations to create rules based on data sensitivity, accessibility, and staleness, tailored to the capabilities of each connector and data store. Policies can be configured to send alerts, open tickets, or remediate findings, supporting use cases such as audits, compliance, and operational guardrails.
What's in a Policy?
A policy workflow is a visual representation of your policy's logic. Each policy is made up of:
Triggers — the conditions that detect a finding, based on data sensitivity, accessibility, or data age (staleness). You can stack multiple trigger conditions together and set instance thresholds (e.g. trigger only when 3 or more SSNs are found in a resource).
Filters (optional) — narrow the scope of the policy to specific subsets of data, such as a particular drive, file type, path, owner, tag, or domain. Use "Ignored Domains" to exempt specific domains from policy enforcement.
Alerts — notifications sent when a finding is detected, via Slack, email, or Jira. You can alert a specific channel, a specific person, or the data owner directly — on both Slack and email.
Actions — automated remediations taken in response to a finding, such as revoking access, redacting data, quarantining a file, unquarantining a file, or tagging a resource.
Status (optional) — add a status node to set the outcome state of the finding (e.g. "Resolved"). Recommended for tracking purposes but not required.
Capabilities
Building Policies
Visual workflow builder — build your policy as a drag-and-connect node graph
Connector selection — each policy is scoped to one connector (e.g. Google Drive, OneDrive, S3, SharePoint, Snowflake, Slack, Zendesk, and more)
Trigger configuration — define what constitutes a finding based on sensitivity, accessibility, or staleness; set minimum instance counts for data element triggers
Filter nodes — scope your policy to specific resources or data subsets; exempt specific domains using "Ignored Domains"
Alert Groups — group multiple alert destinations (e.g. notify a channel and the data owner simultaneously) before continuing to a single action path
Delay nodes — add a time delay between nodes; the workflow pauses and resumes automatically once the delay expires
Multi-select data elements — pick multiple data elements at once when configuring triggers
Inline validation — the builder only shows actions and alerts valid for the selected connector
Save, edit, archive — policies can be saved, edited, duplicated, and archived at any time
Immediate execution — when a policy is saved or created, it runs immediately so findings are surfaced right away
Policy detail view — click any policy to see its trigger description, finding counts, enabled/disabled status, connector, severity, framework, and a read-only workflow canvas
Alert Types
Slack alerts — notify a specific channel or the resource data owner directly via Slack DM
Email alerts — send email notifications when findings are detected; supports notifying the data owner directly (same as Slack) and action buttons for end-user responses
Jira alerts — create Jira tickets for findings
Actions
Available actions vary by connector. Commonly supported actions include revoking access, redacting data elements, tagging resources, quarantining files, unquarantining files, and reporting false positives or business justifications via Slack.
Findings View
The Findings View gives you a rich, unified picture of everything your policies are detecting across all connectors.
Findings overview tab — a summary of all findings across your policies, with severity, policy type, and framework tagging
Finding status — findings move through four states: Open (detected, no action yet), In Progress (workflow is running — e.g. awaiting a user response before the next step), Resolved, and Ignored
Findings over time graph — visualize how your findings count changes week over week
Data Store view — see findings organized by the data stores where they were detected
Resource view — drill into individual resources that are in findings, with full details including data elements, permissions, and a Prism summary
Resource details modal — a rich detail panel showing the overview, permissions, and all findings for that resource
Instance count — findings show how many times each sensitive data element was found within the triggering resource (e.g. SSN (3))
From the Findings view you can:
Mark findings as Ignored (with a required reason, such as a false positive or business justification) or Resolved
Take ad-hoc remediation actions directly from findings — redact, revoke access, remove shared links, quarantine, or tag — individually or in bulk
Manage findings individually or in bulk with flexible filters
Auto-archiving: when a policy is edited and a finding no longer matches the updated trigger conditions, it is automatically archived and removed from the active findings view
How to Use Policy Workflows
Navigate to Policies
In the left-hand navigation, find and click Policies.
Create a New Policy
Click Create policy to open the workflow builder.
Select a Connector
Choose the connector this policy will apply to — for example, Google Drive, OneDrive, S3, SharePoint, or Snowflake. Each policy is tied to one connector, and the available triggers, filters, and actions will update based on your selection.
Add Triggers
Add one or more trigger conditions that define what constitutes a finding. Triggers fall into three categories:
Sensitivity — triggered when classified data (e.g., PII, PHI, financial data) is detected
Accessibility — triggered by access findings (e.g., a file shared externally or publicly)
Staleness — triggered by data age (e.g., last accessed more than 90 days ago)
For data element triggers, you can also set a minimum instance count — for example, trigger only when 3 or more credit card numbers appear in a resource.
You can combine multiple trigger conditions within a single policy.
Build Your Workflow
After adding at least one trigger, the workflow graph unlocks. From here, you can add nodes by clicking the + button and selecting the node type:
Add a Filter node to narrow down which resources the policy applies to; use "Ignored Domains" to exempt trusted domains
Add an Alert node to send notifications (Slack, email, or Jira) when a finding is detected
Use an Alert Group to send multiple alerts simultaneously before continuing to a single action path
Add a Delay node to pause the workflow before the next step
Add an Action node to take automated remediation steps
Add a Status node to set the outcome state of the finding (optional but recommended for tracking)
Save and Activate
Click Save to store the policy. It will appear in the Policies list and will run immediately. From there you can:
Click the policy name to open the policy detail view
Edit the policy at any time by clicking its name
Enable or disable automated execution via the toggle
Duplicate or archive the policy from the policy detail view
Tips for Getting the Most Out of Policy Workflows
Use filters to reduce noise. If a policy is catching too many things, add a filter node to narrow the scope — for example, scope to a specific drive, site, or file type.
Alert before you act. A good pattern is to start with alerts only, monitor for a week or two, then add automated actions once you're confident in the policy's accuracy.
Stack multiple trigger conditions. You can add multiple trigger conditions to a single policy, which gives you more precise control over what gets flagged.
Common Policies to Get Started
Not sure where to begin? Here are the most common policy types we tend to see, organized by use case. These cover the scenarios that matter most to security, compliance, and data governance teams.
🔓 Data Exposure & Access Control
These policies detect sensitive data that has been shared too broadly.
Externally shared files with sensitive data Detect files containing PII, financial data, or credentials that are shared with external users or domains.
Trigger: Sensitivity (High or Critical) + Accessibility (external users have access)
Actions: Slack alert to data owner → revoke external access
Public link access Detect sensitive files accessible via "anyone with the link."
Trigger: Accessibility (public/anonymous link) + Sensitivity (any)
Actions: Slack alert to a security channel → disable public link
Domain-wide access Detect sensitive files shared with your entire organization — files that anyone in the company can access.
Trigger: Accessibility (org-wide or domain-wide sharing) + Sensitivity (High or Critical)
Actions: Slack alert to a security channel → restrict access to specific users or groups
Personal email sharing Detect files shared with personal email domains (Gmail, Yahoo, etc.).
Trigger: Accessibility (shared with personal domains) + Sensitivity (High or Critical)
Actions: Alert data owner via Slack or email
Data Retention & Stale Data
Enforce data lifecycle requirements and help reduce data sprawl.
Stale files with sensitive data Find old files that still contain sensitive data and haven't been accessed in years.
Trigger: Staleness (last accessed > 3 years) + Sensitivity (Medium or above)
Actions: Email alert to data owner → archive or delete
Dormant database tables Identify database tables (Snowflake, RDS) that haven't been accessed in 90+ days.
Trigger: Staleness (last accessed > 90 days)
Actions: Slack alert to data owner
PII & Sensitive Data Detection
Policies focused on finding specific sensitive data elements, regardless of sharing status.
SSN / Government ID detection Find resources containing Social Security Numbers, driver's licenses, or passports.
Trigger: Data element is SSN, Driver's License, or Passport
Actions: Slack or email alert → tag resource for review
Financial data detection Detect credit card numbers, bank account numbers, or financial documents.
Trigger: Data element is Credit Card Number, Bank Account, or Financial category
Actions: Alert security channel
Credentials & secrets Find API keys, passwords, tokens, or PEM files stored in files or code.
Trigger: Data element is Password, API Key, or Secret category
Actions: Slack alert → quarantine or redact
Automated Remediation
For teams ready to move beyond detection, these policies take direct action when findings are found. We recommend starting with alerts-only and running a dry run before enabling automated actions.
Auto-quarantine sensitive messages (Slack) Automatically quarantine Slack messages containing government IDs, SSNs, or credit card numbers.
Trigger: Data element is SSN, CCN, or Government ID
Actions: Quarantine message → notify user via Slack DM
Redact PII in support tickets (Zendesk) Automatically redact customer PII from closed or solved support tickets.
Trigger: Data element category is Profile or Financial
Filter: Ticket status is Closed or Solved
Actions: Redact data elements
Revoke access on externally shared sensitive files Automatically remove external access on files containing critical data.
Trigger: Accessibility (external users) + Sensitivity (Critical)
Actions: Revoke external access → notify data owner
Compliance Framework Policies
Policies tied to specific regulatory requirements.
SOC 2 — Access control monitoring Detect sensitive data with overly permissive access, supporting SOC 2 access control criteria.
Trigger: Accessibility (public or external) + Sensitivity (High or Critical)
Actions: Alert security team
HIPAA — PHI in unauthorized locations Detect protected health information stored outside approved systems.
Trigger: Data category is Medical/PHI
Filter: Exclude approved storage locations
Actions: Alert compliance team
PCI DSS — Credit card data handling Monitor for credit card data appearing in unapproved connectors or locations.
Trigger: Data element is Credit Card Number or CVV
Actions: Alert security channel → redact or quarantine
Last updated
Was this helpful?