Cloud Security and Continuity Under ISO 27001 and ISO 22301

Cloud services do not remove information-security or continuity responsibilities. They redistribute them across the customer, cloud provider and other suppliers. ISO/IEC 27001 helps an organisation manage confidentiality, integrity and availability risks, while ISO 22301 provides a management-system approach to sustaining priority activities through disruption.

The useful question is not whether a provider is “secure” or “resilient.” It is whether the complete service, including the customer’s configuration, identities, data, integrations and recovery decisions, can meet approved business needs.

Replace the outdated continuity reference

Older cloud guidance may refer to BS 25999, an earlier business-continuity standard. ISO 22301 is the current international requirements standard for a business continuity management system. ISO/IEC 27001:2022 is the current ISMS requirements standard, and ISO/IEC 27017:2026 provides cloud-specific security-control guidance based on ISO/IEC 27002.

This matters because a modern cloud control model must address shared responsibility, rapid configuration change, service concentration and provider dependencies. Do not carry an old standard number into policy without reassessing the actual service and current requirements.

The ISO 27001 and ISO 27017 comparison explains how cloud-control guidance supports, but does not replace, the ISMS.

Define the complete cloud service

Start with the business service rather than the provider contract. Map the applications, data, identities, networks, regions, support arrangements and upstream services required to deliver an outcome.

For each material cloud service, record:

• business owner and technical owner;
• information classification and service criticality;
• provider, service model and purchased tier;
• customer and provider responsibilities;
• primary and recovery locations;
• identity, network and encryption dependencies;
• integrations and downstream consumers;
• recovery objectives and minimum service needs;
• incident and continuity contacts; and
• exit, data return and deletion arrangements.

This record should be specific enough to expose hidden dependencies. A software service may rely on the customer’s identity provider, a separate integration platform and a provider-operated backup feature. Any one of those can determine the real recovery outcome.

Build a shared-responsibility matrix

Supplier documentation often describes responsibility at a high level. Convert it into decisions the organisation can operate and test.

Control area	Provider responsibility	Customer responsibility	Joint evidence
Identity	Platform identity capabilities and service administration	Account lifecycle, authentication settings and access review	Configuration, access records and escalation route
Data protection	Service storage and available encryption features	Classification, key choices, retention and lawful use	Enabled settings, key records and restore sample
Availability	Contracted infrastructure and service commitments	Architecture, demand planning and business workarounds	Service reports, incident review and exercise results
Logging	Events exposed by the service	Enablement, export, retention and response	Source configuration, received events and alert cases
Recovery	Provider recovery capabilities	Workload recovery design and priority decisions	Recovery procedure, dependency map and timed test
Exit	Provider export and deletion mechanisms	Migration plan, validation and access removal	Export test, revocation and closure evidence

Treat unclear ownership as a risk. “Shared” should not mean that neither party has an assigned action. The supplier security lifecycle guide provides a broader structure for due diligence, contracting, monitoring and exit.

Connect security risk and business impact

ISO 27001 risk assessment and ISO 22301 business impact analysis answer different questions. Risk assessment considers uncertainty, threats, vulnerabilities and consequences. Business impact analysis examines how disruption affects activities over time and what recovery priorities are needed.

Use both views. A provider-region outage may have low likelihood but unacceptable impact for a priority service. A misconfigured storage policy may create a more frequent confidentiality risk without stopping the service. The treatment portfolio should address both.

Avoid assuming that a provider’s availability commitment equals the organisation’s recovery objective. Contracted availability is measured over a period and may provide service credits. A recovery objective is an organisation-approved target for restoring an activity or workload after disruption. They are related but not interchangeable.

Design for failure at the right level

Select continuity strategies from business need, dependency and cost. Options can include multi-zone deployment, alternate regions, independent backups, exportable data, alternate communication channels, manual workarounds or an alternative provider.

More infrastructure is not automatically more resilient. Two instances in one failure domain may share the same dependency. A second region may still rely on one identity service or deployment pipeline. Multi-provider designs add operational complexity and can fail if they are not maintained and exercised.

Document the scenario each measure addresses, its activation authority, required people and expected outcome. The ISO 22301 continuity-controls guide shows how business continuity practices can strengthen ISO 27001 availability controls.

Protect information during recovery

Recovery can weaken normal controls if teams use emergency accounts, copied data, temporary networks or manual transfers. Define security requirements for the recovery state:

• who may declare and administer recovery;
• how emergency identities are protected and reviewed;
• which data copies are permitted and where they may be restored;
• how keys, secrets and certificates are available;
• which logs remain active;
• how temporary connections are approved; and
• how normal controls are reinstated.

Backups should be protected from the same identity or destructive event that affects production where the risk warrants it. Test both restoration and integrity. A provider dashboard showing successful backup jobs does not prove that the business service can be recovered.

Manage location and concentration risk

Cloud location is more than the region selected in a console. Consider where primary data, replicas, backups, support access and diagnostic records may be processed. Confirm legal, contractual and operational requirements, then monitor changes in provider architecture and subprocessors.

The cloud data-location risk guide explains how to maintain this evidence without relying on a one-time location statement.

Concentration also matters. Several business services may use the same provider, identity platform, network carrier or managed-service team. Assess aggregate impact rather than approving each service in isolation.

Specify supplier evidence before contracting

Request evidence that supports the actual decision. Depending on risk, this may include independent assurance reports, certification scope, service architecture, recovery-test summaries, incident history, subcontractor information and operational performance.

Check dates, scope, exclusions and customer responsibilities. A certificate can support assurance, but it does not prove that a particular workload is correctly configured or that the customer’s end-to-end recovery will meet its objectives.

Contract terms may address notification, service changes, access to evidence, cooperation during incidents, data portability, recovery support and termination. Ensure the service tier purchased provides the necessary capability; features described in general documentation may not apply to every plan.

Exercise end-to-end recovery

Use scenarios that include provider and customer actions. A useful exercise can test:

1. detection and escalation of the disruption;
2. decision authority and contact availability;
3. restoration of data, configuration and identities;
4. reconnection of integrations and dependent services;
5. security monitoring during the recovery state;
6. business validation of the resumed service; and
7. controlled return to normal operation.

Record actual timing, data condition, failed assumptions, workarounds and assigned improvements. Tabletop discussion tests decisions and roles; technical recovery tests verify capability. Use both where appropriate.

Audit the operating chain

Sample cloud services by business impact, information sensitivity and supplier. Trace each sample from approval and responsibility mapping to configured controls, monitoring, continuity strategy and exercise evidence.

Useful audit questions include:

• Which party owns each material control and recovery action?
• Do contracted features match the deployed service tier?
• Can the organisation recover without the primary identity or administration path?
• Are backups independent enough for the relevant scenarios?
• Do provider reports lead to decisions and actions?
• Has an end-to-end exercise tested integrations and business validation?
• Can data and configurations be exported during exit?

A pass is supported when responsibilities are explicit, the service design follows risk and impact, supplier evidence is current and recovery is tested across organisational boundaries.

A partial result may exist when provider assurance is strong but customer configuration, concentration analysis or end-to-end testing is incomplete.

A fail is likely when the organisation relies on provider reputation, cannot identify critical dependencies or has never demonstrated that its service and data can be recovered.

Use the risk score calculator to prioritise cloud scenarios consistently, while retaining management judgement and approved risk criteria.

Maintain one evidence system

Cloud services change frequently. Trigger review after major architecture, provider, region, identity, data or contract changes. Reconcile inventories with observed services and remove abandoned resources and access.

The official ISO/IEC 27017:2026 page confirms that the current edition provides cloud-service security-control guidance. The official ISO 22301 overview describes the requirements standard for business continuity management systems.

The strongest evidence is an end-to-end chain: a defined business service, explicit shared responsibilities, risk- and impact-based design, current supplier assurance and a recovery result that the business has validated.