Is PagerDuty SOC 2 compliant? A security leader's honest assessment

TL;DR: PagerDuty holds an active SOC 2 Type II certification, confirmed through its public security page and Assurance Profile portal, but understanding the certification's scope is critical for your own audit preparation. To pass your own SOC 2 audit, you must still manually reconstruct incident timelines across Slack, Jira, and alerting logs, a process that regularly costs dozens of hours per audit cycle. incident.io can reduce this compliance burden by capturing incident timelines directly in Slack and providing private incidents with role-based access control for sensitive incidents.

Security leaders evaluating PagerDuty for vendor risk assessments often stop at verifying the SOC 2 certification checkbox. That's the wrong place to stop. The harder question is whether PagerDuty's compliance posture reduces your audit burden or adds another disconnected tool whose logs you must manually reconcile the week before your auditor arrives.

PagerDuty maintains a valid SOC 2 Type II certification, confirmed through its public security page and Assurance Profile portal. This assessment covers how to obtain the full report and where compliance gaps can emerge in your incident response process.

Current PagerDuty SOC 2 Type II compliance status

PagerDuty holds an active SOC 2 Type II certification, confirmed through its public security page and Assurance Profile portal. The certification assures that PagerDuty designed effective security controls and operates them consistently, as defined by AICPA Trust Services Criteria.

The distinction between Type I and Type II matters for vendor risk assessments. A Type I report confirms controls are suitably designed at a single point in time. A Type II report confirms those controls operated effectively over a sustained period, typically 6 to 12 months. PagerDuty's Type II certification demonstrates sustained operational effectiveness rather than a snapshot.

Verify PagerDuty compliance status: Access PagerDuty's official Trust Center and Assurance Profile at assurance.pagerduty.com to request their latest audit reports, sub-processor lists, and security certifications.

Breakdown of SOC 2 Type II controls

According to PagerDuty's SOC 2 announcement, the examination covers two Trust Services Criteria:

• Security (CC series): Protects the service against unauthorized access, both physical and logical.
• Availability (A series): Confirms the service is available for operation and use as committed or agreed.

PagerDuty's SOC 2 announcement confirms the original Type II examination evaluated PagerDuty's processes, procedures, and controls for its on-call management platform and Event Intelligence Services. PagerDuty's security documentation lists controls including role-based access control, audit logging, incident response procedures, change management, and data encryption. PagerDuty's security page also lists ISO 27001 certification as a secondary trust signal, discussed below.

Latest SOC 2 audit timeline details

PagerDuty conducts third-party SOC 2 audits with a testing window of approximately 6 months. For your vendor risk assessment, track two dates: the testing period start date and the report issuance date. If the most recent report's testing period ended more than 12 months ago, request a bridge letter confirming continuous coverage, as your own SOC 2 auditor will verify vendor certifications were valid during your control testing window.

Steps to obtain PagerDuty audit reports

Obtaining PagerDuty's full SOC 2 Type II report requires one of the following:

1. Active customer account: Log in and navigate to PagerDuty's security page, then use the "Request a copy of PagerDuty's SOC 2 Type 2 Reports" link.
2. Non-Disclosure Agreement (NDA): Prospective customers evaluating PagerDuty may request access through the Assurance Profile portal at assurance.pagerduty.com.

Once received, store the report in your vendor compliance folder alongside PagerDuty's ISO 27001 certificate and in-scope services documentation.

Defining PagerDuty's SOC 2 audit boundaries

Most security leaders under-examine this boundary. PagerDuty's certification covers its internal systems, not your incident response process running on top of them.

PagerDuty's documentation states that it incorporates generally available services into compliance efforts based on anticipated use cases, feedback, and demand. Critically, some services are not currently listed in the scope of the most recent assessment, and you must evaluate before using those services. This is a shared responsibility model, and the boundary sits in an operationally significant place.

Mapping PagerDuty to SOC 2 criteria

The table below maps PagerDuty's native features to their corresponding SOC 2 Common Criteria and the audit evidence each feature provides.

Note that CC7.1 covers detection and monitoring of configuration changes and new vulnerabilities, while incident response execution maps to CC7.2 through CC7.4.

PagerDuty's documentation states that all employees and contractors attend mandatory Information Security Training during onboarding and annually.

Audited PagerDuty service boundaries

PagerDuty's SOC 2 announcement defines the audited boundary as the logical and physical systems it operates to deliver its on-call management platform and Event Intelligence Services.

What sits outside that boundary: The coordination work that happens after PagerDuty pages someone. The Slack channel your team creates, the decisions made in that channel, the remediation steps taken, and the post-mortem written three days later from memory. None of that typically appears in an alerting tool's audit scope.

