Using ISO 22301 to Strengthen ISO 27001 Continuity Controls

ISO/IEC 27001 and ISO 22301 address related but different outcomes. ISO/IEC 27001 manages information-security risk, including security during disruption and ICT readiness for business continuity. ISO 22301 provides a full business continuity management system for understanding impacts, selecting continuity strategies, operating response arrangements and improving resilience.

An organisation can use ISO 22301 practices to make its ISO 27001 continuity controls more credible. It does not need ISO 22301 certification to do so, and ISO 27001 certification does not prove conformity with ISO 22301.

The practical objective is a traceable chain from risk and business impact to recovery design, exercised performance and improvement.

Start with the current control context

ISO/IEC 27001:2022 Annex A includes control 5.29 on information security during disruption and control 5.30 on ICT readiness for business continuity. An organisation considers these and other Annex A controls through its risk-treatment process; applicability and implementation should be justified in the Statement of Applicability.

Control 5.29 is broader than restoring servers. It concerns maintaining information security at an appropriate level while the organisation is disrupted. Control 5.30 focuses on whether ICT readiness supports the organisation’s continuity needs.

The Annex A control lookup can help teams locate relevant control themes. Always use the organisation’s licensed standard for normative wording.

What ISO 22301 adds

ISO 22301:2019 specifies requirements for a business continuity management system. Its operational practices add useful depth in five areas.

Business impact analysis

Business impact analysis identifies prioritised activities, the effects of interruption, time-dependent consequences, dependencies and resource needs. This gives security and technology teams a business basis for recovery priorities.

Without that basis, an ICT team may restore the easiest systems first or apply one recovery target to everything. A defensible priority connects systems and data to services the organisation has decided must recover.

Risk assessment for disruption

Continuity risk work considers sources of disruption and the likelihood and consequence of interruption. It complements, rather than replaces, the ISMS risk assessment. Keep the methods connected so cyber scenarios, facility loss, supplier failure and utility outage do not fall between teams.

Continuity strategies

A strategy explains how required capability will be achieved. Options can include alternate facilities, redundant services, manual operation, reciprocal arrangements, diversified suppliers, protected backups and staff cross-training.

The strategy should address security consequences. A manual workaround may preserve service but introduce uncontrolled records. An alternate environment may recover capacity but weaken access restrictions. Security criteria belong in the selection decision.

Plans and procedures

Response and recovery plans translate strategy into action. They should identify authority, activation criteria, communication, dependencies, sequencing, security safeguards and return-to-normal arrangements.

Exercise and evaluation

Exercises test assumptions before a real event. They can reveal unavailable people, inaccessible credentials, incorrect recovery order, stale contact data or an unworkable manual process. Results create operating evidence and improvement actions.

The official ISO 22301 overview confirms the current 2019 edition and its focus on planning for, responding to and recovering from disruption.

Build one traceable continuity chain

Use a chain that an owner and auditor can follow:

1. prioritised activity and impact;
2. supporting information, ICT, people, facility and supplier dependencies;
3. approved recovery need;
4. disruption and security risks;
5. selected continuity strategy;
6. implemented plans and technical arrangements;
7. exercise or event evidence;
8. result against the approved need; and
9. corrective action and effectiveness review.

Do not force every artefact into one file. A controlled relationship between records is more useful than a large document that quickly becomes stale.

Translate business needs into ICT readiness

A recovery objective is not an architecture by itself. Technology owners need enough context to design and verify capability.

For each critical service, define:

• the business outcome that must continue or resume;
• information and system dependencies;
• required data state and integrity;
• tolerable interruption and data loss as approved by the business;
• minimum capacity and performance;
• identity, logging and monitoring requirements during recovery;
• upstream and downstream dependencies;
• supplier commitments and escalation paths; and
• conditions for returning to normal operation.

The risk score calculator can support prioritisation where it aligns with the approved method, but a score should not substitute for impact analysis.

Preserve security during disruption

Pressure changes behaviour. People share accounts, bypass approvals, move data to personal channels or disable controls to restore service. Continuity design must anticipate this.

