Does PagerDuty store all EU customer data strictly within the EU?

No. PagerDuty's EU service region hosts core incident data in AWS Frankfurt (eu-central-1), but certain global metadata, user profiles, and mobile push notifications may still route through US infrastructure, and EU-headquartered sub-processors may not be guaranteed for every processing activity. Standard Contractual Clauses cover these cross-border flows, but absolute EU data pinning across all data categories is not guaranteed.

What is PagerDuty's breach notification SLA under its GDPR DPA?

PagerDuty commits to notifying affected customers of a confirmed data breach "without undue delay" per GDPR Article 33(1) language, but the DPA does not specify a numeric SLA such as 24 or 48 hours, creating potential ambiguity for controllers managing the regulatory notification window.

How do we handle EU data residency differently than PagerDuty?

We provide strict regional data isolation, with core incident data, timelines, and metadata remaining within the EU region, and our audit logs are available for export with 12 months of retention on the Enterprise plan for full auditability.

Can we execute a pre-signed DPA with you?

Yes. We offer a DPA that eliminates the manual sales-gate and extended review process required by legacy vendors, and our trust center provides SOC 2 Type II documentation and GDPR compliance details on request.

Is our AI a GDPR compliance risk?

No, provided you review the data handling documentation before deployment. We maintain Zero Data Retention agreements with OpenAI and Anthropic, and automatic PII redaction strips sensitive patterns at the API ingestion layer.

How do PagerDuty's audit log gaps affect SOC 2 audits?

PagerDuty's audit trail reporting excludes changes to users or levels on escalation policies and details about schedule overrides, meaning compliance teams may need to manually reconstruct access histories from supplementary sources. Auditors may question whether the control evidence is complete, which can widen audit scope.

What is the 30-day sub-processor objection window and how do we manage it?

When PagerDuty adds a new sub-processor, the DPA establishes an objection window. Under general authorization models, customers who do not object within the specified timeframe may be deemed to have accepted the change, though this depends on the specific DPA language and whether the controller had genuine, informed notice with enough time for meaningful objection. Subscribe to the RSS feed and build a calendar review process to ensure your legal team can evaluate each addition against your vendor risk policy within the notification window.

PagerDuty GDPR compliance: Data processing, DPA terms, and EU data residency | Blog

TL;DR: PagerDuty meets baseline GDPR requirements with an EU service region in AWS Frankfurt, but its legacy architecture may create compliance friction: audit log access is limited to 31-day query windows with potential gaps in escalation policy history. For fintech and healthtech teams under SOC 2 or ISO 27001 audit pressure, incident.io provides strict regional data isolation, automated immutable audit logs exportable as CSV, and private incident controls enforced via SAML/SCIM in Slack, cutting the manual hours spent reconstructing audit evidence.

Most CISOs evaluate incident management tools for uptime and alert routing. The real compliance risk during a P1 incident is harder to spot: customer PII silently flows across international borders, lands in sub-processor systems your legal team never reviewed, and sits in a format that can require significant manual effort to reconstruct for your next audit.

Evaluating PagerDuty for GDPR compliance requires looking past high-level certifications to verify actual data residency pinning, sub-processor security, and automated audit trail generation. This guide breaks down PagerDuty's DPA terms, EU data residency limitations, and sub-processor disclosures, while showing how modern platforms automate these compliance controls directly inside your chat workspace.

Before committing to any incident management vendor, your legal and security teams need a clear picture of how GDPR obligations are structured across the platform. The following areas cover what to examine.

GDPR Article 28 requires any third-party platform processing personal data on your behalf to execute a binding Data Processing Agreement (DPA) covering security of processing (Article 32), data minimization, breach notification, and audit rights. For incident management tools, this matters more than most buyers realize: on-call engineer directories, escalation histories, and notification records typically contain personal data. Engineer names, phone numbers, and email addresses flow through platform workflows. In a security incident, records may contain customer identifiers or system details embedded in log output.

