Incident Concepts Across ISO 27001, ISO 22301 and ISO 20000

The word “incident” changes emphasis across information security, business continuity and service management. A cyberattack may threaten confidentiality, interrupt a critical activity and degrade an IT service at the same time. One event can therefore activate several management processes without becoming three unrelated cases.

The practical solution is a shared factual record with distinct assessment lenses, owners and outcomes. This article compares ISO/IEC 27001, ISO 22301 and ISO/IEC 20000-1 at that operating level. It also explains why ISO 28003, despite appearing in older comparisons, belongs to a different category.

The descriptions below are operational summaries, not reproduced ISO definitions. Organisations should use the editions and audit criteria applicable to them.

The three incident lenses

ISO/IEC 27001: protect information

The information-security lens asks whether events threaten confidentiality, integrity or availability and whether coordinated response is required. Assessment considers affected information, systems, people, obligations, attacker activity, evidence and potential escalation.

The process must connect reporting, assessment, response, learning and preservation of relevant records. A security event does not automatically become an information security incident; the organisation needs defined assessment and decision criteria.

ISO 22301: protect continuity of priority activities

The business-continuity lens asks whether disruption threatens the organisation’s ability to continue or recover prioritised products, services and activities within approved needs. It considers business impact, dependencies, response structure, continuity strategies, communications and recovery.

ISO’s overview of ISO 22301:2019 identifies it as the requirements standard for business continuity management systems. ISO also notes that a revision is under development, so organisations should monitor the edition applicable to their programme rather than assume a draft has replaced the published edition.

ISO/IEC 20000-1: protect service delivery and value

The service-management lens asks how an unplanned condition affects an agreed service and how normal service can be restored and improved. It considers users, service levels, priority, resolver groups, changes, problems, suppliers and communication.

ISO/IEC 20000-1:2018 establishes requirements for a service management system covering planning, transition, delivery and improvement of services. ISO reports that the 2018 edition was confirmed in 2023 and remains current.

What ISO 28003 actually addresses

ISO 28003 is not a fourth operational incident-management system for an organisation. Its subject is requirements for bodies that audit and certify supply-chain security management systems. It is about conformity-assessment competence and process, not how an operating company should classify a cyber alert, service outage or continuity disruption.

Older discussions may place it beside the three management-system standards because audit and certification bodies must consider the schemes they assess. Practitioners designing an integrated incident workflow should not treat ISO 28003 as another internal incident definition. If supply-chain security is relevant, identify the organisation’s applicable operational and contractual criteria separately.

Compare the operating emphasis

Question	Information security	Business continuity	Service management
Primary concern	Risk to information and related assets	Disruption to prioritised activities	Interruption or degradation of services
Common trigger	Suspicious activity, disclosure, loss, manipulation or control failure	Event with actual or potential disruptive impact	User report, monitoring alert or service failure
Immediate decision	Does this require security incident response?	Should continuity response or recovery arrangements activate?	What priority and restoration route apply?
Important authority	Security incident lead, risk and obligation owners	Strategic, tactical and operational continuity leadership	Incident manager, service owner and resolver teams
Completion focus	Controlled response, evidence, obligations and security learning	Stabilised operations, recovered priorities and resilience improvement	Restored agreed service and managed underlying causes

These perspectives overlap. They do not need identical severity scales, but their scales must translate well enough for coordinated escalation.

Use one event, several classifications

Consider ransomware affecting an order platform.

The information-security process assesses attacker access, affected data, integrity, lateral movement, evidence and notification obligations. The continuity process considers whether order fulfilment can continue, which workarounds or recovery strategies to invoke and when priorities must shift. The service-management process coordinates user communication, technical restoration, emergency change and service-level impact.

A single master identifier can connect the case. Each discipline can retain fields or restricted records needed for its decisions. This avoids contradictory timelines while protecting sensitive information.

The integrated ISO 27001 and ISO 22301 audit guide shows how common processes can be audited without erasing standard-specific criteria.

Design a shared record

The common record should capture facts useful to every response team:

