Incident Response
Security events are classified as events, incidents, privacy events, availability failures, customer-impacting events, or service-commitment failures and escalated based on severity.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
Security and service events are classified consistently, assigned a defensible severity, and escalated to the right technical, executive, privacy, legal, or customer-response owners.
First SOC 2 program
Use a one-page severity matrix with company-specific examples, require a ticket or incident record for declared events, and make one on-call person responsible for escalating uncertain or high-impact cases.
As the company scales
Use structured classification fields, automated routing, specialized privacy and service paths, response-time monitoring, downgrade review, and regular calibration using real and simulated cases.
Describe how the company distinguishes routine alerts, security incidents, privacy events, availability failures, customer-impacting issues, and other cases needing specialist review.
You should end up with: Event classification guide with examples
Consider affected customers, data sensitivity, service disruption, privilege, scope, active exploitation, recovery complexity, and uncertainty rather than relying on one tool score.
You should end up with: Severity matrix and decision prompts
Map each category and severity to primary and backup technical, executive, privacy, legal, support, and communications contacts.
You should end up with: Classification-to-escalation matrix
Record classifier, timestamp, known facts, category, severity, rationale, affected services or customers, notifications made, and later reclassification.
You should end up with: Attributable classification and escalation record
Test urgent and ambiguous scenarios to confirm the right people can be reached, acknowledge responsibility, and open the appropriate response process.
You should end up with: Escalation-path test and findings
Review selected cases, downgrades, missed escalations, and inconsistent classifications, then update examples or training.
You should end up with: Classification quality review
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
Covered security and service events enter an attributable record with source, time, affected scope, owner, status, and final classification or disposition.
Include this context
Event or incident ID
Include this context
Source and reported time
Include this context
Affected service or data
Include this context
Owner
Include this context
Current status
Include this context
Final disposition
Weak evidence to avoid
An informal chat thread about an event with no stable ID, recorded source, affected scope, owner, or final classification.
Confirm what the record proves
A qualified responder distinguished the event category using known facts and preserved reclassification as understanding changed.
Include this context
Event ID
Include this context
Category
Include this context
Known facts
Include this context
Classifier and time
Include this context
Prior and new value
Include this context
Change rationale
Weak evidence to avoid
A final category field with no classifier, timestamp, supporting facts, prior value, or rationale for a change.
Confirm what the record proves
The selected category and severity reached the correct primary or backup responder and acknowledgment or fallback is visible.
Include this context
Event ID
Include this context
Escalation trigger
Include this context
Recipient
Include this context
Sent and acknowledged times
Include this context
Fallback used
Include this context
Linked response record
Weak evidence to avoid
A message posted to a general channel with no intended recipient, acknowledgment, fallback, timestamp, or linked incident.
Confirm what the record proves
Severity reflects documented technical, service, customer, data, and uncertainty factors and has an attributable decision history.
Include this context
Event ID
Include this context
Initial severity
Include this context
Factors considered
Include this context
Decision-maker and time
Include this context
Current severity
Include this context
Change rationale
Weak evidence to avoid
A scanner priority copied into the incident field without customer impact, affected service, decision-maker, or recorded rationale.
Type 1
The current category and severity guides, primary and backup escalation routes, enabled incident workflow, and the latest qualifying event classification or exercise record showing the process is usable at the review date. If neither exists, retain complete zero-result queries from every defined event-intake source, current workflow configuration, and a documented walkthrough of a representative classification and escalation scenario.
Type 2
Every security, privacy, availability, and customer-impacting event entering the defined classification intake sources during the review period, including events closed as non-incidents, reclassified events, escalated incidents, duplicates linked to a retained parent, and events routed to specialist review; plus every classification and escalation tabletop or exercise due under the period-effective schedule, at least annually, including due, completed, cancelled, missed, and rescheduled occurrences. Preserve the original scheduled occurrence when an exercise moves and link it to the replacement date and final result. If the event population is zero, preserve full-period source exports and an attributable management confirmation.
Export the full-period population from every defined event-intake source and reconcile stable source IDs to classification records and incident or specialist outcomes, preserving duplicates and non-incident closures. Separately reconcile every exercise due on the period-effective calendar to a result or documented disposition, retaining cancelled, missed, and rescheduled occurrences and linking each original date to any replacement. If every event source returns zero, retain the query criteria, covered dates, zero-result exports, and management confirmation that no alternative intake channel produced covered events; a zero-event period does not remove the scheduled exercise population.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: Security and service events are classified consistently, assigned a defensible severity, and escalated to the right technical, executive, privacy, legal, or customer-response owners.
Compare the documented owner with the intended role (CISO / Incident Commander / Privacy-Legal Owner), then compare dated records with the stated cadence: Per event/incident; tabletop at least annually.
Export the full-period population from every defined event-intake source and reconcile stable source IDs to classification records and incident or specialist outcomes, preserving duplicates and non-incident closures. Separately reconcile every exercise due on the period-effective calendar to a result or documented disposition, retaining cancelled, missed, and rescheduled occurrences and linking each original date to any replacement. If every event source returns zero, retain the query criteria, covered dates, zero-result exports, and management confirmation that no alternative intake channel produced covered events; a zero-event period does not remove the scheduled exercise population.
The current category and severity guides, primary and backup escalation routes, enabled incident workflow, and the latest qualifying event classification or exercise record showing the process is usable at the review date. If neither exists, retain complete zero-result queries from every defined event-intake source, current workflow configuration, and a documented walkthrough of a representative classification and escalation scenario.
Every security, privacy, availability, and customer-impacting event entering the defined classification intake sources during the review period, including events closed as non-incidents, reclassified events, escalated incidents, duplicates linked to a retained parent, and events routed to specialist review; plus every classification and escalation tabletop or exercise due under the period-effective schedule, at least annually, including due, completed, cancelled, missed, and rescheduled occurrences. Preserve the original scheduled occurrence when an exercise moves and link it to the replacement date and final result. If the event population is zero, preserve full-period source exports and an attributable management confirmation.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates Covered security and service events enter an attributable record with source, time, affected scope, owner, status, and final classification or disposition.
For each selected record, confirm it demonstrates A qualified responder distinguished the event category using known facts and preserved reclassification as understanding changed.
For each selected record, confirm it demonstrates The selected category and severity reached the correct primary or backup responder and acknowledgment or fallback is visible.
For each selected record, confirm it demonstrates Severity reflects documented technical, service, customer, data, and uncertainty factors and has an attributable decision history.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.