incident.io GDPR compliance: Data processing agreement, data residency, and privacy controls

TL;DR: incident.io provides a GDPR-compliant incident management platform that satisfies strict EU data protection requirements. We offer an Article 28 Data Processing Addendum (DPA) and dedicated EU data residency with primary hosting in Belgium and a hot standby in the Netherlands, ensuring no customer data leaves Europe for EU-region customers. With role-based access control, SAML provisioning (Pro and Enterprise plans), and private incident workflows, security teams can isolate sensitive data inside Slack. Our AI features operate under data handling agreements with OpenAI and Anthropic.

Disclaimer: This guide is for informational purposes only and does not constitute legal, regulatory, or compliance advice. GDPR obligations vary by organization, data type, and jurisdiction. Consult qualified legal counsel before relying on any information in this guide for compliance decisions.

During a P1 incident, your engineers focus on resolution while security and compliance teams face a parallel risk: PII scattered across Slack channels, an incomplete incident timeline, and an audit package that will cost dozens of hours to reconstruct manually. This guide details how incident.io satisfies GDPR Article 28 and Article 32 requirements through a documented DPA, strict EU data residency architecture, and granular privacy controls.

GDPR Article 28: incident.io DPA template

GDPR Article 28 requires every data controller to engage only data processors that provide sufficient guarantees around technical and organizational security measures. Our Data Processing Addendum codifies those guarantees and defines the boundary between what we secure and what you configure.

The shared responsibility model works as follows:

• incident.io secures: infrastructure encryption, SOC 2 Type II controls, and AI data handling policies.
• Customers configure: access control settings, private incident visibility rules, and identity provisioning. Document this boundary early to establish clear responsibility for security controls during your procurement review.

Accessing our GDPR DPA template

We host our Article 28 Data Processing Addendum, and your legal team can download and review it without a sales call. For custom DPA amendments, redlined negotiation, or a GDPR Article 28 questionnaire response, contact your account representative or reach us at help@incident.io.

The DPA also grants customers the right to audit incident.io's compliance with its data processing obligations (Section 4.2.14): once per calendar year, with one calendar month's advance written notice, and at the customer's cost. If your procurement process includes a vendor audit right as a non-negotiable term, this clause satisfies it. The incident.io Trust Center provides access to our SOC 2 Type II report, penetration test executive summaries, and sub-processor disclosure upon request during your security review.

Documenting sub-processor audits

Our DPA requires sub-processors to meet data protection standards, covering contractual obligations that apply to incident.io itself. The full, current sub-processor list is available at incident.io/legal/sub-processors and through the Trust Center.

Mapping incident.io roles under GDPR Article 28

The table below maps GDPR articles to the specific technical controls we provide.

Table 1: GDPR article to incident.io control mapping

incident.io does not currently support deletion of individual incident records via the dashboard, and the documented deletion process does not publish a specific completion timeline. See "Ensuring permanent PII deletion" below for the full process and constraints.

EU data hosting configuration

Many regulated customers require EU data residency, and auditors will not accept "we store data in the cloud" as an answer. Here is our exact architecture.

Reviewing EU customer data processing locations

For EU-region customers, we host all customer data within Europe. Primary hosting runs in Belgium, with a hot standby in the Netherlands. No customer data leaves Europe for EU-region accounts.

Data residency region selection occurs during initial onboarding. Contact your account representative if you have specific EU data residency requirements that need to be documented before account provisioning.

Selecting your data residency region

If your legal team has flagged EU data residency as a procurement gate, raise this during your first technical call to confirm the provisioning flow.

Sensitive incident management via RBAC and SAML

The most common GDPR risk in Slack-native incident response is not a platform breach but a junior engineer posting PII into a public incident channel because the tooling provides no guardrails. incident.io's private incident controls, SAML SSO, and granular RBAC address this at the architecture level.

Configuring SAML and SCIM provisioning

SAML SSO is available on the Pro and Enterprise plans. It connects incident.io to your existing identity provider, helping ensure access control aligns with your organization's user provisioning.

SCIM provisioning is available on the Enterprise plan. SCIM automates user lifecycle management, helping organizations manage user access efficiently. For organizations under continuous audit pressure, the Enterprise plan's SCIM automation can help eliminate deprovisioning gaps that regularly appear as audit findings.

Handling RBAC for secure incident access

incident.io provides role-based access control to manage incident permissions. For the full role hierarchy and permission model, refer to incident.io's user roles and permissions documentation or ask your account representative to walk through the current access control model during your technical review.

Managing access to private incident data

Private incidents are available on the Pro and Enterprise plans (not available on Team plan). When you mark an incident private, we restrict access to invited users only. You can grant access via three routes:

