Most cloud workloads reach production after a review that checks a few network diagrams and nothing else, so identity sprawl, open data paths and missing logs are found later by an attacker or an auditor. This template gives you a repeatable architecture review procedure for a single cloud workload or landing zone. Its review areas follow the seven best practice areas of the AWS Well-Architected Framework security pillar (security foundations, identity and access management, detection, infrastructure protection, data protection, incident response and application security), with cross-references to the Azure Well-Architected security checklist (SE:01 to SE:12), the Google Cloud Well-Architected security focus areas and the NCSC Cloud Security Principles, so it works on any provider. It is written for security architects, cloud platform teams and the risk owners who sign off new workloads.
How to use this template
- Replace text in square brackets, such as [Organisation], [Security Architecture team] and [risk owner], with your own terms.
- "Must" indicates a mandatory requirement; "should" indicates a recommended practice where exceptions may be justified and recorded.
- Complete one copy per workload. Sections 3 to 9 are the review areas: answer every question with Yes, Partial, No or Not applicable, and attach evidence (a console export, a policy file, a query result), not an assertion.
- Rate each gap using section 10 and record the outcome in section 11. A review is not complete until the decision is signed.
- Re-use the evidence: many answers map to controls in NIST SP 800-53 Rev 5, ISO/IEC 27001:2022 Annex A and CIS Controls v8.1, so store them where your audit team can find them.
1. Scope and triggers
This procedure applies to cloud workloads run by or for [Organisation] on [AWS / Microsoft Azure / Google Cloud / other], including infrastructure, platform and serverless services, and the accounts, subscriptions or projects that host them.
A review must be performed when:
- A new workload is proposed for production, or an existing workload moves to a new provider, region or account structure.
- A workload begins processing data classified as [Confidential] or above, personal data, payment card data or [regulated data type].
- A significant change is made: new external exposure (public endpoint, API, partner integration), new identity federation, new cross-account or cross-tenant trust, or a change of encryption key ownership.
- An incident or penetration test finds a design-level weakness.
- [12] months have passed since the last review for workloads rated High or Critical, [24] months for others.
Record: workload name, business owner, technical owner, provider and region, account, subscription or project IDs, data classification, and the review reference [REV-YYYY-NNN].
2. Roles and contacts
| Role | Responsibility in the review | Name and contact |
|---|---|---|
| [Risk owner] (business) | Accepts residual risk and signs the decision in section 11 | [Name] |
| Technical owner | Provides the architecture pack and evidence, owns remediation | [Name] |
| Reviewing security architect | Runs the review, rates findings, recommends the decision | [Name] |
| Cloud platform team | Confirms landing zone guardrails and inherited controls | [Team] |
| IAM and NHI owner | Reviews human and machine identities, roles and secrets | [Team] |
| Security operations | Confirms logs arrive, detections exist and the incident runbook works | [Team] |
| Data protection or privacy officer | Required where personal data is processed | [Name] |
The reviewing architect must not be a member of the team that designed the workload.
Required inputs: architecture and data flow diagrams with trust boundaries; list of accounts, subscriptions or projects; infrastructure as code repository link; identity inventory (human roles, service accounts, workload identities, API keys); data inventory with classification; threat model (see the Threat Modelling Guide); results of the provider's native posture tool for the in-scope accounts.
3. Security foundations and governance
| # | Question | Evidence |
|---|---|---|
| 3.1 | Is the workload in a dedicated account, subscription or project within the organisation's landing zone, separated from other environments? | Account or project hierarchy export |
| 3.2 | Do organisation guardrails apply (AWS service control policies and resource control policies, Azure Policy assignments, Google Cloud organisation policy constraints)? | Effective policy list |
| 3.3 | Is the shared responsibility split for each service in use documented, including any provider operator access controls relied on? | Responsibility matrix |
| 3.4 | Is all infrastructure deployed from version-controlled code with peer review, and is console change in production restricted? | Repository and pipeline links |
| 3.5 | Are regions restricted to those approved for the data's residency requirements? | Region policy |
See the Shared Responsibility Models Guide and the Cloud Provider Support and Operator Access Controls Guide.
4. Identity and access management
| # | Question | Evidence |
|---|---|---|
| 4.1 | Do people access the cloud only through the central identity provider with phishing-resistant MFA, with no local IAM users for humans? | Identity provider federation config; IAM user list |
| 4.2 | Do workloads use short-lived credentials (instance or execution roles, managed identities, workload identity federation) instead of long-lived access keys or service account keys? | Key inventory with ages |
| 4.3 | Is every non-human identity owned, documented and scoped to the actions it needs? Has unused access been removed? | Unused access findings; role policy export |
| 4.4 | Are privileged roles granted just in time with approval, and are break-glass accounts controlled and monitored? | PIM or JIT configuration |
| 4.5 | Are cross-account, cross-tenant and external trusts listed and justified, with conditions such as external ID or organisation ID? | External access analyser output |
| 4.6 | Are secrets held in a managed secrets store, never in code, images or environment variables in plain text? | Secret scanning result |
See the Cloud IAM Review Checklist and the IAM Access Analyzer Guide.
5. Detection and logging
| # | Question | Evidence |
|---|---|---|
| 5.1 | Are control plane audit logs (CloudTrail, Azure Activity Log, Google Cloud Audit Logs) enabled organisation-wide and sent to a separate, access-restricted log account or project? | Trail or sink configuration |
| 5.2 | Are data access logs enabled for stores holding classified data? | Logging settings per store |
| 5.3 | Is the provider's threat detection service enabled for the workload's accounts, with findings routed to the SOC? | Service status, sample finding |
| 5.4 | Do detections exist for the workload's top threats from the threat model, such as new access keys, policy changes, public exposure and logging being disabled? | Detection rule list |
| 5.5 | Is log retention at least [12 months], and are logs protected against deletion? | Retention and immutability settings |
See the Cloud Logging and Audit Trail Guide.
6. Infrastructure protection
| # | Question | Evidence |
|---|---|---|
| 6.1 | Are networks segmented into tiers with deny-by-default rules, and is administrative access (SSH, RDP) closed to the internet and brokered through a managed access service? | Security group or firewall rule export |
| 6.2 | Do internet-facing endpoints sit behind a web application firewall and DDoS protection, and is every public endpoint listed? | Endpoint inventory |
| 6.3 | Do private services use private connectivity (private endpoints, PrivateLink, Private Service Connect) rather than public endpoints? | Endpoint configuration |
| 6.4 | Are compute images hardened to a baseline, patched within [policy SLA] and scanned for vulnerabilities, including containers and functions? | Image pipeline, scan report |
| 6.5 | Is the instance metadata service protected (for example IMDSv2 required on AWS)? | Configuration export |
7. Data protection
| # | Question | Evidence |
|---|---|---|
| 7.1 | Is every data store classified and tagged? | Data inventory |
| 7.2 | Is data encrypted at rest, and is key ownership (provider-managed, customer-managed, external) chosen and recorded for the classification? | Key policy, key decision record |
| 7.3 | Is TLS 1.2 or higher enforced in transit, including between internal services? | Policy or listener configuration |
| 7.4 | Is public access blocked at account or organisation level for object storage, and are any exceptions documented? | Public access settings |
| 7.5 | Is a data perimeter in place so data can only be reached by trusted identities from expected networks? | Perimeter policies |
| 7.6 | Are backups isolated in a separate account or vault with immutability and tested restores? | Backup plan, last restore test |
See the Cloud Data Perimeter Guide and the Cloud Native Backup and Ransomware Resilience Guide.
8. Incident response and recovery
| # | Question | Evidence |
|---|---|---|
| 8.1 | Does a runbook exist for this workload covering credential compromise, data exposure and ransomware, with named contacts? | Runbook link |
| 8.2 | Does security operations hold pre-provisioned, tested access to investigate the accounts (read-only forensic role, log access)? | Role definition, last test date |
| 8.3 | Can compromised credentials be revoked and resources isolated quickly, and has this been exercised? | Exercise record |
| 8.4 | Are recovery time and recovery point objectives defined and met in a restore test? | Test report |
See the Cloud Incident Response Guide.
9. Application security and supply chain
| # | Question | Evidence |
|---|---|---|
| 9.1 | Does the pipeline run static analysis, dependency scanning and infrastructure as code scanning, with blocking thresholds? | Pipeline configuration |
| 9.2 | Does the pipeline authenticate to the cloud through short-lived federation (OIDC) rather than stored keys, with deploy roles scoped per environment? | Trust policy |
| 9.3 | Are third-party components, images and functions layers from trusted, pinned sources? | Software bill of materials |
| 9.4 | Has the application been tested (penetration test or equivalent) within [period] for external exposure? | Test report |
10. Findings and risk rating
Record each gap as a finding with: ID, review area, description, affected resources, likelihood, impact, rating, recommended fix, owner and due date.
| Rating | Example | Remediation deadline | Effect on decision |
|---|---|---|---|
| Critical | Classified data publicly reachable; long-lived administrator key in code | Before go-live | Blocks approval |
| High | No audit logs for the account; workload role with wildcard permissions | Before go-live, or [30] days with risk owner acceptance | Conditional approval only |
| Medium | Missing detection for a modelled threat; restore not tested | [90] days | Approval with tracked action |
| Low | Tagging gaps; documentation incomplete | Next review | No effect |
11. Decision and sign-off
The reviewing architect recommends one of: Approved, Approved with conditions (list findings and dates), or Not approved. The [risk owner] signs the decision and any risk acceptance. Risk acceptances must have an expiry date of no more than [12 months]. Record: decision, date, conditions, signatures, next review date.
12. Review of this template
This template is owned by [Security Architecture team] and is reviewed at least annually, and after any major revision of the provider frameworks it maps to.
Implementation guidance
Review area cross-reference. The table maps each section to the provider frameworks so teams on any cloud can trace questions back to their own guidance.
| Template section | AWS Well-Architected security pillar area | Azure Well-Architected checklist | Google Cloud focus area | NCSC Cloud Security Principle |
|---|---|---|---|---|
| 3. Foundations | Security foundations | SE:01 Establish a security baseline; SE:04 Create intentional segmentation and perimeters | Cloud governance, risk, and compliance | 4 Governance framework; 3 Separation between customers |
| 4. IAM | Identity and access management | SE:05 Implement strict, conditional, and auditable IAM; SE:09 Protect application secrets | Identity and access management | 9 Secure user management; 10 Identity and authentication |
| 5. Detection | Detection | SE:10 Implement a holistic monitoring strategy | Logging, auditing, and monitoring | 13 Audit information and alerting for customers |
| 6. Infrastructure | Infrastructure protection | SE:06 Isolate, filter, and control network traffic; SE:08 Harden all workload components | Infrastructure security | 11 External interface protection; 12 Secure service administration |
| 7. Data | Data protection | SE:03 Classify and apply sensitivity labels; SE:07 Encrypt data | Data security | 1 Data in transit protection; 2 Asset protection and resilience |
| 8. Incident response | Incident response | SE:12 Define and test incident response procedures | Security operations (SecOps) | 5 Operational security |
| 9. Application | Application security | SE:02 Align secure development lifecycle; SE:11 Establish a comprehensive testing regimen | Application security | 7 Secure development; 8 Supply chain security |
Rolling it out.
- Pilot on two workloads: one new and one existing, with a reviewing architect and the technical owner in the same session. Time how long evidence collection takes.
- Automate evidence: most answers in sections 4 to 7 can come from the provider's posture tooling and configuration exports. Pre-populate the template from those outputs so the review session focuses on design questions, not data gathering.
- Tier the depth: a small organisation can run a single combined review for each workload; a large organisation should run a lightweight review for Low-classification workloads and the full template for anything handling classified data or exposed externally.
- Connect to change: add the triggers in section 1 to your change process so a new public endpoint or cross-account trust raises a review request automatically.
- Measure: track the share of production workloads with a current review, the number of open Critical and High findings past their deadline, median days to close High findings, and the count of risk acceptances past expiry.
Common mistakes. Accepting diagrams as evidence instead of configuration exports; reviewing human access but not service accounts and keys; signing off with Critical findings "to be fixed later" and no date; and running the review once at go-live but never on change.
Supporting guides. Review method: Security Architecture Review Guide. AWS specifics: AWS Well-Architected Security Pillar Guide. Multi-account design: AWS Multi-Account Security Reference Architecture Guide.
Sources. AWS: Well-Architected Framework security design principles · AWS: Well-Architected Framework security pillar · Microsoft Learn: Design review checklist for Security · Google Cloud: Well-Architected Framework security pillar · NCSC: The cloud security principles
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Security Architecture Review Guide · AWS Well-Architected Security Pillar Guide · Cloud IAM Review Checklist · Shared Responsibility Models Guide