incident.io SOC 2 compliance: What's certified, how controls work, and what auditors need to know

TL;DR: incident.io holds an active SOC 2 Type II certification. Our Slack-native platform automates incident response workflows and captures structured, exportable evidence from every incident, eliminating the need to reconstruct timelines from fragmented tools. Private incidents, SAML SSO (Pro and above), SCIM-based role provisioning (Enterprise), and EU data residency in Belgium keep your sensitive workflows protected. Request our SOC 2 Type II report and full security packet through our Trust Center.

When a vendor security questionnaire asks how you secure incident data, "trust us" isn't an acceptable answer. This guide lays out incident.io's exact SOC 2 Type II certification scope, the specific controls we cover, and how our platform turns every incident into structured, audit-ready evidence, so your compliance team can complete their vendor review with documentation rather than assertions.

Understanding incident.io's current SOC 2 Type II status

Here's what our certification covers and how we maintain it.

SOC 2 Type II certification details

incident.io is fully SOC 2 Type II certified, and our Trust Center provides direct access to the SOC 2 Type II report, penetration test results, and automated infrastructure checks.

Our security FAQs documentation provides additional technical detail on each control domain for teams conducting a formal vendor risk assessment.

SOC 2 audit cycle and timing

A SOC 2 Type II audit requires an auditor to observe your controls operating over a defined period, typically 3 to 12 months depending on your organization's testing cadence. We use Vanta to automate continuous compliance monitoring against our SOC 2 control requirements, surfacing exceptions before they become audit findings.

After integrating Vanta, we wrote policies and completed audit preparation for our first SOC 2 audit in approximately two to three weeks. Contact help@incident.io or visit our Trust Center to confirm the current report's observation window dates.

ISO 27001 and additional certifications

We hold SOC 2 Type II certification today. If ISO 27001 is a requirement for your procurement process, contact our compliance team at help@incident.io to discuss your specific needs before starting your proof of concept.

Defining the incident.io SOC 2 Type II boundary

Here's a precise breakdown of what the audit covers, how our system is scoped, and which product features fall within the certified boundary.

Scope of SOC 2 trust criteria

Our SOC 2 Type II certification covers the controls governing our logical access (SAML SSO, SCIM provisioning, private incidents, RBAC), network security, and change management processes, as well as our infrastructure redundancy, backup procedures, and our 99.9% platform availability SLA (99.99% for Enterprise on-call notification triggering). It also covers how we handle customer incident data, AI-processed content, and sub-processor relationships, including the Zero Data Retention agreements we hold with OpenAI and Anthropic.

incident.io SOC 2 system boundaries

Our primary application, Slack integration, and related components run on Google Cloud Platform, with transactional data hosted in GCP's Belgium region (europe-west1). We use AES-256 encryption at rest. Our security architecture includes the application layer, database layer, infrastructure configuration, and our Slack and Microsoft Teams integration surfaces.

incident.io SOC 2 Type II coverage

Our SOC 2 certification supports all core product features:

• On-call scheduling and alert routing
• Incident response coordination (Slack-native and web dashboard)
• Status page management
• Post-mortem generation and timeline capture
• Investigations (our AI SRE product) and Scribe (call transcription)
• Audit log retention and export (Enterprise plan, 12-month retention)

SOC 2 Type II certification and GDPR compliance support all plan tiers. Access controls like SAML SSO, private incidents, and audit log exports require specific plan tiers, which we detail in the controls section below.

Aligning incident.io controls with SOC 2 requirements

The table below maps our specific features to SOC 2 control categories, giving your compliance team a structured reference for their vendor assessment.

Enforcing SSO and SCIM-based access controls

Organizations on our newer Pro plans and Enterprise can enable SAML SSO to manage dashboard access through their identity provider. SCIM provisioning is available on our Enterprise plan, giving identity providers central control over user access and automated deprovisioning. SCIM reduces manual access revocation overhead when engineers change roles or leave the company, supporting user access review requirements under SOC 2 logical access controls.

The full platform walkthrough shows how incident roles are assigned and enforced during a live incident, and how RBAC separately governs account-level access such as settings, billing, and private-incident visibility. For a full breakdown of what each permission controls, including private incident access, data erasure, and settings management, see our user permissions documentation.

