ISO 27001 and ISO 22301 for Critical Infrastructure Resilience

Critical infrastructure organisations cannot treat cybersecurity and continuity as separate paperwork streams. A compromised engineering workstation can affect a physical process. A power, telecoms or cooling failure can disable security monitoring. A supplier outage can remove both operational capability and access to evidence.

ISO/IEC 27001 and ISO 22301 provide complementary management systems for these connected risks. ISO/IEC 27001 addresses information-security risk. ISO 22301 addresses the continuity of prioritised activities through disruption. Used together, they can align risk ownership, controls, recovery priorities, exercises and improvement.

They do not replace sector law, safety obligations, engineering standards or regulator directions. Organisations must map those requirements separately.

Begin with the critical service

Start with the service or outcome society, customers or the organisation depends on, not with a list of devices.

For each critical service, identify:

• the required outcome and acceptable degraded state;
• people and specialist skills;
• operational technology and information technology;
• data, communications and timing dependencies;
• sites, power, cooling and physical access;
• upstream and downstream services;
• suppliers, maintainers and cloud services;
• safety and environmental constraints;
• legal and regulatory obligations; and
• recovery priorities and decision authority.

This service view prevents local optimisation. A resilient control room is not enough if field communications, identity services or a specialist supplier cannot recover.

Connect security risk and business impact

Information-security risk assessment examines threats, vulnerabilities, likelihood and consequences affecting confidentiality, integrity and availability. Business impact analysis examines how interruption affects prioritised activities over time and what resources they need.

Use both. A risk register alone may not establish recovery order. Impact analysis alone may not explain how a malicious actor could corrupt data or misuse recovery access.

A practical integration model is:

1. define critical services and scope;
2. perform business impact analysis;
3. identify information, technology and supplier dependencies;
4. assess cyber, physical and operational disruption scenarios;
5. select security treatments and continuity strategies;
6. define service and control performance criteria;
7. exercise connected scenarios; and
8. improve from evidence.

The risk matrix guide explains how to make scoring definitions repeatable. The risk score calculator can support evaluation if it matches the approved method.

Treat IT and OT as connected but different

Operational technology often has availability, safety, latency and equipment-life constraints that differ from corporate IT. Patching, scanning or automated isolation may have physical consequences. Unsupported systems and specialist protocols can limit standard controls.

This is not a reason to exclude OT from governance. It is a reason to tailor treatment and record the rationale.

Consider:

• network architecture and controlled conduits;
• remote maintenance paths;
• privileged engineering access;
• portable media and maintenance devices;
• change control and configuration baselines;
• monitoring appropriate to the environment;
• time synchronisation and log preservation;
• safe isolation and manual operation;
• backup of configurations and engineering data;
• spare equipment and vendor support; and
• secure restoration after a cyber event.

The Annex A control lookup can help identify ISO 27001 control themes. Engineering and sector requirements may demand additional measures.

Design for degraded operation

Continuity does not always mean full restoration. A critical service may operate at reduced capacity under controlled conditions.

Define:

• minimum safe and secure service level;
• maximum duration of degraded operation;
• authority to enter and leave that state;
• staffing and shift requirements;
• manual or alternate procedures;
• information needed to make decisions;
• temporary security exceptions;
• monitoring and escalation;
• records created during the period; and
• reconciliation on return to normal.

Manual operation can introduce transcription errors, weak access control and incomplete logs. Test the process with realistic workload rather than assuming people can perform it indefinitely.

Control emergency and remote access

Vendors and engineers may need rapid access during disruption. Pre-design the route.

Strong arrangements can include:

• named accounts and approved roles;
• phishing-resistant authentication where feasible;
• time-bounded authorisation;
• controlled jump services;
• session logging appropriate to the risk;
• separation between enterprise and operational environments;
• monitored break-glass access;
• rapid revocation;
• contractual availability and escalation; and
• review after every emergency use.

Shared credentials without traceability weaken both security and incident reconstruction.

Align supplier resilience

Critical services often depend on telecoms, cloud, equipment manufacturers, managed security, fuel, logistics or specialist maintenance. A contract statement that a supplier has a continuity plan is weak evidence.

For material suppliers, determine:

• the service and dependency in scope;
• recovery and support commitments;
• security responsibilities;
• incident notification and coordination;
• subcontractor and concentration exposure;
• data and configuration access during disruption;
• testing participation;
• alternate arrangements;
• evidence and audit rights; and
• exit or transition capability.

