What is ISO 27001 Annex A 5.26 – Response to Information Security Incidents?
ISO 27001 Annex A 5.26 focuses on ensuring that the organization responds to information security incidents according to established procedures.
A.5.24 focuses on planning and preparation.
A.5.25 focuses on assessing security events and deciding whether they constitute incidents.
A.5.26 focuses on what the organization actually does after an incident has been identified.
The objective is to ensure that incidents are handled in a controlled, coordinated, and documented manner.
Examples include:
- Compromised user accounts
- Malware infections
- Ransomware
- Data breaches
- Unauthorized access
- Phishing-related compromise
- Lost or stolen devices
- Cloud account compromise
- API key exposure
- Source-code leakage
- Denial-of-service attacks
- Insider security incidents
- Third-party security incidents
Simple Explanation
Once a security event has been identified as an incident, the organization must respond quickly, systematically, and according to its defined incident-response process.
Why is ISO 27001 Annex A 5.26 Important?
Security incidents can develop quickly.
A compromised account can be used to:
Access email → steal credentials → access cloud systems → access customer data → create persistence → cause further damage
A delayed or poorly coordinated response can increase the impact.
A structured response helps the organization:
- Contain the incident
- Limit damage
- Protect information
- Preserve evidence
- Restore services
- Meet contractual obligations
- Assess notification requirements
- Coordinate internal and external teams
- Document decisions
- Learn from the incident
Simple Principle
The objective of incident response is not simply to fix the immediate problem. It is to control the incident, understand its impact, recover safely, and prevent further damage.
A.5.24 vs. A.5.25 vs. A.5.26
These three controls should be understood together.
| Control | Main Question |
|---|---|
| A.5.24 | Are we prepared for security incidents? |
| A.5.25 | Is this security event an incident, and how serious is it? |
| A.5.26 | How do we respond to the identified incident? |
The overall flow is:
Prepare → Detect → Assess → Decide → Respond → Recover → Learn
What Does A.5.26 Require?
The organization should establish and implement procedures for responding to information-security incidents.
The response should be:
- Timely
- Coordinated
- Risk-based
- Documented
- Authorized
- Consistent with the incident-management process
Depending on the incident, response activities may include:
- Incident declaration
- Initial assessment
- Containment
- Investigation
- Evidence preservation
- Eradication
- Recovery
- Communication
- Notification assessment
- Incident closure
1. Activate the Incident Response Process
Once A.5.25 determines that an event is an incident, the appropriate response process should be activated.
Example:
Suspicious login
↓
Assessment
↓
Confirmed compromised administrator account
↓
Incident declared
↓
Incident response process activated
The organization should assign an incident owner.
2. Record the Incident
Create an incident record.
Example:
| Field | Example |
|---|---|
| Incident ID | INC-2026-007 |
| Date/time detected | 15 March 2026 10:15 UTC |
| Incident type | Account compromise |
| Affected system | Google Workspace |
| Severity | High |
| Incident owner | Security Lead |
| Status | Investigating |
| Initial impact | Potential unauthorized access |
The incident record should be updated throughout the response.
3. Perform Initial Assessment
The response team should quickly establish what is known.
Questions may include:
- What happened?
- When did it happen?
- How was it detected?
- Which systems are affected?
- Which accounts are affected?
- What information may be affected?
- Is the attacker still active?
- Is the incident ongoing?
- Is customer information involved?
- Is production affected?
At this stage, the objective is to obtain enough information to make immediate decisions.
4. Contain the Incident
Containment aims to stop the incident from getting worse.
Examples:
Compromised Account
- Disable account
- Reset password
- Revoke sessions
- Revoke tokens
- Remove unauthorized MFA methods
Compromised Cloud Credential
- Revoke key
- Rotate credentials
- Restrict permissions
- Review cloud activity
Malware
- Isolate endpoint
- Block malicious communication
- Disable affected account if necessary
Ransomware
- Isolate affected systems
- Prevent further network spread
- Protect backups
- Restrict compromised credentials
Containment should be performed carefully so that important evidence is not unnecessarily destroyed.
5. Preserve Evidence
Incident response should consider evidence preservation.
Potential evidence includes:
- Authentication logs
- Cloud logs
- Firewall logs
- EDR records
- Email records
- Application logs
- Database logs
- Screenshots
- Malware samples
- System images
- Relevant communications
Evidence should be protected from unauthorized modification or deletion.
For serious incidents, specialist forensic support may be appropriate.
This connects directly with A.5.28 – Collection of Evidence.
6. Investigate the Incident
The organization should determine:
What happened?
Identify the initial event.
How did it happen?
For example:
- Phishing
- Stolen password
- Vulnerability
- Misconfiguration
- Malware
- Insider action
- Supplier compromise
What was affected?
Identify:
- Systems
- Accounts
- Applications
- Data
- Customers
- Suppliers
How long did it continue?
Determine the likely timeline.
What actions did the attacker perform?
Look for:
- Logins
- Privilege escalation
- Data access
- Credential creation
- Configuration changes
- Data transfer
- Persistence mechanisms
7. Eradicate the Cause
After containment and investigation, remove the underlying cause where practical.
Examples:
Compromised Account
Disable → Reset → Revoke sessions → Remove unauthorized access → Re-enable securely
Malware
Isolate → Remove malware → Patch → Rebuild if required → Validate
Vulnerability
Identify → Patch → Test → Validate → Monitor
Exposed API Key
Revoke → Rotate → Identify usage → Investigate → Secure storage
The organization should avoid simply fixing the visible symptom while leaving the root cause unresolved.
8. Recover Systems
After containment and eradication, restore affected systems safely.
Recovery may include:
- Restoring backups
- Rebuilding systems
- Reinstalling software
- Restoring configurations
- Re-enabling accounts
- Validating system integrity
- Monitoring for recurrence
Recovery should be controlled.
Do not simply restore a compromised system without understanding whether the original attack path remains open.
9. Verify That the Incident Is Contained
Before closing an incident, determine whether:
- Unauthorized access has stopped
- Compromised credentials have been revoked
- Malware has been removed
- Vulnerabilities have been addressed
- Unauthorized accounts have been removed
- Monitoring is active
- Systems are functioning normally
For significant incidents, additional monitoring may be appropriate.
10. Manage Communications
Incident communication should follow the organization’s established communication process.
Potential audiences include:
- Employees
- Management
- Customers
- Suppliers
- Regulators
- Law enforcement
- Insurance providers
Not every incident requires communication to every group.
Communication should be:
- Accurate
- Authorized
- Timely
- Appropriate to the situation
Employees should not independently communicate unverified incident information externally.
11. Assess Notification Requirements
Some incidents may create notification obligations.
The organization should assess:
- Applicable laws
- Regulatory requirements
- Customer contracts
- Data-processing agreements
- Insurance requirements
- Industry-specific requirements
For example, an incident involving personal information may require a separate privacy/legal assessment.
The incident response team should involve appropriate legal or privacy specialists when required.
12. Coordinate with Third Parties
Some incidents require coordination with external organizations.
Examples:
- Cloud providers
- SaaS vendors
- Managed security providers
- Payment processors
- Cybersecurity consultants
- Forensic specialists
- Legal counsel
- Cyber insurers
For example:
Cloud account compromise
→ Internal security team
→ Cloud provider
→ Forensic/security specialist
→ Legal/privacy
→ Management
The response should follow the organization’s supplier and incident-management arrangements.
13. Document Decisions and Actions
Every significant incident should have an appropriate record.
Document:
- What happened
- When it happened
- Who responded
- What was discovered
- What decisions were made
- Why decisions were made
- What actions were taken
- What systems were affected
- What information was affected
- What communications occurred
- What corrective actions were identified
Documentation helps with:
- Auditability
- Legal review
- Customer communication
- Lessons learned
- Management reporting
- Future prevention
14. Close the Incident
An incident should not be closed simply because the immediate problem appears fixed.
Before closure, verify:
- Containment completed
- Investigation completed
- Recovery completed
- Required communications completed
- Evidence preserved
- Corrective actions assigned
- Risk reassessed
- Lessons learned captured
The incident can then be formally closed.
Startup Example
Consider a SaaS startup operating on AWS.
A security alert identifies unauthorized access to an administrator account.
Step 1 – Incident Declared
The event has already been assessed under A.5.25 and classified as a high-severity incident.
Step 2 – Contain
The security team:
- Disables the account
- Revokes active sessions
- Revokes API keys
- Blocks suspicious access
Step 3 – Preserve Evidence
The team preserves:
- AWS CloudTrail logs
- Identity logs
- Application logs
- Relevant security alerts
Step 4 – Investigate
The team discovers that credentials were obtained through phishing.
Step 5 – Determine Impact
The investigation identifies:
- Unauthorized AWS access
- Access to production systems
- No evidence of customer-data extraction at the time of assessment
Step 6 – Eradicate
The company:
- Resets affected credentials
- Enables stronger authentication
- Removes unauthorized access
- Reviews IAM permissions
Step 7 – Recover
Production systems are validated and returned to normal operation.
Step 8 – Communicate
Management and relevant internal stakeholders are informed.
Legal/privacy teams assess whether any external notification is required.
Step 9 – Close
The incident report is completed and corrective actions are assigned.
Step 10 – Improve
The company introduces:
- Phishing-resistant authentication where appropriate
- Additional security awareness training
- Improved privileged-access controls
- Enhanced monitoring
This demonstrates a complete response rather than simply “resetting the password.”
Startup-Focused Quick Summary
A startup can implement A.5.26 using the following sequence:
1. Declare
Confirm the event is an incident.
2. Assign
Appoint an incident owner.
3. Assess
Understand the initial impact.
4. Contain
Stop the incident from spreading or continuing.
5. Preserve
Protect relevant evidence.
6. Investigate
Determine what happened and why.
7. Eradicate
Remove the cause and attacker access.
8. Recover
Restore affected systems securely.
9. Communicate
Inform appropriate stakeholders.
10. Close
Document the outcome and assign corrective actions.
Example Incident Response Timeline
| Time | Action | Owner |
|---|---|---|
| 10:15 | Alert detected | Security |
| 10:20 | Incident declared | Incident Manager |
| 10:25 | Account disabled | IT |
| 10:30 | Sessions revoked | IT |
| 10:40 | Evidence preserved | Security |
| 11:00 | Initial investigation | Security |
| 12:00 | Impact assessment | Incident Team |
| 13:00 | Management briefing | Incident Manager |
| 15:00 | Root cause identified | Security |
| 16:00 | Remediation completed | IT |
| Next day | Recovery validation | Engineering |
| Day 2 | Incident review | Management |
| Day 3 | Corrective actions assigned | Security |
This type of timeline can provide useful evidence that the organization followed a controlled process.
Incident Response Checklist
Initial Response
- Incident declared
- Incident owner assigned
- Severity confirmed
- Affected systems identified
- Incident record created
Containment
- Compromised accounts disabled
- Credentials/tokens revoked
- Affected systems isolated where required
- Attack path restricted
- Additional compromise checked
Evidence
- Relevant logs preserved
- Evidence protected
- Timeline established
- Relevant communications retained
Investigation
- Root cause investigated
- Systems affected identified
- Data potentially affected identified
- Attacker activity assessed
- Customer impact assessed
Eradication
- Malware removed
- Vulnerabilities addressed
- Credentials rotated
- Unauthorized access removed
- Security controls strengthened
Recovery
- Systems restored
- Backups validated where applicable
- System integrity checked
- Monitoring increased
- Business operations restored
Closure
- Incident report completed
- Notifications assessed
- Corrective actions assigned
- Lessons learned recorded
- Incident formally closed
Audit Evidence for Annex A 5.26
An auditor may review evidence showing that actual incidents are handled according to established procedures.
Policies and Procedures
- Incident Management Policy
- Incident Response Procedure
- Incident Escalation Procedure
- Data Breach Response Procedure
- Evidence Handling Procedure
Incident Records
- Incident tickets
- Incident reports
- Incident timelines
- Investigation records
- Root-cause analysis
- Corrective-action records
Technical Evidence
- Authentication logs
- Cloud logs
- EDR records
- Firewall logs
- SIEM alerts
- System recovery records
- Backup restoration evidence
Communication Evidence
- Management notifications
- Customer communications where applicable
- Supplier communications
- Legal/privacy assessments
Improvement Evidence
- Post-incident review
- Lessons learned
- Corrective actions
- Updated procedures
- Security-control improvements
Audit Checklist
Incident Activation
- Is there a defined process for activating incident response?
- Is an incident owner assigned?
- Is severity confirmed?
Containment
- Are containment procedures defined?
- Are compromised credentials revoked?
- Can affected systems be isolated?
- Are critical systems protected from further impact?
Investigation
- Is evidence preserved?
- Is the incident timeline documented?
- Is root cause investigated?
- Is impact assessed?
Eradication
- Is the underlying cause addressed?
- Are vulnerabilities remediated?
- Are compromised credentials rotated?
- Is unauthorized access removed?
Recovery
- Are systems safely restored?
- Is system integrity validated?
- Is additional monitoring performed?
Communication
- Are communication responsibilities defined?
- Are legal/privacy requirements assessed?
- Are customer notification requirements considered?
Closure
- Is the incident report completed?
- Are corrective actions assigned?
- Are lessons learned captured?
- Is the incident formally closed?
Common Mistakes
1. Only Resetting the Password
If an account is compromised, changing the password may not be enough.
The organization should investigate:
- Active sessions
- API tokens
- OAuth applications
- MFA settings
- Privileged access
- Other systems accessed
2. Destroying Evidence During Containment
Immediately rebuilding or deleting an affected system may remove useful evidence.
Containment should consider investigation requirements.
3. Focusing Only on Technical Recovery
Restoring the system does not automatically mean the incident is finished.
The organization should also assess:
- Data impact
- Customer impact
- Legal obligations
- Root cause
- Corrective actions
4. No Incident Owner
A response involving ten people but nobody accountable can become chaotic.
Assign an incident manager.
5. Poor Communication
Unverified information can create additional problems.
Use predefined communication and approval processes.
6. No Documentation
If actions and decisions are not recorded, it becomes difficult to demonstrate what happened or learn from it.
7. Closing Too Early
The incident should not be closed simply because the immediate symptom disappeared.
Confirm containment, investigation, remediation, and recovery.
8. No Root-Cause Remediation
If the organization fixes the immediate problem but does not address the underlying cause, the incident may happen again.
Practical Startup Implementation Model
A simple model for A.5.26 is:
Declare → Contain → Preserve → Investigate → Eradicate → Recover → Communicate → Close
Declare
Activate the incident process.
Contain
Stop the incident from getting worse.
Preserve
Protect relevant evidence.
Investigate
Determine what happened and the extent of impact.
Eradicate
Remove the cause and attacker access.
Recover
Restore secure operations.
Communicate
Inform appropriate stakeholders.
Close
Document the incident and assign corrective actions.
Policy vs. Process vs. Evidence
| Area | Policy | Process | Evidence |
|---|---|---|---|
| Incident response | Incident Management Policy | Incident Response Procedure | Incident report |
| Containment | Incident Response Policy | Containment Procedure | Containment record |
| Investigation | Investigation Policy | Investigation Procedure | Investigation report |
| Evidence | Evidence Handling Policy | Evidence Preservation Process | Logs/evidence |
| Recovery | Business Continuity Policy | Recovery Procedure | Recovery record |
| Communication | Incident Communication Policy | Communication Process | Approved communications |
| Closure | Incident Management Policy | Incident Closure Process | Closure report |
| Corrective action | Security Improvement Policy | Remediation Process | Action tracker |
Relationship with Other ISO 27001 Controls
A.5.24 – Incident Management Planning and Preparation
Establishes the organization’s incident-response readiness.
A.5.25 – Assessment and Decision on Information Security Events
Determines whether an event is an incident and how it should be classified.
A.5.26 – Response to Information Security Incidents
Defines and implements the actual response.
A.5.27 – Learning from Information Security Incidents
Uses incidents to improve the organization’s security.
A.5.28 – Collection of Evidence
Supports appropriate collection and preservation of evidence.
A.8.8 – Management of Technical Vulnerabilities
Relevant when incidents are caused by or expose technical vulnerabilities.
A.8.15 – Logging
Provides information required for investigation.
A.8.16 – Monitoring Activities
Supports detection and investigation.
A.8.32 – Change Management
Important when remediation requires controlled changes to systems.
The overall lifecycle becomes:
Prepare → Assess → Respond → Learn → Preserve Evidence
Useful Documents for A.5.26
A startup may create:
- Incident Response Procedure
[Insert Draft Document Link] - Incident Response Playbook – Account Compromise
[Insert Draft Document Link] - Incident Response Playbook – Ransomware
[Insert Draft Document Link] - Incident Response Playbook – Data Breach
[Insert Draft Document Link] - Incident Response Playbook – Phishing
[Insert Draft Document Link] - Incident Response Playbook – Cloud Compromise
[Insert Draft Document Link] - Incident Investigation Template
[Insert Draft Document Link] - Incident Timeline Template
[Insert Draft Document Link] - Incident Closure Report
[Insert Draft Document Link] - Corrective Action Tracker
[Insert Draft Document Link]
Questions an Auditor May Ask
An auditor may ask:
What happens after a security event is classified as an incident?
Who takes ownership of the incident?
How do you contain a compromised account?
How do you preserve evidence?
How do you determine which systems and information were affected?
How do you investigate the root cause?
How do you determine whether customers or regulators need to be notified?
How do you recover affected systems?
Can you show an example of a completed incident report?
How do you ensure corrective actions are completed?
How do you know that the incident has been fully contained before closing it?
Startup-Focused Final Takeaway
ISO 27001 Annex A 5.26 is about turning incident-management plans into action.
A startup does not need a huge security operations center to implement this control effectively.
It needs a clear process that allows the team to move from:
Incident identified
↓
Contain the threat
↓
Preserve evidence
↓
Investigate
↓
Remove the cause
↓
Recover securely
↓
Communicate appropriately
↓
Document and improve
Key Principle
Incident response is not simply fixing what broke. It is controlling the incident, understanding what happened, protecting evidence, recovering safely, and reducing the chance of recurrence.
Simple Sequence
Declare → Contain → Preserve → Investigate → Eradicate → Recover → Communicate → Close
That is the practical purpose of ISO 27001 Annex A 5.26 – Response to Information Security Incidents.