incident.io security whitepaper: architecture, encryption, and compliance controls

TL;DR: Security and compliance teams conducting technical reviews need assurance that vendor tools protect sensitive data. This whitepaper details the security architecture of incident.io, including AES-256 encryption at rest, TLS encryption in transit, and logical data isolation. We enforce least privilege through SAML and SCIM, allowing you to isolate sensitive security incidents from the rest of your organization. Our AI features, Scribe and Investigations, never train on your data. With SOC 2 Type II compliance and GDPR-aligned data residency, incident.io secures your incident response while automating audit evidence collection.

When a P0 security incident hits, the last thing you need is to spend minutes piecing together who's on call while sensitive breach details risk leaking into a public Slack channel. We built incident.io to eliminate that exposure through strict architectural controls: AES-256 encryption at rest, TLS encryption in transit, SAML-enforced access isolation, and zero-data-retention AI agreements.

This whitepaper gives you the technical specifications you need for a formal vendor security assessment, covering infrastructure architecture, encryption, identity management, AI compliance, audit logging, and penetration testing.

incident.io platform security foundations

incident.io is a Slack and Microsoft Teams native incident management platform serving more than 1,200 companies, including Netflix, Etsy, and Vanta. We don't bolt security on after the fact. We build it into the core architecture through least privilege access, logical data isolation, automated audit logging, and clear AI data boundaries.

We provide four core security capabilities:

• Role-based access control: Tiered default roles that build on each other, with role assignment automated via SCIM. Contact our team for current role tier names and permissions.
• Private incidents: Invitation-only access with no visibility to uninvited users, enforced at the Slack channel level.
• Immutable audit logs: Automatic capture of every configuration change and permission modification.
• Identity integration: SAML and SCIM support for centralized provisioning with Okta, Microsoft Entra ID, and Google Workspace.

The platform captures a structured, timestamped record of every incident action automatically, so your team produces audit-ready evidence as a by-product of running incidents, not as a separate manual task. The Vanta case study illustrates this in practice: Vanta automated a manual five-step incident process and now alerts the right people within minutes, with every incident producing a complete timeline that satisfies their own compliance platform's rigorous standards.

We encrypt all customer data using AES-256 at rest, and store structured incident data (timelines, post-mortem fields, decisions) in our own secured infrastructure, separate from Slack's. Our data management documentation covers redaction, erasure, and retention configuration in full.

Architecting for secure incident response

The following sections cover how incident.io's infrastructure is designed to keep incident data isolated, traceable, and recoverable.

Cloud hosting and infrastructure security

incident.io runs on Google Cloud Platform (GCP) using Kubernetes for container orchestration and Terraform for infrastructure as code. We use GCP's managed services for databases, with multi-region redundancy by design.

Architecture for secure data isolation

Many security teams get concerned about a Slack-native tool for exactly the right reason: if the incident management platform lives in Slack, does sensitive data live in Slack's infrastructure? The answer is no, and the architecture makes that explicit.

incident.io captures data from Slack via APIs, then processes and stores structured incident data (timelines, post-mortem fields, decisions, access logs) in our own secure, encrypted database. The Slack channel serves as the collaboration interface, but we store the permanent record on incident.io infrastructure subject to SOC 2 controls. We logically isolate customer data and enforce strict access controls at the application layer.

For EU customers, we host transactional data processing in a dedicated EU cloud region, with an additional hot standby in a secondary EU region. To configure specific data residency requirements, work directly with our team during onboarding.

Mapping incident data flows

When a Datadog or Prometheus alert fires, the data flow works as follows:

1. The alert reaches incident.io's API endpoint over encrypted TLS.
2. incident.io creates a dedicated Slack channel and pages on-call responders.
3. We capture all responder actions within that channel (role assignments, status updates, decisions) via the Slack API and write them to our encrypted database.
4. We send structured data to integrations with Jira, Linear, or Azure DevOps over authenticated, encrypted API connections.
5. We update the status page automatically and record every action in the audit log with a timestamp and actor identity. We route telemetry through incident.io's application layer and into your encrypted incident record.

System resilience and recovery protocols

We operate under a 99.99% uptime SLA on the Enterprise plan, with multi-region redundancy. We support 1,200 API requests per minute and maintain high availability across alerts, on-call, and status page functions.

Protecting customer data at rest and transit

The sections below detail the encryption standards and key management practices that apply to all customer data within incident.io.

AES-256 storage for incident data

We encrypt all customer data at rest using AES-256, the same standard used by financial institutions and government agencies. We manage encryption keys through GCP's secret management infrastructure.

