# PagerDuty security review checklist: questions to ask before signing *July 9, 2026* > **TL;DR:** A PagerDuty security review requires more than verifying baseline certifications. You need to pressure-test how the platform handles incident isolation, audit trail integrity, and PII exposure during live incidents, because these are where the real compliance gaps appear. PagerDuty's web-first architecture creates a manual compliance tax: fragmented timelines, limited native Slack isolation for sensitive incidents, and SAML not available on entry-level plans. This checklist gives you the exact questions to ask before signing. Most security reviews treat on-call and incident response tools as simple notification engines, and that framing misses the biggest compliance risks entirely. PagerDuty alerts your engineers when something breaks, but it does not automatically generate the complete audit trail evidence your SOC 2 Type II auditors need. That evidence lives across Slack threads, call notes, ticket updates, and PagerDuty logs, and your team is responsible for assembling it. This checklist covers the technical questions, documentation requests, and red flags that a structured PagerDuty vendor security review must include. It also shows where Slack-native platforms like incident.io eliminate compliance overhead by capturing evidence automatically where the work happens. ## Core certifications for vendor risk management Start with what PagerDuty can prove, not what their sales deck claims. Verify the scope of those certifications, not just their existence, because scope is where gaps appear. ### Reviewing SOC 2 Type II audit reports Request PagerDuty's current SOC 2 Type II report directly from their assurance portal at assurance.pagerduty.com. If available, the report should confirm that PagerDuty has completed a SOC 2 Type II examination, but verify which [Trust Services Criteria](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022) (TSC) the audit covers. Ask these specific questions: * Which TSC categories are covered: Security, Availability, Confidentiality, Processing Integrity, or Privacy? * What is the audit period, and is the report current within 12 months? * Are there any qualified opinions, exceptions, or noted control deficiencies in Section IV? Security is typically the mandatory TSC category in SOC 2 audits. For an incident management vendor, Availability and Confidentiality should be explicitly in scope. If they are not, your auditors will flag that gap. ### Validating PagerDuty ISO 27001 compliance Request the current ISO 27001 certificate and the Statement of Applicability (SoA). The SoA lists which Annex A controls are in scope and which are excluded and why. Check that the certification covers the specific cloud environments your team will use. If the certificate covers only a development environment and excludes your production service region, you cannot use it as valid audit evidence. ### Reviewing PagerDuty GDPR documentation PagerDuty includes [Standard Contractual Clauses](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en) as part of its customer Data Processing Addendum. Request the full DPA before signing and verify: * That SCCs cover EU-to-non-EU data transfers * That sub-processor obligations include their own DPAs with SCCs * That breach notification timelines are explicitly stated (regulatory frameworks typically require prompt notification, often within 72 hours) ### Verifying PagerDuty compliance benchmarks For regulated industries, request written confirmation of PagerDuty's status against: * **HIPAA:** Business Associate Agreement availability (required if health data enters the platform) * **FedRAMP:** [Authorization status](https://www.fedramp.gov/marketplace/products/?view=cards) (required for US federal customers) * **PCI-DSS:** Scope confirmation if cardholder data could appear in alert payloads ## How PagerDuty secures customer information These questions cover how PagerDuty protects your data at the infrastructure level. ### Validating PagerDuty encryption controls PagerDuty states it provides SSL/TLS for data in transit. Request PagerDuty's Information Security Practices document directly to verify specific encryption algorithms (such as AES-256 at rest), TLS version minimums, key management process and rotation frequency, and which third-party key management services are used. * Encryption algorithm for data at rest and in transit * Key management process and rotation frequency * Which third-party key management services are used ### Verifying PagerDuty data sovereignty PagerDuty reportedly offers a choice between the US service region and a European service region hosted in Frankfurt, Germany. The critical constraint: you must select your region at account creation. PagerDuty does not document a self-service post-setup migration path between regions, which means a configuration error at setup can lock your data in the wrong jurisdiction. Ask PagerDuty to confirm in writing: * That your data does not cross geographic boundaries after region selection * What the migration process is if you need to move regions post-setup ### Defining data retention and purge cycles PagerDuty retains Change Event data for 90 days by default. For personal data, retention is tied to service delivery and legal obligations, but default terms may not align with your compliance policies. Confirm whether you can configure custom retention periods and whether hard deletion of incident payloads is available on your plan tier. Confirm with PagerDuty whether sensitive incident data can be removed from their systems, including backups, through their data erasure request process, and whether such requests are logged for audit purposes. ### Evaluating AI and ML data usage PagerDuty's AIOps features analyze incident and alert data to surface patterns and suggest responses. Before signing, confirm in writing whether PagerDuty's AI models train on your incident data, whether you can opt out without losing AI functionality, and how long customer data persists in AI training pipelines. This matters because AI features that process incident data can expose customer PII, internal architecture details, and remediation steps to training pipelines outside your direct control. incident.io encrypts data at rest and in transit and does not train models on customer data without consent. For full detail on data handling and access controls, review incident.io's [security FAQ documentation](https://docs.incident.io/admin/security-faqs) for your security review package. ### Vendor assessment: sub-processor controls Request PagerDuty's complete sub-processor list, including the data access scope per vendor and their individual compliance certifications. Verify that PagerDuty contractually requires its sub-processors to meet equivalent security standards and that a defined notification process exists for sub-processor changes. ### Assessing PagerDuty resilience plans Request PagerDuty's Business Continuity and Disaster Recovery plans. Confirm Recovery Point Objective (RPO) and Recovery Time Objective (RTO) commitments, whether DR environments are in the same geographic region as your primary environment, and when PagerDuty last completed a live failover test. ## How to assess PagerDuty authentication security These checks cover how PagerDuty manages identity, access, and authentication controls. ### Assessing PagerDuty SAML compliance PagerDuty supports SAML 2.0 with identity providers including Okta, Microsoft Entra ID, OneLogin, Ping Identity, and others. However, SAML SSO is excluded on PagerDuty's Free plan but included starting at the Professional plan. Confirm your specific target tier includes it, because a parallel username/password login path may exist and bypass your identity controls if it does not. Confirm that SSO enforcement can be made mandatory for all users on your target plan, not just enabled as an option, before signing. ### SCIM integration for identity control [SCIM](https://datatracker.ietf.org/doc/html/rfc7644) provisioning is available on PagerDuty plans, but higher-tier plans may gate full SCIM functionality (including incident reassignment and user offboarding automation). Verify which SCIM capabilities are included at your plan level before committing. There is also a specific deprovisioning behavior to verify: if you deactivate a user in your identity provider, PagerDuty deletes that user. If you later reactivate that user in Okta, PagerDuty creates a new account rather than restoring the original one. Confirm with PagerDuty whether historical incident assignments, notification rules, and schedule memberships tied to the deleted account carry over to the new one. During initial SCIM user creation, provisioning services typically send only core mandatory attributes in the POST operation. Custom attributes follow in subsequent PATCH updates, which means custom attribute changes in your IdP may not appear in PagerDuty until the next sync cycle runs. ### Enforcing least privilege access Evaluate PagerDuty's RBAC model by mapping your required roles to their default role options. Ask whether custom roles are available on your plan tier and whether role-based access applies to specific service dependencies, not just global account permissions. ### Evaluating MFA vendor capabilities Verify that MFA can be strictly enforced across all users and all authentication methods, including mobile app access. Optional MFA is not sufficient for a compliance audit. Confirm whether [MFA enforcement](https://www.cisa.gov/MFA) is available on your plan tier or requires an upgrade. ### Configuring idle session timeout controls Request documentation on session timeout defaults and whether your team can configure them to match your security policy. Unattended sessions on shared or mobile devices are a common PII exposure vector during incident response, and your contract should specify enforceable timeout limits. ## Verifying PagerDuty compliance and audit readiness These checks confirm whether PagerDuty can produce the evidence your auditors will request. ### Audit log format and export standards Ask PagerDuty to demonstrate the log export process before signing. Confirm the formats available (JSON is supported via the Audit Records API; verify whether CSV export is available for your plan), whether the API supports automated log exports, and whether rate limits or volume restrictions would affect bulk exports during an active audit. ### Validating incident timeline integrity This is where PagerDuty's architecture creates the most significant compliance gap. PagerDuty captures alert arrival time, acknowledgment, escalation, and resolution, and its Slack integration records incident-related actions in the channel. But the continuous, chronological audit trail that SOC 2 auditors need, covering every role assignment, escalation decision, severity change, and status update in a single tamper-proof record, requires manual assembly from PagerDuty logs, Slack exports, and call notes. For a SOC 2 auditor, the question is not just "when was the alert acknowledged?" It is "who decided to escalate, who approved the remediation step, and when?" Answering that question from PagerDuty alone requires reconstruction work. incident.io solves this at the architecture level. The [automated timeline](https://docs.incident.io/post-incident/timeline) captures every command, role assignment, severity change, and status update with a timestamp, creating a continuous audit trail without requiring a separate note-taker. ### Extracting logs for compliance reviews Ask PagerDuty to walk through exactly how a SOC 2 auditor would access log data, including whether there is an API endpoint for audit log exports, whether exports include user-action logs beyond alert events, and whether the export process requires elevated admin permissions that your team must document as a compensating control. ### Validating PagerDuty audit documentation Confirm that exported PagerDuty logs meet the specific evidence format your auditors accept. Ask your external auditors in advance whether PagerDuty's log format satisfies their evidence requirements for control testing, particularly for incident response and change management controls. ## Evaluating PagerDuty incident isolation controls These controls determine whether sensitive incidents stay contained and whether PII exposure risk is managed during active response. ### Managing private incident access controls PagerDuty lets you set teams to private within the web interface, but this control does not extend to associated Slack channels. When an incident bridges from PagerDuty into a Slack channel, [Slack's native permissions](https://slack.com/intl/en-gb/help/articles/201314026-Permissions-by-role-in-Slack) govern who sees that channel, not PagerDuty's RBAC. A user with [Slack channel-invite permissions](https://slack.com/intl/en-gb/help/articles/29661601203603-Limit-channel-invitations-in-an-Enterprise-organisation) can add people to that channel regardless of the access restriction set in PagerDuty. incident.io handles this at the architecture level. Converting an incident to private is done by [making the channel private](https://docs.incident.io/incidents/sensitive-incidents) in Slack, and incident.io enforces that restriction automatically. Only users already in the private channel can discover or access the incident. > "incident.io is a good tool for also for handling security incidents. Separate incident types and good customisation options cover most of our needs. Security features, like private incidents, or restricting incident creation are also pretty helpful." - [Verified user on G2](https://www.g2.com/products/incident-io/reviews/incident-io-review-9692852) ### How PagerDuty protects customer PII Ask PagerDuty whether alert payloads are scanned or filtered for PII before storage. When monitoring tools fire alerts that include customer records, API keys, or error messages containing personal data, that data may be stored in PagerDuty's incident log. Confirm: * Whether PagerDuty supports payload filtering or masking before storage * Whether data erasure requests submitted to PagerDuty's Privacy Team result in deletion across all storage systems including backups, and whether PagerDuty can confirm this in writing * Whether erasure requests and their outcomes are logged for audit purposes ### Enforcing granular access control Map your incident response roles (incident commander, security responder, communications lead) to PagerDuty's permission model and confirm whether those roles can be scoped to specific services or teams. Global roles granting broad read access across all services create unnecessary PII exposure risk for engineers who only need access to a specific stack. ### Methods for automated data obfuscation Ask whether PagerDuty supports automatic redaction or masking of sensitive strings in alert payloads, such as credit card patterns, SSNs, or API key formats. If this is not available natively, document the manual control your team will use as a compensating control in your SOC 2 evidence package. ## Key security documents to request from PagerDuty Build this document request list into your procurement process before vendor conversations begin. 1. **SOC 2 Type II report:** Focus on Sections III and IV for system description and control testing results. Flag any noted exceptions in Section IV, since these indicate controls that were not operating effectively during the audit period. 2. **GDPR Data Processing Agreement:** Verify it includes the complete sub-processor list with appropriate change notice period, data deletion timelines, and breach notification obligations that align with regulatory requirements. 3. **Network architecture diagram:** Confirm data flows align with your region selection and that inter-service communication is encrypted in transit. 4. **Penetration test executive summary:** Verify recent completion and review remediation timelines for any critical findings. 5. **Internal incident response plan:** Understand how PagerDuty handles their own security incidents, including the customer notification process and escalation chain for data breach events. 6. **Historical uptime data:** Verify for your specific service region. incident.io maintains a 99.99% uptime SLA as a comparison benchmark. 7. **Contract security terms:** Include a defined breach notification timeline (with the clock starting when PagerDuty becomes aware, not when their investigation completes), a named security contact with direct escalation rights, explicit data center region commitment, custom retention periods if your regulatory obligations require them, and data deletion timeline upon contract termination with a deletion certificate upon request. ## Verifying PagerDuty internal security controls Verify these operational controls directly before signing: * **Vulnerability management:** Confirm scanning cadence covers all production assets including third-party libraries and container images. Verify patch timelines align with industry guidance for critical and high severity findings. Request evidence from the last two quarters. * **Employee security:** Confirm annual role-specific security awareness training for employees with customer data access, pre-hire background checks for roles with production access, and regular privileged access reviews. * **Breach notification:** Verify the contractual commitment specifies the clock starts when PagerDuty becomes aware of the breach and matches or exceeds regulatory notification requirements. * **Continuous monitoring:** Ask whether PagerDuty participates in a continuous monitoring program, publishes real-time status updates, and proactively notifies customers of material changes to security controls or sub-processors. ## Security and compliance posture: PagerDuty vs. incident.io The table below summarizes the key architectural differences that affect compliance outcomes for security teams. | Security capability | PagerDuty | incident.io | | --- | --- | --- | | SAML/SCIM integration | SAML on higher-tier plans, SCIM availability varies by tier | SAML and SCIM both Enterprise-tier only | | Private incident isolation | Automated workflows create public Slack channels only (private channels require manual creation), Slack channel access governed by Slack permissions | Native Slack-private channels with automated RBAC | | Audit trail generation | Alert and escalation events captured in platform logs | Automated timeline capture | | AI data privacy | Opt-out policies should be verified directly | Data handling documented in security FAQs | Security reviews most often flag the private incident isolation gap as a critical finding. PagerDuty's RBAC operates inside its own web interface, but the associated Slack channel is governed by Slack's native permissions, not PagerDuty's. A user with Slack channel-invite permissions can potentially add others to a sensitive incident channel regardless of the access restriction set in PagerDuty. incident.io's [private incident controls](https://docs.incident.io/incidents/sensitive-incidents) close this gap natively. The channel restriction and the incident record lock together, so only authorized responders can access the incident. For teams migrating off PagerDuty, incident.io provides [dedicated migration tooling](https://incident.io/rescue/pagerduty). The [Fin case study](https://incident.io/customers/fin) shows a team that migrated off PagerDuty and Atlassian Status Page in weeks, with faster MTTR and reduced cognitive overhead as the outcome. Vanta's experience validates this in a compliance-critical context. Vanta, which operates its own SOC 2 compliance platform, automated a previously manual five-step incident process with incident.io. [Book a demo](https://incident.io/demo) of incident.io to see how automated, audit-ready incident timelines and private incident controls work in Slack before you finalize your vendor decision. ## Key terms glossary **SAML/SCIM:** Security Assertion Markup Language and System for Cross-domain Identity Management, which automate user authentication and provisioning across your identity provider and the vendor platform. **Private incident:** An isolated incident workflow restricted to authorized responders, preventing sensitive data or PII from being exposed in public channels during a security breach. **Immutable log:** A tamper-proof, chronological record of events that cannot be altered or deleted, serving as valid evidence for SOC 2 and ISO 27001 compliance audits. **Data sovereignty:** The legal requirement that digital data is subject to the laws of the country in which it is located, making geographic region selection a compliance-critical decision at account creation. **Trust Services Criteria (TSC):** The categories evaluated in a SOC 2 audit: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is typically mandatory and the others must be explicitly in scope to count as compliance evidence. **Sub-processor:** A third-party vendor that a SaaS provider uses to process customer data. Under GDPR, the primary vendor is responsible for ensuring sub-processors meet equivalent data protection standards.