From incident to crisis: how ISO/IEC 27035, ISO 22320 and ISO 22361 work together

Three standards, three audiences

Most organisations read these standards in isolation, because they are owned by different teams. The security operations team knows ISO/IEC 27035 and the NIST incident response guide. Emergency and business continuity managers know ISO 22320. Executives, if anyone, have heard of ISO 22361. Read together, they describe a single escalation path, and each one picks up where the previous one stops.

The overlap is deliberate. ISO 22320 says its incident management process applies to any scale of incident and at all levels of responsibility, and ISO 22361 positions crisis management as a strategic capability that sits alongside business continuity, emergency management and incident response rather than replacing them. The practical problem is not that the standards conflict. It is that organisations implement them as three plans, in three tools, with no agreed point at which one hands over to the next.

ISO/IEC 27035 and NIST SP 800-61r3: handling the incident

ISO/IEC 27035-1:2023 sets out the principles and process of information security incident management. Its process runs through five phases: plan and prepare; detect and report; assess and decide; respond; and learn lessons. The second edition was revised to align with ISO/IEC 27002:2022.

NIST SP 800-61 Revision 3, finalised in April 2025, replaced the 2012 Computer Security Incident Handling Guide. It is written as a Community Profile of the NIST Cybersecurity Framework 2.0, so incident response is described through the CSF Functions: Govern, Identify and Protect for preparation, Detect, Respond and Recover for the incident itself, and improvement activities for lessons learned.

Both are written for the people handling the incident. They are excellent at the technical life cycle and deliberately say little about what the board should decide when the incident stops being technical. That is not a gap in either document; it is where the other two standards begin.

ISO 22320: commanding a major incident

ISO 22320:2018 gives guidelines for incident management in the emergency management sense: how an organisation, or several organisations together, command a response. Its principles include unity of command (every person reports to one supervisor at any point in time), working together, an all-hazards approach, information sharing, safety, flexibility and continual improvement.

Its process is a loop of observation, information gathering and sharing, assessment and forecasting, planning, decision-making and communication, implementation and feedback. Planning produces an incident action plan with objectives, strategy, safety, communications and resources for an operational period. The standard also expects resources to be allocated, tracked and released, a common operational picture shared between those involved, and a formal hand-over when incident management ends.

• One incident commander at a time, with a recorded hand-over when command changes.
• An incident action plan for each operational period, with objectives that end as met, not met or carried forward.
• Resources tracked from request to release, so stand-down does not leave people or vendors committed.
• A common operating picture for everyone working the response.

This is the tier most organisations skip. A security team escalates straight from a ticket to an executive phone call, and nobody owns the coordination in between.

ISO 22361: leading a crisis

ISO 22361:2022 provides guidelines for a strategic crisis management capability. It is addressed to top management, and its clauses cover crisis concepts and principles, building the capability (structure, roles and alternates, activation and stand-down, situational awareness), crisis leadership, strategic decision-making, crisis communication, and training, validation and learning.

Two of its expectations change how a crisis is run. Decisions should be structured and logged, with the options considered and the information available at the time, so they can be reviewed later on their merits rather than on their outcome. And communication with stakeholders, regulators, the media and staff is treated as part of the response, not something done after it.

ISO 22361 is a guidance standard, so organisations align to it rather than certify against it. That makes evidence important: the best proof of a crisis capability is the record of how a real crisis or a realistic exercise was handled.

Where escalation fails

Post-incident reviews tend to find the same four failures, regardless of sector.

1. Escalation happens late, because the decision is made by whoever is on call, under pressure, without agreed criteria.
2. The crisis team receives forwarded technical updates instead of a statement of business impact and the decisions required.
3. Regulator and agency deadlines are tracked in someone's head or calendar, and the first one is missed while the team is still assembling.
4. Each tier keeps its own record, so the crisis team re-asks questions the incident team has already answered, and the final review cannot reconstruct who knew what, when.

Escalation criteria that work

The fix for late escalation is criteria agreed in advance and applied every time. Good criteria are measurable, cover more than cyber events and suggest a level rather than imposing one. A named person still makes the declaration, and the criteria met are recorded as its basis.

The thresholds above are a starting point. Set your own with the board, write them into the crisis management plan and test them in an exercise.

What the board should see

Directors need three things in a crisis: what has happened, what it means for the business, and what they are being asked to decide. A one-page brief built around six impact dimensions covers most of what a board asks: operations, customers, finances, legal and regulatory position, people and safety, and reputation.

• A short narrative in plain English, five sentences or fewer, with absolute dates and figures.
• An impact rating for each dimension, where an impact nobody has assessed yet is shown as not assessed, never as fine.
• The decisions the crisis team needs from the board, in one place.
• The clocks that matter: the next situation report, regulator and agency obligations, and progress against stand-down criteria.

Every statement in the brief should trace to a recorded fact. If the same data always produces the same words, the brief can be trusted, and arguments in the boardroom are about decisions rather than about whose numbers are right.

Regulators and government agencies

In a serious incident the regulator clock usually starts before the crisis team meets. Map every obligation in advance, give each one an owner and a deadline, and hold external statements until a reviewer who did not draft them has approved them. Some common deadlines:

For deadlines across Australia, New Zealand, Singapore, Malaysia and the Gulf, see our guide to cyber incident reporting deadlines.

Exercising the whole chain

Most exercises test one tier. The security team runs a technical drill; the executives run a discussion-based tabletop. The failures described above happen between the tiers, so the most valuable exercise runs one scenario from the first alert to the board brief, with timed injects and objectives agreed in advance.

• Crisis declared within 30 minutes of the scenario starting.
• First situation report within 90 minutes of declaration.
• Business impact assessed within an hour of declaration.
• Every decision recorded with options and a rationale.
• Every external statement approved before release.
• The regulator notified within the applicable deadline.

Score each objective from what the team actually recorded, not from impressions in the debrief. The after-action report then becomes evidence of exercising and validation under ISO 22361, and of response plan testing under regimes such as APRA's CPS 234.

A practical integration checklist

1. Define three levels (incident, major incident, crisis) and who leads each.
2. Agree escalation criteria with the board and write them into the plan.
3. Name an incident commander role and the rules for handing over command.
4. Build a crisis team with alternates and a decision log keeper.
5. Design a one-page board brief around business impact and decisions.
6. Map every regulator and agency obligation, with an owner and a deadline.
7. Put external communications behind a two-person approval.
8. Keep one record across all three levels, so nothing is retyped at escalation.
9. Exercise the whole chain at least annually, scored against objectives.
10. Feed the lessons back into the plan and your ISO 22361 and ISO/IEC 27035 evidence.

GRCLens implements this checklist as one module: Incident & Crisis Management keeps the incident, the major incident and the crisis on one record, with escalation triggers, ISO 22320 command, a plain-English board view, regulator clocks, scored exercises and evidence published into your ISO 22361 assessment.

Frequently asked questions