> For the complete documentation index, see [llms.txt](https://docs.teleskope.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.teleskope.ai/the-platform/policy-maker.md). # 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 {% stepper %} {% step %} **Navigate to Policies** In the left-hand navigation, find and click **Policies**. {% endstep %} {% step %} **Create a New Policy** Click **Create policy** to open the workflow builder. {% endstep %} {% step %} **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. {% endstep %} {% step %} **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. {% endstep %} {% step %} **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) {% endstep %} {% step %} **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 {% endstep %} {% endstepper %} *** ## 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 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.teleskope.ai/the-platform/policy-maker.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.