ISO 27001 Incident Response Plan
1. Purpose
The Incident Response Plan defines how the organization detects, reports, assesses, contains, investigates, communicates, resolves, and learns from information security incidents.
The objective is to ensure that security incidents are handled in a structured, timely, and repeatable manner, while minimizing business impact and preserving relevant evidence.
The plan should work together with the organization’s:
- Information Security Policy
- Incident Management Policy
- Risk Register
- Business Continuity Plan
- Disaster Recovery Plan
- Authority & Regulatory Contact Register
- Data Breach / Privacy Incident Procedure
- Supplier Management Process
2. What Is an Information Security Incident?
An information security incident is an event that may compromise the confidentiality, integrity, or availability of information or information systems.
Examples include:
- Compromised user account
- Phishing attack
- Malware or ransomware
- Unauthorized access
- Data leakage
- Customer data exposure
- Lost or stolen device
- Privileged account misuse
- Cloud security incident
- Website/application compromise
- Vulnerability exploitation
- Denial-of-service attack
- Unauthorized change to production systems
- Third-party security incident
- Accidental disclosure of confidential information
Not every security event is necessarily an incident. The organization should assess events and determine whether formal incident response is required.
3. Incident Response Objectives
The incident response process should aim to:
- Detect incidents quickly.
- Report and escalate incidents appropriately.
- Assess the severity and potential impact.
- Contain the incident.
- Preserve relevant evidence.
- Remove the underlying cause where possible.
- Restore affected services securely.
- Communicate with relevant stakeholders.
- Meet applicable legal, regulatory, and contractual obligations.
- Identify lessons learned.
- Reduce the likelihood of recurrence.
4. Incident Response Lifecycle
The organization should follow a defined lifecycle:
Prepare
↓
Detect & Report
↓
Triage & Assess
↓
Contain
↓
Investigate
↓
Eradicate
↓
Recover
↓
Communicate
↓
Close
↓
Lessons Learned & Improve
This lifecycle should be adapted to the organization’s size, technology, risk profile, and incident type.
5. Phase 1 – Preparation
Effective incident response begins before an incident occurs.
The organization should maintain:
- Incident response procedures
- Incident reporting channels
- Incident response team / responsible personnel
- Contact information
- Escalation matrix
- Authority and regulatory contacts
- Customer communication process
- Backup and recovery procedures
- Logging and monitoring
- Security tools
- Evidence preservation procedures
- Communication templates
- Incident register
- Relevant supplier contacts
Startup Example
A SaaS startup may use:
- AWS CloudTrail
- AWS CloudWatch
- AWS GuardDuty
- Microsoft 365 / Google Workspace logs
- Endpoint security
- GitHub audit logs
- Application logs
- Ticketing system
- Password manager
- SIEM where justified
The organization should use existing technology wherever practical rather than creating unnecessary processes.
6. Phase 2 – Detect & Report
Security events may be identified through:
- Employees
- Customers
- Security monitoring
- Cloud alerts
- Vulnerability scanning
- Penetration testing
- Antivirus/EDR
- SIEM
- Application monitoring
- Suppliers
- Internal audit
- External parties
Employees should have a simple way to report suspected incidents.
Example Reporting Message
“I received a suspicious email that appears to request my corporate credentials. I have not entered my password. The email was received at 10:15 AM and is attached.”
The employee should not attempt to investigate or delete potential evidence unless instructed.
7. Phase 3 – Triage & Initial Assessment
The incident responder should determine:
- What happened?
- When did it happen?
- Who reported it?
- Which systems are affected?
- Which information is affected?
- Is the incident ongoing?
- Is unauthorized access suspected?
- Are customers affected?
- Is personal data involved?
- Is a supplier involved?
- What is the potential business impact?
- Are legal or regulatory obligations triggered?
Create an initial incident record immediately.
Initial Incident Record
| Field | Information |
|---|---|
| Incident ID | IR-2026-001 |
| Date/Time Reported | [Date/Time] |
| Reported By | [Name] |
| Incident Type | Unauthorized Access |
| Affected System | AWS Production |
| Initial Severity | High |
| Status | Investigating |
| Incident Owner | Security Lead |
| Business Owner | CTO |
| Personal Data Involved | Under Assessment |
| Customer Impact | Under Assessment |
| Regulatory Notification | Under Assessment |
8. Incident Severity Classification
The organization should define severity levels appropriate to its risk profile.
Example
| Severity | Description | Example |
|---|---|---|
| Critical | Major or potentially widespread impact | Confirmed customer data breach / ransomware affecting critical production |
| High | Significant security or business impact | Compromised privileged AWS account |
| Medium | Limited impact requiring investigation | Malware on one employee endpoint |
| Low | Minor security event | Suspicious email blocked before interaction |
Severity should be reassessed as new information becomes available.
A low-severity event can become a high-severity incident if evidence shows greater impact.
9. Phase 4 – Containment
The immediate objective is to prevent the incident from spreading or causing additional damage.
Possible containment actions include:
- Disable compromised account
- Revoke active sessions
- Reset credentials
- Rotate API keys
- Isolate endpoint
- Block malicious IP addresses
- Disable compromised access
- Restrict network connectivity
- Suspend affected integration
- Block malicious email
- Restrict affected cloud resource
- Temporarily disable vulnerable functionality
Containment decisions should consider the potential business impact of taking a system offline.
Example
If an AWS administrator account is compromised:
Detect → Disable/Restrict Account → Revoke Sessions → Rotate Credentials → Review CloudTrail → Identify Unauthorized Changes → Contain Affected Resources
10. Phase 5 – Investigation
The investigation should establish, as far as reasonably possible:
- What happened?
- How did the attacker or event originate?
- Which account or system was involved?
- What information was accessed?
- What actions were performed?
- How long did the activity continue?
- Which systems were affected?
- Whether the incident spread
- Whether data was accessed, modified, deleted, or exfiltrated
- Whether other systems may be compromised
Evidence Sources
Depending on the incident, evidence may include:
- Authentication logs
- AWS CloudTrail
- CloudWatch logs
- Application logs
- Firewall logs
- EDR alerts
- Email logs
- Identity provider logs
- GitHub audit logs
- Database logs
- Network logs
- Screenshots
- System timestamps
- Incident tickets
- Relevant communications
11. Evidence Preservation
Incident evidence should be preserved appropriately.
The organization should consider:
- Original logs
- Relevant timestamps
- Screenshots
- System records
- Access logs
- Email headers
- Files involved
- Incident communications
- Investigation notes
- Hashes where appropriate
- Chain-of-custody records where required
Evidence should be protected from unauthorized modification or deletion.
Where legal proceedings may be possible, the organization should involve appropriate legal or forensic specialists.
12. Phase 6 – Eradication
After sufficient investigation, the organization should remove or address the cause of the incident.
Possible actions:
- Remove malware
- Patch exploited vulnerability
- Disable compromised accounts
- Rotate credentials
- Remove unauthorized access
- Rebuild compromised systems
- Remove malicious code
- Correct insecure configuration
- Update firewall rules
- Remove unauthorized applications
- Correct access permissions
Eradication should address the underlying cause rather than only the visible symptom.
13. Phase 7 – Recovery
Affected services should be restored in a controlled manner.
Before returning systems to normal operation, verify:
- Vulnerability has been addressed
- Unauthorized access has been removed
- Credentials have been rotated where required
- Security configurations are correct
- Monitoring is active
- Backups are available
- Systems are functioning correctly
- Business owners approve restoration where appropriate
Recovery Flow
Contain → Correct → Validate → Monitor → Restore → Observe
Enhanced monitoring may be appropriate following a significant incident.
14. Phase 8 – Communication & Escalation
Incident communication should be controlled.
Potential stakeholders include:
- Top Management
- Security Team
- IT / Engineering
- Legal
- Privacy Team
- HR
- Customers
- Suppliers
- Insurance provider
- Regulators
- Law enforcement
- External forensic specialists
Not every incident requires communication to every stakeholder.
The incident owner should determine communication requirements based on the incident, contractual obligations, legal requirements, and business impact.
15. Regulatory & Authority Notification
When an incident may trigger legal or regulatory notification:
Incident Identified
↓
Determine Jurisdictions
↓
Assess Applicable Requirements
↓
Determine Whether Notification Is Required
↓
Consult Legal / Compliance
↓
Identify Authority
↓
Prepare Required Information
↓
Obtain Required Approval
↓
Submit Through Official Channel
↓
Record Notification & Reference Number
↓
Track Follow-up
The Authority & Regulatory Contact Register should be used to identify the relevant authority and official communication channel.
Notification deadlines and required information should be determined from the applicable law or regulatory requirement rather than assumed.
16. Customer Communication
Customer notification may be required by:
- Contract
- Applicable law
- Regulatory requirements
- Business decision
- Customer-specific security requirements
Customer communications should be:
- Accurate
- Timely
- Approved by the appropriate internal function
- Based on verified information
- Clear about known facts and uncertainties
- Coordinated with legal/compliance requirements
Avoid communicating unverified technical conclusions.
17. Incident Response Roles
| Role | Responsibility |
|---|---|
| Top Management | Strategic decisions and major business escalation |
| Incident Manager | Coordinates overall response |
| Security Lead / CISO | Security assessment and technical coordination |
| IT / Engineering | Technical containment, investigation and recovery |
| Legal | Legal obligations and external communications |
| Privacy Lead | Personal-data impact assessment |
| HR | Employee-related incidents |
| Communications / Customer Success | Customer communication where authorized |
| System Owner | Business impact and system recovery |
| External Specialist | Forensics, legal or technical support where required |
For a small startup, one person may perform multiple roles. However, conflicts of interest and approval requirements should be considered.
18. Incident Escalation Matrix
| Trigger | Escalate To | Target |
|---|---|---|
| Suspected account compromise | Security Lead / IT | Immediately |
| Privileged account compromise | CTO / Security Lead | Immediately |
| Customer data exposure | Security + Privacy + Legal | Immediately |
| Major production outage caused by security event | CTO / Management | Immediately |
| Suspected criminal activity | Legal / Management | As appropriate |
| Potential regulatory notification | Legal / Compliance | Immediately |
| Major supplier security incident | Supplier Owner + Security | Immediately |
| Confirmed critical incident | Incident Manager + Top Management | Immediately |
The organization should define specific response and escalation targets appropriate to its business and risk profile.
19. Incident Response Communication Tree
Example:
Employee / Monitoring Tool
↓
Security Lead
↓
Incident Manager
↓
CTO / Management
↓
Legal / Privacy
↓
Customer / Regulator / Authority
where applicable.
For critical incidents, the organization should maintain an out-of-band communication method in case normal corporate systems are unavailable.
20. Incident Management Record
Each significant incident should have a record containing, as applicable:
| Field | Example |
|---|---|
| Incident ID | IR-2026-001 |
| Date Detected | 30-Sep-2026 |
| Date Occurred | 30-Sep-2026 |
| Reporter | Employee |
| Incident Type | Phishing |
| Severity | Medium |
| Affected Asset | Microsoft 365 |
| Description | Credential phishing email |
| Initial Actions | Account secured |
| Containment | Session revoked |
| Investigation | Login activity reviewed |
| Root Cause | User interaction with phishing link |
| Data Impact | None identified |
| Customer Impact | None |
| Regulatory Impact | None identified |
| Corrective Action | MFA verification + awareness training |
| Owner | Security Lead |
| Closure Date | [Date] |
| Lessons Learned | [Details] |
21. Lessons Learned
After an incident has been resolved, conduct a post-incident review for significant incidents.
Questions should include:
- What happened?
- How was it detected?
- What worked well?
- What did not work?
- Was escalation timely?
- Were the right people involved?
- Was evidence preserved?
- Were communications effective?
- Were legal/regulatory requirements considered?
- Did existing controls operate as expected?
- What caused the incident?
- What should be changed?
- Does the risk register need updating?
- Are additional controls required?
- Does the incident require security awareness or training?
- Should policies or procedures be updated?
22. Corrective Actions
Lessons learned should result in tracked improvement actions where appropriate.
| Action ID | Issue | Corrective Action | Owner | Due Date | Status | Evidence |
|---|---|---|---|---|---|---|
| CA-001 | Weak MFA enforcement | Enforce MFA for privileged accounts | IT | [Date] | Open | Configuration |
| CA-002 | Phishing awareness gap | Conduct targeted awareness training | HR/Security | [Date] | Open | Training record |
| CA-003 | Excessive privilege | Review AWS IAM permissions | CTO | [Date] | Open | Access review |
Corrective actions should be tracked until completion and their effectiveness should be evaluated where appropriate.
23. Link to the Risk Register
A significant incident should trigger consideration of whether the organization’s risk assessment remains valid.
Example:
Incident: Compromised AWS administrator account
↓
Existing Risk: Unauthorized production access
↓
Risk Register Review
↓
Assess Existing Controls
↓
Update Risk Rating if Necessary
↓
Additional Treatment
↓
Implement Control
↓
Collect Evidence
↓
Verify Effectiveness
This connects incident management with the wider ISMS.
24. Incident Response Evidence
Possible audit evidence includes:
- Incident Response Plan
- Incident Management Policy
- Incident register
- Incident tickets
- Security alerts
- Investigation records
- Log evidence
- Containment records
- Recovery records
- Regulatory notifications
- Customer communications
- Lessons-learned records
- Corrective action records
- Updated risk assessments
- Security monitoring reports
- Incident response test/exercise records
Sensitive incident information should be protected from unauthorized access.
25. Incident Response Testing
The organization should periodically test whether its incident response process actually works.
Testing can include:
Tabletop Exercise
Example:
“An attacker has obtained credentials for an AWS privileged account. What does the organization do during the first 30 minutes?”
Participants discuss:
- Who receives the alert?
- Who takes ownership?
- Who disables the account?
- Who investigates?
- Who contacts management?
- Is customer data affected?
- Who determines notification requirements?
- Who communicates with customers?
- What evidence is collected?
Technical Simulation
Where appropriate, the organization may conduct controlled technical exercises to test detection, containment, and recovery capabilities.
After the Exercise
Record:
- Scenario
- Participants
- Expected response
- Actual response
- Gaps identified
- Corrective actions
- Owners
- Target dates
26. AWS SaaS Startup Example
Scenario
An AWS production administrator account shows an unexpected login from an unfamiliar location.
Response
1. Detect
CloudTrail / identity monitoring generates an alert.
2. Report
Security Lead opens incident IR-2026-004.
3. Triage
Determine:
- Account involved
- Login time
- Source
- Actions performed
- Resources accessed
- Possible data exposure
4. Contain
- Disable/restrict account
- Revoke active sessions
- Rotate credentials
- Review privileged access
5. Investigate
Review CloudTrail and other relevant logs.
6. Eradicate
Remove unauthorized access and correct the underlying weakness.
7. Recover
Validate AWS configuration and restore normal operations.
8. Assess Impact
Determine whether customer information or other sensitive information was accessed.
9. Regulatory/Contractual Assessment
Legal/Compliance determines whether notification obligations apply.
10. Lessons Learned
Update:
- Risk Register
- Access Control
- MFA controls
- Privileged access process
- Monitoring
- Security awareness
- Incident response procedures
27. Incident Response Checklist
Preparation
- Incident Response Plan approved
- Incident response roles assigned
- Contact list maintained
- Authority contacts identified
- Monitoring implemented
- Logging enabled
- Backup/recovery process established
- Communication channels defined
Detection
- Event reported
- Incident ID created
- Initial severity assigned
- Affected assets identified
- Incident owner assigned
Response
- Incident contained
- Evidence preserved
- Investigation performed
- Root cause assessed
- Regulatory requirements assessed
- Customer impact assessed
- Required notifications completed
Recovery
- Threat removed
- Vulnerability addressed
- Systems validated
- Services restored
- Enhanced monitoring performed
Improvement
- Lessons learned completed
- Corrective actions recorded
- Risk Register reviewed
- Controls reviewed
- Policies updated where necessary
- Management informed
28. ISO 27001 Connection
The Incident Response Plan supports the organization’s broader ISMS by connecting:
Security Event → Incident → Risk Assessment → Response → Evidence → Corrective Action → Risk Update → Continual Improvement
The organization should be able to demonstrate not only that it has an incident response document, but that it can detect, respond to, record, learn from, and improve after information security incidents.
29. Final Principle
A good incident response plan should answer five questions quickly:
What happened?
Who is responsible?
What do we do now?
Who needs to be informed?
What will we change afterward?
For a startup, incident response does not need to be complicated.
A practical model is:
Detect → Assess → Contain → Investigate → Recover → Communicate → Learn → Improve