No explicit Article 6 lawful basis appears in PagerDuty's publicly available documentation; the DPA states that Customer Personal Data is processed "for the limited and specified business purpose(s) of providing the Services as described in the Agreement," which suggests contract performance, but your legal team should confirm the applicable basis directly with PagerDuty's privacy team before finalizing your Records of Processing Activities.

According to PagerDuty's publicly available documentation, the platform acts as a data processor under Article 28, with the customer acting as data controller. Module 2 of the EU Standard Contractual Clauses (SCCs) covers controller-to-processor transfers, with Module 3 applying where the customer itself operates as a processor.

PagerDuty sub-processor disclosures

Sub-processors compound compliance risk quickly. Every vendor PagerDuty engages to process your incident data becomes a compliance touchpoint your legal team must review. PagerDuty maintains a public sub-processor list at pagerduty.com/subprocessors, with an RSS feed available for change notifications. According to PagerDuty's documentation, the company requires all sub-processors to undergo a risk assessment and sign written agreements ensuring adequate data protection.

For AI services, PagerDuty's published generative AI guidelines state that the company will not use customer data to train AI models that may benefit other parties without that customer's explicit permission. This is a platform-wide policy commitment; PagerDuty's public documentation does not break down retention or training terms by named AI sub-processor. Named AI sub-processors on PagerDuty's published list include AWS Bedrock, Azure OpenAI, Google, and IBM; your legal team should review PagerDuty's generative AI guidelines at pagerduty.com/security/generative-ai-guidelines/ and confirm applicable terms for each provider during contract review.

The DPA is the legal foundation for your GDPR compliance posture with PagerDuty. The sections below walk through how it is structured and where your obligations begin.

How to request the PagerDuty DPA

PagerDuty's DPA is incorporated by reference into its Terms of Service, meaning accepting the Terms automatically activates Article 28 obligations. The full DPA is available at pagerduty.com/data-processing-addendum, and the Standard Contractual Clauses are included within it, so no additional addendum may be required for cross-border transfer compliance.

This creates a subtle governance risk: your legal team must proactively pull the current DPA version and document that review, rather than receiving a countersigned document through a formal execution workflow.

Defining sub-processor data rights

Under PagerDuty's DPA terms, sub-processors may access, store, and process customer personal data only to the extent necessary to provide contracted services. PagerDuty maintains general written authorization for sub-processor use, meaning customers grant upfront approval for sub-processors on the published list rather than approving each individually.

You retain the right to object to new sub-processors, but PagerDuty uses an objection-based mechanism: if PagerDuty adds a sub-processor, you must notify them within a specified timeframe (commonly 30 days) of the updated list publication if you object. The specific terms depend on your DPA, and missing the objection window may be deemed acceptance under general authorization models. For security teams running continuous audit programs, this creates ongoing administrative overhead requiring calendar-based monitoring of the sub-processor RSS feed.

Mandatory Article 28 processor obligations

Under the DPA, notification of any confirmed data breach is committed to "without undue delay," using the statutory GDPR language from Article 33(1) but without specifying a numeric SLA. You carry the regulatory notification window to your supervisory authority (typically 72 hours under GDPR Article 33), but your contract with PagerDuty may not guarantee processor notification within a specific timeframe before that clock expires.

Best practice for DPAs in regulated industries is an explicit numeric commitment of 24 to 48 hours from breach confirmation. PagerDuty's "without undue delay" standard is legally compliant but introduces ambiguity that compliance teams should document in their risk register.

Accurate data mapping starts with knowing exactly what personal data PagerDuty processes on your behalf. The following covers both what flows through the platform and how it is secured.

Personal data categories processed

Every active incident in PagerDuty touches multiple categories of personal data. Data categories include:

On-call engineer identifiers: names, email addresses, phone numbers, and mobile device tokens for push notifications.
Alert payload content: structured monitoring data that may embed IP addresses or system identifiers depending on alert configuration.
Incident timeline entries: documentation that may include system details.
Call and conference data: metadata and, where recorded, call transcripts. The compliance risk is not just what PagerDuty collects by design, but what ends up in free-text alert payloads and chat history by accident.

