The key issue in ISO 27001:2022 Control 5.23, "Information Security for Use of Cloud Services," is the fragmentation of responsibility between the cloud customer and the cloud service provider (CSP). Organizations frequently mistake the "Shared Responsibility Model" for an excuse to delegate risk entirely, failing to maintain oversight, monitoring, and granular control over the data they house within third-party cloud environments.
Understanding Control 5.23 within the ISO 27001:2022 Framework
ISO 27001:2022 represents a significant evolution in international information security standards, particularly with the transition of its Annex A controls into thematic groupings. Control 5.23 falls under the "Organizational Controls" category. Its primary purpose is to ensure that when an organization utilizes cloud services—whether Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (IaaS)—the security requirements for those services are defined, addressed, and continuously monitored.
Unlike legacy on-premises security, where the organization owned the entire stack, cloud services introduce a dependency on external providers. Control 5.23 mandates that organizations do not treat their cloud subscriptions as "set and forget" entities. Instead, it requires a formal process for defining the security needs for the use of cloud services, ensuring that the cloud environment aligns with the organization’s overall Information Security Management System (ISMS).
The Core Problem: The Illusion of "Outsourced Security"
The most significant risk identified by auditors and security professionals regarding Control 5.23 is the "delegation fallacy." Organizations often assume that because a CSP provides a secure, compliant infrastructure (e.g., meeting SOC 2 or ISO 27001 certification), the data stored within that infrastructure is inherently secure. This is a dangerous misconception.
In a cloud environment, the provider is responsible for the security of the cloud (the physical data centers, the hypervisor, and the network infrastructure), but the customer is almost always responsible for security in the cloud. This includes, but is not limited to:
- Identity and Access Management (IAM): Configuring roles, permissions, and multi-factor authentication (MFA).
- Data Classification and Encryption: Ensuring that sensitive data is appropriately labeled and encrypted both at rest and in transit.
- Configuration Management: Ensuring that storage buckets, virtual machines, and databases are not left exposed to the public internet.
The key issue is that organizations fail to map their internal policy requirements to the technical controls available within the CSP's interface. When these configurations are misaligned, the organization remains legally and operationally liable for the resulting security breach, regardless of the CSP's underlying compliance.
Defining Security Requirements for Cloud Services
To comply with Control 5.23, an organization must move beyond generic security policies and establish specific, enforceable requirements for cloud service usage. This process begins with a formal risk assessment of the intended cloud usage.
- Requirement Specification: Before migrating to or expanding a cloud service, the organization must define exactly what data will be hosted, the sensitivity of that data, and the regulatory requirements that apply to it (e.g., GDPR, HIPAA, or local data residency laws).
- Provider Assessment: The organization must review the CSP’s security documentation. This is not just a "check-the-box" exercise of asking for their ISO 27001 certificate. It requires a detailed review of their terms of service, data processing agreements (DPAs), and incident response procedures.
- Contractual Alignment: The contract with the CSP must explicitly state the roles and responsibilities. If the CSP is meant to manage specific security patches or logging, this must be explicitly documented to avoid the "responsibility gap."
The Burden of Continuous Monitoring
Even if an organization defines perfect requirements and secures a contract that clearly delineates responsibility, the "set and forget" mentality remains a hurdle. Cloud environments are dynamic. An administrator might change a storage bucket policy from "private" to "public" in seconds to facilitate a project, inadvertently exposing sensitive data.
Control 5.23 requires the organization to maintain visibility. This means implementing Cloud Security Posture Management (CSPM) tools or equivalent manual processes to monitor the configuration of cloud services continuously. Without automated monitoring, the organization is effectively operating in the dark. In 2026, the complexity of multi-cloud environments—where an organization uses services from AWS, Azure, and Google Cloud simultaneously—further exacerbates the difficulty of maintaining a unified security posture.
Comparative Analysis: Responsibilities in the Cloud Stack
The division of labor varies significantly depending on the service model. Understanding these boundaries is essential for addressing the audit requirements of Control 5.23.
| Service Model | Responsibility: CSP | Responsibility: Customer |
|---|---|---|
| IaaS (e.g., AWS EC2) | Physical hardware, virtualization layer. | OS patching, application security, IAM, data encryption, network firewall rules. |
| PaaS (e.g., Azure SQL) | Hardware, OS, runtime environment. | Application code, data management, access controls, internal firewall rules. |
| SaaS (e.g., M365) | Entire stack including application software. | User access, data classification, sharing settings, data backup/retention. |
As shown in the table, the customer's role is least involved in SaaS but still critical regarding data access and sharing. The most common point of failure for SaaS is not the provider's infrastructure but the customer's failure to enforce Multi-Factor Authentication (MFA) or properly configure external sharing permissions.
Common Pitfalls in Implementing Control 5.23
1. Lack of Asset Inventory
Organizations cannot secure what they cannot see. A "shadow IT" phenomenon frequently occurs where departments procure cloud services without the knowledge of the IT or security team. If a cloud service is not documented in the inventory, it cannot be subjected to the security controls mandated by ISO 27001.
2. Neglecting Off-boarding
When a business relationship with a CSP ends, or an internal project is decommissioned, data must be securely deleted. Failure to ensure the secure erasure of data in the cloud is a major compliance issue under Control 5.23 and related privacy regulations.
3. Over-reliance on Default Settings
Most CSPs provide "default" settings that prioritize usability over security. For example, logging might be turned off to save on storage costs, or API access might be overly permissive. Adopting defaults without a security review is a direct violation of the intent behind Control 5.23.
Steps to Achieve Compliance and Operational Security
To effectively manage Control 5.23, organizations should follow a structured approach that integrates cloud security into their existing ISMS processes.
- Develop a Cloud Usage Policy: Establish a clear policy that dictates how employees may request, procure, and use cloud services. This policy should mandate a security review for any new service.
- Establish a Cloud Asset Register: Maintain a real-time list of all cloud services in use, the business owner responsible for them, and the classification of data they process.
- Implement Technical Guardrails: Use Infrastructure-as-Code (IaC) to enforce security settings. By codifying infrastructure, you ensure that new cloud resources are deployed with security configurations by default, rather than relying on human configuration.
- Conduct Periodic Audits: Do not wait for the annual ISO 27001 audit to test your cloud security. Schedule quarterly reviews of IAM policies, public-facing assets, and logging integrity.
- Test Incident Response: Ensure your incident response plan specifically covers cloud-based scenarios. If a data breach occurs at the CSP level, how will you be notified? What is your role in containment? These procedures must be tested via tabletop exercises.
The Role of Automation in 2026
By 2026, the sheer velocity of cloud deployments makes manual compliance unsustainable. Organizations that excel at Control 5.23 are leveraging automated tools to bridge the gap. CSPM tools can automatically scan for misconfigurations that violate organizational policies—such as a storage bucket lacking encryption or an administrative account lacking MFA.
When a policy violation is detected, these tools can either alert the security team or, in advanced deployments, automatically remediate the issue by resetting the configuration to a secure baseline. This automation is the gold standard for fulfilling the "continuous monitoring" requirement inherent in the ISO 27001:2022 framework.
Addressing Cloud Data Residency
A sub-issue within Control 5.23 is data residency. Many organizations are required by law or contract to keep data within specific geographic borders. If a CSP moves data between global data centers to optimize performance, the organization may unintentionally fall out of compliance. Ensure that the CSP’s regional settings are locked to the required geography and that this is verified periodically.
Final Recommendation for Implementation
The most immediate action for any organization struggling with Control 5.23 is to perform a "Responsibility Gap Analysis." Take your current cloud architecture, define each component, and explicitly mark whether the responsibility for security falls on the CSP or your organization. Where your organization is responsible, audit the current configuration against your internal security policy. If you find gaps, prioritize them based on the risk of data exposure. By documenting this process, you satisfy the auditor's requirement for evidence of control implementation and drastically improve your actual security posture.
