1. Purpose
The Security Incident Communication Procedure defines how information security incidents are communicated internally and externally throughout the incident lifecycle.
The procedure ensures that incident information is:
- Communicated to the right people
- Communicated at the right time
- Based on verified information
- Protected from unnecessary disclosure
- Consistent across communication channels
- Escalated according to incident severity
- Aligned with legal, regulatory, contractual, customer, and business requirements
The objective is to support effective incident response without creating additional security, privacy, legal, or reputational risk.
2. Scope
This procedure applies to security incidents involving:
- Employees and contractors
- Customer information
- Personal or regulated information
- Cloud environments
- SaaS applications
- Production systems
- Endpoints and servers
- Source code and CI/CD
- Suppliers and third parties
- Phishing
- Malware and ransomware
- Account compromise
- Unauthorized access
- Data breaches
- Vulnerability exploitation
- Availability incidents
- Physical security incidents affecting information
It applies to:
- Internal communication
- Management escalation
- Technical coordination
- Customer communication
- Supplier communication
- Legal and regulatory communication
- Law-enforcement communication
- Other authorized external communication
3. Communication Principles
Incident communication should follow these principles:
3.1 Communicate Quickly
Significant incidents should be communicated promptly according to the Incident Escalation Matrix.
3.2 Communicate Facts
Use verified information wherever possible.
Clearly distinguish:
- Confirmed facts
- Preliminary findings
- Assumptions
- Unknown information
- Information still under investigation
3.3 Do Not Speculate
Do not make unsupported statements about:
- Root cause
- Attacker identity
- Number of affected users
- Data accessed
- Financial impact
- Regulatory consequences
unless supported by evidence or appropriately qualified.
3.4 Use Authorized Channels
Sensitive incident information should only be communicated through approved communication channels.
3.5 Apply Need-to-Know
Only provide information necessary for the recipient to perform their role.
3.6 Maintain Consistency
Internal, customer, supplier, and regulatory communications should be coordinated.
3.7 Protect Evidence
Communication should never result in modification, deletion, or unnecessary disclosure of investigation evidence.
4. Incident Communication Roles
| Role | Communication Responsibility |
|---|---|
| Incident Commander | Coordinates overall incident communication |
| Security Lead | Provides technical security information |
| IT/Cloud Lead | Provides infrastructure status |
| Application/DevOps Lead | Provides application and development status |
| Privacy Lead | Provides privacy/data-impact assessment |
| Legal/Compliance | Reviews legal, regulatory, and contractual communications |
| Business Owner | Provides business/customer impact |
| Executive Management | Provides executive direction and approves major decisions |
| Communications/Customer Success | Coordinates approved customer communication |
| Supplier Owner | Coordinates third-party communications |
The detailed responsibilities should follow the approved Incident Response Team RACI.
5. Communication Lifecycle
The communication process follows:
Detect → Validate → Classify → Escalate → Communicate → Update → Recover → Close → Learn
Communication should continue throughout the incident rather than occurring only at the beginning and end.
6. Initial Incident Communication
Once a potentially significant incident is identified:
- Create or update the incident record.
- Assign an incident ID.
- Determine initial severity.
- Identify the Incident Commander.
- Activate relevant response team members.
- Notify required stakeholders.
- Establish the approved communication channel.
- Record significant communications in the incident record.
The initial communication should normally contain:
- Incident ID
- Date/time
- What was detected
- Current severity
- Affected system/service
- Known impact
- Unknowns
- Immediate actions
- Incident owner
- Next update time
7. Initial Communication Template
Subject: Security Incident – [Incident ID] – [Severity]
Incident ID: [INC-XXXX]
Date/Time Detected: [Date/Time]
Severity: [SEV-1 / SEV-2 / SEV-3 / SEV-4]
Summary:
[Brief factual description]
Affected Systems:
[Systems/services currently known to be affected]
Known Impact:
[Current confirmed impact]
Unknown / Under Investigation:
[Information not yet confirmed]
Actions Taken:
[Containment/investigation actions]
Incident Commander:
[Name/Role]
Next Update:
[Date/Time]
Important: Please do not forward incident information outside the authorized response group unless instructed.
8. Internal Communication
Internal communication may involve:
- Security
- IT
- Engineering
- DevOps
- Business owners
- Privacy
- Legal
- Compliance
- HR
- Executive management
- Customer support
- Procurement/supplier management
The audience should be determined based on:
- Severity
- Affected systems
- Information involved
- Business impact
- Required expertise
- Legal/privacy considerations
- Customer impact
9. SEV-1 Communication
SEV-1 incidents require immediate and coordinated communication.
Typical Communication Path
Incident Responder
↓
Incident Commander
↓
Security Leadership
↓
Technical Teams
↓
Business Owner
↓
Privacy/Legal
↓
Executive Management
↓
Customers/Regulators/Suppliers Where Required
The actual communication path should follow the organization’s approved escalation structure.
SEV-1 Updates
Updates should be frequent enough to support effective decision-making.
Each update should clearly state:
- What is known
- What changed
- What remains unknown
- Current impact
- Actions completed
- Actions underway
- Decisions required
- Next update time
10. SEV-2 Communication
SEV-2 incidents require prompt communication to the relevant security, technical, business, and management stakeholders.
Communication may include:
- Incident Manager
- Security Lead
- IT/Engineering
- Business Owner
- Privacy/Legal where applicable
- Supplier Owner where applicable
Executive escalation should occur if the impact increases or the incident meets SEV-1 criteria.
11. SEV-3 Communication
SEV-3 incidents are normally managed within the operational security/IT teams.
Management or business communication should occur where:
- Customer impact exists
- Sensitive information is involved
- The incident continues longer than expected
- Severity increases
- Additional support is required
12. SEV-4 Communication
SEV-4 events may be handled through normal operational channels.
Examples:
- Blocked phishing
- Failed attack
- Automated scanning
- Low-risk policy violation
Significant trends or repeated events should still be communicated during security or management reviews.
13. Technical Team Communication
Technical communication should contain sufficient detail for responders to act.
Examples:
- Affected IP addresses
- Hostnames
- Cloud resources
- IAM identities
- Logs
- Indicators of compromise
- Vulnerabilities
- Affected applications
- Configuration changes
- Containment status
Sensitive technical information should only be shared with authorized personnel.
14. Management Communication
Management communications should focus on:
- Business impact
- Customer impact
- Severity
- Current response status
- Risk
- Decisions required
- Resources required
- Expected recovery
- Regulatory/contractual considerations
- Residual risk
Management does not necessarily need every technical investigation detail.
15. Customer Communication
Customer communication may be required where an incident:
- Affects customer services
- Affects customer information
- Creates contractual notification obligations
- Causes significant service disruption
- Requires customer action
Before communication, the organization should assess:
- What is confirmed
- What information may be disclosed
- Contractual requirements
- Legal requirements
- Privacy requirements
- Customer impact
- Required customer actions
Customer communication should be approved by the designated business, legal/privacy, and management roles according to the organization’s RACI.
16. Customer Communication Principles
Customer communications should:
- Be factual
- Be timely
- Avoid speculation
- Explain known impact
- Explain actions taken
- Explain customer actions required, if any
- Provide a contact point
- Provide updates where appropriate
Do not unnecessarily disclose:
- Security architecture
- Credentials
- Internal vulnerabilities that could increase risk
- Investigation techniques
- Personal information
- Confidential third-party information
- Unverified attacker claims
17. Supplier Communication
Where a supplier is involved:
- Notify the Supplier Owner.
- Review contractual notification requirements.
- Contact the supplier through an approved channel.
- Request relevant incident information.
- Obtain the supplier’s incident reference.
- Assess organizational impact.
- Track supplier corrective actions.
- Record communications in the incident record.
Examples include:
- AWS
- SaaS providers
- Managed service providers
- Payment providers
- Security vendors
- Software suppliers
- Critical technology suppliers
18. Privacy and Personal Data Incidents
If personal data may be involved:
Security → Privacy → Legal → Business → Management
The Privacy/Legal function should assess:
- What information is involved
- Whose information is involved
- Whether unauthorized access occurred
- Whether information was disclosed or exfiltrated
- Applicable legal/regulatory requirements
- Contractual notification requirements
- Customer notification requirements
- Required timing
- Required content
The security team should provide evidence and technical findings without independently determining legal notification obligations.
19. Regulatory Communication
Where regulatory notification may be required:
- Identify the applicable requirement.
- Confirm whether the incident meets the reporting threshold.
- Identify the responsible authority.
- Determine required information.
- Establish the required reporting timeframe.
- Obtain appropriate Legal/Privacy approval.
- Submit through the authorized channel.
- Retain evidence of submission.
- Track subsequent regulator communications.
The organization should not assume that every security incident requires regulatory notification.
20. Law Enforcement Communication
Where law enforcement involvement is appropriate:
- Legal counsel should normally be consulted.
- Evidence should be preserved.
- Communication should be authorized.
- The organization should maintain a record of communications.
- Technical responders should avoid independently sharing sensitive information without authorization.
Law-enforcement involvement may be considered for serious incidents such as:
- Major ransomware
- Extortion
- Significant fraud
- Serious unauthorized access
- Major data theft
- Criminal activity
21. External Communication Approval
Before significant external communication, confirm:
| Question | Status |
|---|---|
| Incident confirmed? | |
| Severity confirmed? | |
| Information verified? | |
| Customer impact assessed? | |
| Privacy impact assessed? | |
| Legal requirements assessed? | |
| Contractual requirements assessed? | |
| Communication approved? | |
| Authorized spokesperson identified? | |
| Recipient confirmed? | |
| Communication recorded? |
22. Communication Channels
Approved communication channels may include:
- Incident management platform
- Secure collaboration channel
- Corporate email
- Emergency phone/voice bridge
- Approved messaging platform
- Ticketing system
- Supplier security portal
- Customer notification system
- Regulatory reporting portal
The organization should define which channels are appropriate for different severity levels.
For highly sensitive incidents, avoid using compromised systems or communication channels.
23. Communication Security
Incident communications may themselves contain sensitive information.
Therefore:
- Use approved corporate accounts.
- Restrict access to authorized personnel.
- Avoid unnecessary personal data.
- Do not include passwords or secrets.
- Do not send credentials through email or chat.
- Use secure file-sharing mechanisms for evidence.
- Avoid forwarding incident communications unnecessarily.
- Protect incident records from unauthorized modification.
- Consider whether an attacker may have access to the normal communication environment.
24. Out-of-Band Communication
Out-of-band communication should be considered when:
- Corporate email may be compromised.
- Collaboration platforms may be unavailable.
- Administrator accounts may be compromised.
- The attacker may monitor internal communications.
- The incident affects identity infrastructure.
Alternative approved communication methods should be maintained in the Incident Response Contact List.
25. Communication During Ransomware
During ransomware incidents:
- Assume affected communication systems may be compromised until verified.
- Use approved alternative communication channels where necessary.
- Do not rely solely on potentially compromised systems.
- Coordinate communications through the Incident Commander.
- Consult Legal regarding ransom/extortion communications.
- Coordinate customer/regulatory communication through authorized personnel.
- Avoid making unsupported statements about attacker activity.
26. Communication During Cloud Compromise
For an AWS SaaS incident, communication may involve:
Security → Cloud Engineering → Incident Commander → Business → Privacy/Legal → Executive Management
Technical updates may include:
- AWS account affected
- IAM identity affected
- Resources involved
- CloudTrail findings
- Containment status
- Data-access assessment
- Recovery status
Avoid distributing unnecessary cloud credentials, security configurations, or sensitive architectural information.
27. Incident Status Updates
Each significant update should follow a consistent structure.
Status
Current Severity:
[SEV-1 / SEV-2 / SEV-3 / SEV-4]
Current Status:
[Investigating / Contained / Recovering / Monitoring]
What We Know:
[Confirmed facts]
What Changed:
[Changes since previous update]
Current Impact:
[Business/customer/security impact]
Actions Completed:
[Completed actions]
Actions Underway:
[Current actions]
Outstanding Risks:
[Known remaining risks]
Decisions Required:
[Management decisions, if any]
Next Update:
[Date/Time]
28. Communication Log
All significant communications should be recorded.
| Date/Time | Sender | Recipient | Channel | Purpose | Key Information | Approval | Evidence |
|---|---|---|---|---|---|---|---|
Examples:
- Incident declaration
- Executive escalation
- Supplier notification
- Customer notification
- Regulatory submission
- Legal advice
- Recovery update
- Closure communication
29. Communication With the Incident Response Team
The Incident Commander should ensure that team members understand:
- Current severity
- Current incident owner
- Their assigned responsibilities
- Known facts
- Known unknowns
- Containment status
- Investigation priorities
- Communication restrictions
- Next decision point
The Incident Response Team RACI should be used to avoid unclear ownership.
30. Communication During Recovery
Recovery communication should confirm:
- Systems being restored
- Services restored
- Security controls restored
- Monitoring active
- Validation completed
- Business services operational
- Remaining risks
- Corrective actions
Recovery should not be communicated as complete until the responsible technical and business owners have verified it.
31. Incident Closure Communication
Before closing the incident:
- Confirm containment.
- Confirm eradication or acceptable control of the threat.
- Confirm recovery.
- Assess customer impact.
- Complete privacy/legal assessment.
- Confirm required notifications.
- Record corrective actions.
- Assess residual risk.
- Complete the Incident Closure Report.
- Communicate closure to relevant stakeholders.
32. Closure Communication Template
Subject: Security Incident Closure – [Incident ID]
Incident ID: [INC-XXXX]
Incident: [Short description]
Severity: [SEV level]
Incident Status: Closed
Summary:
[Brief factual summary]
Impact:
[Confirmed impact]
Actions Completed:
[Containment, investigation, eradication and recovery]
Customer/Privacy Impact:
[Assessment]
Corrective Actions:
[Actions remaining or completed]
Residual Risk:
[Summary]
Next Steps:
[Monitoring, corrective actions or lessons learned]
Incident Owner:
[Name/Role]
33. Communication Records and Evidence
Retain appropriate evidence such as:
- Incident emails
- Secure chat records
- Meeting records
- Phone/voice bridge records where documented
- Customer notifications
- Supplier notifications
- Regulatory submissions
- Legal communication records where appropriate
- Approval records
- Incident status updates
- Communication logs
Records should be retained according to the organization’s information retention requirements.
34. Communication Mistakes to Avoid
Do Not:
- Speculate about attackers.
- Announce an unconfirmed breach.
- Promise that no data was accessed before investigation is complete.
- Share passwords or secrets.
- Share unnecessary personal information.
- Send sensitive information through unapproved channels.
- Allow multiple teams to issue conflicting external statements.
- Delete incident communications.
- Delay urgent containment while waiting for a communication draft.
- Allow unauthorized employees to communicate externally.
35. Startup Implementation Model
A small SaaS startup can implement a simple communication structure:
SEV-1
Incident Commander → Security/Engineering → Business Owner → Legal/Privacy → Executive → Customers/Regulators Where Required
SEV-2
Security Lead → Technical Owner → Business Owner → Legal/Privacy Where Required → Management
SEV-3
Security/IT → Relevant Technical Owner → Management Where Required
SEV-4
Operational Security/IT → Normal Reporting
One person may perform multiple roles, but the organization should maintain clear decision authority.
36. Communication Testing
Communication arrangements should be tested periodically.
A tabletop exercise can test:
Incident Detected
→ Incident Declared
→ Security Team Activated
→ Executive Escalation
→ Customer Impact Identified
→ Privacy/Legal Assessment
→ Customer Communication Drafted
→ Supplier Notification
→ Recovery Update
→ Closure Communication
The test should evaluate:
- Contact availability
- Escalation speed
- Communication channels
- Approval process
- Message consistency
- Role clarity
- Evidence recording
- Out-of-band communication capability
37. ISO 27001 Connection
The procedure supports the organization’s information security incident management arrangements by establishing a controlled approach to:
- Incident reporting
- Internal escalation
- Incident coordination
- Management communication
- Technical communication
- Customer communication
- Supplier communication
- Legal/privacy coordination
- Regulatory communication
- Incident closure communication
The organization should determine communication requirements based on its:
- Information security risks
- Business structure
- ISMS scope
- Incident severity
- Customer requirements
- Contractual commitments
- Legal and regulatory obligations
- Supplier relationships
The procedure is an organizational implementation mechanism and should be tailored to the organization’s environment.
38. Audit Evidence
Useful evidence includes:
- Approved Security Incident Communication Procedure
- Incident Communication Log
- Incident Reports
- Escalation records
- Incident status updates
- Customer communications
- Supplier notifications
- Regulatory submissions
- Management communications
- Incident Closure Reports
- Communication approval records
- Tabletop exercise records
- Lessons Learned
- Corrective Action Tracker
39. Incident Communication Audit Trail
A complete communication trail should demonstrate:
Incident Detected
→ Incident Reported
→ Incident Validated
→ Severity Assigned
→ Incident Commander Assigned
→ Response Team Notified
→ Management Escalated Where Required
→ Technical Updates Provided
→ Business Impact Communicated
→ Privacy/Legal Engaged Where Required
→ Supplier Notified Where Required
→ Customer Notification Assessed
→ Regulatory Notification Assessed
→ Approved Communications Issued
→ Status Updates Recorded
→ Recovery Communicated
→ Closure Communicated
→ Lessons Learned
40. Final Principle
Communicate Early + Communicate Facts + Protect Sensitive Information + Use Authorized Channels + Escalate Appropriately + Keep Stakeholders Updated + Document Every Significant Communication.
Effective incident communication is not about communicating everything to everyone.
It is about ensuring that the right information reaches the right person at the right time, through the right channel, with the appropriate authorization.