> 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/connectors/saas/slack/slack.md).

# Enterprise+

Teleskope's Slack DLP gives security teams real-time, policy-driven control over sensitive data flowing through Slack — across messages, files, canvases, and lists. Policies are fully composable: you define what to detect, where to enforce it, and how to respond, with multi-step workflows that can include time delays, escalations, and end-user remediation.

### How It Works

#### Historical & Real-Time Detection

Teleskope inspects Slack content at three enforcement points, depending on the policy and your tenant configuration:

* **Pre-send interception.** Files can be scanned and intercepted *before* they're delivered into the channel, blocking sensitive content from ever reaching recipients.
* **Sub-second post-send scanning.** Messages, files, canvas updates, list edits, and any subsequent modifications are inspected within roughly one second of being posted, so violations can be quarantined or remediated almost immediately.
* **Historical scanning.** Teleskope can scan content already in Slack, messages, files, canvases, and lists posted before the policy was created or before Teleskope was installed. This surfaces existing exposure across your tenant so you can remediate legacy sensitive content, not just net-new posts.

Coverage extends across every editable surface in Slack — not just new messages, but edits, replies, canvas changes, and list updates — so users can't slip sensitive data in through a later edit.

#### Flexible Policy Triggers

Each policy defines *when* it fires. Triggers can be combined and scoped to match your organization's risk model:

* **User** — specific users or service accounts
* **Group** — IDP groups, departments, or Slack user groups
* **Channel name** — exact match or pattern (e.g., everything matching `finance-*`)
* **Channel type** — internal channels, Slack Connect / externally shared channels, DMs, MPIMs
* **Workspace** — apply policies differently across workspaces in your Enterprise Grid
* **Data type** — detected data elements (e.g., `bank_account`, `ssn`, `api_key`) and document types (e.g., contracts, source code, financial reports)

Triggers are AND-combined by default, so a policy can target, for example, "any message in an externally shared channel that contains an SSN or bank account number."

#### Configurable Action Workflows

Once a policy fires, Teleskope runs a workflow of actions you've defined. Workflows support branching, time delays, and end-user input, so you can build graduated responses instead of binary block/allow decisions.

Available actions include:

* **Quarantine** — tombstone the message or file so it's hidden from the channel while preserving the original for review
* **Notify data owner** — DM the user who posted the content with context and self-service remediation options
* **Notify security team** — post to an admin channel with full finding details and action buttons
* **Redact** — permanently remove the sensitive elements from the message or file
* **Restore (un-quarantine)** — un-tombstone content if it's confirmed as a false positive
* **Update finding status** — mark findings as ignored, false positive, or resolved
* **Time delays** — pause the workflow for a defined window (e.g., one hour, one day) before escalating

A typical graduated workflow looks like this:

> Detect SSN in a Slack Connect channel → quarantine the message → notify the data owner and the security channel → wait 1 day → if the owner takes no action, redact permanently → if the owner flags as a false positive, restore the original message.

This pattern lets the workflow handle the long tail of legitimate-but-sensitive content automatically while still defaulting to a safe state.

### **Prerequisites:**

1. Your Slack User has the *Org Owner* role
   1. Ideally this User is a Service Account
2. Your Slack tenant has the Discovery API enabled and available
3. Your Teleskope user has the *Admin* role

{% stepper %}
{% step %}
**Install the Teleskope Data Security app**

* Navigate to Settings → Connectors → Slack
* Click **Enroll+**
* Select the **Full access** radio button
* Click the **Add to Slack** button<br>

  <div align="left"><figure><img src="/files/7ouW5VfKwutdAhffNdFE" alt="" width="208"><figcaption></figcaption></figure></div>
* Ensure you have the correct tenant selected and displayed in the upper right hand of the Authentication page
* Click **Allow** at the bottom of the page
* Teleskope will automatically begin scanning
  {% endstep %}

{% step %}
**Enable Notifications**

1. Add the App to your Workspaces
   1. In your App Admin page, add the Teleskope app to any workspaces you would target for notifications.
2. Invite the App (`/add`) to target notification channels

{% hint style="info" %}
If the app doesn't appear and was installed as a connector, contact a Workspace owner.
{% endhint %}
{% endstep %}

{% step %}
**Create a DLP policy in Policy Maker**

* Click **Create Policy +**
* Define your trigger conditions
* Restrict your policies to specific channels during testing
* Add automated actions
  * Use the **Quarantine** action to temporarily tombstone sensitive content
    * Determine an Admin channel for notifications and action options within slack
    * Optionally message the end user for self-reporting
      {% endstep %}
      {% endstepper %}

## Classifications & Filtering Behavior

We handle certain elements in different ways. Below is a summary of our filtering logic as well as elements that we do not detect for storage and filtering reasons.

### Credit Card Numbers

Credit card numbers must pass our post-validation rules, meaning they must pass [Luhn Algorithm](https://en.wikipedia.org/wiki/Luhn_algorithm) checks.

### Social Security Numbers

While certain SSNs such as `123-45-6789` are **structurally valid** under SSA assignment rules, we proactively **filter out common test patterns or sequences** that are far more likely to be false positives (FPs). This helps reduce noise in results and minimizes the likelihood of inaccurate detections during scanning.

### Email Addresses

We **filter out internal and company-specific email addresses** during scans. This is primarily to reduce noise and manage storage effectively, particularly in the context of historical scanning, where repeated detection of internal contacts can become very storage-intensive.

{% hint style="info" %}
**The following elements are also skipped for similar storage and filtering reasons:**

* `WEBSITE`
* `FIRST_NAME`
* `LAST_NAME`
* `MIDDLE_NAME`
* `USER_IDENTIFIER`
* `LANGUAGE`
* `ORGANIZATION`
  {% endhint %}