How-To9 May 2026 10 min read

SOC 2 PagerDuty: Incident Management and On-Call Evidence

SOC 2 PagerDuty setup covering escalation policies, on-call schedules, incident response workflows, postmortem documentation, and how to export CC7.3 incident evidence.

Key Takeaways

PagerDuty on-call schedules and escalation policies satisfy CC7.3 incident response assignment requirements.
Every incident in PagerDuty is timestamped and logged, providing an automated incident register for auditors.
Response automation (runbooks, auto-remediation) demonstrates a mature CC7.3 incident response process.
PagerDuty postmortem reports linked to incidents provide the root cause analysis evidence auditors expect.
Integrating monitoring tools via PagerDuty Events API v2 creates a single incident source of truth.
The PagerDuty Audit Records API enables automated evidence export for your SOC 2 audit package.

In this guide

PagerDuty and SOC 2 CC7.3
Escalation Policies and On-Call Schedules
Incident Response Workflow
Severity Classification
Postmortem Documentation (CC7.3)
Integrating Monitoring Tools
Extracting Audit Evidence

PagerDuty and SOC 2 CC7.3

CC7.3 states that "the entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives" and "identified security incidents are contained, remediated, and recovered from." PagerDuty is the operational backbone for this criterion — it receives alerts from monitoring tools, routes them to the right engineer, tracks response times, and captures incident resolution.

Auditors testing CC7.3 will ask to see: your documented incident response policy, evidence that incidents were detected and assigned to a responsible party (PagerDuty incidents list), evidence that incidents were responded to within documented SLAs (PagerDuty response time reports), and postmortem documentation for significant incidents. PagerDuty generates the evidence for all but the last point automatically.

Escalation Policies and On-Call Schedules

Create an escalation policy for each service tier. Navigate to PagerDuty → Configuration → Escalation Policies → New Escalation Policy. For production services: Level 1 — On-Call Engineer (acknowledge within 5 minutes). Level 2 — Senior Engineer / Tech Lead (if not acknowledged in 10 minutes). Level 3 — Engineering Manager (if not acknowledged in 20 minutes). Level 4 — CTO/VP Engineering (if not acknowledged in 30 minutes). This escalation structure satisfies the "assigned to a responsible party" requirement of CC7.3.

Create on-call schedules that ensure 24/7 coverage: Navigate to Configuration → Schedules → New Schedule. For a team of 6 engineers, create a weekly rotation. Add overrides for holidays and vacations via the Schedule → Add Override feature. When a team member is unable to cover their on-call rotation, the override record in PagerDuty documents the handoff — this is useful evidence if an auditor asks about on-call coverage during a specific incident.

Document the escalation policy in your incident response policy document. Include the policy name as configured in PagerDuty, the response time SLAs at each escalation level, and the services/teams covered. Auditors want to see that the PagerDuty configuration matches a documented policy, not that it was configured ad hoc.

Incident Response Workflow

Configure PagerDuty Services with status updates and response plays. Navigate to Configuration → Services → [service] → Response plays. Create a response play for each severity level. For P1 (critical): automatically add the on-call manager as a subscriber, send a Slack message to #incidents, and prompt the responder to open a war room call. This ensures the right people are involved from the first minute of a critical incident.

Enable PagerDuty Incidents to automatically create a Jira ticket or GitHub issue for each incident via the integration. This gives the incident a persistent record outside PagerDuty where post-incident tasks (code fixes, policy updates) are tracked. Link the PagerDuty incident to the Jira ticket in the incident notes. When auditors ask for evidence of a specific incident's resolution, you can show the PagerDuty timeline + the Jira remediation ticket as corroborating artifacts.

Use PagerDuty's built-in Incident Status Page or integrate with Statuspage.io to communicate outages to customers. During audit, auditors may compare customer-reported incidents on your status page against your PagerDuty incident log to verify that detection was timely. A customer reports an outage that appears in PagerDuty 5 minutes before the Statuspage update is a positive finding — you detected it before customers did.

Severity Classification

Document a severity classification matrix in your incident response policy. Common definitions: P1 (Critical) — complete service outage or active data breach, customer impact confirmed, response SLA 5 minutes. P2 (High) — significant service degradation, some customers impacted, response SLA 15 minutes. P3 (Medium) — partial degradation, limited customer impact, response SLA 1 hour. P4 (Low) — no customer impact, internal systems only, response SLA next business day.

Configure PagerDuty urgency rules to match this matrix: High urgency incidents (P1, P2) use phone and SMS notification; Low urgency incidents (P3, P4) use push notification only. Configure business hours rules so that P3/P4 incidents during off-hours are delivered the next business day. This prevents alert fatigue from low-priority incidents paging engineers at 3am, which reduces the risk of on-call engineers ignoring real P1 alerts.

