incident.io SAML SCIM: How private incidents and access controls work together

TL;DR: Security leaders evaluating the incident.io Enterprise or Pro plan can secure sensitive data and automate compliance evidence using SAML and SCIM integrations. The platform supports role-based access control (RBAC); private incidents in Slack are isolated through direct invitation, team membership, or the org-wide "Manage private incidents" permission. This helps prevent unauthorized PII exposure during active breaches and generates audit logs designed to support SOC 2 Type II evidence requirements, eliminating the dozens of hours security teams typically spend on manual log reconstruction per audit cycle. While legacy tools rely on manual channel management, the platform aims to automate isolation at scale, so your team responds faster without creating new compliance gaps.

Identity provisioning is treated as an onboarding checklist item far too often. During a P0 security incident, your SAML and SCIM configurations are the only things standing between containment and a regulatory compliance failure. When a breach fires an automated alert, the last outcome you want is a public Slack channel where hundreds of engineers can see exposed customer PII while you are still triaging scope.

This guide explains how we integrate with identity providers like Okta and Microsoft Entra ID via SAML and SCIM to enforce granular RBAC. SAML and SCIM establish the role and permissions layer, including who holds the "Manage private incidents" permission; private incident access itself is then granted through direct invitation or team membership at declaration time. These controls prevent unauthorized PII exposure and automatically generate immutable audit logs for SOC 2 Type II compliance, so your team responds faster without creating new compliance gaps.

Mapping SAML roles to private incident access

SAML authentication in incident.io does more than verify identity at login. It serves as the foundation for determining who can view, join, and take action on any incident, including the sensitive ones that must stay restricted to a defined group of responders.

How SAML authentication establishes identity

We use WorkOS to provide SAML, mapping users by ID and email address. When a user authenticates, the SAML assertion carries identity and group membership data into incident.io, where that data feeds the RBAC model.

Configuration follows this sequence:

1. Navigate to Settings, then Security, and click Connect.
2. Choose your identity provider from the list (Okta or Microsoft Entra ID are explicitly supported; consult the SAML SSO documentation to confirm current provider availability before completing setup).
3. Follow the setup instructions and configure which user email domains authenticate through SAML.

The SAML SSO documentation covers domain verification and identity provider connection setup. To maintain access during an identity provider outage, the SAML migration guide recommends enabling email sign-in as a fallback before you need it.

Enforcing RBAC with SCIM

SCIM handles the ongoing synchronization of who belongs to which group and which permissions that group carries in incident.io. While SAML authenticates at login, SCIM is where group-to-role mapping lives and where permission changes propagate.

According to our SCIM provisioning documentation, when you install SCIM, the platform links existing users to SCIM users and updates their permissions according to your configured group-to-role mappings. If a user was previously assigned an elevated role and is no longer a member of the groups assigned that role, the system adjusts their access accordingly. Once SCIM is active, your identity provider governs permissions, reducing ad-hoc manual override risk.

One important edge case to plan for: when a user is deactivated in your IdP, a SCIM deprovisioning request is sent that deactivates their incident.io web UI access. However, as our application runs both in Slack and on our web dashboard, it's possible that a user can be deactivated in your IdP but still be an active member of your organization's Slack workspace. If this happens, the user will be treated as 'active' until they're deactivated in Slack.

We recommend managing Slack users through the same IdP as incident.io to keep both synchronized and close this gap.

How IdP groups map to incident roles

Specific IdP groups map to specific incident roles, ensuring only authorized personnel can assume critical responsibilities during a crisis. Organizations typically configure role assignments so that engineers who are not explicitly mapped to an elevated group cannot interact with or view restricted incidents.

Example group-to-role mappings that organizations commonly configure:

• Security operations group: mapped to elevated roles, granting incident creation and severity assignment capabilities.
• Engineering on-call group: mapped to responder roles, granting /inc command access during active incidents.
• Compliance team group: mapped to custom roles with appropriate access to incidents containing sensitive data. This group-based structure makes your IdP the single source of truth for authorization, replacing a manually maintained list inside incident.io that someone has to update every time an engineer changes teams. The changelog entry on role assignment explains how groups are automatically provisioned and assigned appropriate base or custom RBAC roles.

Granular RBAC enforcement in incident workflows

The sections below cover how those role assignments are configured and where they take effect across the incident workflow. Once SAML and SCIM establish the role structure, we enforce those roles consistently across every layer of the incident workflow: the web dashboard, Slack channel interactions, and timeline access.

Configuring group-to-role mappings in SCIM

