Annex A 5.23: Information Security for Use of Cloud Services

Annex a 5.23: information security for use of cloud services requirement means you must govern cloud use with defined security requirements, clear shared-responsibility ownership, and ongoing assurance that cloud configurations, access, and data protections match your risk and compliance needs. Operationalize it by inventorying cloud services, setting minimum control baselines, contracting for security terms, and retaining recurring evidence.

Key takeaways:

• Treat cloud services as a controlled third-party service with explicit requirements, not an ad hoc IT convenience.
• Prove operation with recurring evidence: inventory, risk assessment, security baseline, monitoring, and review records.
• Align responsibilities across your team and the cloud provider through contracts, configuration standards, and continuous assurance.

A 27001 auditor will look for one thing under Annex A 5.23: you control how cloud is selected, configured, and monitored, with evidence that your controls work over time. The control is easy to “say yes to” and surprisingly easy to fail in practice because cloud adoption often happens bottom-up, across multiple teams, with inconsistent baselines and unclear ownership.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate 5.23 into a small set of non-negotiables: (1) a complete inventory of cloud services and cloud-hosted systems, (2) defined security requirements for cloud use (by data type and workload), (3) third-party due diligence and contract terms that match those requirements, and (4) continuous operational checks for misconfiguration, excessive access, and uncontrolled data movement.

This page gives requirement-level implementation guidance you can hand to Cloud, Security, Procurement, and Engineering without rewriting it. It also focuses on the part that most teams miss: evidence. If you cannot show repeatable control operation, you will struggle to demonstrate conformity with ISO/IEC 27001 expectations for cloud governance ¹.

Regulatory text

Framework reference: ISO/IEC 27001:2022 Annex A control 5.23 ¹

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 5.23 implementation expectation (Information Security for Use of Cloud Services).” ¹

What the operator must do (requirement intent):
You must define and implement information security requirements for cloud services, then verify those requirements are met throughout the cloud service lifecycle (selection, onboarding, change, and offboarding). This includes governing cloud use through policy, roles/responsibilities, risk assessment, contractual terms, configuration standards, and ongoing assurance activities ¹.

Plain-English interpretation

If your organization uses any cloud service (IaaS, PaaS, SaaS, managed databases, “AI as a service,” or cloud-based logging/monitoring), you need a documented, enforced way to:

1. decide which cloud services are allowed for which data and workloads,
2. require security controls from the provider and from your own teams (shared responsibility), and
3. continuously confirm your cloud environment stays compliant after changes.

A clean mental model: 5.23 is “cloud governance plus proof.” Your auditor will not accept “our provider is secure” or “we have SOC 2 reports” as a substitute for your own cloud requirements and your own operational checks.

Who it applies to

Entity scope

• Any organization implementing ISO/IEC 27001 that uses cloud services in delivering products/services or supporting internal operations ².

Operational contexts that trigger 5.23 work

• SaaS for business functions: HRIS, CRM, ticketing, finance, collaboration tools.
• IaaS/PaaS hosting: production apps, dev/test environments, container platforms, serverless, managed databases.
• Security and operations tooling in cloud: cloud SIEM, monitoring, endpoint management consoles.
• Third-party sub-processors: your third parties using cloud to process your data.

If any team can “click-to-buy” a cloud service, you need governance controls that work at the speed of procurement and engineering.

What you actually need to do (step-by-step)

Below is a practical implementation sequence that maps cleanly to auditor expectations for Annex a 5.23: information security for use of cloud services requirement.

1) Establish cloud governance ownership (RACI you can enforce)

• Assign an Executive Owner (often CISO/Head of Security) and a Control Owner (GRC/Security Assurance).
• Define required approvers for: new cloud provider, new account/subscription, new region, and new data classification in cloud.
• Document the shared responsibility boundaries: what your cloud provider does, what your teams must configure and monitor.

Output: Cloud governance RACI + onboarding/offboarding workflow.

2) Build and maintain a complete cloud services inventory

Minimum fields auditors expect to see in an inventory:

• Provider/service name, purpose, business owner, technical owner
• Data types and classification processed/stored
• Integration points (SSO, APIs, data flows)
• Hosting regions and residency constraints
• Contract and renewal date
• Evidence links (risk assessment, due diligence package, security baseline)