The supplier audit guide shows how to test outsourced arrangements against risk and contract.

Build exercise scenarios across boundaries

Single-team exercises miss important interactions. Use scenarios that connect cyber, physical and continuity decisions.

Examples include:

• ransomware affects corporate identity while operators need plant access;
• a telecoms failure removes remote monitoring and supplier contact;
• corrupted engineering data is restored from an unverified source;
• a site evacuation transfers control to an alternate location;
• a critical cloud service fails during a severe weather event;
• a supplier remote account is compromised during emergency maintenance; or
• a power disturbance damages equipment and disrupts logging.

Set objectives before the exercise. Measure decision time, service outcome, safety constraints, security control, information integrity, communication and evidence quality.

Do not label an exercise successful merely because the meeting finished. Record unmet objectives and use them to improve design.

Evidence model

An auditor should be able to trace:

Decision	Useful evidence
Why the service is critical	Scope, impact analysis, obligations and management approval
What can disrupt it	Connected scenario and risk assessment
Why controls were selected	Treatment decision, engineering rationale and applicability
How service continues	Strategy, procedures, resource and supplier arrangements
Whether capability works	Exercise, test, maintenance and incident records
How weaknesses are addressed	Actions, risk decisions and effectiveness review

The data-centre controls guide provides a deeper example of connecting physical, environmental and technology evidence.

Audit sampling

Build samples around services and dependencies, not only control departments.

Select:

• one highest-impact service;
• one service with legacy OT;
• one material remote-access path;
• one critical supplier;
• one recent change;
• one failed or partial exercise result; and
• one real disruption, if available.

Trace each sample end to end. For a remote-access sample, inspect approval, identity, session evidence, monitoring, revocation and post-use review. For a recovery sample, verify configuration and data integrity rather than only system availability.

Governance and ownership

Critical infrastructure resilience needs joint ownership:

• top management sets risk appetite and resolves priorities;
• service owners define critical outcomes;
• safety and engineering teams protect physical process constraints;
• security manages information risk;
• continuity coordinates impact analysis and recovery;
• operations maintain day-to-day capability;
• procurement governs supplier commitments;
• legal and regulatory teams interpret obligations; and
• internal audit evaluates the integrated system.

No single framework owner can accept every operational, safety and public-impact risk.

Audit questions

Ask:

• Are critical services and dependencies complete across IT, OT, people, sites and suppliers?
• Do security and impact analyses use consistent service boundaries?
• Are unsupported or constrained systems subject to approved treatment?
• Can degraded operation preserve safety, integrity and accountability?
• Is emergency access tested and reviewable?
• Do supplier commitments match internal recovery assumptions?
• Have exercises tested compound scenarios and unavailable dependencies?
• Are failed objectives visible to management?
• Do improvements have owners and effectiveness evidence?
• Are sector-specific obligations mapped beyond ISO certification?

Pass, partial and fail examples

Pass: The organisation governed critical services end to end, connected IT and OT risk, tested degraded operation and suppliers, and used exercise results to improve security and recovery capability.

Partial: Risk and continuity processes were mature individually, but supplier assumptions and OT recovery dependencies were not fully reconciled.

Fail: The certified scope excluded the operational environment supporting the critical service. Recovery relied on an untested vendor account and no one owned secure degraded operation.

These examples illustrate evidence maturity and do not replace an auditor’s judgement.

Common weaknesses

Avoid:

• starting with asset lists instead of service outcomes;
• excluding OT because standard IT controls are difficult;
• treating availability as the only security concern;
• designing recovery without verifying data integrity;
• assuming manual operation is unlimited;
• relying on supplier claims without service-level evidence;
• exercising teams separately;
• hiding failed objectives;
• using certification as evidence of legal compliance; or
• overlooking physical and safety constraints.

The U.S. Cybersecurity and Infrastructure Security Agency’s Cross-Sector Cybersecurity Performance Goals provide voluntary high-impact practices that can supplement, but do not replace, an organisation’s risk treatment and sector requirements.

Practical conclusion

ISO 27001 and ISO 22301 are most useful to critical infrastructure when they govern one service reality. Connect information risk to business impact, security controls to recovery strategies, and technology evidence to operational outcomes.

Test compound scenarios, degraded modes, suppliers and emergency access. Keep safety and sector obligations explicit. The result should be more than two aligned policy sets: it should be a service that remains secure enough and recoverable when normal assumptions fail.