ISO 27001 A.5.24: Prepare for Security Incidents
ISO 27001 A.5.24 addresses planning and preparation for information security incident management. It calls for defined, established and communicated processes, roles and responsibilities. A useful plan tells people how to recognise a concern, reach the right decision-maker and coordinate action when time, information and normal systems are limited.
What A.5.24 requires in practice
Control A.5.24 is about preparation. The organisation must get ready in advance to handle information security incidents, by defining and setting up incident management processes, roles and responsibilities and making sure they are communicated. The emphasis falls on what is settled before anything goes wrong.
In practice that means three things an auditor can look for. There is a defined process describing how events are reported, assessed, handled and closed. Roles and responsibilities are clear, including who leads, who decides and who speaks to outsiders. And the arrangements have been communicated so the people concerned know what they are expected to do. The control does not dictate a team structure or tools. A small organisation may rely on a few named roles and a simple route, while a larger one may need a dedicated function; either can meet the control if it works.
Prepare decisions before writing detailed instructions
Identify the decisions that could delay or worsen a response. Who can isolate a service, authorise external assistance, communicate with a customer or accept a temporary operating restriction? The answer may depend on severity and business consequence. Establish authority and escalation routes with appropriate cover for absence.
Set priorities that responders understand. Protecting information, preserving evidence, restoring service and meeting external obligations can create competing demands. The plan should identify how those trade-offs are resolved. A technical responder should not have to invent the organisation’s business priorities during a serious incident.
Involve operational, management and relevant specialist roles. Information security incidents are not confined to malware. Lost documents, unauthorised changes or supplier failures may require a different combination of people. Plan around realistic scenarios drawn from the organisation’s information and services.
Make the reporting and coordination route usable
Provide a clear point of contact and explain what staff should report. People should not need to prove that an incident has occurred before raising a concern. Give responders a consistent way to record initial facts, assess significance and coordinate the next action.
Consider unavailable or untrusted systems. If the normal messaging service is affected, a plan stored only in that service may be inaccessible. Decide how authorised responders can obtain essential contact and procedure information safely. Protect emergency arrangements from unnecessary exposure while ensuring they remain usable.
Why incident preparation matters to the business
When an incident starts, people look for direction. If roles and routes were not settled earlier, the first hours are lost to argument about who decides, who tells the client and who may switch a system off. Prepared organisations respond faster, make fewer avoidable errors and communicate more calmly with customers and regulators. Preparation also reduces the damage that comes from improvising under pressure. For auditors and clients, a defined and communicated process is the first sign that incidents will be handled consistently, and the quickest way to build trust after one has occurred.
How to implement A.5.24
Keep the plan simple enough that people can follow it when stressed. One route to a usable arrangement is shown here. Incident plans fail when they are written once and shelved. Involve the people who will actually respond, including those from operations, HR and communications, since an incident is rarely only technical. Use plain language and short steps. Keep contact details where they can be reached when systems are down, and think about how the plan will work when key people are unavailable or the usual tools cannot be used.
- Decide what kinds of events the process must cover.
- Describe the path from first report to closure in plain language.
- Assign roles, with deputies, and give each person the authority needed to act.
- Agree how and when management, clients, authorities and other parties are told.
- Provide contact routes that work outside normal hours.
- Communicate the arrangements and make sure responders understand them.
- Test the plan with a realistic scenario and improve it.
Illustrative BPO example: the only contact route fails
A hypothetical BPO business relies on its internal collaboration platform for incident reporting. During a simulated access problem, team leaders cannot reach the incident channel or retrieve the contact list. The written plan assumes the same service will always be available.
The organisation establishes an appropriate alternative route and rehearses how supervisors reach authorised responders. The exercise checks acknowledgement and decision-making, not just whether a message can be sent. The team records the gap and verifies the revised arrangement in a later controlled exercise.
Illustrative manufacturing example: isolation has production consequences
A hypothetical manufacturer suspects unauthorised changes in a system used to issue production instructions. Disconnecting it could protect information but disrupt production and affect other operational risks. The IT team knows how to disconnect the system but lacks authority to decide the business response.
Preparation assigns a joint decision route involving competent technical and operational personnel. The exercise examines what evidence is needed, which immediate protective actions are authorised and how continuity arrangements connect. It avoids a simplistic instruction to disconnect every affected system regardless of consequence.
Coordinate external relationships in advance
Identify where suppliers, customers, authorities or specialist advisers may need to participate. Relevant contractual and legal reporting obligations require informed assessment; the standard does not create one universal notification deadline. Maintain an authorised route for determining what applies and for approving external communications.
Check that contracted support is actually available under the agreed arrangement. A supplier’s ordinary helpdesk may not provide the incident assistance assumed by the plan. Define what information can be shared and how sensitive incident material will be protected.
Exercise the process, then improve it
A discussion exercise can reveal missing authority, unclear criteria and impossible assumptions without disrupting live services. More technical exercises may be appropriate where authorised and safely scoped. State the objective and boundaries, use suitable test data and make participants aware of how an exercise is distinguished from a real event.
Evaluate decisions and handovers. Record what caused delay, what information was unavailable and whether roles understood their responsibilities. Assign improvements and check completion. A successful exercise is one that provides trustworthy learning, even when it exposes weaknesses.
Evidence and common failures
Useful evidence includes communicated processes, role assignments, preparation records, exercises and completed improvements. The control requires functioning preparation, not a prescribed number of pages. Common weaknesses include contact lists without owners, plans copied from unrelated organisations and exercises that stop before difficult business decisions arise.
Sample whether an alternate responder can find the current procedure and explain their authority. Confirm that the incident plan links to evidence handling and continuity where relevant. Preparation should make coordinated action possible rather than encourage untrained staff to investigate independently.
Frequently asked questions
Must every organisation have a dedicated incident-response department?
No universal team structure is prescribed. Roles, competence, authority and availability must fit the organisation’s needs. Smaller organisations can combine roles and use agreed external support where appropriate.
Is a tabletop exercise enough?
It can test decisions and coordination. It does not necessarily demonstrate technical recovery or configuration capabilities. Choose exercises that address the questions your organisation needs to answer.
Should staff investigate before reporting?
They should follow the reporting process and avoid uncoordinated investigation. Early factual reporting helps competent responders assess the event without unnecessary delay or alteration of evidence.
Prepare a response your team can operate
Ask Sterling to support incident-management preparation. Consulting, scoped Effivity ISO & GRC automation software and 93 Annex A Controls training can connect plans with responsible people and evidence. Certification is independently decided. Explore the wider organisational controls.