Postmortem Documentation (CC7.3)

CC7.3 requires that "the causes of security incidents are analyzed and corrective actions are taken." Postmortems satisfy this requirement. Define in your incident response policy that P1 incidents require a postmortem within 48 hours and P2 incidents within 1 week. PagerDuty has a built-in Postmortem feature: navigate to Incidents → [incident] → Postmortem.

A SOC 2-quality postmortem includes: incident timeline (what happened, when, detected by what monitor), root cause analysis (5-whys or fishbone), customer impact (number of users affected, duration, data exposure if any), corrective actions (with owners and due dates), and preventive measures (what systematic changes prevent recurrence). Create a postmortem template in PagerDuty and require it for all qualifying incidents.

Export postmortems for the audit period. PagerDuty allows PDF export of individual postmortems. Compile these into an incident register: a spreadsheet listing each incident with severity, date, duration, customer impact, and a link to the postmortem. This register is the primary CC7.3 evidence artifact and demonstrates an operating incident management program, not just a tool installation.

Integrating Monitoring Tools

PagerDuty acts as the aggregation layer for alerts from all monitoring tools. Configure integrations for: Datadog (via the Datadog-PagerDuty integration in Datadog Service Management), AWS CloudWatch (via SNS → Lambda → PagerDuty Events API v2), GuardDuty findings (via EventBridge → Lambda → PagerDuty), GitHub Security Alerts (via GitHub webhook → PagerDuty). Use the Events API v2 (`POST https://events.pagerduty.com/v2/enqueue`) for custom integrations.

For each integration, configure event routing rules in PagerDuty Event Orchestration: route security alerts (GuardDuty, Security Hub) to the security team service, infrastructure alerts (CloudWatch, Datadog) to the platform team service, and application alerts to the application team service. This ensures each type of incident is handled by the team best positioned to respond, reducing mean time to resolution (MTTR) — a key availability metric for SOC 2.

Extracting Audit Evidence

Export PagerDuty incident data for your audit period using the PagerDuty API or the built-in analytics. Navigate to Analytics → Incidents → select date range → Export CSV. This CSV contains every incident with: incident number, service, severity, created date, acknowledged date, resolved date, response time, and responder. This data is your primary CC7.3 evidence showing that incidents were detected and responded to within SLA.

Use the PagerDuty Audit Records API (`GET /audit/records`) to export administrative actions: escalation policy changes, user additions/removals, and service configuration changes. This provides meta-evidence that the incident management system itself was properly administered. Include response time statistics: % of P1 incidents acknowledged within 5 minutes, % resolved within 4 hours. Show trend improvement over the audit period if available — auditors appreciate evidence of a maturing program.

Frequently Asked Questions

What PagerDuty plan do we need for SOC 2 compliance?

PagerDuty Professional covers on-call schedules, escalation policies, and incident management — sufficient for SOC 2 CC7.3. The Business plan adds event orchestration, response plays, and analytics, which reduce manual work. For the Audit Records API used for evidence export, you need the Business plan or higher. Most SOC 2 clients use the Professional or Business tier.

How many postmortems do SOC 2 auditors expect to see?

Auditors typically sample 3–5 incidents from your audit period and ask for their postmortems. They look for completeness (root cause identified, corrective actions with owners and due dates) rather than quantity. If you have no postmortems because you had no significant incidents, document this in your incident register with a note that all incidents during the period were P3/P4 and did not meet the postmortem threshold.

Should security incidents and operational incidents be in the same PagerDuty account?

Yes. Keeping them in the same tool with different services and escalation policies is simpler than maintaining two separate incident management systems. Create a dedicated "Security Incidents" service in PagerDuty with a separate escalation policy that includes the security team. This gives security incidents their own routing, SLAs, and audit trail while maintaining a unified incident management program.

What if we had a P1 incident during our audit period with no postmortem?

Write a retrospective postmortem now. While it will not have the real-time quality of a contemporaneous postmortem, a retroactive analysis based on available logs, Slack messages, and commit history is better than nothing. Be transparent with your auditor — note the date the postmortem was written versus the incident date, and add to your corrective actions: "implement mandatory postmortem process effective [date]".

Can Statuspage replace PagerDuty for SOC 2 incident management?

No. Statuspage is an external communication tool for publishing incident status to customers. PagerDuty (or equivalent) is the internal incident management system that routes alerts, tracks response times, and documents resolution. SOC 2 CC7.3 requires evidence of internal incident detection, assignment, response, and resolution — Statuspage alone does not provide this evidence.