Execution tip: Start with finance/AP (paid subscriptions), SSO directory (app catalog), and cloud org accounts. Reconcile to identify “shadow cloud.”

Output: Cloud services register (system of record) with ownership and data classification.

3) Define cloud security requirements (a minimum baseline + risk-based add-ons)

Write a “Cloud Security Standard” that states what must be true before go-live and what must be continuously true. Keep it short enough that engineers will follow it.

Baseline topics to include:

• Identity and access management: SSO, MFA, least privilege, break-glass access
• Logging and monitoring: what logs, retention expectations, alert routing
• Encryption: in transit, at rest, key management ownership
• Configuration management: approved regions, network controls, secure defaults
• Vulnerability and patch expectations (where applicable)
• Data handling: approved storage locations, restrictions on public sharing
• Backup/restore and resilience expectations
• Incident notification and support paths (provider and internal)

Risk-based add-ons (triggered by data class/workload criticality):

• Customer data processing, regulated data, or production workloads
• External-facing services
• High privilege admin consoles
• Material subcontracting/sub-processing

Output: Approved cloud security standard + control mappings to your ISMS.

4) Embed requirements into third-party due diligence and contracting

Treat cloud providers as third parties with explicit security obligations. Your due diligence package should align to the baseline above.

Contract/security schedule topics to negotiate or confirm:

• Security responsibilities and control commitments relevant to your use case
• Incident notification expectations
• Subprocessor transparency (where applicable)
• Data location and return/deletion at termination
• Audit/support rights and evidence availability
• Change notification for material service changes that affect security

Output: Completed third-party risk assessment for cloud services + executed contract/security addendum.

5) Implement technical guardrails to enforce the baseline

Policy documents do not prevent drift. Put guardrails where changes occur:

• Cloud org/account structure and centralized identity
• Baseline configurations via templates (infrastructure-as-code where feasible)
• Preventive controls: restrict public storage, restrict unmanaged admin accounts, restrict unapproved regions
• Detective controls: alerts for public exposure, privilege escalation, key changes, disabled logs

Output: Guardrail configurations + monitoring rules with ownership.

6) Operationalize continuous assurance (recurring evidence capture)

Define review cadences for:

• Cloud inventory completeness and new service intake
• Access reviews for privileged roles
• Configuration compliance checks against your baseline
• Incident and problem trends related to cloud misconfiguration
• Provider assurance updates (new reports, material changes, major incidents)

Output: Recurring review records, tickets, and monitoring reports that show the control operates continuously.

7) Offboarding and exit readiness

Cloud risk persists at termination. Require:

• Data export/return steps
• Verified deletion/retention decisions
• Access removal
• Integration disablement (SSO/API keys)
• Evidence archive (final configuration snapshots and termination confirmation)

Output: Offboarding checklist completion + termination evidence.

Required evidence and artifacts to retain

Auditors will ask for proof across selection, operation, and review. Keep evidence in a single control folder tied to 5.23.

Core artifacts (high value in audits):

• Cloud services inventory/register with ownership and data classification
• Cloud security policy/standard and configuration baselines
• Cloud third-party due diligence packages (risk assessments, provider attestations you received, security questionnaires you completed)
• Contracts/security addenda and DPAs (where applicable)
• Onboarding approvals (tickets/records) showing risk-based decisions
• Monitoring and logging evidence (screenshots/reports, alert tickets, log retention settings)
• Access review evidence for privileged cloud roles
• Periodic compliance review results and remediation tracking
• Offboarding checklists and data deletion/return confirmations

Practical evidence tip: Store “point-in-time” exports (PDF or immutable snapshots) for key settings. Cloud consoles change; auditors want what was true at the time of operation.

Common exam/audit questions and hangups

Where auditors push:

• “Show me your cloud inventory and how you know it is complete.”
• “What security requirements do you impose on cloud services, and where are they documented?”
• “Who owns shared responsibility tasks like logging configuration, key management, and identity?”
• “How do you prevent or detect misconfiguration and public exposure?”
• “Show recurring evidence, not one-time project artifacts.”