Defining audit boundaries and gaps

The compliance gap is significant, and it costs the most hours before an audit. PagerDuty alerts the right person, but it doesn't coordinate the response or document it in a format auditors can use directly.

According to incident.io's post-mortem research, manual post-mortem reconstruction can waste significant time per incident as teams review Slack threads, monitoring data, and call recordings to rebuild timelines. Your auditor needs a continuous, defensible record of how your team handled incidents during the audit period. PagerDuty's event logs capture alerting actions. The actual incident coordination narrative, including who made which decisions, when they escalated, and how they communicated with customers, requires manual assembly from separate systems.

Validating PagerDuty's secondary audit credentials

Beyond SOC 2, verify three additional compliance credentials:

Current ISO 27001 certification status

PagerDuty's security page lists ISO 27001 certification, providing assurance that it has implemented an Information Security Management System (ISMS) meeting international standards. For organizations operating under ISO 27001 themselves, this is a meaningful secondary signal alongside the SOC 2 Type II report. Request the current ISO 27001 certificate with expiration date when you collect the SOC 2 report, and confirm the issuing certification body is accredited.

How to access PagerDuty DPA templates

For GDPR compliance, PagerDuty's Data Processing Addendum states it protects Customer Personal Data regardless of where data is transferred or processed. The DPA is available through PagerDuty's legal documentation portal and covers onward transfers using Standard Contractual Clauses. Execute the DPA before processing any EU personal data and retain a signed copy as evidence for GDPR compliance reviews.

Supported data residency regions

PagerDuty's security documentation lists US and EU data residency options. You choose the geographic region of PagerDuty data centers that host your account during setup. If you need to change residency after onboarding, PagerDuty's Professional Services can facilitate a migration, though a fee typically applies. If your organization processes personal data of EU residents, confirm your PagerDuty instance reflects EU residency before your GDPR review and document that configuration as part of your evidence package.

Essential evidence for your SOC 2 audit

Passing your own SOC 2 audit with PagerDuty in your stack means producing evidence across four control domains: access control, incident management, monitoring, and change management. PagerDuty contributes audit artifacts in the alerting and access control domains. Everything else you assemble manually.

Mapping evidence to SOC 2 controls

Start by listing every SOC 2 control in your control environment that touches incident response. Common examples include:

• CC7.2: Monitoring of system operations and incident response
• CC7.3, CC7.4: Incident response execution and recovery
• CC6.1: Logical access controls to system components

For each control, document which tool provides the evidence and how it's exported. PagerDuty covers part of CC7.2 (alert routing) and CC6.1 (RBAC logs). The documentation gap for incident response narrative appears the moment your on-call engineer leaves PagerDuty and starts working in Slack.

Enforcing RBAC via SAML and SCIM

PagerDuty's documentation confirms SAML and SCIM support for identity-provider-based access control. For your audit, use your identity provider (Okta, Azure AD, or equivalent) as the system of record for PagerDuty access, not PagerDuty's internal user management.

Auditors reviewing CC6.1 will ask for evidence of access reviews and deprovisioning. If you rely on PagerDuty's internal access management rather than SCIM-provisioned access from your IdP, you need manual exports and comparison reports to demonstrate timely deprovisioning. SCIM integration can automate this and produce cleaner evidence. Validate SCIM configuration specifics against your IdP's connector documentation.

Managing incident data for SOC 2

The practical problem for most security teams: PagerDuty generates event logs, Slack generates message exports, Jira generates ticket history, and post-mortems live in Confluence. Your auditor needs a coherent incident narrative. Your team typically stitches these together manually.

For a P1 security incident under SOC 2 audit scope, you must show:

1. When the alert fired (PagerDuty log export)
2. Who was paged and acknowledged (PagerDuty event log)
3. What the team discussed during response (Slack channel export)
4. What remediation steps were taken (Jira ticket history)
5. What the final post-mortem concluded (Confluence document)

That's four exports from four systems, manually correlated by timestamp and incident identifier.

Assessing PagerDuty sub-processor security

PagerDuty's sub-processor list is available through the Assurance Profile portal alongside the SOC 2 report. Review it before your next vendor risk assessment cycle. Your vendor risk management controls may require evidence that you've reviewed sub-processor security postures, so document the review date and any sub-processors relevant to data your organization transmits to PagerDuty.

Pre-audit verification checklist

Before your next SOC 2 renewal, verify the following for PagerDuty:

• Obtain the current SOC 2 Type II report and confirm the testing window dates.
• Obtain the ISO 27001 certificate and confirm its expiration date.
• Review the in-scope services list to confirm your services are covered.
• Execute the DPA for any EU personal data processing.
• Confirm your data residency region and document it (US or EU).
• Review the sub-processor list and file it.
• Configure SCIM provisioning so deprovisioning evidence comes from your IdP.