PagerDuty secures this data through encryption in transit and at rest, account-level access controls, and sub-processor agreements. However, PagerDuty's audit trail reveals a structural limitation: audit records from the last 12 months may be accessible, but the maximum single-query duration is 31 days. More critically, the audit log excludes changes to users or levels on escalation policies and details about overrides or users added or removed from schedules.

These gaps mean compliance teams cannot reconstruct a complete access history for an audit from PagerDuty's native logs alone, and must stitch together supplementary records from Slack exports, Jira ticket histories, and external identity provider logs.

incident.io addresses this at the architecture level. Automated, immutable audit logs capture configuration changes, incident access, and permission modifications, with logs available for centralized oversight. Commands, role assignments, and events are recorded with timestamps, giving auditors the record trail they need without manual reconstruction.

Selecting EU data residency zones in PagerDuty

EU data residency in PagerDuty is not a single toggle. The sections below explain how the architecture works and what you must verify at setup and on an ongoing basis.

Infrastructure mapping for EU compliance

PagerDuty offers two service regions: US and EU. The EU service region hosts core data in AWS eu-central-1 (Frankfurt), covering primary incident data, alert routing, and schedule management for accounts configured in the EU region.

The critical limitation is what "EU service region" does not cover. PagerDuty's documentation confirms the platform can forward REST API and Events API requests from the US service region to EU when it detects an EU integration or API key, but recommends sending API requests directly to dedicated EU service region URLs for improved reliability. Integration configurations that do not explicitly target EU endpoints may route data through US infrastructure.

Beyond API routing, global user profile data, mobile push notification infrastructure, and certain sub-processor services may not pin strictly to the EU region. PagerDuty's sub-processor list may show EU-headquartered companies using US-based sub-processors, and EU data hosting does not guarantee all metadata flows remain within EU borders.

How to configure EU data residency

EU service region selection happens at account creation, not as a post-hoc configuration change. Confirm the following before signing:

Account provisioning: Request explicit confirmation from PagerDuty sales that the account is provisioned in the EU service region (eu-central-1).
Integration configuration: Audit all monitoring and ITSM integrations to verify they target EU-specific API endpoints.
Sub-processor review: Identify US-based sub-processors in the published list and document Standard Contractual Clauses coverage for each.
Mobile notification routing: Confirm with PagerDuty whether mobile push notification infrastructure falls under the EU service region designation.

The distinction between "core data in EU" and "all data in EU" matters for Article 44 cross-border transfer compliance. If metadata, logs, or notifications touch US infrastructure, your legal team must document which specific data flows trigger the SCCs and which sub-processors those flows cover.

PagerDuty's sub-processor list and disclosure

Sub-processor oversight is an ongoing obligation under Article 28, not a one-time review. Here is how PagerDuty structures its disclosure and what your team needs to track.

How to verify PagerDuty sub-processors

PagerDuty maintains its sub-processor list at a public URL (pagerduty.com/subprocessors) with an RSS subscription option for change notifications. The list specifies each sub-processor's name, location, and the services they provide within the platform.

Key sub-processor security obligations

Security standards are enforced on sub-processors through contractual due diligence: each sub-processor undergoes a risk assessment before engagement and signs a Data Processing Addendum consistent with applicable legal requirements, satisfying the Article 28(4) obligation to impose equivalent obligations on sub-processors.

However, PagerDuty's documentation does not specify whether it requires sub-processors to hold SOC 2 Type II or ISO 27001 certification as a baseline condition. For organizations with strict vendor risk management programs, raise this directly during contract negotiation.

Sub-processor change notification protocol

When PagerDuty adds or removes a sub-processor, it updates the published list. Your objection window (commonly 30 days from the date the updated list is available) depends on your specific DPA terms. Your legal or procurement team must track these changes and evaluate each addition against your vendor risk policy within that window.

Compliance steps for data subject rights requests

GDPR grants individuals specific rights over their personal data. The following covers how those requests are handled and what your team is responsible for coordinating.

How PagerDuty handles data subject access requests

