SOC 2 Slack Compliance: Data Retention and SSO Setup

Slack in SOC 2 Scope

Slack is in SOC 2 scope for most SaaS companies because it handles: customer support communications (customer PII), internal security discussions (vulnerability details), incident response communications (production data references), and shared credentials (unfortunately still common). Slack holds a SOC 2 Type II report, downloadable from slack.com/trust. Your responsibility is its configuration.

The primary SOC 2 concerns with Slack are: unauthorized access (SSO enforcement), data retention (how long messages containing customer data are stored), data loss prevention (preventing sensitive data from being shared externally), and access control (who can see what channels). This guide addresses all four.

SSO Enforcement and MFA (CC6.1)

Enforce SSO via your identity provider (Okta, Azure AD, Google Workspace) for Slack. Navigate to Slack Admin → Settings → Authentication → SAML Authentication. Configure your IdP SAML settings and set "Require SAML for all workspace members". When SSO is enforced, users cannot log in with a Slack password — they must authenticate through your IdP, inheriting your IdP's MFA enforcement.

After enabling SSO, de-provision Slack access by deactivating the user in your IdP rather than in Slack directly. When the IdP session is revoked, the Slack session expires at the next token refresh. For immediate revocation, use the Slack SCIM API (`DELETE /scim/v2/Users/{id}`) from your IdP provisioning connector to deactivate the Slack account synchronously with the IdP deactivation. This satisfies CC6.3 timely de-provisioning.

Set session duration in Slack Admin → Settings → Authentication → Session duration. Set to 8 hours or 1 day. Shorter sessions mean more frequent re-authentication through your IdP, which provides more MFA challenges but also more user friction. 1 day is a reasonable balance for most companies. Document the session duration in your access control policy.

Message Retention Policies (C1.1)

Slack message retention policies define how long messages are stored before automatic deletion. Navigate to Slack Admin → Retention & Deletion. For workspace-level retention, set a default policy. Consider: if you set retention too long (years), you accumulate sensitive data. If too short (days), you lose operational context. For SOC 2, the relevant question is: how long is customer data in Slack messages retained?

Recommended approach: set workspace-level retention to 1 year. For channels that routinely contain sensitive data (customer support, security, incident response), set channel-level retention to 90 days with a documented business justification. In Slack Admin → Channel policies → Custom retention, configure per-channel. Add a pinned message in sensitive channels: "This channel has 90-day retention for data minimization. Do not share customer credentials here."

For SOC 2 Type II audits covering a 12-month period, ensure your retention policy is at least 12 months so that Slack data is available if auditors request communication evidence. If your policy is shorter, ensure you have a data export/archive solution (Slack Enterprise Grid or a third-party archiver like Aware or Smarsh) that retains messages beyond the live Slack retention window.

DLP and Content Controls

Slack does not include native DLP on Pro or Business+ plans. For DLP, integrate a third-party solution: Nightfall AI, Polymer, or Veriato. These tools scan Slack messages and files in real time for sensitive data patterns (credit card numbers, SSNs, Aadhaar numbers, API keys) and can quarantine, delete, or alert on violations. Configure your DLP tool to alert the security team when sensitive patterns are detected in Slack.

For Enterprise Grid, enable Slack's Data Loss Prevention integration via the DLP API. Configure DLP policies for file uploads: block uploading files named "passwords", "credentials", or matching patterns like `*.pem`, `*.key`. Create a Slack App with the `files:read` scope that scans uploaded files with your DLP engine and revokes files that match sensitive patterns.

Configure "Approved Apps" in Slack Admin → App Management → Restrict Slack app installations. Set "Require app approval from Slack admin before installation". Review pending app requests weekly and approve only apps that have been through your vendor assessment process. Unauthorized Slack apps can exfiltrate all messages visible to the user who installed them.

Slack Connect Security

Slack Connect allows external partners, vendors, and customers to communicate in shared channels. These channels are high-risk for SOC 2 because external participants who are not subject to your IdP controls can access the channel content. Navigate to Slack Admin → Slack Connect settings. Set "Who can send invites" to "Only workspace owners and admins". Disable "Allow members to accept invitations from external organizations without admin approval".

For existing Slack Connect channels, conduct a quarterly review: navigate to Admin → Slack Connect → Manage external connections. Review each channel for necessity, verify external members are still current employees of the partner organization, and revoke inactive connections. Document this review. Slack Connect channels that contain customer data or incident details are particularly sensitive — consider banning these use cases via policy.

Admin Controls and User Management (CC6.2)

Limit Slack workspace owners to 2–3 individuals. Workspace owners have unrestricted access to all channels, messages, and files — this is a high-privilege role. Navigate to Admin → People → [user] → Change role. Additional admins should be Workspace Admins (can manage members but not view private channels) rather than Owners. Document the Owner list and review it quarterly.

Enable user provisioning via SCIM. With SCIM, your IdP (Okta or Azure AD) manages Slack user accounts automatically. When a new employee is onboarded in your IdP, they are automatically added to Slack and assigned to the appropriate user groups (channels). When an employee is offboarded, their Slack account is deactivated within minutes of IdP deactivation. This eliminates the risk of former employees retaining Slack access.

Audit Log Evidence (CC6.3)

Slack's Audit Logs API (available on Enterprise Grid) records administrative actions: user invitations, role changes, channel creation/deletion, app installations, and authentication events. Access via `GET https://api.slack.com/audit/v1/logs?action=user_login&oldest=[timestamp]`. Export monthly to your compliance platform or S3. Key events for SOC 2: `user_login`, `user_logout`, `user_deactivated`, `role_change_to_admin`, `app_approved`, `channel_archive`.

For non-Enterprise Grid plans, Slack provides a basic Workspace Export that includes all public channel messages, but not private channel messages or DMs. Navigate to Admin → Import/Export Data → Export. This export is useful for demonstrating retention policy compliance but is less useful for access control evidence. Supplement with Okta/Azure AD authentication logs that show Slack SSO events for access evidence.