1. Direct invitation to a specific user
2. Incident Team membership, as covered in the private incidents for teams changelog (granting an entire team access in one step)
3. The organization-wide "Manage private incidents" permission

The incident creator does not get automatic access to a private incident by default. They need one of the three routes above (direct invitation, Team membership, or the org-wide "Manage private incidents" permission) like any other user. A Slack workspace admin override also exists for additional oversight.

We recommend using a dedicated service account rather than a named individual's account. Full configuration instructions are in the sensitive incidents documentation.

"We really like the ability to customize our catalog, settings and workflows to completely meet our organization's needs." - Verified user on G2

Exporting audit logs for compliance

We provide audit log export as an Enterprise plan feature powered by WorkOS, retaining entries for 12 months and covering configuration changes, permission modifications, and user access events. Administrators export logs for any time period in CSV format from Settings > Security, or stream logs continuously to external SIEM providers including Datadog, Splunk, and AWS S3. The audit logs API also supports programmatic access for automated compliance pipelines.

Auditors who ask for a complete record of who accessed which incident and when get a single exportable file, not a multi-week Slack archaeology project.

incident.io breach notification SLAs

GDPR Article 33 requires supervisory authority notification within 72 hours of becoming aware of a personal data breach. Your DPA with incident.io defines how we support that obligation.

Setting breach notification SLA terms

Our DPA commits us to notify affected customers without undue delay upon becoming aware of a personal data breach involving customer data. The full contractual language is available in the Data Processing Addendum. Download and review that section before completing your legal sign-off.

GDPR Article 33 defines the required notification content: the nature of the breach, the categories and approximate number of data subjects affected, the likely consequences, and the remediation measures taken or proposed.

incident.io's DPA commits to notifying affected customers without undue delay, addressing the breach notification obligations set out in GDPR Article 33 (notification to the supervisory authority within 72 hours) and Article 34 (notification to affected data subjects where the breach is likely to result in high risk).

Whether your specific implementation satisfies both articles depends on your documented processes and contractual terms. Review the incident.io Data Processing Addendum alongside Articles 33 and 34 to confirm how each obligation is covered.

How long would it take your security team to assemble a complete, timestamped incident record right now if a regulator asked for one tomorrow? If the answer involves scrolling through Slack history or chasing engineers for notes, that gap is worth closing before a breach occurs. incident.io's timeline capture and audit log export turn that multi-day reconstruction into a single CSV export from Settings > Security.

Establishing breach alert protocols

incident.io's on-call and alerting features can automate the internal notification workflow your security team needs to start the 72-hour clock. When your SIEM (Datadog, Splunk, or a connected monitoring tool) detects an anomaly, incident.io workflows can create an incident channel and page your security on-call rotation.

Vanta, a compliance platform that evaluates security tooling for a living, automated a manual 5-step incident process and now alerts the right people within minutes of a suspected incident.

Reviewing breach notification terms in the DPA

The Data Processing Addendum is at incident.io/legal/data-processing-addendum. Your legal team can review the breach notification clauses without a sales call. If your privacy counsel requires custom amendments to notification timelines or wants explicit 72-hour processor-to-controller SLA language, contact help@incident.io with your DPA redline.

GDPR-compliant data removal

GDPR Article 17 grants data subjects the right to request erasure of their personal data. Your incident timelines, post-mortems, and status page histories may all contain PII that falls under this obligation.

Ensuring permanent PII deletion

Upon account termination, incident.io deletes customer data through a support-mediated process: email help@incident.io with your organization URL and ownership verification to initiate deletion. The delete account documentation covers the full process. The current documentation does not state a timeline for completion.

One important constraint to document before your legal review: incident.io currently does not support deletion of individual incident records through the dashboard. If a data subject erasure request names a specific incident, contact help@incident.io to initiate a deletion request. This limitation is worth noting explicitly in your GDPR documentation so there are no surprises during an audit.

Managing incident data auto-deletion

For customers requiring defined data lifecycle controls, contact your account representative to discuss your specific retention requirements.

Handling right to erasure requests

Here is a repeatable workflow for compliance officers executing Article 17 requests:

1. Identify scope: Confirm which user records or account data contain the data subject's personal data.
2. incident.io's forwarding SLA: If a data subject or regulator contacts incident.io directly instead of you, Section 4.2.10 of the DPA requires incident.io to forward that request to you within 5 business days of receipt. Document this SLA in your Article 17 response procedure so you are not caught off guard by a request you did not originate.
3. Export first: If the deletion touches audit evidence you need for a separate legal hold, export that record before initiating deletion.
4. Delete the account: Use the delete account documentation for organizational removal.
5. Confirm deletion: Audit log entries capture the deletion event with a timestamp. Export the confirmation event as CSV for your Article 17 response documentation.
6. Respond to the data subject: GDPR requires a response without undue delay and within one month of receiving the request.

