ISO 27001 Annex A 5.23 – Information Security for Use of Cloud Services

Annex A 5.23 treats a cloud service as a live dependency, not a purchase you assess once. The control asks you to define information security requirements for each cloud service you consume, apply them across the full lifecycle — acquisition, use, management and exit — and keep the arrangement understood as both your configuration and the provider's service evolve.

The operational core is the shared responsibility model. For every cloud service you must be able to say who secures what: which controls the provider operates, which sit with you as the customer, and where the boundary moves between IaaS, PaaS and SaaS. A requirement that is the provider's job in one service can be your job in another; misreading that split is a common cause of incidents.

Crucially, 5.23 is not satisfied by a signed contract and a security questionnaire at go-live. A provider can add a subprocessor, relocate processing to a new region, change a data-processing clause, or amend its trust and security commitments at any point in the relationship. The control expects you to notice those changes and reassess, so that the risk position you signed off on is still the risk position you are actually running.

In practice that means a stated position on how cloud services may be acquired and used, explicit selection and exit criteria, and a mechanism for keeping provider commitments — data location, security certifications, subprocessors, breach-notification terms — under review for the life of the service rather than only at procurement.

An assessor is looking for evidence that cloud services are governed as a managed portfolio, not adopted ad hoc. Concrete artefacts include:

• A cloud services policy stating how services may be acquired, who approves them, the security requirements they must meet, and the criteria for exiting or migrating away from one.
• An inventory of cloud services in use, each mapped to a business owner, the data classification it handles, and its position under the shared responsibility model.
• A documented responsibility split per service — provider-operated controls versus customer-operated controls — reconciled against the provider's own shared-responsibility documentation.
• Evidence of provider due diligence: current certifications (for example ISO 27001, SOC 2), the signed DPA, subprocessor list, data-location commitments and breach-notification terms, each captured with a date.
• A defined review cadence and a record of reviews actually performed, risk-weighted so that critical services are examined more often than low-impact ones.
• A dated trail of detected provider-side changes — a new subprocessor, a moved data region, an updated DPA or security policy — with your assessment of each and any action taken.
• An exit and portability plan covering data return or deletion, so that dependency on a single provider does not become an unmanaged availability risk.

The cadence and change-trail items are where 5.23 meets the monitoring discipline of 5.22: good practice is not just holding today's snapshot of a provider's posture, but being able to show when that posture changed and that you caught it. A dated record of the change — rather than a vague recollection that the provider probably updated its DPA at some point — is what turns a review into evidence.

Because many of these changes are published externally, on a provider's subprocessor list, DPA or published security policy, a monitoring layer such as Venpo can watch those public documents and timestamp exactly what changed, giving you a corroborating record without waiting for the provider to send a notice. It supplements your own review; the internal assessment and risk decision remain yours.

Controls 5.19 through 5.23 form the supplier-relationship cluster, and they run in sequence across the life of a third-party arrangement:

• 5.19 – Information security in supplier relationships: the overall approach to managing security risk arising from suppliers.
• 5.20 – Addressing information security within supplier agreements: getting the right security terms into the contract.
• 5.21 – Managing information security in the ICT supply chain: propagating your requirements down the chain of ICT product and service suppliers, including sub-suppliers and any party a supplier sub-contracts to.
• 5.22 – Monitoring, review and change management of supplier services: keeping the relationship under review and reacting to change after signing.
• 5.23 – Information security for use of cloud services: the cloud-specific application of that same lifecycle, from acquisition to exit.

5.23 is the domain-specific control; 5.22 is the engine that keeps it honest over time. 5.23's guidance has its own approach for monitoring, reviewing and evaluating each cloud service; 5.22 supplies the wider supplier discipline of review and change management that keeps it working after go-live. A new subprocessor on a SaaS provider's disclosure page, processing moved to a different jurisdiction, or a materially revised DPA is simultaneously a 5.23 cloud-risk event and a 5.22 change event — and that join is where a change can happen without anyone detecting or assessing it.

Because much of what changes on the provider side is published externally, the detection burden for both controls falls partly on watching the provider's published documents. This is the narrow, honest role for an external monitoring layer: services such as Venpo crawl vendors' published legal documents — subprocessor lists, DPAs, privacy policies, terms and published security policies — and produce a dated diff when the text changes, which feeds the 5.22 review that keeps your 5.23 cloud governance current. It corroborates your supplier-review process; it does not replace the internal assessment, the contract terms, or the risk decision that remain yours.

• Treating go-live as the finish line. A thorough onboarding assessment followed by silence is the most common gap. The control is a lifecycle obligation, and a two-year-old provider file with no review since is a finding.
• No cloud inventory, or a stale one. Shadow SaaS adopted by a team without going through procurement is invisible to the ISMS and cannot be governed. If you cannot list the cloud services in use, you cannot claim to secure them.
• Owning the wrong side of the shared-responsibility line. Assuming the provider encrypts, patches, backs up or configures securely when that duty actually sits with the customer. Misreading the boundary produces real exposure and audit findings alike.
• Ignoring subprocessor and data-location changes. A provider adding a subprocessor or moving processing to a new region can breach your own data-transfer commitments. If the first you hear of it is during an incident, your 5.22 and 5.23 monitoring was not working.
• Change detection that depends on the provider telling you. Relying solely on vendor notification emails means silent or buried changes go unnoticed. Effective monitoring watches the published artefacts directly.
• No exit plan. Concentration on a single provider with no tested route to retrieve or delete data turns a supplier relationship into an unmanaged availability and lock-in risk.
• Undated evidence. Knowing a provider's current posture is not the same as showing when it changed and that you responded. Without dates, a review is an assertion rather than evidence.