Cloud Security Reference Patterns: [Organisation or platform name]

Catalogue of approved cloud security patterns for identity, network, data protection, workload protection, logging and detection, and posture management, with the implementation on AWS, Microsoft Azure and Google Cloud and a control mapping. It draws on the provider security reference guidance: the AWS Security Reference Architecture (AWS SRA, AWS Prescriptive Guidance, updated June 2026), the Microsoft cloud security benchmark (MCSB v2, in preview, overview dated 15 January 2026, superseding v1) and the Google Cloud enterprise foundations blueprint (formerly the security foundations blueprint). Controls map to the CSA Cloud Controls Matrix v4.1 (January 2026), NIST SP 800-53 Rev. 5 and CIS Benchmarks by topic. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Scope and how to use the patterns
2. Reference sources and versions
3. Shared responsibility
4. Security organisation structure
5. Identity and access patterns
6. Network security patterns
7. Data protection and key management patterns
8. Workload protection patterns
9. Logging, detection and response patterns
10. Posture management and policy as code
11. Provider equivalence table
12. Control mapping
13. Exceptions and pattern lifecycle
14. Adoption register and traceability
15. Glossary and references

1. Scope and how to use the patterns

1.1 Scope

1.2 Pattern structure

Every pattern in sections 5 to 10 uses the same fields so that workload teams can compare them and auditors can trace them.

1.3 Adoption rule

Example: Production workloads adopt every pattern with status Approved unless an exception is recorded in section 13. Non-production workloads adopt the identity, logging and data protection patterns and may defer the others. Pattern adoption is checked at the architecture review (architecture/architecture-review-request) and continuously by posture management (section 10).

2. Reference sources and versions

CSA has published a transition plan for STAR submissions: v4.0 and v4.1 are both accepted from March 2026, only v4.1 from December 2027, and the v4.0.x CCM and CAIQ are withdrawn in January 2028. Check the current timeline at cloudsecurityalliance.org.

3. Shared responsibility

Rows marked "Customer" are split between the platform team (shared services and guardrails) and the workload team (resource configuration). Record the split for each pattern in the RACI below.

4. Security organisation structure

The AWS SRA organises a multi-account environment as: the Org Management account; a Security OU with a Security Tooling account and a Log Archive account; an Infrastructure OU with a Network account and a Shared Services account; and a Workloads OU with application accounts. The current SRA (revised 30 June 2026) also recommends a dedicated Monitoring account in the Security OU as the home of organisation-wide CloudWatch telemetry, with the Log Archive account kept as the immutable storage sink. Azure and Google Cloud achieve the same separation with management groups and subscriptions, and with folders and projects.

5. Identity and access patterns

Verification for every identity pattern: posture checks for local users, keys older than [90 days], roles assigned to individuals, and use of break-glass identities. Detailed design belongs in the IAM solution design (security/iam-solution-design).

6. Network security patterns

Topology, address plan and hybrid connectivity are designed in the Network architecture design (architecture/network-architecture-design).

7. Data protection and key management patterns

Certificate hierarchy and lifecycle are designed in the PKI and certificate architecture (security/pki-certificate-architecture). Residency constraints are assessed in the Data residency and sovereignty assessment (compliance/data-residency-sovereignty-assessment).

8. Workload protection patterns

Supply chain controls for the pipeline itself are covered in Supply chain security (security/supply-chain-security).

9. Logging, detection and response patterns

Incident handling follows the Incident response plan (compliance/incident-response-plan); alert definitions live in the Observability specification (ops/observability-spec).

10. Posture management and policy as code

Remediation service levels (Example): critical findings fixed within [2 days], high within [7 days], medium within [30 days]; anything longer needs an exception in section 13.

11. Provider equivalence table

12. Control mapping

CSA CCM v4.1 domains: A&A Audit and Assurance; AIS Application and Interface Security; BCR Business Continuity Management and Operational Resilience; CCC Change Control and Configuration Management; CEK Cryptography, Encryption and Key Management; DCS Datacenter Security; DSP Data Security and Privacy; GRC Governance, Risk Management and Compliance; HRS Human Resources Security; IAM Identity and Access Management; IPY Interoperability and Portability; IVS Infrastructure and Virtualization Security; LOG Logging and Monitoring; SEF Security Incident Management, E-Discovery and Cloud Forensics; STA Supply Chain Management, Transparency and Accountability; TVM Threat and Vulnerability Management; UEM Universal Endpoint Management.

MCSB v2 (preview) domains: NS Network Security, IM Identity Management, PA Privileged Access, DP Data Protection, AM Asset Management, LT Logging and Threat Detection, IR Incident Response, PV Posture and Vulnerability Management, ES Endpoint Security, BR Backup and Recovery, DS DevOps Security, AI Artificial Intelligence Security. MCSB v1 also has GS Governance and Strategy.

13. Exceptions and pattern lifecycle

13.1 Pattern lifecycle

13.2 Exceptions

Expired exceptions are reported to the risk owner and the security architecture authority each month. Record accepted risk in the Risk register (compliance/risk-register).

14. Adoption register and traceability

Traceability runs from requirement to pattern, guardrail, control and evidence:

15. Glossary and references

15.1 Glossary

15.2 References

Standard and licence note

Structure aligned with the AWS Security Reference Architecture, the Microsoft cloud security benchmark, the Google Cloud enterprise foundations blueprint and the CSA Cloud Controls Matrix v4.1, with control identifiers from NIST SP 800-53 Rev. 5. Only account, domain, product and control names and identifiers are used, for mapping; no recommendation, control or benchmark text is reproduced, and CIS Benchmarks are referenced by name and topic only. The pattern text is original and written for this collection. AWS, Microsoft Azure, Google Cloud and their products are trademarks of their owners; this template is not affiliated with or endorsed by them, the Cloud Security Alliance or the Center for Internet Security. Check the current official documentation and framework versions before use. Template licence: MIT.