Automating SOC 2 audit evidence

Every action taken inside incident.io, whether typed in Slack with an /inc command, triggered by a Datadog alert, or captured by Scribe during a call, writes to a structured timeline. This directly supports SOC 2 system operations controls, which require evidence that your incident response process detects, responds to, and recovers from incidents in a documented, repeatable way. Your auditors get a single, defensible evidence source rather than a manually reconstructed Slack export.

"The separation of functionality between Slack and the website is extremely powerful. This gives us the ability to have rich reporting and compliance controls in place without cluttering the experience and the workflow for the incident responders working to solve the incident during the live phase." - Joar S. on G2

Securing data at rest and in transit

We encrypt all customer data at rest using AES-256. GCP manages encryption key operations, with access controls restricting which service accounts and personnel can access production data stores. For a full breakdown of transport encryption and network security controls, see our security FAQs documentation.

Meeting SOC 2 evidence requirements

The operational problem for most security teams isn't whether their incident response process is documented: it's that documentation varies by team, by incident, and by whoever happened to take notes on a given shift. Auditors can't evaluate a process they can't observe consistently. incident.io enforces a single Slack-native workflow across every incident, capturing the same structured data points every time: who declared the incident, what severity was assigned, which roles were filled, what decisions were made, and when the incident resolved.

Accessing the incident.io SOC 2 Type II report

Here's how to request our report, what the full security packet contains, and what to focus on when your compliance team reviews it.

Requesting our SOC 2 Type II report

The process has three steps:

1. Visit the Trust Center at trust.incident.io and locate the SOC 2 data room request form.
2. Contact our compliance team at help@incident.io if you need to expedite the request for an active vendor review.
3. Sign a standard mutual NDA and receive secure access to the full SOC 2 Type II report, penetration test results, and automated infrastructure check summaries.

If your legal team requires a custom NDA template, our compliance team handles that through the same channel.

Accessing incident.io audit documentation

Our full security packet includes:

• SOC 2 Type II report (full auditor opinion, system description, and test results)
• Most recent penetration test summary from our independent third-party security firm
• GDPR Article 28 Data Processing Agreement
• Sub-processor list with data handling classifications
• Security architecture overview

You can access all documents through trust.incident.io immediately after signing the NDA. Our security FAQ documentation also answers common vendor questionnaire questions directly, which can accelerate your internal review.

Reviewing the SOC 2 audit report

When your compliance team reviews the report, focus on three sections:

• The system description: Confirms the audit boundary, infrastructure components, and the Trust Services Criteria in scope. Use this to verify our Belgium-region data hosting and GCP architecture.
• The controls and test results: Details each control, how it was tested, and whether it operated effectively over the observation period. Map these against your own CC requirements.
• The CUECs: Lists the controls your organization must implement for the overall control objective to be met (Linford & Co). User deprovisioning and access reviews are typical CUECs for our platform.

Accessing incident.io security documentation

Here's where to find our compliance documentation, how our security controls are validated, and how we manage sub-processor relationships.

Accessing the incident.io GDPR DPA

We offer a Data Processing Agreement governing how we process personal data on behalf of customers, as required under Article 28 of the GDPR. EU customers can execute the DPA through our Trust Center. Primary data hosting in GCP's Belgium region (europe-west1) means no customer data leaves Europe for EU-region customers, with a hot standby in the Netherlands providing redundancy. If your legal team requires DPA amendments or a sub-processor data transfer impact assessment, contact our compliance team directly.

Designing security controls and architecture

Our security program includes external penetration testing by an independent third-party firm, with penetration test summaries available through the Trust Center. Continuous vulnerability scanning runs against our GCP infrastructure, with findings tracked through our internal remediation program and verified in each SOC 2 audit cycle.

Validating security controls

Our controls aren't just checked annually by our external auditor. We monitor them daily via Vanta and receive immediate alerts when exceptions occur, surfacing issues before they become audit findings. Vanta uses our platform to automate their own incident response workflows. A compliance automation company trusting incident.io for their own incident management is a meaningful reference for security leaders evaluating vendor reliability.

Viewing the incident.io sub-processor list

Our key sub-processors include:

• Google Cloud Platform: Primary infrastructure, Belgium region
• OpenAI: AI processing for Investigations, under Zero Data Retention terms
• Anthropic: AI processing for Investigations, under Zero Data Retention terms
• WorkOS: Powers SCIM and SAML authentication flows

The complete, up-to-date sub-processor list is available through trust.incident.io. We update this list when we add or change sub-processors and notify customers under our DPA terms.

Mapping incident activity to control requirements

Here's how incident.io generates structured, auditor-ready evidence from every incident, and how to extract it for your review.

Automating audit-ready incident logs

Every /inc command, severity change, role assignment, and status update writes to a structured incident timeline automatically, with no action required from the incident lead or note-taker. The timeline captures the actor, target, and timestamp for each change.

This removes the largest source of SOC 2 audit preparation overhead for engineering teams: manually reconstructing what happened, when, and who authorized it from Slack scroll-back weeks after the incident closed. As one G2 reviewer from the computer software industry noted:

"When we were looking for a tool to improve the experience for both our incident response teams as well as for communicating effectively with management, incident.io came through on both counts." - Verified user on G2

Extracting SOC 2 audit logs

Audit logs are available on our Enterprise plan with 12 months of retention. Here's how administrators export them:

1. Navigate to Settings in the incident.io dashboard.
2. Select Security from the left navigation panel.
3. Filter the audit log view by target, event type, actor, or date range to scope your evidence package.
4. Export the filtered results for inclusion in your audit evidence package.

Full export instructions, including field definitions and filtering options, are in our audit logs documentation. Each entry records the actor, target, event type, and contextual details including location and user agent.

Completing the vendor security questionnaire checklist

Use this checklist to track your vendor security review progress:

• SOC 2 Type II report requested via Trust Center
• NDA executed and report access confirmed
• Penetration test summary reviewed
• GDPR DPA executed (EU customers)
• Sub-processor list reviewed and approved by legal
• SAML SSO configured with your identity provider (Pro or Enterprise)
• SCIM provisioning enabled for automated user lifecycle management (Enterprise)
• Private incidents enabled for sensitive security workflows (Pro or Enterprise)
• Audit log access confirmed and retention period verified (12 months on Enterprise)
• AI data handling reviewed: ZDR agreements with OpenAI and Anthropic confirmed
• EU data residency confirmed for Belgium-region hosting (EU customers)
• CUECs mapped to your internal controls

Protecting PII in incident workflows

A common concern for security-focused teams is the risk of a junior on-call engineer posting PII, customer account data, or breach details into a public Slack channel during a security incident. Private incidents address this directly.

When you declare a private incident using the /inc command in Slack, you set "Who should be able to see this incident?" to "Only invited users." From that point, access is strictly invite-only, granted through direct invitation, incident team membership, or the organization-wide "Manage private incidents" permission. The private incidents changelog details how team-scoped privacy controls extend this to group-level access management. Escalation notifications for private incidents include only a link to the dashboard, not the incident's content, so details stay restricted even as you page additional responders.

Private incidents are available starting on our Pro plan. Our sensitive incidents documentation covers the full access control model, including how Slack workspace admin overrides work and how to configure them correctly for your security policies.

For AI-processed content, our managing sensitive data documentation explains how automatic redaction removes sensitive data patterns from messages before they reach the OpenAI or Anthropic [REDACTED]APIs.

If your security review is active and you need to complete vendor due diligence this quarter, the fastest path forward is a technical demo where we walk your team through a simulated security incident using private incidents and show the audit log export in real time. Book a demo and we'll bring our compliance team to the call.

Key terms glossary

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

Trust Services Criteria (TSC): Control categories defined by the AICPA for SOC 2 audits, including Security, Availability, Processing Integrity, Confidentiality, and Privacy.

SCIM (System for Cross-domain Identity Management): An IETF-standardized protocol (RFC 7644, building on the RFC 7643 core schema) that enables identity providers to automatically provision and deprovision user accounts in connected applications.

Zero Data Retention (ZDR): A contractual agreement with an AI API provider ensuring inputs and outputs are not used for model training.

Complementary user entity controls (CUECs): Controls listed in a SOC 2 report that the customer (your organization) must implement for the overall control objective to be achieved.

GDPR Article 28 DPA: A Data Processing Agreement under Article 28 of the General Data Protection Regulation governing how processors handle personal data.