Security controls for AI-powered incident tools

AI features inside an incident management platform are, reasonably, a compliance red flag until proven otherwise. Here is the exact data handling architecture for Investigations and Scribe.

GDPR compliance for AI investigations

Investigations, our AI-powered incident automation, automates up to 80% of incident response by analyzing telemetry, code changes, and past incident history to surface likely root causes. It operates under data handling agreements with OpenAI and Anthropic that prevent storage and use of your data for model training after the API request completes.

The AI data handling documentation covers the full redaction and routing architecture.

GDPR standards for Scribe transcripts

Scribe, our real-time call transcription feature, captures spoken decisions and action items during incident calls and surfaces them as structured timeline entries. incident.io encrypts Scribe transcripts at rest using AES-256. According to incident.io's documentation, audio and video are not stored, and incident.io deletes third-party recordings when the last human leaves the call.

Encryption protocols for customer data

incident.io encrypts all customer data at rest using AES-256 across all storage layers.

AI model training and data privacy

incident.io does not use customer data to train proprietary AI models. The data handling agreements with OpenAI and Anthropic include commitments that customer data is not used to improve their foundation models. Both commitments are reflected in the Addendum's sub-processor disclosures.

For security teams evaluating Investigations against their AI governance policies, the AI data handling page provides the technical detail needed to complete a standard AI risk assessment.

Regulatory and security audit requirements

The table below maps incident.io's certifications and controls to common audit requirements.

GDPR and security compliance checklist

SOC 2 Type II audit readiness

incident.io holds SOC 2 Type II certification, audited annually by an independent third-party firm. Our SOC 2 Type II report covers three of the five possible trust service criteria: security, availability, and confidentiality. Every incident timeline, role assignment, and action captured in incident.io constitutes structured, timestamped control evidence. When your SOC 2 auditor asks for evidence that incident response procedures were followed consistently, you export the incident timeline as CSV rather than reconstructing a narrative from Slack scroll-back.

Fin migrated from PagerDuty and Atlassian Status Page to incident.io and reported faster incident resolution along with reduced cognitive overhead from centralizing workflows in Slack. That centralization is the same property that makes audit evidence collection straightforward.

ISO 27001 certification status

incident.io is SOC 2 Type II certified. ISO 27001 certification is not yet in place. If ISO 27001 is a hard procurement gate for your organization, contact your account representative to understand current timeline and interim evidence options.

Annual penetration testing schedule

incident.io conducts annual penetration testing using independent third-party security firms. Executive summaries of penetration test results are available to customers and prospects under NDA through the Trust Center. Request the executive summary during your proof of concept rather than waiting until legal review.

GDPR compliance and DPA support queries

If your legal or security team needs documentation not covered in this guide, email help@incident.io with your specific request: DPA redlines, sub-processor disclosure, penetration test summaries, or GDPR questionnaire responses.

Incident management does not have to be a compliance liability. incident.io's Slack-native architecture captures an immutable, exportable audit trail automatically, so your security team spends hours on actual incident response rather than days reconstructing evidence for auditors. The controls described in this guide are built into the platform architecture from the ground up, not bolted on.

Book a demo to walk through a simulated private incident workflow, review SAML/SCIM configuration live, and see a sample audit log export that mirrors what you would submit as SOC 2 evidence.

Key terms glossary

Data Processing Agreement (DPA): A legally binding contract between a data controller and a data processor that defines the rights and obligations of each party under GDPR, covering data handling, breach notification, and sub-processor management.

Data residency: The physical and geographic location where an organization's data is stored and processed, determining which legal jurisdiction governs that data.

Role-Based Access Control (RBAC): A method of restricting system access to authorized users based on their specific organizational role, used in incident.io to control who can view, edit, or export incident data.

SCIM provisioning: System for Cross-domain Identity Management, an open standard that automates user provisioning and de-provisioning across identity providers and SaaS applications. Available on the incident.io Enterprise plan.

Zero Data Retention (ZDR): A security policy where third-party API providers such as OpenAI and Anthropic process data in real time without storing or logging it after the API request completes. Under ZDR, inputs and outputs are not stored at rest after the API response is returned, and your data is not used to train or improve either provider's models. Minimal retention exceptions may apply depending on each provider's agreement terms. Review the AI data handling documentation and the sub-processor disclosures to confirm the exact scope of any carve-outs before relying on ZDR for compliance purposes.

Private incidents: An incident.io feature on Pro and Enterprise plans that restricts incident channel access to explicitly invited users or teams, preventing accidental PII exposure in Slack during sensitive security events.