During initial configuration, you define the mapping logic that governs role assignment for every future incident. The Okta SCIM group setup documentation walks through creating the Okta application, configuring push groups, and mapping SCIM groups to roles using the "Add assignment" workflow in our settings page.

This automation prevents the human error that surfaces during high-stress P0 incidents. Without it, a tired on-call engineer might manually grant channel access to someone who should not have it, a decision that can compromise incident containment and create a compliance gap that takes days to reconstruct.

Dashboard and timeline access controls

At the dashboard level, private incident visibility follows the same three-mechanism model as Slack: direct invitation, team membership, or the org-wide "Manage private incidents" permission. According to our sensitive incidents documentation, when an incident is marked private, it remains visible only to explicitly invited team members.

Slack workspace admins and users holding the "Manage private incidents" permission retain access to all private incidents, but the broader engineering organization cannot view the incident, its timeline, or any associated metadata.

A security engineer in the Security-Ops group, authenticated via SAML and provisioned via SCIM, sees private incidents they have been directly invited to, belong to an invited team for, or can access because they hold the "Manage private incidents" permission. A software engineer in a product group sees only the standard operational incidents; they have no access to private incidents unless they are explicitly invited at declaration time or added to an invited team.

This dashboard-level segregation supports SOC 2 logical access restriction requirements, giving auditors a clear view of which roles can see which incident types without requiring manual access list reconstruction. Our security overview page documents the full certification scope.

Slack channel membership controls

In the Slack-native interface, group membership controls which users can execute /inc commands within a private incident channel. We typically require privileged Slack access to create and manage private channels, and the Slack admin setup documentation covers how to configure that dedicated Slack connection for incident.io. Private incident channels require a privileged Slack connection tied to a Workspace Owner account, and our privileged access help article explains what those permissions cover.

Standard vs. private incident access matrix:

The table below illustrates how different organizational groups might be configured to access standard and private incidents. Private incident access is determined by direct invitation, team membership, or the "Manage private incidents" permission, not automatically assigned by SCIM role. The mappings below reflect how teams are typically configured, not automatic SCIM-driven isolation. Actual permissions depend on your SCIM group-to-role mappings.

"The Incident Workflows - The tool significantly reduces the time it takes to kick off an incident. The workflows enable our teams to focus on resolving issues while getting gentle nudges from the tool to provide updates and assign actions, roles, and responsibilities." - Carmen G. on G2

Limiting PII exposure through incident isolation

Private incidents are designed for situations where broader engineering visibility creates data exposure risk: security breaches, suspected account compromises, HR-related incidents, or cases involving customer PII. The isolation mechanism is automatic and enforced either at the moment of declaration or at any later point during the incident's lifecycle.

Enforcing access via SAML and SCIM

When a responder declares an incident as private, we create a private Slack channel. A private incident is visible only to users who are directly invited, belong to an invited team, or hold the org-wide "Manage private incidents" permission. You can declare an incident private from the start or convert a public incident to private mid-investigation. This flexibility matters because the nature of an incident is not always clear at the first alert: a performance degradation can reveal signs of data exfiltration mid-investigation.

SCIM's role is to keep team membership and the "Manage private incidents" permission assignment current and synchronized with the IdP. When your IdP updates a group that maps to an incident.io team or role, SCIM propagates that change automatically, ensuring the right people have the right access without manual intervention. This automated synchronization is what makes the isolation enforceable: your IdP remains the single source of truth for who belongs to which team and which users hold elevated permissions.

The privileged Slack access connection makes this isolation enforceable without relying on a Slack administrator to manually lock down a channel during a live incident, which is exactly the kind of bottleneck that costs containment time when every minute of delay expands regulatory exposure.

Example: Compliance team access configuration

A concrete configuration example: you create a compliance administrators group in Okta containing your CISO, legal counsel, and head of compliance. You map that Okta group to an incident.io Catalog team using SCIM-driven catalog management. This keeps the team roster current in incident.io's Catalog automatically as your IdP group membership changes.

The Catalog team is used for alert routing and automation; it does not itself grant private incident access. When P0 or P1 incidents involving financial data or regulatory exposure are declared private, the responder invites the Compliance-Admins team directly during declaration, or a pre-configured workflow invites it automatically. Users in this group who hold the "Manage private incidents" permission will have access to all private incidents regardless of invitation.

Because the Catalog team stays synchronized with your Okta group, any responder inviting the Compliance-Admins team to a private incident will always reach the current roster without manual list maintenance. The external memberships guide covers teams whose membership is maintained outside incident.io's direct management.