Comparing SOC 2 readiness: PagerDuty vs incident.io

The comparison below addresses compliance-specific features directly. PagerDuty's alerting capabilities are strong, and incident.io integrates with it rather than replaces it. The gap is in coordination, documentation, and audit evidence generation.

Generating immutable compliance logs

incident.io captures actions, decisions, status changes, and role assignments with timestamps and attribution throughout the incident lifecycle. This happens inside Slack, where your team already works, so there's no parallel documentation burden.

The audit logs feature records platform actions in a format suitable for export and auditor review.

The contrast with PagerDuty's event logs is operational: PagerDuty's audit logs capture system events within PagerDuty's boundary. incident.io's timeline captures the incident response narrative, the kind of cross-functional story your auditor needs to read.

Private incident workflows with RBAC

Sensitive security incidents create a specific risk that PagerDuty's architecture doesn't address: a junior on-call engineer exposing breach details in a public Slack channel because the tooling has no private-incident controls. That's a Personally Identifiable Information (PII) exposure event and a compliance gap in a single action.

incident.io's private incident workflow (available on the Pro plan) solves this directly. When declaring a sensitive incident, you select 'Only invited users (private)' via the Slack command. Access is enforced by RBAC aligned with your identity provider, not a manual channel workaround. Only explicitly invited responders can see the incident, its timeline, and any shared data.

For security teams running P0 investigations, active breach responses, or executive-account compromise investigations, this is the difference between a controlled response and a compliance gap.

Generating evidence for SOC 2 audits

The strongest proof point for a compliance-focused audience is Vanta. Vanta is a compliance platform whose entire business depends on getting compliance right, for itself and for its customers. Vanta uses incident.io to automate its own incident response process.

With incident.io, Vanta automated a manual 5-step incident process and now alerts the right people within minutes.

"A true leader in the incident management space... 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

Common pitfalls in PagerDuty security reviews

Avoid these three mistakes when reviewing PagerDuty's compliance posture:

Over-scoping PagerDuty in your audit: PagerDuty satisfies controls related to automated alert detection and escalation. For coordination, documentation, and post-incident evidence, document which tool covers those controls separately. Treating PagerDuty as evidence of your entire incident management control environment creates audit complexity without adding assurance.

Failing to extract complete evidence: For your audit package, export these four log categories covering the full audit period: a user access report with active users, roles, and last-login timestamps; escalation policy changes; incident alert logs showing alerts fired, acknowledged, and resolved; and a configuration change log for service definitions and integrations. Label each export with the control it satisfies and the audit period it covers.

Lacking PII (Personally Identifiable Information) controls during investigations: Without native private-incident support, teams typically rely on ad-hoc channel configuration to handle sensitive security incidents involving customer data, which creates GDPR notification risk and a compliance documentation gap. Mitigating this through process controls alone requires pre-defining approved private channels, training every on-call engineer on PII handling, and auditing channel membership before each sensitive incident.

Process controls require more comprehensive documentation for auditors than technical controls. The Security FAQs in incident.io's documentation cover data handling questions that apply directly to this concern.

See automated compliance in action

If your security team is ready to see how automated timeline capture and private incident workflows simplify your next SOC 2 audit, book a demo. We'll walk through a simulated security incident, including a private P0 breach response with SAML/SCIM-enforced access control, so you can see exactly what your auditor will see.

Key terms glossary

SOC 2 Type II: An audit standard that measures the operational effectiveness of a vendor's security controls over a sustained period, typically 6 to 12 months, confirming those controls operated consistently rather than just existed at a point in time.

Audit boundary: The defined scope of systems, processes, and services covered by a specific compliance certification. PagerDuty's audit boundary covers its own infrastructure and services, not the incident coordination workflows customers run on top of it.

Immutable log: A tamper-proof, timestamped record of events that cannot be altered or deleted after creation, serving as definitive evidence for compliance audits. incident.io's timeline capture generates audit logs as a byproduct of normal incident operations.

SAML/SCIM: Security Assertion Markup Language (SAML) and System for Cross-domain Identity Management (SCIM) are protocols for identity-provider-based authentication and automated user provisioning and deprovisioning, reducing manual access review burden for SOC 2 CC6.1 controls.

Private incident: An incident workflow where access is restricted to explicitly invited users via RBAC enforcement, preventing sensitive incident details such as breach indicators or PII from appearing in public channels.

Sub-processor: A third-party vendor that a primary data processor such as PagerDuty engages to process customer data on its behalf. GDPR and SOC 2 vendor risk programs require reviewing sub-processor security postures and documenting that review.