Under GDPR Article 15, data subjects can request access to all personal data you hold about them. For PagerDuty, this covers on-call engineer profiles, notification history, incident participation records, and any PII embedded in alert payloads or timeline entries. PagerDuty's Privacy Team handles DSAR fulfillment on request.

When an engineer leaves your organization, deleting their personal data across PagerDuty to comply with Article 17 (Right to Be Forgotten) requires coordination with PagerDuty's Privacy Team, creating a process your team must track and document for auditors.

incident.io's SCIM integration (available on the Enterprise plan) automates deprovisioning: removing an engineer from your identity provider typically revokes their access to incident.io and may reduce the exposure window between off-boarding and access removal.

Core security controls and compliance badges

GDPR compliance sits alongside broader certification and access control requirements that auditors will examine. The following maps those requirements to both platforms.

Accessing the SOC 2 Type II report

PagerDuty holds SOC 2 Type II certification. Security teams must request the full report through PagerDuty's trust center, typically as part of a sales or renewal process, covering the Trust Services Criteria for security, availability, and confidentiality. incident.io also holds SOC 2 Type II certification and is GDPR compliant with encryption at rest, serving 1,200+ companies including Netflix, Etsy, and Vanta.

Managing ISO 27001 security requirements

PagerDuty holds ISO 27001 certification as part of its broader security program, alongside SOC 2 Type II and FedRAMP Low. For organizations pursuing their own ISO 27001 certification, your certification body will want evidence that key third-party vendors operate under equivalent or compatible control frameworks.

Protecting PII via strict access rules

The table below maps specific GDPR and SOC 2 control requirements to both platforms' native capabilities:

GDPR / SOC 2 control requirement	PagerDuty approach	incident.io approach
Article 32: Security of processing (RBAC)	Manual channel configuration with risk of over-permissioning.	RBAC enforced via SAML (Pro and above) and SCIM (Enterprise) with private incident channels.
Article 30: Records of processing (audit trail)	Manual reconstruction from Slack, Jira, and alert logs with 31-day query limits and escalation policy gaps.	Automated, immutable timeline capture retained for 12 months on the Enterprise plan.
Data minimization (PII redaction)	Manual redaction of alert payloads and chat history required post-incident.	PII handling controls at the API level.
EU data residency (data pinning)	Core data in EU Frankfurt, but metadata and notifications may route through US infrastructure.	Strict regional data isolation with dedicated EU hosting for transactional data.
Article 17: Right to be forgotten	Manual Privacy Team workflow with undocumented cascade deletion scope.	Automatic deprovisioning via SCIM (Enterprise) with audit log entry on removal.

incident.io's Investigations and Scribe are the two AI products security teams scrutinize most during compliance reviews. Here's the concrete answer: incident.io maintains Zero Data Retention agreements with AI providers (OpenAI and Anthropic), meaning no inputs or outputs are stored and neither provider uses customer data for model training. Automatic redaction strips sensitive patterns from messages before they reach AI models at the API ingestion layer.

"A true leader in the incident management space, Their data model is incredibly flexible and they continue to improve their core product at a steady pace. A company using Incident.io shows they are serious about using the best incident management tools to ensure the best user experience and maximize participation in incidents." - Christopher on Trustpilot

The Vanta case study is worth highlighting specifically because Vanta is itself a compliance platform. When a company whose core product is compliance automation chooses incident.io and automates a previously manual 5-step incident process, alerting the right people within minutes, that provides a strong compliance signal for your own vendor review.

Essential steps for DPA and data residency

The steps below translate PagerDuty's GDPR structure into concrete actions your legal, security, and procurement teams need to complete and maintain.

PagerDuty acts as a data processor under GDPR Article 28. Your organization, as the entity that determines the purposes and means of processing, acts as the data controller. This means you carry the primary compliance obligation to your data subjects and regulators, and PagerDuty's obligations flow from its contract with you.

How PagerDuty handles EU SCC requirements

