A.5.23 and A.5.24 — Cloud Services Security

Understanding Controls A.5.23 and A.5.24: The Cloud Security Lifecycle

After fifteen years of auditing organizations across every sector, I've watched cloud adoption evolve from experimental to essential—and I've seen the same security mistakes repeated countless times. Controls A.5.23 and A.5.24 in ISO 27001:2022 exist precisely because the standard's authors recognized that cloud security couldn't remain an afterthought. These paired controls establish a comprehensive framework: A.5.24 governs the planning and preparation before you commit to any cloud service, while A.5.23 addresses the ongoing acquisition, use, management, and eventual exit from cloud relationships.

What makes these controls particularly significant is their lifecycle approach. They acknowledge that cloud security isn't a one-time decision but an ongoing governance challenge that begins before procurement talks start and continues through service termination. This represents a fundamental shift from treating cloud services as simple vendor relationships to recognizing them as complex shared responsibility partnerships.

The Foundation: A.5.24 Planning and Preparation

Control A.5.24 requires that cloud service acquisition be preceded by proper planning that considers information security requirements. In my experience auditing organizations, this is where most failures originate—not in the technical implementation, but in the complete absence of security-informed planning.

A recent audit of a financial services company illustrates this perfectly. They had migrated their customer portal to a major SaaS platform without conducting any security assessment beyond confirming the vendor had "SOC 2 certification." When I asked to see the security requirements that informed their selection process, the IT director produced a feature comparison spreadsheet. No risk assessment, no data classification analysis, no regulatory impact evaluation—just pricing and functionality.

Effective implementation of A.5.24 requires establishing security requirements before your procurement team engages with vendors. This includes:

• Data classification analysis — What data will the service process? What's its sensitivity level under your classification scheme?
• Regulatory mapping — Which compliance requirements (GDPR, HIPAA, PCI DSS) will apply to this processing?
• Risk appetite definition — What level of residual risk is acceptable for this service category?
• Technical baseline requirements — Encryption standards, access controls, audit capabilities, incident response capabilities
• Shared responsibility boundaries — Clear delineation of which controls you expect the provider to manage versus what remains your responsibility

This planning phase also requires considering the supplier relationship management implications defined in Control A.5.21. Cloud providers aren't traditional suppliers—they're technology partners with complex sub-processor relationships that can fundamentally alter your risk landscape.

Cross-Standard Integration

A.5.24 planning must also consider other ISO 27000 series standards. For public cloud services processing personal data, ISO/IEC 27018 provides specific guidance on privacy protection. Organizations subject to GDPR should ensure their planning addresses the enhanced data protection requirements outlined in 27018. Similarly, ISO/IEC 27017 offers cloud-specific control implementations that should inform your security requirements baseline.

The Operational Reality: A.5.23 Lifecycle Management

Control A.5.23 addresses the ongoing governance of cloud services throughout their lifecycle. This isn't about creating bureaucracy—it's about maintaining visibility and control as your cloud relationships evolve.

The control specifically requires documented processes for acquisition, use, management, and exit from cloud services, established "in accordance with the organization's information security requirements." This language is intentionally broad because cloud governance must be tailored to your specific risk environment.

Acquisition Phase: Beyond Vendor Questionnaires

During acquisition, A.5.23 requires more than checking compliance boxes. You need documented evaluation criteria that map directly to the security requirements established under A.5.24. This includes:

• Technical assessment — Review of SOC 2 Type II reports, penetration testing results, and architectural documentation
• Sub-processor due diligence — Understanding the provider's supply chain and how they manage third-party relationships
• Contractual security terms — Service level agreements for security controls, incident notification requirements, audit rights, and breach liability
• Shared responsibility validation — Confirming that both parties understand their respective control obligations

The acquisition process should also address data residency requirements. ISO/IEC 27002:2022 specifically mentions processing and storing information "in approved locations (e.g. particular country or region)." For organizations subject to data localization laws, this becomes a critical contractual requirement.

Use and Management: Ongoing Governance

Once operational, A.5.23 requires ongoing management processes. This means continuous monitoring of the shared responsibility model and regular validation that the provider continues meeting your security requirements.

Practical implementation includes:

• Regular control attestation review — Annual review of SOC 2 reports, noting any exceptions or changes in scope
• Change management coordination — Processes for the provider to notify you of significant infrastructure or service changes
• Incident response integration — Clear procedures for handling security incidents that span both organizations
• Performance monitoring — Regular assessment of service delivery against contractual security commitments

