What is ISO 27001 Annex A 5.24 – Information Security Incident Management Planning and Preparation?
ISO 27001 Annex A 5.24 focuses on ensuring that the organization is prepared to respond effectively to information security incidents.
An organization should not wait until a security incident occurs to decide:
- Who should respond?
- Who should be contacted?
- What should be done first?
- Who has authority to make decisions?
- How should evidence be preserved?
- When should customers be informed?
- When should regulators or authorities be contacted?
- How should the incident be documented?
- How should the organization recover?
A.5.24 is therefore primarily about planning and preparation.
It establishes the foundation for the incident-management controls that follow.
Examples of Information Security Incidents
An incident could include:
- Ransomware
- Malware infection
- Phishing attack
- Stolen credentials
- Unauthorized access
- Data breach
- Accidental disclosure of information
- Lost or stolen device
- Cloud misconfiguration
- DDoS attack
- Compromised API key
- Source-code exposure
- Insider misuse
- Website compromise
- Third-party security incident
- Business email compromise
- Significant vulnerability exploitation
Simple Explanation
Before an incident happens, decide who will respond, what they will do, how they will communicate, and how the incident will be controlled and documented.
Why is ISO 27001 Annex A 5.24 Important?
Security incidents often happen under pressure.
During an incident, people may have incomplete information, limited time, and competing priorities.
Without preparation, an organization may:
- Delay containment
- Destroy evidence
- Contact the wrong people
- Make inconsistent decisions
- Fail to meet contractual obligations
- Miss regulatory notification requirements
- Communicate incorrect information
- Lose track of actions
- Increase the impact of the incident
A prepared organization can respond more systematically.
Simple Principle
You cannot predict every incident, but you can prepare how your organization will respond.
What Does Annex A 5.24 Require?
The organization should establish and maintain processes for preparing to manage information-security incidents.
This includes establishing:
- Incident-management responsibilities
- Roles and authorities
- Reporting channels
- Incident classification
- Escalation procedures
- Communication procedures
- Response procedures
- Contact information
- Evidence-handling arrangements
- Coordination with relevant internal and external parties
- Training and awareness
- Testing or exercising of incident-response arrangements
The level of preparation should be proportionate to the organization’s size, complexity, risks, and business requirements.
A 15-person SaaS startup does not necessarily need the same incident-response structure as a multinational bank.
However, it still needs to know:
Who responds → What happens → Who decides → Who communicates → How the incident is documented
A.5.24 vs. Incident Response
It is useful to understand that incident management is a lifecycle.
A simplified model is:
Prepare → Detect → Report → Assess → Respond → Recover → Learn
A.5.24 primarily addresses the Prepare stage.
The organization should have the necessary foundation before an incident occurs.
1. Establish an Information Security Incident Management Process
Create a documented process explaining how incidents are handled.
A basic process could be:
Report
↓
Record
↓
Triage
↓
Classify
↓
Escalate
↓
Contain
↓
Investigate
↓
Eradicate
↓
Recover
↓
Close
↓
Learn
Not every incident will require every stage at the same level of detail.
2. Define Incident Management Roles and Responsibilities
Someone must be responsible for coordinating the response.
Typical roles may include:
| Role | Responsibility |
|---|---|
| Incident Manager | Coordinates overall response |
| IT/Security Lead | Technical investigation and containment |
| Management | Business decisions and escalation |
| Legal | Legal and regulatory assessment |
| HR | Employee-related incidents |
| Communications | Internal/external communications |
| Privacy Lead/DPO | Personal-data breach assessment |
| System Owner | Supports affected system |
| Vendor Manager | Coordinates with suppliers |
| External Expert | Specialist support where required |
In a startup, one person may perform several roles.
For example:
CTO = Incident Manager + Technical Lead
Founder/CEO = Executive Decision Maker
External Legal Counsel = Legal/Regulatory Advisor
The important point is not the number of people.
The important point is that responsibilities are clearly defined.
3. Define Incident Reporting Channels
Employees should know how to report a suspected security incident.
Possible channels include:
- security@company.com
- Dedicated incident ticket
- Security hotline
- IT helpdesk
- Slack/Teams emergency channel
- Phone escalation
- Incident-management platform
The reporting mechanism should be practical.
For critical incidents, relying exclusively on normal corporate email may not be sufficient if the email environment itself is compromised.
4. Define What Should Be Reported
Employees should understand that they do not need to determine whether something is definitely a security incident.
They should report suspicious events such as:
- Unexpected password reset
- Suspicious login
- Phishing email
- Lost laptop
- Unknown software
- Accidental data disclosure
- Suspicious file encryption
- Unauthorized access
- Strange cloud activity
- Exposed credentials
- Customer reporting a security issue
Important Principle
Employees should report suspected incidents; trained personnel should determine their severity.
5. Define Incident Classification
Not every event has the same impact.
A startup can use a simple classification model.
| Severity | Example | Response |
|---|---|---|
| Low | Suspicious email reported | Normal investigation |
| Medium | Employee account compromised | Security escalation |
| High | Customer data potentially exposed | Incident team activated |
| Critical | Ransomware affecting production | Executive escalation |
The organization should define what triggers escalation.
6. Define Incident Escalation
An incident should be escalated when its impact exceeds predefined thresholds.
Escalation factors may include:
- Number of affected users
- Customer impact
- Sensitive information involved
- Production outage
- Financial impact
- Regulatory implications
- Media/public exposure
- Critical supplier involvement
- Potential criminal activity
For example:
Potential customer data breach
→ Security Lead
→ Incident Manager
→ Management
→ Legal/Privacy
→ Customer/regulatory notification assessment
7. Establish an Incident Response Team
Organizations should identify the people who may participate in incident response.
For a startup:
Core Incident Team
- CTO / Technical Lead
- Security Lead
- Founder/Management
- IT Administrator
Supporting Team
- Legal counsel
- Privacy advisor
- HR
- Communications
- Cloud provider
- Managed security provider
- Cybersecurity consultant
- Forensics specialist
Maintain an updated contact list.
8. Maintain Emergency Contact Information
During an incident, people should not waste time searching for contact details.
Maintain an Incident Contact List containing:
- Internal contacts
- Management contacts
- IT/security contacts
- Legal contacts
- Privacy contacts
- Key cloud providers
- Critical suppliers
- Cyber insurance provider
- External forensic experts
- Relevant authorities where applicable
The contact list should be periodically reviewed.
9. Establish Communication Procedures
Incident communication should be controlled.
The organization should define:
- Who can communicate externally
- Who can communicate with customers
- Who communicates with regulators
- Who communicates with employees
- Who communicates with media
- How incident information is approved
- What information can be disclosed
This helps prevent conflicting or premature statements.
Example
A developer discovers possible customer-data exposure.
The developer should not independently email every customer.
Instead:
Developer → Incident Team → Assessment → Management/Legal → Approved Communication
10. Prepare Incident Response Procedures
Create practical procedures for common scenarios.
For example:
Phishing
Report → Disable compromised account → Reset credentials → Review access → Investigate → Monitor
Lost Laptop
Report → Lock/wipe device → Revoke sessions → Assess data exposure → Document
Ransomware
Detect → Isolate → Preserve evidence → Activate incident team → Investigate → Recover
Cloud Credential Exposure
Revoke credential → Rotate secret → Review activity → Determine impact → Remediate → Document
Data Breach
Contain → Preserve evidence → Assess information affected → Legal/privacy review → Notification assessment → Recovery
The procedures do not need to predict every possible incident.
They should provide enough guidance to help the organization respond consistently.
11. Establish Evidence Preservation Procedures
During an investigation, evidence may be required to understand what happened.
Evidence could include:
- System logs
- Authentication logs
- Cloud activity logs
- Email records
- Endpoint logs
- Firewall logs
- Security alerts
- Screenshots
- Relevant files
- Network information
- Incident tickets
- Communications
The organization should consider:
- Who can collect evidence?
- Where is it stored?
- How is it protected?
- Who can access it?
- How is integrity maintained?
- When can it be deleted?
For serious incidents, specialist forensic advice may be appropriate.
12. Establish Legal and Regulatory Escalation
Some incidents may create legal, regulatory, contractual, or customer-notification obligations.
The incident process should therefore include escalation to appropriate legal/privacy personnel.
Potential considerations include:
- Personal-data breach
- Customer contractual requirements
- Regulatory reporting
- Law-enforcement involvement
- Cyber insurance requirements
- Contractual notification timelines
The organization should not assume that every incident requires external notification.
The incident should first be assessed against applicable requirements.
13. Establish Third-Party Incident Coordination
Security incidents can originate from suppliers.
For example:
Cloud provider incident
→ Organization receives provider notification
→ Security team assesses impact
→ Affected systems identified
→ Customers/management notified where required
→ Response coordinated with provider
This connects A.5.24 with:
- A.5.19 Supplier Relationships
- A.5.20 Supplier Agreements
- A.5.21 ICT Supply Chain
- A.5.22 Supplier Service Monitoring
- A.5.23 Cloud Services
14. Train Employees
An incident-response plan is ineffective if employees do not know how to use it.
Training should cover:
- What constitutes a security incident
- How to report an incident
- Who to contact
- What employees should do immediately
- What employees should not do
- Phishing reporting
- Lost-device reporting
- Data-breach escalation
Training should be appropriate to the person’s role.
15. Test Incident Response
Organizations should periodically test their incident-response arrangements.
Testing can include:
Tabletop Exercise
Discuss a simulated incident.
Example:
“A customer’s production data may have been accessed using a compromised administrator account. What do we do?”
Participants discuss:
- Who is contacted?
- Who makes decisions?
- How is the account contained?
- What evidence is preserved?
- Who assesses customer impact?
- Who communicates externally?
Technical Simulation
Conduct a more practical exercise involving:
- Account compromise
- Malware
- Ransomware
- Cloud credential exposure
- Data leakage
Testing should identify weaknesses in the response process.
Startup Example
Consider a SaaS startup with:
- AWS production environment
- GitHub
- Google Workspace
- Slack
- Customer database
- 50 employees
One morning, the security team discovers that an employee’s Google Workspace account has been compromised.
Without Preparation
The team may ask:
Who should handle this?
Should we disable the account?
Should we contact the customer?
Should we preserve the logs?
Who should speak to management?
Does this need legal review?
This causes delay.
With A.5.24 Preparation
The response is:
Employee reports incident
↓
Incident ticket created
↓
Security Lead performs triage
↓
Account disabled
↓
Sessions/tokens revoked
↓
Evidence preserved
↓
Incident classified
↓
Incident Manager notified
↓
Impact assessment performed
↓
Legal/privacy review if required
↓
Recovery and monitoring
↓
Incident documented
↓
Lessons learned
The difference is preparation.
Startup-Focused Quick Summary
A startup can begin implementing A.5.24 with a relatively simple framework.
1. Create an Incident Response Policy
Define the organization’s overall approach.
2. Define Incident Roles
Identify who handles technical, management, legal, privacy, and communications responsibilities.
3. Create an Incident Reporting Channel
Make reporting easy.
4. Create an Incident Register
Record incidents consistently.
5. Define Severity Levels
Establish simple escalation criteria.
6. Create Response Playbooks
Prepare procedures for common scenarios.
7. Maintain Emergency Contacts
Keep internal and external contacts current.
8. Train Employees
Teach everyone how to report incidents.
9. Test the Plan
Conduct tabletop exercises.
10. Improve After Incidents
Capture lessons learned and update procedures.
Example Incident Response Register
| Incident ID | Date | Incident | Severity | Owner | Status | Root Cause | Corrective Action |
|---|---|---|---|---|---|---|---|
| INC-001 | 10-Jan-2026 | Phishing | Medium | Security | Closed | User clicked link | Training + MFA |
| INC-002 | 22-Feb-2026 | Lost laptop | Medium | IT | Closed | Device lost | Remote wipe |
| INC-003 | 05-Mar-2026 | API credential exposure | High | CTO | Closed | Secret in repository | Rotate keys + scanning |
The register should contain enough information to demonstrate controlled incident management while protecting sensitive incident details appropriately.
Example Incident Severity Matrix
| Severity | Typical Impact | Escalation |
|---|---|---|
| Low | Minimal/no business impact | IT/Security |
| Medium | Limited system or user impact | Security Lead |
| High | Customer/data/business impact | Incident Manager + Management |
| Critical | Major outage, significant breach, ransomware | Executive Incident Team |
The organization should define its own thresholds based on risk.
Audit Evidence for Annex A 5.24
An auditor may look for evidence that incident management has been planned and prepared.
Policies and Procedures
- Information Security Incident Management Policy
- Incident Response Procedure
- Incident Escalation Procedure
- Evidence Preservation Procedure
- Data Breach Response Procedure
Roles
- Incident response team list
- RACI matrix
- Contact list
- Escalation matrix
Operational Records
- Incident register
- Incident tickets
- Incident reports
- Corrective-action records
- Lessons-learned records
Training
- Security awareness training
- Incident reporting training
- Incident-response team training
Testing
- Tabletop exercise records
- Simulation reports
- Test findings
- Corrective actions
External Coordination
- Cloud provider contacts
- Cybersecurity provider contacts
- Legal contacts
- Cyber insurance information
- Critical supplier escalation contacts
Audit Checklist
Governance
- Is an incident-management policy established?
- Are incident-management responsibilities defined?
- Is there a documented incident-response process?
Reporting
- Can employees easily report suspected incidents?
- Are reporting channels documented?
- Are incidents recorded?
Roles
- Is an incident response team defined?
- Are responsibilities documented?
- Are escalation authorities defined?
- Are emergency contacts maintained?
Classification
- Are incidents classified by severity?
- Are escalation criteria defined?
- Are significant incidents escalated appropriately?
Response Preparation
- Are response procedures available?
- Are common incident scenarios covered?
- Are evidence-preservation procedures defined?
- Are communication procedures defined?
Legal and Regulatory
- Is legal/privacy escalation defined?
- Are applicable notification obligations considered?
- Are customer contractual requirements considered?
Training and Testing
- Are employees trained to report incidents?
- Is the incident response team trained?
- Are incident-response exercises conducted?
- Are lessons learned tracked?
Common Mistakes
1. Having an Incident Response Policy but No Practical Process
A policy saying “the company will respond to incidents” is not enough.
People need to know how.
2. No Clear Incident Owner
During an incident, everyone may assume someone else is responsible.
Define an incident manager.
3. Employees Do Not Know How to Report Incidents
A complicated reporting process can delay detection.
Make reporting simple.
4. Treating Every Security Event as a Major Incident
Not every failed login is a crisis.
Define sensible classification and escalation criteria.
5. No Contact List
A response plan may fail if nobody knows how to reach the:
- Cloud provider
- Legal counsel
- Security consultant
- Management
- Privacy specialist
6. No Evidence Preservation
An organization may accidentally delete logs or modify affected systems before investigation.
Evidence handling should be considered during preparation.
7. No Tabletop Exercises
A document can look excellent and still fail in practice.
Test it.
8. Ignoring Third-Party Incidents
A security incident at AWS, Microsoft, GitHub, or another supplier may affect your organization.
Supplier incident escalation should be included.
9. No Lessons-Learned Process
An incident should improve the organization’s security.
After significant incidents, ask:
- What happened?
- Why did it happen?
- What worked?
- What failed?
- What should change?
Practical Startup Implementation Model
A simple implementation model is:
Define → Assign → Report → Classify → Escalate → Respond → Test → Improve
Define
Create the incident-management policy and procedures.
Assign
Define roles and responsibilities.
Report
Provide simple reporting channels.
Classify
Determine severity and impact.
Escalate
Escalate according to predefined criteria.
Respond
Contain, investigate, recover, and document.
Test
Conduct exercises.
Improve
Apply lessons learned.
Policy vs. Process vs. Evidence
| Area | Policy | Process | Evidence |
|---|---|---|---|
| Incident management | Incident Management Policy | Incident Response Procedure | Approved policy |
| Reporting | Security Incident Policy | Incident Reporting Process | Incident ticket |
| Escalation | Escalation Requirements | Escalation Matrix | Escalation record |
| Investigation | Incident Investigation Policy | Investigation Procedure | Investigation report |
| Communication | Incident Communication Policy | Communication Procedure | Approved communication |
| Evidence | Evidence Handling Policy | Evidence Preservation Process | Evidence records |
| Training | Security Awareness Policy | Incident Training | Training records |
| Testing | Incident Exercise Requirements | Tabletop Exercise | Exercise report |
Relationship with Other ISO 27001 Controls
A.5.24 – Incident Management Planning and Preparation
Establishes the foundation for incident response.
A.5.25 – Assessment and Decision on Information Security Events
Determines whether a security event should be classified as an incident and how it should be handled.
A.5.26 – Response to Information Security Incidents
Addresses how the organization responds to identified incidents.
A.5.27 – Learning from Information Security Incidents
Ensures lessons from incidents are captured and used for improvement.
A.5.28 – Collection of Evidence
Addresses the collection and preservation of evidence.
Together, these controls form an important incident-management lifecycle:
Prepare → Assess → Respond → Learn → Preserve Evidence
A.5.24 is therefore the foundation.
Useful Documents for A.5.24
A startup may create:
- Information Security Incident Management Policy
[Insert Draft Document Link] - Incident Response Procedure
[Insert Draft Document Link] - Incident Severity Matrix
[Insert Draft Document Link] - Incident Escalation Matrix
[Insert Draft Document Link] - Incident Response Team RACI
[Insert Draft Document Link] - Incident Reporting Form
[Insert Draft Document Link] - Incident Register
[Insert Draft Document Link] - Security Incident Communication Procedure
[Insert Draft Document Link] - Evidence Preservation Procedure
[Insert Draft Document Link] - Incident Response Tabletop Exercise Template
[Insert Draft Document Link]
Questions an Auditor May Ask
An auditor may ask:
How does an employee report a suspected security incident?
Who is responsible for managing a significant security incident?
How do you classify incident severity?
What causes an incident to be escalated to management?
How do you preserve evidence?
Who is responsible for communicating with customers?
How do you determine whether legal or regulatory notification is required?
When was the incident response process last tested?
Can you show evidence of an incident-response exercise?
What happens if your primary IT/security person is unavailable?
These questions test whether the organization has operational readiness, rather than simply having an incident-response policy.
Startup-Focused Final Takeaway
ISO 27001 Annex A 5.24 is fundamentally about being prepared before something goes wrong.
A startup does not need a massive Security Operations Center to implement this control.
It needs a practical system that answers:
What is an incident?
How do we report it?
Who takes ownership?
How do we classify it?
When do we escalate it?
Who needs to be informed?
How do we preserve evidence?
How do we respond?
How do we test our readiness?
A practical sequence is:
Prepare → Assign → Report → Classify → Escalate → Respond → Test → Improve
The key principle
Do not create an incident-response plan only for the auditor. Create one that your team can actually use at 2:00 AM when a real security incident occurs.
That is the real purpose of ISO 27001 Annex A 5.24.