Preventing PII leakage with RBAC

When a breach is detected, the operational sequence matters. Declaring a private incident immediately restricts the communication channel, the timeline, and all associated investigation data to the authorized group before any PII is referenced in a message. Here is the sequence for a data egress scenario:

1. On-call security engineer receives a P0 alert from your monitoring system.
2. Engineer runs /inc declare in Slack and marks the incident as private.
3. A private Slack channel is created; only users directly invited by the responder, members of an invited team, or users holding the "Manage private incidents" permission can access it.
4. Alert details, including any referenced customer records, appear only inside the private channel.
5. The timeline begins capturing automatically from declaration, creating the audit record from the first action.

Granular permissions should extend beyond Slack channel access to the integrations associated with the private incident. When properly configured, Jira tickets and post-mortem drafts generated from private incidents can maintain the same access boundaries as the channel itself, creating a closed evidence loop where the entire incident artifact remains within the authorized access boundary.

This is the architectural difference between RBAC synchronized at the identity layer versus RBAC managed through manual Slack permissions. SCIM keeps team rosters and the "Manage private incidents" permission assignment synchronized with the IdP: automated and auditable. The responder or a configured workflow then invites the relevant team to the private incident: explicit and intentional.

The identity layer ensures the right people are always in the right teams; the invitation step ensures only the teams that need access to a specific incident receive it. Manual Slack permissions, in contrast, depend on someone remembering to lock the channel at 2 AM while simultaneously trying to contain a breach.

Compliance-ready logs for sensitive cases

We capture access attempts, channel views, and timeline modifications for private incidents in the audit log. According to the audit logs documentation, these entries cover configuration changes as well as changes to a user's permissions, including access grants to private incidents. Logs are available for export as CSV or for streaming into SIEM providers.

Vanta, a compliance platform whose own business depends on getting compliance right, uses incident.io to generate this evidence automatically. According to the Vanta case study, Vanta automated a manual five-step incident process and now alerts the right people within minutes, freeing the team to focus on substantive compliance work instead of coordination overhead.

Automated evidence collection for SOC 2

Proving incident access controls to a SOC 2 auditor costs security teams dozens of hours of manual log reconstruction per audit cycle when tooling does not capture evidence automatically. We aim to eliminate that overhead by making timeline capture a default behavior, not an optional add-on.

Generating immutable incident audit logs

The audit log feature captures configuration changes and user permission changes in a record available for export via the web dashboard or queried through the API for SIEM ingestion. According to the audit logs documentation, each log entry includes actor identity, timestamp, and the specific action performed.

The audit logs documentation provides the full schema for programmatic ingestion, allowing your SIEM to ingest incident.io audit events alongside other security telemetry.

Mapping access controls to SOC 2 requirements

incident.io's SOC 2 Type II report covers the Security, Availability, and Confidentiality Trust Service Categories. The audit log and SCIM provisioning workflow generate evidence that supports access control, authorization, and monitoring requirements within those categories: SCIM group mapping enforces role-based access at provisioning, SCIM group changes and IdP deprovisioning drive access updates, and audit logs capture access attempts and configuration changes.

Showing an auditor a clear mapping of SAML/SCIM roles to incident access, backed by exportable log entries, satisfies access control evidence requirements without manual reconstruction from Slack exports or screenshot archaeology.

Immutable audit logs for private incidents

Private incidents generate audit log entries that can be reviewed to verify access controls. An auditor reviewing access controls for a sensitive incident can verify that only authorized group members accessed the timeline, without seeing the underlying incident content. This separation lets you prove control effectiveness to auditors while maintaining the confidentiality of the incident's substantive details, a distinction that matters when the incident involves an executive account compromise or an HR matter.

We are SOC 2 Type II certified and GDPR compliant, with AES-256 encryption at rest. The full certification details, including the SOC 2 Type II report and penetration test results, are available at the incident.io Trust Center.

Deploying role-based access for secure workflows

The steps below walk through configuring SAML and SCIM in the two most common identity providers, setting up isolation for private incidents, and building a repeatable audit process.

Enforcing RBAC via SAML attributes

Configure SAML in Okta:

1. Create a SAML 2.0 application in the Okta Admin Console.
2. Set the Single Sign-On URL and Audience URI from incident.io Settings > Security.
3. Add attribute statements mapping email, firstName, lastName, and groups.
4. Assign the application to your Security-Ops, On-call-Engineers, and Compliance-Admins groups.
5. Complete domain verification in incident.io Settings > Security.