PagerDuty's DPA incorporates the EU Standard Contractual Clauses for controller-to-processor transfers (Module 2) and processor-to-sub-processor transfers (Module 3). These SCCs provide the legal transfer mechanism for personal data flowing outside the EEA to PagerDuty's US infrastructure or US-based sub-processors.

For a Schrems II-compliant transfer impact assessment, your legal team must document the specific data flows that activate the SCCs, the sub-processors each flow touches, and whether the technical and organizational measures in PagerDuty's DPA are sufficient given the legal landscape in the destination country.

Processing times for DPA agreements

Because PagerDuty incorporates its DPA into the Terms of Service, legal execution takes minimal time. The real cost sits in the vendor onboarding process: reviewing the sub-processor list, completing a transfer impact assessment, mapping data flows, and securing legal sign-off on DPA terms. For organizations with formal vendor risk management programs, this process can take multiple weeks.

incident.io offers a DPA you can execute efficiently, and its trust center provides SOC 2 Type II documentation and GDPR compliance details on request.

Restricting data transfers outside the EU

To minimize unauthorized cross-border data transfers with PagerDuty, implement the following technical and organizational measures:

Account provisioning: Confirm EU service region selection at setup. This cannot be changed retroactively without a full account migration.
Integration audit: Verify all monitoring and ITSM integrations target EU service region endpoints rather than global (US) endpoints.
RSS monitoring: Subscribe to the sub-processor RSS feed and schedule a calendar review with sufficient time before your objection window closes to ensure meaningful review.
SCC documentation: Map each US-based sub-processor to the transfer mechanisms defined in PagerDuty's DPA in your data flow register.
Mobile notification routing: Request written confirmation from PagerDuty that mobile push notification infrastructure is architecturally isolated within the EU service region.

For teams considering migration, incident.io provides PagerDuty migration tools including import capabilities for schedules and escalation policies, and the migration guide covers the available migration tooling. Fin migrated off PagerDuty and Atlassian Status Page, achieving reduced MTTR and less cognitive overhead.

"We like how we can manage our incidents in one place. The way it organises all the information being fed into an incident makes it easy to follow for everyone in and out of engineering. The recent addition of on-call allowed us to migrate our incident response from PagerDuty and it was very straight forward to setup." - Harvey J. on G2

The incident.io PagerDuty Rescue Program details the migration path for teams moving off PagerDuty specifically. See incident.io's regional data isolation controls and automated audit log exports in a live environment.

Book a demo to walk through a simulated security incident including private incident channel setup, SAML provisioning (Pro and above), SCIM provisioning (Enterprise), and a full audit log export in the format your auditors will accept.

Key terms glossary

Data Processing Agreement (DPA): A legally binding contract between a data controller and a data processor defining the terms and security controls for processing personal data under GDPR Article 28.

Standard Contractual Clauses (SCCs): Standardized contract terms approved by the European Commission to ensure adequate data protection when transferring personal data outside the EU, covering controller-to-processor (Module 2) and processor-to-sub-processor (Module 3) flows.

Sub-processor: A third-party service provider engaged by a data processor to perform specific data processing activities on behalf of the data controller, subject to Article 28(4) obligations.

Private incidents: A feature that restricts access to sensitive security incidents using granular, SAML-enforced (Pro and above) and SCIM-enforced (Enterprise) role-based access controls, preventing PII and remediation details from appearing in public Slack channels.

Investigations: Our AI-powered product that analyzes telemetry, code changes, and past incidents to identify root causes and draft fix PRs, operating under Zero Data Retention agreements with no model training on customer data.

DSAR (Data Subject Access Request): A formal request by an individual to access all personal data an organization holds about them under GDPR Article 15, requiring a documented fulfillment workflow from the data controller and any relevant processors.

SCIM (System for Cross-domain Identity Management): An open standard protocol that automates user provisioning and deprovisioning between identity providers (such as Okta) and third-party applications, eliminating manual off-boarding gaps in access control.

Immutable audit log: A tamper-proof record of system events (access changes, configuration updates, incident actions) that cannot be edited after creation, providing forensically reliable evidence for SOC 2 and GDPR compliance audits.