The management phase also intersects with Control A.5.25 (assessment and decision on information security events). Cloud incidents require coordinated response between customer and provider, making incident management planning critical to your overall incident response capability.

Exit Strategy: The Often-Neglected Phase

Control A.5.23 explicitly requires exit strategies—perhaps the most commonly overlooked aspect of cloud governance. During audits, I routinely find organizations with no documented plan for service termination, data retrieval, or knowledge transfer.

Effective exit planning addresses:

• Data portability — How will you extract your data in usable formats? What about configuration settings and customizations?
• Secure deletion — Contractual guarantees for secure deletion of your data from provider systems
• Transition timelines — Minimum notice periods and support duration during migration
• Knowledge transfer — Documentation of configurations, integrations, and operational procedures

ISO/IEC 19941 provides detailed guidance on cloud portability that should inform your exit planning requirements.

Multi-Cloud Complexity

A.5.23 specifically addresses organizations using multiple cloud services from different providers—an increasingly common scenario. This creates additional complexity in managing controls, interfaces, and service changes across providers.

Multi-cloud governance requires:

• Consistent security baselines — Standardized security requirements across all cloud relationships
• Integration security — Assessment of risks created by data flows between different cloud platforms
• Coordinated change management — Understanding how changes in one service might affect security in others
• Consolidated monitoring — Unified view of security posture across all cloud relationships

What the Auditor Looks For

During ISO 27001 audits, I examine specific evidence to validate conformity with A.5.23 and A.5.24:

For A.5.24 (Planning and Preparation):

• Documented cloud security requirements that informed service selection
• Risk assessments completed before acquisition decisions
• Evidence that security requirements were communicated to procurement teams
• Regulatory impact analysis for planned cloud services
• Shared responsibility model definitions developed during planning

For A.5.23 (Lifecycle Management):

• Documented cloud governance procedures covering acquisition through exit
• Service level agreements with specific security obligations
• Evidence of ongoing provider assessment and monitoring
• Incident response procedures that include cloud provider coordination
• Exit strategies with data retrieval and secure deletion provisions
• Change management processes for cloud service modifications

I also look for integration with your broader risk management processes. Cloud services can't be managed in isolation—they must be integrated into your overall information security governance framework.

Common Implementation Mistakes

Based on hundreds of audits, these are the most frequent failures I encounter:

Audit Tip: The biggest mistake organizations make is treating cloud security as a compliance checkbox rather than an ongoing governance responsibility. Security isn't something you verify once and forget—it requires continuous management throughout the service relationship.

• Retroactive security assessment — Conducting security reviews after service deployment rather than during planning
• Inadequate contract terms — Relying on standard terms of service without negotiating security-specific provisions
• Unclear responsibility boundaries — Assuming the provider handles all security aspects without explicit validation
• Missing exit strategies — No documented plan for service termination or data retrieval
• Isolated governance — Managing cloud security separately from broader supplier and risk management processes

Practical Implementation Roadmap

For organizations implementing these controls, start with A.5.24 planning requirements:

1. Develop cloud security standards — Create baseline security requirements for different service categories
2. Integrate with procurement — Ensure procurement teams understand security requirements and evaluation criteria
3. Establish shared responsibility templates — Define standard control allocation models for different cloud service types
4. Create governance procedures — Document processes for ongoing management, monitoring, and exit planning
5. Train relevant staff — Ensure teams understand both technical requirements and governance obligations

Remember, A.5.23 and A.5.24 aren't about avoiding cloud services—they're about using them securely and strategically. When implemented properly, these controls enable confident cloud adoption while maintaining the security governance your organization requires.

Ready to strengthen your cloud security governance? Join our community of ISO 27001 practitioners at the IX ISO 27001 Info Hub for ongoing guidance and peer discussion, or reach out for specialized consultation on cloud security implementation.

Need personalized guidance? Reach our team at ix@isegrim-x.com.

Related Articles

• Annex A.5.1 through A.5.4 — Information Security Policies and Roles
• A.5.5 and A.5.6 — Contact with Authorities and Special Interest Groups
• A.5.7 Threat Intelligence — What Auditors Actually Expect
• A.6.1 through A.6.3 — Screening Employment Terms and Awareness
• A.7.1 through A.7.4 — Physical Perimeters Entry and Securing Facilities