Configure SAML in Microsoft Entra ID:

1. Create an Enterprise Application in the Entra ID portal.
2. Configure Single Sign-On using SAML and input the reply URL from incident.io Settings > Security.
3. Add security group claims to the SAML token configuration.
4. Assign the application to the relevant Entra ID groups.
5. Complete domain verification in incident.io Settings > Security.

Configuring SCIM for role mapping

Okta SCIM setup:

1. In incident.io, navigate to Settings > Integrations and search for Okta.
2. Click Connect in the automatic user provisioning section to launch the SCIM directory sync flow, powered by WorkOS.
3. Create the Okta app and configure push groups correctly.
4. Return to incident.io Settings and click "Add assignment" to map SCIM groups to incident.io roles.

Microsoft Entra ID SCIM setup:

1. Open the Enterprise Application created during SAML setup.
2. Click Provisioning, then Get started, and set Provisioning Mode to Automatic.
3. Copy the SCIM Base Connector URL from incident.io into Tenant URL and the Access Token into Secret Token.
4. Click Test Connection, then Save, and configure attribute mappings and group assignments.

The SCIM help documentation notes that providers are evaluated to ensure they send correct group membership updates. If your provider returns an unsupported message, contact us before deploying in production.

Enforcing isolation for sensitive incidents

Pre-deployment checklist for private incidents:

• Connect incident.io via privileged Slack access (Settings > Slack integration > Privileged access)
• Create "Compliance-Admins" and "Security-Ops" groups in your IdP
• Map both groups to corresponding incident.io teams in SCIM settings to keep team membership synchronized
• Configure private incident rules: set P0 and P1 security incident types to default to "Private"
• Run a private incident drill: invite the Compliance-Admins team during declaration and confirm only invited team members and users with the "Manage private incidents" permission can access the channel and timeline
• Verify that non-authorized engineers see the incident listed but cannot access the channel or timeline
• Export a test audit log entry and confirm the field structure matches your SOC 2 evidence requirements
• Configure SIEM streaming (Datadog, Splunk, or AWS S3) for continuous log ingestion

Auditing SAML SCIM authorization enforcement

Build a quarterly review process around three core steps:

1. Export and cross-reference: Export the audit log for the review period and cross-reference SCIM group assignments against the current state of your IdP groups to confirm no drift has occurred between what the IdP holds and what incident.io reflects.
2. Test deprovisioning: Deactivate a test user in your IdP and confirm that their incident.io web UI access is revoked immediately, then verify that Slack access is also revoked if your IdP manages Slack provisioning via the same directory.
3. Verify integration health: Confirm the Slack privileged access connection remains active and that no workspace changes have interrupted private channel management.

Modifications to SAML mappings, SCIM configurations, and manual role overrides should be captured in the global audit log, which you can export via the web dashboard (CSV) or query through the audit logs documentation for SIEM ingestion.

Security architects evaluating the Enterprise or Pro plan can watch the incident.io how it works demo and the full platform walkthrough to see the Slack-native response lifecycle and web dashboard configuration in action. Book a demo to see private incident workflows and SAML/SCIM role mapping running against sample provider configuration.

Key terms glossary

Private incident: An isolated incident workflow in incident.io that restricts visibility and Slack channel access to users who are directly invited, belong to an invited team, or hold the org-wide "Manage private incidents" permission.

SCIM provisioning: An industry-standard protocol (System for Cross-domain Identity Management) that automates the exchange of user identity data between identity providers and service providers like incident.io.

SAML assertion: A cryptographically signed document sent by an identity provider to incident.io that communicates user authentication status and group membership attributes.

Immutable audit log: A tamper-proof, read-only record of actions, decisions, and access changes captured during incidents and configuration management.

RBAC (role-based access control): An authorization model where access to resources is determined by roles assigned to a user, with those roles often derived from IdP group membership.

SOC 2 Type II: An auditing standard that evaluates whether a service provider's security controls operate effectively over a defined period.

PII (Personally Identifiable Information): Data that can identify an individual, such as names, email addresses, or account details, requiring special handling during incidents.

SIEM (Security Information and Event Management): A platform that collects, analyzes, and correlates security event data from multiple sources for monitoring and compliance.

IdP (Identity Provider): A service that manages user identities and authentication, such as Okta, Microsoft Entra ID, or Google Workspace.

P0/P1 incidents: Priority-zero and priority-one incidents representing the most critical severity levels requiring immediate response.