• master identifier and source;
• report, detection and first-known times;
• affected services, information and activities;
• current symptoms and known impact;
• assigned coordination lead;
• classification under each relevant lens;
• decisions, owners and approvals;
• actions and communication;
• evidence locations;
• service and business recovery validation;
• unresolved facts and assumptions; and
• linked problems, risks and corrective work.

Restrict security-investigation, personal or legal material. A shared record means shared traceability, not unrestricted access.

Define activation and escalation separately

A high-priority service incident is not automatically a continuity activation. A serious security incident might have no visible outage. A disruptive facility event may require continuity action without creating an information-security incident.

Define triggers for each process and the points where teams must consult one another. Examples include:

• actual or suspected compromise of critical information;
• projected outage beyond a service or activity tolerance;
• loss of a key site, supplier or workforce capability;
• uncertainty about data integrity before recovery;
• emergency change that could affect evidence;
• customer, regulator or public communication; and
• impact spanning several services or entities.

Document who can activate each response structure and who resolves conflicting priorities.

Reconcile severity without forcing one scale

Security may rate impact using confidentiality, integrity and availability. Continuity may use maximum tolerable disruption, recovery objectives and business impact. Service management may combine impact and urgency.

Create translation rules rather than a universal number. For example, a service priority may trigger immediate security review when the cause appears malicious. A security severity may trigger continuity assessment when projected availability or integrity consequences threaten a priority activity.

The risk score calculator can support consistent risk discussion, but it should not replace service, continuity or legal decision criteria.

Coordinate response and recovery authority

Integrated procedures should state who can:

• isolate systems or accounts;
• invoke workarounds or alternate sites;
• prioritise scarce recovery resources;
• approve emergency changes;
• preserve forensic material;
• communicate with users, customers and authorities;
• accept degraded operation;
• validate data and service restoration; and
• declare stand-down or closure.

Conflicts should be visible. Restoring from an unverified backup may improve availability while creating integrity risk. Keeping a server online for evidence may extend disruption. Record the options, advice, decision owner and rationale.

Keep recovery evidence multidimensional

“System online” is insufficient for many cases. Recovery evidence may include:

• infrastructure and application health;
• data reconciliation or integrity validation;
• restored security configuration;
• user or transaction testing;
• capacity and monitoring results;
• business-owner acceptance;
• closure of temporary workarounds;
• communication completion; and
• remaining risk or follow-up action.

The incident-management evidence guide provides a fuller model for timelines and security records.

Learn once, improve several systems

Hold a coordinated review when a case crossed disciplines. Ask what happened, why controls did not prevent or detect it earlier, how decisions worked, whether recovery assumptions held and which dependencies failed.

Then route improvements to the right systems:

• ISMS risk and control changes;
• continuity strategy, plan or exercise changes;
• service problem and change work;
• supplier assurance;
• competence and communication; and
• objectives or management review.

Avoid three separate reviews that assign duplicate actions or conflicting causes. Keep one action owner and link it to every affected management-system record.

Audit questions and sampling

An integrated auditor may ask:

• Can the organisation identify the complete population of relevant cases?
• Are classification and activation decisions traceable?
• Do severity models translate across teams?
• Who resolves containment versus restoration conflicts?
• Are timelines reconciled?
• How is recovery validated under each lens?
• Do lessons update all affected management systems?

Sample a security-only event, a service-only interruption and a case that activated multiple disciplines. Compare source alerts, tickets, continuity logs, changes, communications, recovery tests and action closure.

Pass

The organisation maintained one reliable case history, applied each relevant assessment lens and coordinated authority, evidence, recovery and improvement without duplication.

Partial

Teams coordinated response effectively, but severity translation and cross-system action closure depended on individual knowledge.

Fail

Separate records gave conflicting times and owners. Service was restored without security validation, and continuity lessons did not reach risk or control decisions.

The practical conclusion

ISO 27001, ISO 22301 and ISO 20000 view incidents through different management objectives. Preserve those distinctions while sharing facts, escalation and learning. One event can require security response, continuity activation and service restoration, but each decision needs the right owner and evidence.

ISO 28003 should not be used as another internal incident-management lens. Recognising that category difference prevents an old comparison from distorting a current operating process.

The subject perspective was informed by Advisera’s cross-standard incident comparison, with current standard status and scope checked against ISO sources.