TLS protocols and cipher standards

We encrypt all data in transit using strong, industry-standard TLS protocols, with insecure SSL/TLS versions disabled across all endpoints. Review our full TLS configuration through our Trust Center.

Automated secret rotation protocols and secure data disposal

We manage API keys, database credentials, and encryption keys through GCP's secret management infrastructure. When a customer requests data deletion under GDPR's right to erasure, we replace the original content with a placeholder value and log the erasure event (including who performed it and when) in the audit log.

We log rotation events in the audit trail, giving you a documented record of every credential lifecycle event. For details on our internal access controls and secret management practices, request our security documentation through the Trust Center. Our sensitive data management documentation details the full erasure workflow and the automated redaction tools available to prevent sensitive data from entering the platform in the first place.

Enforcing least privilege for incident response

The following covers how incident.io controls who can access what, from authentication through to incident-level visibility.

Managing authentication with SAML/SCIM

We provide SSO via SAML on Enterprise and newer Pro plans, integrating with Okta, Microsoft Entra ID, and Google Workspace. Because SAML routes authentication through your identity provider, your existing MFA policies apply to incident.io access without requiring a separate authentication layer.

SCIM provisioning automates the full user lifecycle. When you assign a user in Okta or Entra ID, we create their account and assign the appropriate RBAC role automatically. When you deprovision a user in your identity provider, incident.io access is revoked, with no manual step required. SCIM and SAML work together so provisioning, role assignment, and authentication all flow from your identity provider as a single source of truth. Detailed configuration guidance lives in our SAML/SCIM security documentation.

Isolating sensitive security incidents

We use private incidents as the primary mechanism for containing sensitive security events, including suspected breaches, zero-days, and executive-account compromises, away from the wider engineering organization.

We restrict private incidents to invitation only. Only users in the incident's private Slack channel can see it exists. incident.io Workspace owners and Slack Workspace owners retain oversight access for compliance purposes, but the broader engineering team sees no channel, no alert, and no incident record. A practical P0 workflow looks like this: a security alert fires, we auto-create a private Slack channel, and we show the incident record only to the responders you have invited.

MFA requirements and session controls

Because SAML routes authentication through your identity provider, your existing MFA policies govern incident.io access. Administrators can configure session duration limits to prevent unauthorized access from unattended devices. We also support IP allowlisting for network-level access control, documented in our IP allowlist guide.

How incident.io simplifies audit evidence collection

Manually piecing together Slack exports, alert logs, tickets, and call transcripts can cost dozens of hours per audit cycle. We eliminate that overhead by capturing every action automatically into a structured, immutable timeline throughout the incident. For Vanta's team, that means every incident automatically produces a complete, structured timeline that maps directly to their own compliance platform's evidence requirements: no manual assembly, no post-incident archaeology.

"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

Audit logs and evidence export

We write every incident action (role assignment, severity change, timeline update, configuration modification, and data erasure) to an immutable audit log with a timestamp and the authenticated identity of the actor. For details on vendor-side access logging and incident.io operator access controls, request our security documentation through the Trust Center.

We export audit logs via CSV export or programmatic access through the Audit Logs API, which supports up to 1,200 requests per minute. You can pipe incident.io audit data directly into your Security Information and Event Management (SIEM) system (Datadog or Splunk) in real time rather than extracting evidence manually during audit preparation.

For each incident, you can export a complete evidence package including the full timeline, every role assignment, all chat messages from the incident channel, action items, and the auto-drafted post-mortem. This package maps directly to control evidence requirements for SOC 2 Type II, ISO 27001, and GDPR incident response documentation.

Configuring retention and vendor auditing

Customers configure custom data retention windows through the admin dashboard, aligned with their internal compliance policies. When a retention window expires, we log the deletion event, giving you documented, repeatable evidence of data lifecycle management for auditors. Audit logs can route directly to Datadog for centralized SIEM oversight. For details on vendor-side access logging and incident.io operator access controls, request our security documentation through the Trust Center.

Validating security controls via threat testing

The sections below outline how incident.io tests and continuously monitors the controls described in this whitepaper.

Annual penetration testing program

We conduct annual third-party penetration tests with the full executive summary available via our Trust Center. An independent third-party firm conducted our most recent engagement, covering both our web application layer and API endpoints. Enterprise plan customers can request the executive summary directly through their Customer Success Manager.

Vulnerability scanning and dependency management

