Overview
The Incident Notification Process is the formal procedure for identifying, escalating, and communicating security incidents to internal and external stakeholders in a timely and controlled manner. It ensures accurate, authorized, and consistent incident communication in alignment with SOC 2 CC2 communication criteria.
Step-by-Step Process
Detect and log incident
The Security Lead or on-call Security Analyst identifies a potential security incident through monitoring alerts, reports, or user notifications. The incident is logged in the incident tracking system with date, time, source, and initial severity. This creates the official record used for escalation and notification decisions.
Role: Security Analyst
Classify incident severity
The Security Lead reviews the incident details and classifies severity based on impact, data sensitivity, and affected systems. Severity determines notification timelines and required audiences. The classification decision is documented in the incident record.
Role: Security Lead
Identify notification requirements
The Security Lead determines who must be notified based on severity, contractual obligations, and regulatory requirements. This includes internal teams, executives, customers, and third parties if applicable. Notification requirements are referenced against the Incident Response Policy.
Role: Security Lead
Trigger incident notification
The Security Lead initiates notifications using the approved communication tool (PagerDuty, Opsgenie, or Slack). Notifications include incident summary, severity, required actions, and next update timeline. All notifications are sent through auditable channels.
Role: Security Lead
Acknowledge and track responses
Recipients acknowledge receipt of the notification through the tool’s acknowledgement or response feature. The Security Lead monitors acknowledgements and escalates if required response times are exceeded. Response tracking ensures accountability.
Role: Security Lead
Provide ongoing updates
The Security Lead provides periodic status updates as the incident progresses or scope changes. Updates are shared using the same notification channel to maintain a complete communication trail. Update timestamps and content are logged.
Role: Security Lead
Close notification and archive evidence
Once the incident is resolved, the Security Lead sends a closure notification summarizing impact and resolution. All notification logs, acknowledgements, and timestamps are archived with the incident record. This completes the communication lifecycle.
Role: Security Lead
What You Need Before Starting
- Incident Response Policy (approved and current)
- Access to incident management tool (PagerDuty, Opsgenie, or Slack)
- On-call schedule and escalation matrix
- Incident severity classification criteria
Evidence Your Auditor Expects
- Incident record showing initial detection date/time and severity classification
- Screenshot or export of PagerDuty/Opsgenie alert with timestamps and recipients
- Slack incident channel message history with timestamps and acknowledgements
- Incident closure notification dated and linked to the incident ID
How This Looks In Your Tools
PagerDuty
Log in to PagerDuty and navigate to Incidents from the top navigation bar. Click “New Incident,” select the impacted service, assign urgency, and add a detailed description before clicking “Create Incident.” PagerDuty automatically notifies the on-call responders.
To notify additional stakeholders, open the incident, select “More” > “Add Responders” or “Run Response Play.” Use the “Timeline” tab to verify notification timestamps and acknowledgements, then export the incident timeline for audit evidence.
Opsgenie
Log in to Opsgenie and go to Alerts > Create Alert. Select the appropriate team, set priority, and enter incident details, then click “Create Alert” to trigger notifications.
Within the alert view, use the “Activity Log” to confirm who was notified and when. Add notes or updates under the “Notes” section and export the alert activity log as evidence once the incident is closed.
Slack
In Slack, navigate to Channels and create or open the designated incident channel (e.g., #incident-YYYYMMDD). Post the initial incident notification including severity, impact, and owner, and tag required stakeholders using @mentions.
Use Slack message timestamps and thread replies to track acknowledgements and updates. After resolution, export the channel history or capture screenshots showing the full notification timeline for evidence retention.
Common Audit Findings
- Incident notifications not sent timely
- This occurs when severity classification or escalation criteria are unclear. Prevent this by maintaining clear severity definitions and automating notifications through incident management tools.
- Lack of evidence for who was notified
- Teams sometimes rely on verbal or informal communication. Always use tools with auditable logs and retain screenshots or exports showing recipients and timestamps.
- Inconsistent notification channels
- Using multiple ad-hoc channels makes communication hard to track. Define and enforce approved notification tools in the Incident Response Policy.
- Missing incident closure communication
- Closure notifications are often overlooked once technical resolution is complete. Add closure confirmation as a required step before marking incidents as resolved.