Hangups that cause findings:

• Cloud standard exists but is optional (“guidelines” with no enforcement).
• Inventory is a spreadsheet last updated long ago.
• Third-party due diligence exists for SaaS but not for PaaS/IaaS accounts created by engineering.
• No evidence of periodic reviews or drift monitoring.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails 5.23	Fix that works
“Our cloud provider is certified, so we’re covered.”	Provider assurance does not equal your configuration compliance.	Pair provider due diligence with your baseline configuration checks and access controls.
Inventory built from procurement only	Misses free trials, team credit cards, and dev accounts.	Reconcile AP + SSO app catalog + cloud org/account list.
No shared responsibility documentation	Teams assume “someone else” handles logs, keys, backups.	Publish a RACI tied to baseline controls; require sign-off at onboarding.
Monitoring exists but no retained evidence	You cannot prove ongoing operation.	Automate evidence capture through recurring exports and tickets.
Offboarding is ignored	Data and access persist after termination.	Require offboarding checklist completion and archive evidence.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied sources. Operationally, 5.23 failures usually surface as: misconfigured public access, excessive privileges, incomplete logging, unclear data residency, and gaps in incident response coordination with a cloud provider. Those issues turn into reportable incidents, customer contract breaches, or audit findings, even without regulator action.

Practical 30/60/90-day execution plan

Your goal is to reach “audit-ready enough” quickly, then mature.

First 30 days (stabilize and make scope visible)

• Assign control owner and publish a cloud governance RACI.
• Stand up a cloud services register and start population from AP + SSO + cloud org accounts.
• Draft a minimum cloud security standard (baseline controls only).
• Define intake workflow for new cloud services and new cloud accounts.

Days 31–60 (embed requirements and start generating evidence)

• Convert the cloud security standard into onboarding checklists and gating approvals.
• Update third-party due diligence templates and contract addenda language for cloud services.
• Implement core guardrails (identity, admin access constraints, logging defaults).
• Start recurring evidence capture: privileged access review records and monitoring alerts/tickets.

Days 61–90 (prove continuous operation and close gaps)

• Perform a cloud inventory completeness review and resolve unknown owners/services.
• Run a configuration compliance review against the baseline; track remediation to closure.
• Test offboarding with at least one cloud service (or run a tabletop if none are terminating soon).
• Prepare an audit packet: “5.23 narrative + evidence index + last review results.”

Where Daydream fits naturally: once you have the control defined, Daydream helps keep 5.23 “alive” by mapping the requirement to a documented control operation and recurring evidence capture, so you can show continuous operation without rebuilding the same audit packet each cycle ¹.

Frequently Asked Questions

Does Annex A 5.23 apply if we only use SaaS (no AWS/Azure/GCP hosting)?

Yes. SaaS is still a cloud service and introduces third-party and data handling risk. Your inventory, security requirements, due diligence, and recurring assurance should cover SaaS apps that process or store company or customer data ¹.

What’s the minimum evidence an auditor will accept for 5.23?

Expect to show a cloud services inventory, a documented cloud security baseline, due diligence/contract artifacts for key providers, and records that you review access and configuration over time. One-time project screenshots are rarely enough without ongoing review evidence.

How do we handle “shared responsibility” in a way auditors recognize?

Put it in writing with ownership by control area (identity, logging, keys, backups, incident response). Then tie those owners to onboarding approvals and recurring reviews so responsibility is operational, not theoretical.

We have multiple cloud accounts and business units. Do we need one standard or many?

Start with one enterprise baseline and allow risk-based exceptions through a documented exception process. Auditors usually accept exceptions when they are time-bound, approved by the right owner, and tracked to remediation.

Do we need to assess every single cloud feature and service?

No. Focus on the cloud services and configurations that process sensitive data or support critical operations. Use your inventory and data classification to prioritize where you enforce stricter requirements and where you can accept lighter controls.

How do we keep evidence fresh without drowning in screenshots?

Automate where you can (exports, reports, tickets) and set a recurring review routine that generates dated artifacts. A small number of high-quality, repeatable artifacts beats a large pile of ad hoc screenshots.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview