ISO 27001 is technology-neutral. The standard does not care whether the information assets it protects sit on hardware the organisation owns, infrastructure the organisation rents, or services the organisation consumes. The control framework adapts to each pattern. In practice, ISMSs designed in the on-premises era and extended to cloud often carry forward assumptions that no longer fit — about data location, about administrative access, about logging, about backup. The ISMS adapts to the cloud reality if the implementation work makes it so; if not, the gap surfaces in audit and in incidents.
The Shared Responsibility Model as a Scoping Tool
Every major cloud provider publishes a shared responsibility model that delineates which security controls the provider is responsible for and which remain with the customer. The model is not abstract — it determines which controls in the ISMS are operated by the organisation, which are operated by the provider with evidence the organisation collects, and which are shared in operationally specific ways. ISMSs that do not encode the shared responsibility model explicitly tend to under-scope provider-operated controls (the organisation does not know what evidence to collect) and over-scope customer-operated controls (the organisation thinks it has the control when the provider does).
Treating the Provider as a Critical Supplier
A cloud provider hosting the bulk of an organisation's production workloads is operationally a critical supplier — frequently the single most critical supplier in the estate. ISO 27001's supplier relationship controls apply with full weight, and the ISMS must treat the provider relationship with the rigour the criticality demands. Provider security certifications (SOC 2, ISO 27001, FedRAMP, sector-specific attestations) form the evidence base. Contractual provisions cover data residency, breach notification, sub-processor management, and audit rights. Operational monitoring tracks provider service health, security incidents disclosed by the provider, and material changes to provider security posture. The supplier management discipline applied to the cloud provider is qualitatively different from the discipline applied to a niche SaaS vendor.
SaaS Sprawl as the Real Scoping Challenge
For most organisations operating today, the larger ISMS scoping challenge is not the primary cloud provider — it is the long tail of SaaS applications the organisation consumes. Marketing platforms, sales tools, HR systems, finance applications, collaboration tools, productivity suites — each holds organisational data, each represents a supplier relationship, each is part of the ISMS scope. Organisations that try to enumerate the SaaS estate at audit time discover that the SaaS sprawl substantially exceeds what IT thinks it is. The SaaS inventory and the supporting supplier management programme are the scoping discipline that keeps the cloud ISMS honest.
A pattern in cloud-era ISMS audits: the organisation has rigorous supplier management for the headline cloud provider, partial visibility into the major SaaS vendors, and effectively no visibility into the long tail of SaaS applications procured by business units outside the formal procurement process. The auditor samples the SaaS estate from a corporate card statement and finds applications that are not in the supplier register, not in the asset register, and not subject to any ISMS control. The headline programme is strong; the long tail is the gap. Discovery here typically starts with the financial system, not with the IT inventory.
Configuration as a Substantive Control Surface
Cloud security failures rarely stem from provider compromise — they predominantly stem from customer misconfiguration. Public buckets, over-permissive identity and access management, exposed management interfaces, missing logging, default credentials, and similar configuration failures account for a significant majority of cloud-era breaches. The ISMS needs to treat configuration as a substantive control surface in its own right — with cloud security posture management tooling, configuration baselines, drift detection, and remediation workflows. Organisations that do not build this capability find that their cloud ISMS works in principle and fails in operation.
ISO 27017 and 27018 as Complementary Standards
ISO 27017 provides cloud-specific guidance complementing ISO 27001 controls, and ISO 27018 covers the protection of personally identifiable information in public clouds. Neither is required for ISO 27001 certification, and both substantially improve the quality of cloud-adapted ISMSs that use them. The standards are written as guidance — they tell the organisation how the existing 27001 controls apply in a cloud context and what additional cloud-specific considerations matter. Organisations operating heavily in cloud derive disproportionate value from reading these standards substantively rather than treating them as optional reference material.
A Cloud-Adapted ISMS Checklist
- Shared responsibility model encoded explicitly per provider, with ISMS responsibilities aligned
- Cloud providers treated as critical suppliers with appropriate contractual and operational management
- Comprehensive SaaS inventory including the long tail surfaced from financial as well as IT records
- Cloud security posture management for configuration drift detection and remediation
- Identity and access management discipline that fits cloud scale — federation, conditional access, privileged access workflows
- Logging and monitoring architecture that aggregates across cloud and on-premises sources
- Data residency and sub-processor management aligned with regulatory and contractual obligations
- Use of ISO 27017 and 27018 as substantive complementary guidance, not just optional reference
The Programme Quality That Matters
The cloud-adapted ISMS that audits well and operates well is not a different standard implementation — it is the same ISO 27001 implementation with cloud-specific decisions made deliberately rather than implicitly. The substantive adaptation work is in the supplier programme, the configuration discipline, the SaaS inventory, and the shared responsibility encoding. Each of these is bounded and tractable. The organisations that do this work produce ISMSs that genuinely cover their operating environment; the organisations that do not produce ISMSs that protect what they used to be and not what they now are.