The incident response policy and procedure is one of the most actively tested documents in a SOC 2 audit. Auditors do not just verify that the document exists — they compare its contents to the actual incidents that occurred during the observation period. If the procedure says incidents are classified within one hour but the incident register shows classification taking days, that discrepancy is a finding. The procedure must reflect what actually happens, and what actually happens must reflect the procedure.
Incident Response Policy Content Requirements
| Policy Section | Required Content | Common Gap |
|---|---|---|
| Scope and definitions | What constitutes a security incident; distinction between events (potential incidents), incidents (confirmed security events), and breaches (incidents involving unauthorized disclosure of data) | Definitions so broad that every alert is an “incident,” overwhelming the register; or so narrow that real incidents are classified as non-incidents |
| Roles and responsibilities | Incident Commander (decision authority); Security Lead (technical response); Communications Lead (client and stakeholder notification); Legal Counsel (breach determination); Executive Sponsor (escalation) | Roles defined but not mapped to specific individuals; single point of failure where one person holds all roles |
| Incident classification | Severity tiers (P1/Critical through P4/Low) with objective criteria for each tier; escalation paths by severity | Severity criteria so subjective that different analysts classify the same incident differently |
| Detection and reporting | Required reporting channels; timeframe for reporting (e.g., security events must be reported within 2 hours of detection); what to do before reporting (preserve evidence, do not delete logs) | No defined reporting channel; employees unsure whether to report minor events |
| Response procedures | Step-by-step response for each severity tier; containment actions; evidence preservation; investigation approach | Generic response steps not tailored to the organization’s specific systems and threat profile |
| Client notification | Decision criteria for client notification; notification timeframe (typically 72 hours after determination of breach); notification content requirements; communication templates | Notification criteria unclear; no designated person to make notification decision; no template prepared |
| Post-incident review | Trigger criteria (all P1 and P2 incidents; P3 at security team discretion); review within defined timeframe (typically 5 business days after resolution); required output (PIR document with root cause and action items) | Post-incident review required by policy but not performed in practice; no evidence of review for incidents during observation period |
Incident Register Design
The incident register is the operational evidence artifact for the incident response policy. It must be maintained throughout the observation period, with all incidents recorded as they occur. The register’s structure should mirror the policy’s definitions — if the policy defines severity tiers, the register should record severity for each incident; if the policy requires post-incident review, the register should have a field linking to the PIR document.
| IMPORTANT | A common audit finding is an incident register with suspicious completeness: no incidents recorded during a period when the organization clearly experienced security events (as evidenced by SIEM alerts and system logs that auditors can review). Auditors interpret an empty or sparse incident register as evidence of poor incident detection or inadequate documentation, not as evidence of an exceptionally secure environment. |
Client Notification Procedures
Client notification procedures are a CC2 and CC7 requirement that organizations frequently leave underspecified. The procedure should define: the threshold for notification (any personal data breach? any confirmed unauthorized access? only events affecting specific data categories?), who makes the notification decision, within what timeframe the decision must be made, who communicates with affected clients, through what channel, and what the notification must include.
Notification templates — pre-written email communications for common incident types that can be adapted and sent quickly — are a best practice that reduces response time, ensures consistent communication, and provides evidence of a prepared communication program. Templates should be reviewed by legal counsel and approved before they are needed — not written during an active incident.
| BITLION INSIGHT | Indonesian companies operating under UU PDP (Personal Data Protection Law) face specific notification requirements: data breaches affecting personal data must be reported to the relevant supervisory authority and affected individuals within a defined timeframe. Aligning the SOC 2 incident notification procedure with UU PDP notification requirements — using the same trigger criteria, timeframe, and communication template — satisfies both requirements with one documented procedure. |