Ninety percent of companies now run some part of their business on cloud applications, according to Bitkom’s 2025 Cloud Report, up from 81 percent the year before. ISO/IEC 27001:2022 responded to that shift with a control that did not exist in the 2013 version: Annex A 5.23, Information Security for Use of Cloud Services.
For SaaS companies and any organization storing customer data in AWS, Azure, Google Cloud, or a stack of subscription tools, this control changes what an auditor expects to see. A signed data processing agreement is no longer enough. You need a documented lifecycle for every cloud service you use, from acquisition through exit, and evidence that your team understands exactly where the provider’s responsibility ends and yours begins.
Why ISO 27001 Needed a Cloud-Specific Control
The original ISO/IEC 27001:2013 Annex A assumed most information assets sat inside infrastructure the organization physically controlled. Supplier controls existed, but nothing addressed the specific mechanics of cloud computing: multi-tenancy, elastic scaling, non-negotiable click-through agreements, or a provider that could relocate your data to a different jurisdiction with a configuration change.
The 2022 revision closed that gap with Control 5.23, sitting inside the organizational controls theme alongside supplier management. It does not replace supplier due diligence under 5.19 through 5.22. It extends that framework to address what makes cloud different: the security boundary is shared, contracts are usually standardized rather than negotiated, and the underlying infrastructure can change without direct notice.
This matters for the Statement of Applicability. Excluding 5.23 because “we use SaaS tools, not our own servers” is a common early mistake. If any information asset in scope touches a cloud service, the control applies, and the SoA needs a documented justification either way.
Secure cloud environments rely on robust ISO 27001 access control requirements for identity and privilege management.
What Annex A 5.23 Actually Requires
Control 5.23 is preventive in nature and covers four lifecycle stages: acquisition, use, management, and exit. ISO frames the requirement simply: processes for each stage should align with the organization’s information security requirements. In practice, auditors break that into concrete, checkable items.
A topic-specific cloud security policy comes first. It should name which cloud service models are permitted, IaaS, PaaS, SaaS, and the security configuration each one requires before it can be adopted. Vague statements like “we vet our vendors” do not satisfy this; the policy needs to specify criteria such as required certifications, encryption standards, and data residency constraints.
Second, the policy has to assign ownership. Control 5.23 is often shared between IT and procurement, but ISO expects a named role, not a committee, responsible for cloud risk decisions.
Third, and this is where most organizations underinvest, the control requires an inventory. Every SaaS, PaaS, and IaaS service touching in-scope data needs to appear in a living register, not a one-time spreadsheet from the last audit cycle. Shadow IT, tools that individual teams adopt without going through procurement, is the most common reason this control fails during surveillance audits.
Cloud security depends on effective third-party governance, making ISO 27001 supplier security controls an essential companion to Annex A 5.23.
| SoA Note: If Control 5.23 is marked applicable in your Statement of Applicability, auditors will expect a dated cloud services inventory, a topic-specific policy, and evidence of at least one provider security review in the last twelve months, not just a policy document sitting unused. |
The Shared Responsibility Model: Where ISO 27001 Draws the Line
Cloud services do not eliminate risk; they redistribute it. Under the AWS Shared Responsibility Model, Amazon secures the physical data centers, the hypervisor, and the global network. The customer is responsible for everything built on top: firewall rules, identity and access management, data classification, and encryption configuration. Azure and Google Cloud use structurally similar splits.
ISO 27001 does not require you to take over the provider’s half of the responsibility. It requires you to document where the line sits and prove your team is actually managing its side. This is a frequent audit failure point: teams assume a Tier 1 provider “handles everything” because the provider holds ISO 27001 or SOC 2 certification, then leave S3 buckets public or IAM roles overly permissive.
The responsibility split also shifts by service model. With IaaS, you manage the operating system, middleware, and application layer. With PaaS, the provider manages the runtime and you focus on application code and data. With SaaS, you are usually left managing configuration, user access, and data governance only, but that residual slice is still yours to prove at audit.
Mapping Annex A Controls Across IaaS, PaaS and SaaS
A useful way to operationalize 5.23 is to map it against the other Annex A controls that already govern access, encryption, and monitoring, then note who owns each one by service model. This table reflects how GAICC-trained auditors typically expect responsibility to be documented in a cloud risk register.
Annex A control ownership by cloud service model
| Annex A Control | IaaS (e.g., EC2, Compute Engine) | PaaS (e.g., managed databases) | SaaS (e.g., CRM, HRIS) |
|---|---|---|---|
| 8.24 Cryptography | Customer configures | Shared configuration | Provider-managed, customer verifies |
| 8.5 Secure Authentication | Customer implements | Customer implements | Customer configures SSO/MFA |
| 5.15 Access Control | Customer owns fully | Customer owns fully | Customer owns role assignment |
| 8.16 Monitoring Activities | Customer configures logging | Shared, provider supplies logs | Provider-dependent, often limited |
| 7.x Physical Controls | Provider-managed | Provider-managed | Provider-managed |
| 5.23 Cloud Service Use | Customer-owned process | Customer-owned process | Customer-owned process |
Multi-Tenancy, Encryption and Access Control in Practice
Multi-tenant architecture, multiple customers sharing the same underlying infrastructure, is what makes SaaS economically viable and what makes ISO auditors ask harder questions. A misconfigured tenant boundary does not just risk one company’s data; it risks every tenant on that instance.
For encryption, ISO 27001 does not mandate a specific algorithm, but auditors expect industry-standard choices documented in policy: AES-256 for data at rest, TLS 1.2 or higher for data in transit, and a defined key management process that specifies who can access encryption keys and how key rotation happens. A common gap is encrypting data at rest but leaving internal service-to-service traffic unencrypted because it “never leaves the VPC.”
Access control compounds the multi-tenancy risk. Role-based access with least privilege, multi-factor authentication, and secure API authentication (OAuth 2.0 or equivalent, not static API keys) are the baseline auditors look for under Controls 5.15 through 5.18. Regular access reviews matter more in cloud environments than on-premise ones, because SaaS platforms tend to have higher onboarding and offboarding velocity, and a departed contractor’s API token is a common finding in penetration test reports.
Supplier Due Diligence: Cloud Providers Are Still Suppliers
Control 5.23 does not operate in isolation. It depends on 5.19 for general supplier relationship rules, feeds into 5.20 for security terms in supplier agreements, and connects to 5.22 for ongoing supplier service monitoring. Auditors expect to see these four controls working together, not 5.23 treated as a standalone checkbox.
Before adopting a cloud provider, the standard expects a documented pre-selection review: current SOC 2 Type II report or ISO 27001 certificate, confirmation that the audit scope actually covers the data center and service being used (not just the parent company), and identification of any Complementary User Entity Controls, security responsibilities the report assumes you will implement yourself, that most teams skip reading.
After onboarding, monitoring cannot stop at “we checked their certificate once.” Annex A 5.22 requires periodic review of the provider’s continued conformance, typically annually, with documented evidence: the current audit report, notes on any subprocessor changes, and confirmation that contractual security terms are still being met.
The Exit Strategy Most Organizations Skip
Every organization plans how it will start using a cloud service. Far fewer plan how they will leave one, and this is the single most commonly missing piece of evidence during 5.23 audits. ISO expects a documented, tested exit strategy for every cloud service classified as critical.
A defensible exit strategy covers three things: a technical procedure for retrieving data in a usable, non-proprietary format; a defined timeline for secure deletion of data on the provider’s side after retrieval; and continuity measures so a critical service does not go dark mid-transition. Auditors increasingly ask for evidence of a dry run, an actual export and integrity check performed on a schedule, not a procedure that has only ever existed on paper.
Vendor lock-in is the underlying risk this addresses. A provider that goes out of business, terminates your account for a terms-of-service dispute, or gets acquired and changes its data handling practices should not be able to leave your organization without access to its own information.
Continuous Monitoring and the Evidence Auditors Actually Ask For
Cloud environments change constantly: new services get provisioned, configurations drift, and access permissions accumulate. A point-in-time review at audit season is not sufficient; Control 5.23 expects ongoing oversight built into how the organization operates day to day.
In practical terms, this means enabling and retaining access logs (AWS CloudTrail, Azure Monitor, or equivalent) for a defined retention period, reviewing configuration against a documented baseline such as CIS benchmarks, and having an alerting mechanism for high-risk changes like a storage bucket becoming publicly accessible.
The evidence trail an auditor wants is specific and dated, not a narrative. A folder of the last twelve months of provider audit reports with internal review notes attached. A baseline configuration report showing active cloud environments meet the organization’s hardening standard. Screenshots or exports showing region-lock policies are enforced where data residency commitments exist. Auditors have grown skeptical of GRC platform dashboards showing a green checkmark with no underlying artifact; they want to see the risk assessment and exit strategy documented in the organization’s own systems, whether that is a wiki, a ticketing system, or a document management platform, not just a third-party tool’s summary screen.
US Regulatory Crosswalk for Cloud Security Controls
For US-based compliance teams, cloud security work under ISO 27001 rarely happens in isolation from other frameworks. Mapping Annex A 5.23 and its supporting controls against US requirements reduces duplicated evidence collection and strengthens the case to leadership that one control investment satisfies multiple obligations.
Cross-framework alignment for cloud security controls
| US Framework | Relevant Requirement | Overlap with ISO 27001 5.23 |
|---|---|---|
| NIST SP 800-53 | SA-9 External Information System Services | Shared responsibility documentation, provider assessment |
| NIST CSF 2.0 | GV.SC (Supply Chain Risk Management) | Cloud provider due diligence and monitoring |
| FedRAMP | Continuous monitoring, POA&M tracking | Ongoing provider security review cadence |
| CMMC 2.0 | SC.L2-3.13.x boundary protection practices | IaaS/PaaS configuration and access control mapping |
| HIPAA Security Rule | Business Associate Agreement requirements | Data residency, encryption, and exit documentation |
| SOC 2 (Type II) | Common Criteria CC9 (Risk Mitigation) | Vendor SOC 2 report review, CUEC implementation |
Where Cloud Security Programs Fail ISO 27001 Audits
A handful of gaps show up repeatedly in nonconformity reports. Shadow IT tops the list: teams self-provisioning SaaS tools outside procurement, which breaks the inventory requirement at its foundation. The fix is rarely a stricter ban; it is a lightweight approval path fast enough that teams do not route around it.
The second recurring gap is assuming certification equals configuration. A provider’s ISO 27001 or SOC 2 certificate proves their controls are sound, not that your account within their platform is configured securely. Auditors will ask you to demonstrate your own configuration evidence separately from the provider’s certificate.
The third is treating the exit strategy as a paragraph in a contract rather than a tested procedure, covered above, and the fourth is documentation that exists but was never updated after a cloud architecture change, a new region, a new subprocessor, a migration between providers, leaving the Statement of Applicability and the risk register out of sync with reality.
Cloud environments should also implement the safeguards described in our ISO 27001 Technological Controls guide.
Frequently Asked Questions
Is ISO 27001 Annex A 5.23 mandatory for every organization?
Control 5.23 is not automatically mandatory, but it becomes relevant the moment any in-scope information asset touches a cloud or SaaS service. You can mark it not applicable in your Statement of Applicability only if you can justify that exclusion, which is rare for any organization running modern IT operations.
Does using AWS or Azure automatically satisfy ISO 27001 cloud requirements?
No. The provider’s own certification covers their side of the shared responsibility model, typically physical security and core infrastructure. You still need to document and prove your own configuration, access control, and monitoring practices for the resources you provision within that environment.
What is the difference between ISO 27001 5.23 and ISO 27017?
ISO 27001 is the certifiable management system standard; Annex A 5.23 is one control within it. ISO 27017 is a code of practice, not a certification, that provides more detailed cloud-specific guidance across 37 existing ISO 27002 controls plus seven cloud-only additions. Many organizations use 27017 to inform how they implement 5.23 rather than certifying against it separately.
How often should we review a cloud provider’s security posture?
Annual review is the common baseline auditors expect, tied to Control 5.22, but higher-risk providers handling regulated data often warrant a more frequent cadence. Reviews should include the current audit report, any subprocessor changes, and confirmation that contractual security terms are still being met.
What audit evidence does an ISO 27001 auditor expect for cloud services specifically?
Expect requests for a cloud services inventory, a topic-specific cloud security policy, signed agreements addressing security requirements, the last 12 months of provider audit reports, a documented exit strategy with evidence of a data export test, and access logs demonstrating monitoring is active rather than theoretical.
Does Control 5.23 apply differently to SaaS versus IaaS providers?
The control’s requirements are the same across service models, but the residual work differs. SaaS customers typically manage configuration, user access, and data governance since the provider controls the underlying stack. IaaS customers carry a larger share of technical responsibility, including operating system and network security.
What is a Complementary User Entity Control, and why does it matter for ISO 27001?
A Complementary User Entity Control, or CUEC, is a security responsibility a SOC 2 report explicitly assumes the customer will implement, such as configuring MFA or managing user provisioning. Auditors check that these CUECs have actually been implemented internally, not just acknowledged on paper.
Conclusion
Cloud security under ISO 27001 comes down to one discipline: knowing exactly where your responsibility starts, documenting it, and proving it with dated evidence rather than a provider’s certificate. Annex A 5.23 formalizes that discipline across the full lifecycle of every cloud service you rely on, from the moment you sign up to the day you leave.
Start by pulling together a current inventory of every SaaS, PaaS, and IaaS service touching in-scope data, then check each one against a documented exit strategy and a security review from the last twelve months. Where those gaps exist, GAICC’s ISO/IEC 27001 Lead Implementer training walks through building this evidence base control by control.