We run continuous static analysis (SAST) and dynamic analysis (DAST) on every code change, with weekly scans checking against common vulnerability patterns including the OWASP Top 10. Critical findings trigger immediate remediation workflows. We monitor third-party dependencies using automated tooling and apply security patches according to risk-based SLAs, with critical vulnerabilities prioritized and tracked through our engineering backlog. We verify database backup integrity through automated restoration tests on a regular schedule.

Securing AI workflows for incident response

Unexplained AI is itself a compliance red flag. Here is exactly how our two AI products, Investigations and Scribe, handle your data.

Investigations and Scribe: data handling

Investigations is our AI SRE product. It analyzes telemetry, code changes, and past incident history to identify root causes, automating up to 80% of incident response. We process your data in isolated, encrypted environments using the same AES-256 at-rest encryption standards as the rest of the platform.

Scribe is our real-time call transcription feature. We process audio in encrypted transit, store transcripts under the same AES-256 encryption as all other incident data, and delete temporary processing artifacts immediately after generating the summary. If a responder accidentally transcribes sensitive information, you can delete the transcript from the dashboard, removing it from Slack, Microsoft Teams, and our database simultaneously.

AI data retention standards and third-party agreements

We hold contractual commitments with all AI sub-processors that prohibit storing inputs or outputs and prohibit using your data for model training. This is a contractual commitment, not an informal policy.

On top of this, you can enable automatic redaction that strips sensitive patterns (Personally Identifiable Information (PII), credentials, internal system names) from messages before they reach any AI model. We run redaction inside incident.io's infrastructure before data leaves our environment. Our AI sub-processor agreements mandate audit rights and no model training on customer data. The full sub-processor list is accessible through our Trust Center.

Verifying control effectiveness and compliance

The following details incident.io's current certification status, active compliance frameworks, and the documentation available to support your vendor assessment.

Compliance framework status

We maintain an active SOC 2 Type II certification with annual renewals, covering security, availability, and confidentiality trust service criteria. We're working toward ISO 27001 certification. If ISO 27001 is a hard requirement for your vendor assessment, our compliance team can walk you through the current control implementation and timeline.

We comply with GDPR and provide a standard Data Processing Agreement incorporating Standard Contractual Clauses as required under GDPR Article 28. The DPA covers our obligations as a data processor, sub-processor disclosure, breach notification timelines, data deletion obligations, and audit rights.

Supported geographic hosting regions and sub-processors

We host EU customer transactional data in a dedicated EU cloud region, with a hot standby in a secondary EU region. We pin all incident data, including backups and replicas, to the selected region. We do not replicate EU customer data to US infrastructure. Contact our team for the specific hosting region details applicable to your configuration.

We publish our sub-processor list through the Trust Center. Every sub-processor undergoes a security review before onboarding, covering compliance certifications, data handling practices, and breach notification commitments. We notify customers before adding new sub-processors.

"We use incident.io at our company and their customer service is amazing. They were incredibly attentive and responsive to our needs. When we required capabilities beyond their initial scope, they didn't turn us away. Instead, they collaborated with their engineering team to develop the necessary solutions." - Michael A. on G2

For security teams that want to verify these controls before approving incident.io as an enterprise vendor, the fastest path is a live technical demo where we walk through a simulated private incident, the SAML/SCIM configuration, and an exported audit log that maps directly to SOC 2 control evidence. Book a demo with our security engineering team.

Key terms glossary

Private incidents: A feature that restricts visibility and access to sensitive security incidents to authorized users only, enforced at the Slack channel level. incident.io and Slack Workspace owners retain oversight access for compliance purposes.

Scribe: Our AI-powered call transcription and decision-capture tool that operates under contractual data protection commitments with all AI sub-processors, with transcripts encrypted at rest and temporary processing artifacts deleted immediately after summary generation.

Investigations: Our AI SRE product that analyzes telemetry and code changes to identify root causes, automates up to 80% of incident response, and never trains on customer data, with contractual commitments from all AI sub-processors prohibiting model training on customer inputs.

SCIM provisioning: System for Cross-domain Identity Management that automates user lifecycle and permission management via your identity provider, including automatic account creation, role assignment, and deprovisioning.

SAML SSO: Security Assertion Markup Language Single Sign-On that routes authentication through your identity provider, allowing your existing MFA policies to govern incident.io access without requiring a separate authentication layer.

Immutable audit log: A tamper-evident record of every incident action, permission change, and configuration modification, exportable via CSV or accessible programmatically through the Audit Logs API, for external SIEM ingestion or direct use as SOC 2 control evidence.

Data residency: The ability to pin all customer data storage and processing to a specific geographic region (either a dedicated EU region for EU customers or a US region), configured at tenant onboarding and documented in the Data Processing Agreement.