Useful safeguards include:

• pre-authorised emergency roles with time-bounded access;
• secure offline access to essential plans and contact data;
• controlled break-glass credentials with logging and review;
• approved communication channels and fallbacks;
• integrity checks before restored data is trusted;
• minimum logging during degraded operation;
• rules for paper or manual records and later reconciliation;
• privacy and classification requirements at alternate sites;
• supplier access controls; and
• explicit security approval for temporary exceptions.

An emergency process should be faster than normal where necessary, but still accountable.

Design exercises that produce assurance

A discussion-based exercise can test decision making, escalation and communication. A technical recovery exercise can test restoration, integrity and dependency sequencing. A simulation can combine business, supplier and technology teams.

Exercise scope should follow risk. Vary scenarios rather than repeating one comfortable outage. Include realistic complications such as unavailable administrators, compromised credentials, a failed restoration point or a communications outage.

Retain:

• approved objective and scenario;
• participants and assigned roles;
• systems and dependencies in scope;
• expected recovery needs;
• actions and timestamps;
• observed security decisions;
• actual results;
• deviations and root causes;
• assigned improvements; and
• later evidence that changes worked.

The distinction between design and performance is explained in the implementation and operating evidence guide.

Sampling continuity evidence

An auditor should avoid selecting only the latest successful exercise. Build a population of prioritised services, plans, exercises, incidents and open actions.

A balanced sample may include:

• one highly critical service;
• one service with significant supplier dependence;
• one recently changed architecture;
• one failed or partly successful exercise;
• one real disruption, if available; and
• one overdue improvement action.

Trace each sample from business need to technical evidence and back. Confirm that excluded services have a reasoned basis.

Ownership

Business continuity is not solely an IT responsibility.

Role	Core responsibility
Top management	Approve policy, priorities, resources and accepted exposure
Service owner	Define critical outcomes and recovery needs
Continuity lead	Coordinate impact analysis, strategies, plans and exercises
Information security	Preserve security outcomes during disruption
ICT owner	Design, operate and prove recovery capability
Supplier owner	Align external commitments and evidence
Internal audit	Independently test the management system and selected controls

Where responsibilities overlap, use the organisation’s role model and escalation path. The goal is accountable decisions, not more job titles.

Audit questions

Ask:

• How were prioritised activities and dependencies determined?
• Can each ICT recovery target be traced to an approved business need?
• How does risk treatment address information security during degraded operation?
• Do plans cover secure access, data integrity, logging and communication?
• Are supplier recovery commitments consistent with internal assumptions?
• What exercises covered the highest-risk dependencies?
• Were failed results recorded without being reclassified as success?
• Did corrective actions receive owners, dates and effectiveness review?
• Has material organisational or technology change triggered re-evaluation?

The incident management evidence guide helps distinguish response to security events from the wider continuity response.

Pass, partial and fail examples

Pass: Recovery arrangements traced to approved business impacts, included security requirements, covered critical dependencies and had recent exercise evidence. Deviations led to completed and evaluated improvements.

Partial: Plans and technical recovery existed, but several targets lacked business approval and supplier assumptions had not been tested.

Fail: Recovery priorities were based on system owner preference. The organisation had never tested restoration, emergency access was shared and no one could show that data integrity would be verified.

These examples indicate evidence maturity rather than fixed conformity decisions.

Common weaknesses

Avoid:

• treating backup completion as proof of recoverability;
• assigning identical recovery needs to every service;
• separating business impact work from technology design;
• omitting people, premises, utilities or suppliers;
• allowing emergency access without accountability;
• testing only the technical restore and not the service outcome;
• reporting exercise completion while hiding failed objectives;
• leaving actions open without risk decisions; or
• assuming one certification proves the other standard.

Practical conclusion

ISO 22301 practices can give ISO 27001 continuity controls the operational depth they need. Use business impact analysis to set priorities, select strategies that preserve security, translate needs into ICT design and exercise the whole chain.

The evidence should show both implementation and operation: approved analysis, configured capability, realistic exercises, honest results and verified improvement. That is stronger than a plan that exists only for an audit.