# Cloud Security Posture Review: [Organisation or cloud estate name], [review period]

> Periodic review of the security posture of one or more cloud estates:
> scope and accounts, shared responsibility split, cloud security posture
> management (CSPM) findings grouped by the domains of the Cloud Security
> Alliance *Cloud Controls Matrix* (CCM) v4.1 (January 2026), identity,
> network exposure, data protection, logging coverage, guardrail drift,
> exceptions, risk rating, remediation plan and trend against the previous
> review. CCM domains are cited by name and identifier only; CIS Benchmarks
> are named as configuration baselines and not reproduced. This report
> records the state of an estate at a point in time; the approved patterns
> it checks against live in Cloud Security Reference Patterns
> (`security/cloud-security-reference-patterns`) and the landing zone design.
> Replace every `[bracketed]` value and every row marked *Example*. Worked
> examples use Corvid Commerce, a fictional SaaS company.

<!--
Guidance: How to use this template
- Use one report per review cycle (for example quarterly) and per estate or
  business unit. Keep the previous report open: section 13 compares against it.
- Work in this order: confirm scope (2), export CSPM data and the asset
  inventory (3), group findings by CCM domain (4), then write the deep-dive
  sections (5 to 9), rate risk (11) and agree the plan (12). Write the
  executive summary (1) last.
- A posture review is not a penetration test and not a design review. It
  measures configuration against an agreed baseline. Exploitation testing
  belongs in Penetration Test Report (`security/pentest-report`).
- Common pitfall: reporting raw finding counts. Leaders need risk, trend and
  decisions. Always pair counts with exposure, data sensitivity and age.
-->

## Document control

<!-- Guidance: Identify the review, its period and the people who accept residual risk. Classify the report: it lists weaknesses in production. -->

| Field | Value |
|---|---|
| Document ID | [CSPR-YYYY-QN] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@cloud-security-lead] |
| Approvers / reviewers | [@ciso], [@head-of-platform], [@cloud-account-owners] |
| Last updated | YYYY-MM-DD |
| Classification | Confidential: contains unremediated weaknesses |
| Review period | [YYYY-MM-DD to YYYY-MM-DD] |
| Data snapshot date | YYYY-MM-DD (CSPM export and inventory taken on this date) |
| Estates in scope | [*Example:* AWS organisation, Microsoft Azure tenant, Google Cloud organisation] |
| Baselines used | [Internal cloud baseline v[x]; CIS Benchmark for [provider] v[x] (licensed copy); provider security recommendations] |
| Control framework mapping | CSA CCM v4.1 (domains and control IDs only) |
| Previous review | [CSPR-YYYY-QN] |
| Next review | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Chief information security officer | [@name] | [Accepted / Changes requested] | YYYY-MM-DD |
| Head of platform or cloud engineering | [@name] | [Decision] | YYYY-MM-DD |
| Risk owner for exceptions (section 10) | [@name] | [Decision] | YYYY-MM-DD |
| Internal audit (observer) | [@name] | [Noted] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Draft from CSPM export and inventory |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Account owners validated findings; false positives removed |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Accepted by CISO; remediation plan agreed |

## Contents

<!-- Guidance: Keep this list aligned with the headings below. -->

1. [Executive summary](#1-executive-summary)
2. [Scope and review method](#2-scope-and-review-method)
3. [Estate inventory and shared responsibility](#3-estate-inventory-and-shared-responsibility)
4. [Findings by CCM domain](#4-findings-by-ccm-domain)
5. [Identity and access posture](#5-identity-and-access-posture)
6. [Network exposure](#6-network-exposure)
7. [Data protection and encryption](#7-data-protection-and-encryption)
8. [Logging and detection coverage](#8-logging-and-detection-coverage)
9. [Guardrail drift and policy as code](#9-guardrail-drift-and-policy-as-code)
10. [Exceptions and risk acceptance](#10-exceptions-and-risk-acceptance)
11. [Risk rating](#11-risk-rating)
12. [Remediation plan](#12-remediation-plan)
13. [Trend and metrics](#13-trend-and-metrics)
14. [Glossary and references](#14-glossary-and-references)

## 1. Executive summary

<!-- Guidance: One page for leaders. State the overall posture, what changed since the last review, the top risks and the decisions you need. Avoid tool jargon. Pitfall: listing every critical finding here; group them into themes. -->

**Overall posture:** [Improving / Stable / Deteriorating] compared with [previous review ID].

*Example (Corvid Commerce, Q3 2026):* Posture improved for the second
quarter in a row. The configuration pass rate rose from 92.5% to 93.6% and
open critical findings fell from 7 to 4. Excluding 120 checks added by the
CSPM vendor this quarter, the like-for-like pass rate is 93.9% (section 13).
The legacy analytics account holds one of the four open critical findings
(two internet-readable buckets with customer exports, CSPR-F-001) and a
public database endpoint pending exception EXC-021. It needs a decision this
cycle: either migrate the workload into the governed landing zone or accept
the risk for 90 days with compensating controls.
Logging coverage of the cloud control plane is complete, but data-plane
logging for object storage covers only 71% of buckets holding confidential
data.

| Headline measure | Previous | Current | Target | Status |
|---|---|---|---|---|
| Configuration pass rate (section 13) *Example* | 92.5% | 93.6% | 95.0% | Improving |
| Open critical findings *Example* | 7 | 4 | 0 | Off target |
| Open high findings *Example* | 31 | 23 | 10 or fewer | Off target |
| Critical findings past SLA *Example* | 3 | 1 | 0 | Off target |
| Accounts outside the governed landing zone *Example* | 5 | 3 | 0 | Improving |
| Control-plane audit logging coverage *Example* | 98% | 100% | 100% | On target |

**Top risks (detail in section 11):**

1. *Example:* RISK-CSPR-001: public read access on two storage buckets with customer exports in the legacy analytics account.
2. *Example:* RISK-CSPR-002: long-lived access keys for 14 machine users, 3 of them (used by a third-party ETL tool) with administrative rights.
3. *Example:* RISK-CSPR-003: incomplete data-plane logging on confidential storage limits breach investigation.

**Decisions requested:**

| ID | Decision | Options | Recommended | Decision owner |
|---|---|---|---|---|
| DEC-001 *(Example)* | Legacy analytics account | Migrate by YYYY-MM-DD, or accept risk 90 days | Migrate; interim block of public access | [@cto] |
| DEC-002 *(Example)* | Ban new static cloud keys for workloads | Policy now, or after workload identity rollout | Policy now, with 60-day exception path | [@ciso] |

## 2. Scope and review method

<!-- Guidance: Make scope testable: which organisations, accounts, regions and services. State the tools, baselines and sampling. Pitfall: silently excluding accounts that the CSPM tool cannot see; list them as a coverage gap instead. -->

### 2.1 Scope

| Item | In scope | Out of scope (reason) |
|---|---|---|
| Cloud estates | [*Example:* AWS organisation `corvid-prod-org`, Azure tenant `corvid.example`, Google Cloud organisation `corvid.example`] | [*Example:* Partner-managed marketing site (covered by supplier assessment)] |
| Environments | [Production, staging, shared services, sandbox] | [Developer personal sandboxes with no data (spot-checked only)] |
| Regions | [All enabled regions] | [None] |
| Service types | IaaS, PaaS, managed Kubernetes, serverless, managed databases, object storage | SaaS applications (covered by SaaS posture review) |
| Identity planes | Cloud IAM, workforce identity provider federation into cloud | Customer identity (see CIAM design) |

### 2.2 Method

1. Export the CSPM finding set and the cloud asset inventory on the snapshot date.
2. Reconcile the account list from the CSPM tool with the organisation or tenant hierarchy. Record every account the tool does not cover in section 3.3.
3. Map each failed check to one CCM v4.1 domain (primary) using the control ID mapping held in the CSPM tool or the internal baseline. Record unmapped checks as "Unmapped" and fix the mapping.
4. Remove confirmed false positives with a written reason; keep the count.
5. Validate the top findings with account owners in a 30-minute session per business unit.
6. Rate risk per theme using section 11 and agree actions in section 12.
7. Compare with the previous review (section 13).

### 2.3 Sources of evidence

| Source | What it provides | Owner |
|---|---|---|
| CSPM platform [name] | Configuration findings against baselines, mapped to CCM | [@cloud-security] |
| Provider-native security hubs [names] | Provider recommendations and threat findings | [@cloud-security] |
| Cloud asset inventory | Accounts, resources, tags, owners | [@platform] |
| Identity provider and cloud IAM reports | Users, roles, keys, last use | [@iam-team] |
| Policy-as-code repository | Preventive guardrails and their versions | [@platform] |
| SIEM log source register | Log types ingested per account | [@soc] |

### 2.4 Limitations

- [*Example:* The CSPM tool evaluates configuration only; it does not observe runtime traffic or application flaws.]
- [*Example:* Two Azure subscriptions were onboarded mid-period; their trend data starts at this review.]
- [*Example:* CIS Benchmark checks rely on the CSPM vendor's licensed implementation; the benchmark text is not reproduced here.]

## 3. Estate inventory and shared responsibility

<!-- Guidance: Show what exists, who owns it and which party is responsible for which layer. Ownerless accounts and services are a finding in themselves. Pitfall: assuming the provider secures managed services end to end. -->

### 3.1 Estate summary

| Estate | Accounts, subscriptions or projects | In CSPM | Resources evaluated | Owner tags complete |
|---|---|---|---|---|
| AWS *Example* | 42 accounts | 41 | 9,880 | 96% |
| Microsoft Azure *Example* | 9 subscriptions | 9 | 2,310 | 91% |
| Google Cloud *Example* | 6 projects | 5 | 1,140 | 88% |
| **Total** *Example* | **57** | **55** | **13,330** | |

### 3.2 Shared responsibility split

Record who operates each layer for the main service models. The provider's
published shared responsibility model is the starting point; the customer
column is what this review measures.

| Layer | IaaS (virtual machines) | PaaS (managed database) | Serverless functions | Managed Kubernetes |
|---|---|---|---|---|
| Physical, hypervisor, provider network | Provider | Provider | Provider | Provider |
| Operating system patching | Customer | Provider | Provider | Provider (control plane), customer (node images unless auto-upgraded) |
| Network controls (security groups, firewall rules, private endpoints) | Customer | Customer | Customer | Customer |
| Identity, roles and keys | Customer | Customer | Customer | Customer (cluster RBAC and cloud IAM) |
| Data classification and encryption choices | Customer | Customer | Customer | Customer |
| Logging enablement and retention | Customer | Customer | Customer | Customer |
| Application code and dependencies | Customer | Customer | Customer | Customer |

### 3.3 Coverage gaps

| ID | Account or scope | Gap | Impact | Action |
|---|---|---|---|---|
| GAP-001 *(Example)* | AWS `corvid-legacy-analytics` | Not onboarded to CSPM; created before the landing zone | Findings unknown beyond manual sample | Onboard by YYYY-MM-DD (ACT-006) |
| GAP-002 *(Example)* | Google Cloud project `corvid-ml-sandbox` | CSPM service account lacks folder-level viewer role | No evaluation this period | Grant role, re-run |

## 4. Findings by CCM domain

<!-- Guidance: Group every failed check under one CCM v4.1 domain so leaders can see where control families are weak. Use domain names and IDs only; do not copy CCM control text. Pitfall: forcing a domain onto a check that does not fit; mark it Unmapped and fix the mapping. -->

CCM v4.1 has 17 domains and 207 control specifications. The table lists
every domain so that gaps in assessment are visible. Counts are open
findings after false-positive removal. Domains marked "Other evidence" are
not assessed by configuration scanning and are covered by the reviews named.

| CCM domain ID | Domain name | Critical | High | Medium | Low | Total | Notes |
|---|---|---|---|---|---|---|---|
| A&A | Audit and Assurance | | | | | | Other evidence: internal audit plan |
| AIS | Application and Interface Security | 0 | 0 | 3 | 8 | 11 | *Example:* API gateway TLS policy, WAF logging |
| BCR | Business Continuity Management and Operational Resilience | | | | | | Other evidence: DR test reports |
| CCC | Change Control and Configuration Management | 0 | 0 | 5 | 12 | 17 | *Example:* resources created outside IaC |
| CEK | Cryptography, Encryption and Key Management | 0 | 2 | 9 | 12 | 23 | *Example:* key rotation disabled on 9 keys |
| DCS | Datacenter Security | | | | | | Provider responsibility; provider attestation reports reviewed |
| DSP | Data Security and Privacy Lifecycle Management | 1 | 4 | 14 | 22 | 41 | *Example:* public buckets, untagged data stores |
| GRC | Governance, Risk and Compliance | | | | | | Other evidence: exception register (section 10) |
| HRS | Human Resources | | | | | | Out of scope for configuration review |
| IAM | Identity and Access Management | 2 | 8 | 21 | 30 | 61 | *Example:* static keys, unused admin roles |
| IPY | Interoperability and Portability | | | | | | Out of scope for configuration review |
| IVS | Infrastructure and Virtualization Security | 1 | 6 | 19 | 25 | 51 | *Example:* open management ports, flat VPCs |
| LOG | Logging and Monitoring | 0 | 2 | 11 | 18 | 31 | *Example:* bucket access logs, flow logs |
| SEF | Security Incident Management, E-Discovery and Cloud Forensics | | | | | | Other evidence: incident response exercise |
| STA | Supply Chain Management, Transparency and Accountability | | | | | | Other evidence: supplier assessments |
| TVM | Threat and Vulnerability Management | 0 | 1 | 6 | 14 | 21 | *Example:* outdated node images, scanner agents missing |
| UEM | Universal Endpoint Management | | | | | | Out of scope (endpoint programme) |
| **Total** | | **4** | **23** | **88** | **141** | **256** | *Example* |

Domain names follow the CCM v4 structure; confirm them against your
licensed CCM v4.1 copy, which is the authoritative list.

### 4.1 Finding record format

Record each finding that is critical, high or part of a top risk in this format.

| Field | Value |
|---|---|
| Finding ID | CSPR-F-[NNN] |
| CCM domain and control ID | [*Example:* DSP, DSP-[nn]] |
| Baseline check | [Internal check ID or CSPM rule ID] |
| Resource and account | [ARN, resource ID or URI], [account] |
| Severity (tool) and rated risk (section 11) | [Critical / High / Medium / Low] |
| Exposure | [Internet-facing / Internal / Isolated] |
| Data class | [Restricted / Confidential / Internal / Public] |
| First seen | YYYY-MM-DD |
| Owner | [@team] |
| Status | [Open / In remediation / Excepted / Closed] |
| Action ID | [ACT-NNN] |

### 4.2 Top findings

| Finding ID | Domain | Summary | Exposure | Data | Age (days) | Owner |
|---|---|---|---|---|---|---|
| CSPR-F-001 *(Example)* | DSP | Two object storage buckets allow anonymous read | Internet | Confidential (customer exports) | 37 | [@analytics] |
| CSPR-F-002 *(Example)* | IAM | Machine users of the third-party ETL tool with an administrative policy; oldest access key 400 days | Internal | Restricted | 400 | [@data-platform] |
| CSPR-F-003 *(Example)* | IAM | Entra ID Global Administrator account without phishing-resistant MFA in the Azure tenant | Internal | Restricted | 5 | [@azure-admins] |
| CSPR-F-004 *(Example)* | IVS | Remote administration port open to any address on a bastion replacement host | Internet | Internal | 6 | [@ops] |

## 5. Identity and access posture

<!-- Guidance: Identity is the main cloud perimeter. Measure privileged identities, static credentials, unused permissions and federation. Link to the IAM design for the target model rather than restating it. Pitfall: counting only human users; machine identities usually outnumber them. -->

Target model: IAM Solution Design (`security/iam-solution-design`). Secret
and key rules: Secrets Management Standard (`security/secrets-management-standard`).

| Measure | Formula | Previous | Current | Target |
|---|---|---|---|---|
| Human cloud access through federation *Example* | federated human principals / all human principals | 94% | 98% | 100% |
| Privileged roles with phishing-resistant MFA *Example* | privileged humans with FIDO2 or equivalent / privileged humans | 89% | 95% | 100% |
| Static access keys for workloads *Example* | count of active long-lived keys attached to machine identities | 22 | 14 | 0 |
| Keys older than rotation period *Example* | keys older than the standard's period / active keys | 41% | 29% | 0% |
| Unused privileged roles (90 days) *Example* | count | 17 | 9 | 0 |
| Standing administrator assignments *Example* | permanent admin assignments not using just-in-time elevation | 31 | 18 | 5 or fewer (break-glass only) |

Observations:

- [*Example:* Just-in-time elevation is live in AWS and Azure; Google Cloud still relies on standing project owner grants in two projects.]
- [*Example:* Cross-account trust policies allow assumption from three external accounts not listed in the supplier register.]

## 6. Network exposure

<!-- Guidance: Show what is reachable from the internet and why. Every internet-facing resource needs an owner and a business reason. Pitfall: reviewing security group rules without checking whether the resource has a public address. -->

| Exposure class | Count | With approved reason | Behind WAF or managed edge | Notes |
|---|---|---|---|---|
| Public load balancers and gateways *Example* | 18 | 18 | 18 | Expected |
| Virtual machines with public IP *Example* | 7 | 4 | 0 | 3 without reason (ACT-004) |
| Management ports open to any source *Example* | 2 | 0 | 0 | Critical and high findings |
| Managed databases with public endpoint *Example* | 1 | 0 | 0 | Legacy analytics |
| Publicly readable object storage *Example* | 5 | 3 (static web assets) | 3 | 2 unexpected (CSPR-F-001) |
| Kubernetes API endpoints public *Example* | 2 | 2 (IP allow-list) | n/a | Plan private endpoints; see Kubernetes Cluster Design (`ops/kubernetes-cluster-design`) |

Record the external attack surface source (CSPM, external scanning, DNS
inventory) and reconcile them: a public address found by external scanning
but missing from the inventory is a high finding.

## 7. Data protection and encryption

<!-- Guidance: Combine data classification with configuration. A misconfiguration on restricted data outranks the same issue on public data. Pitfall: treating "encrypted at rest with provider keys" as the whole answer; check key ownership, rotation and access to keys. -->

| Measure | Previous | Current | Target |
|---|---|---|---|
| Data stores with a data classification tag *Example* | 81% | 87% | 100% |
| Confidential or restricted stores encrypted with customer-managed keys *Example* | 72% | 80% | 100% |
| Customer-managed keys with rotation enabled *Example* | 84% | 90% | 100% |
| Stores with public access block at account level *Example* | 39 of 42 AWS accounts | 41 of 42 | All |
| Backups encrypted and in a separate account or vault *Example* | 90% | 93% | 100% |
| TLS 1.2 or later enforced on public endpoints *Example* | 97% | 100% | 100% |

Key management practices are defined in PKI and Certificate Architecture
(`security/pki-certificate-architecture`) and the secrets standard. Record
deviations here only as findings.

## 8. Logging and detection coverage

<!-- Guidance: Check that the logs you need for investigation exist, are centralised and are protected from tampering. Retention and log content rules belong to the logging standard; this section measures coverage. Pitfall: confusing "log enabled" with "log ingested and alerting". -->

Required sources and retention: Security Logging Standard (`security/security-logging-standard`).

| Log source | Accounts required | Enabled | Centralised in SIEM | Immutable storage | Detection rules active |
|---|---|---|---|---|---|
| Control-plane audit logs *Example* | 57 | 57 | 57 | Yes | 42 |
| Identity provider sign-in logs *Example* | n/a | Yes | Yes | Yes | 18 |
| Network flow logs (production) *Example* | 24 | 22 | 22 | Yes | 6 |
| Object storage data access logs (confidential) *Example* | 31 buckets | 22 | 22 | Yes | 3 |
| Managed Kubernetes audit logs *Example* | 6 clusters | 6 | 6 | Yes | 9 |
| DNS query logs *Example* | 24 | 15 | 15 | No | 2 |

Coverage formula: *coverage = sources enabled and centralised / sources
required*. *Example:* data access logs on confidential buckets = 22 / 31 =
71%.

## 9. Guardrail drift and policy as code

<!-- Guidance: Compare deployed preventive and detective guardrails against the approved set in the landing zone design. Drift means a guardrail was removed, weakened, excepted without record, or never applied to a new account. Pitfall: measuring only detective findings; a missing preventive guardrail creates findings faster than teams can close them. -->

Approved guardrails: Cloud Landing Zone Design (`architecture/landing-zone-design`), section 7 and section 9.

| Guardrail ID | Guardrail | Type | Expected scope | Applied | Drift | Action |
|---|---|---|---|---|---|---|
| GR-001 *(Example)* | Deny disabling of control-plane audit logs | Preventive (organisation policy) | All accounts | 57 / 57 | None | |
| GR-002 *(Example)* | Deny public object storage unless tagged `public-approved` | Preventive | All accounts except web asset account | 54 / 56 | 2 accounts excluded without record | ACT-001 |
| GR-003 *(Example)* | Deny creation of long-lived user access keys | Preventive | Workload accounts | 30 / 42 | Not applied in legacy OU | ACT-002 |
| GR-004 *(Example)* | Require encryption with customer-managed keys for restricted data stores | Detective with auto-ticket | All | 57 / 57 | Rule version 1.3 deployed, 1.4 approved | ACT-007 |
| GR-005 *(Example)* | Restrict regions to approved list | Preventive | All | 57 / 57 | None | |

Also record:

- Resources created outside IaC (click-ops) in production: [*Example:* 63 resources, 0.8% of 7,900 production resources].
- Policy-as-code test pass rate in the pipeline: [*Example:* 100% of 48 policy tests].
- Accounts vended without the baseline in the period: [*Example:* 0].

## 10. Exceptions and risk acceptance

<!-- Guidance: Every finding that will not be fixed within its SLA needs a recorded exception with an owner, compensating controls and an expiry. Expired exceptions revert to open findings. Pitfall: exceptions without expiry dates, which become permanent risk acceptance nobody approved. -->

| Exception ID | Finding or guardrail | Reason | Compensating controls | Residual risk | Approved by | Expiry |
|---|---|---|---|---|---|---|
| EXC-014 *(Example)* | GR-002 for `corvid-web-assets` | Static website assets must be public | Bucket holds only build output; write access limited to the release pipeline | Low | [@ciso] | YYYY-MM-DD |
| EXC-019 *(Example)* | CSPR-F-002: the 3 ETL machine-user keys (recorded in the secrets standard register as SMX-003) | Third-party ETL tool does not support workload identity | Administrative policy replaced by a policy scoped to the ETL buckets (ACT-002), IP condition, 30-day rotation, alert on use from a new IP | Medium | [@ciso] | YYYY-MM-DD (90 days) |
| EXC-021 *(Example)* | Public database endpoint in legacy analytics | Pending migration (DEC-001) | IP allow-list, TLS required, database audit logging on | High | Pending decision | n/a |

Rules applied in this review:

1. Exceptions for critical findings require CISO approval and expire after at most 90 days *(Example)*.
2. Exceptions for high findings require the head of platform and expire after at most 180 days *(Example)*.
3. An exception with no compensating control is not granted; the finding stays open and escalates.
4. Expired exceptions this period: [*Example:* 2, both reopened as findings].

## 11. Risk rating

<!-- Guidance: Turn findings into risks a leader can decide on. Rate by likelihood (exposure, exploitability, guardrails) and impact (data class, privilege, blast radius). Use your enterprise risk scale so risks can move to the risk register. Pitfall: copying tool severity as risk; the tool does not know your data or business context. -->

Rating method *(Example)*: likelihood 1 to 5 multiplied by impact 1 to 5.
Score 15 to 25 is High, 8 to 14 is Medium, 1 to 7 is Low. Use the scale in
your enterprise risk methodology if one exists.

| Risk ID | Theme | Linked findings | Likelihood | Impact | Score | Rating | Treatment |
|---|---|---|---|---|---|---|---|
| RISK-CSPR-001 *(Example)* | Public exposure of customer exports | CSPR-F-001, EXC-021 | 4 | 5 | 20 | High | Mitigate (ACT-001, ACT-006) |
| RISK-CSPR-002 *(Example)* | Long-lived privileged machine credentials | CSPR-F-002, GR-003 drift | 3 | 5 | 15 | High | Mitigate (ACT-002) |
| RISK-CSPR-003 *(Example)* | Insufficient data-plane logging for investigations | Section 8 | 3 | 4 | 12 | Medium | Mitigate (ACT-005) |
| RISK-CSPR-004 *(Example)* | Open management ports on internet-facing hosts | CSPR-F-004 | 3 | 4 | 12 | Medium | Mitigate (ACT-004) |
| RISK-CSPR-005 *(Example)* | Standing administrator assignments in Google Cloud | Section 5 | 2 | 4 | 8 | Medium | Mitigate (ACT-003) |

Transfer High and Medium risks to the enterprise risk register (Risk
Register Template, `compliance/risk-register`) with the same IDs.

## 12. Remediation plan

<!-- Guidance: Each action has one owner, a due date, a verification method and the risk it reduces. Prefer actions that fix a class of findings (a guardrail) over actions that fix one resource. Pitfall: actions owned by "the cloud team" with no named person. -->

| Action ID | Action | Reduces | Owner | Due | Verification | Status |
|---|---|---|---|---|---|---|
| ACT-001 *(Example)* | Remove public access from the two buckets; apply GR-002 to the two excluded accounts | RISK-CSPR-001 | [@analytics-lead] | YYYY-MM-DD | CSPM check passes; external scan shows no anonymous read | In progress |
| ACT-002 *(Example)* | Apply GR-003 to legacy OU; replace 11 of the 14 workload keys with workload identity; scope the 3 ETL keys under EXC-019 to the ETL buckets | RISK-CSPR-002 | [@platform-lead] | YYYY-MM-DD | Static workload key count is 3 or fewer, each covered by EXC-019; no key has an administrative policy | Planned |
| ACT-003 *(Example)* | Move Google Cloud owner grants to just-in-time elevation | RISK-CSPR-005 | [@gcp-admin] | YYYY-MM-DD | IAM report shows no standing owner outside break-glass | Planned |
| ACT-004 *(Example)* | Close management ports; use session manager or identity-aware proxy | RISK-CSPR-004 | [@ops-lead] | YYYY-MM-DD | No port 22 or 3389 open to any source | In progress |
| ACT-005 *(Example)* | Enable data access logging on the 9 remaining confidential buckets and ingest to SIEM | RISK-CSPR-003 | [@soc-lead] | YYYY-MM-DD | Coverage 31 / 31 | Planned |
| ACT-006 *(Example)* | Onboard legacy analytics account to CSPM; migrate per DEC-001 | RISK-CSPR-001, GAP-001 | [@analytics-lead] | YYYY-MM-DD | Account in CSPM and landing zone | Planned |
| ACT-007 *(Example)* | Deploy GR-004 rule version 1.4 | Section 7 | [@platform-lead] | YYYY-MM-DD | Policy version in all accounts | Planned |

Remediation SLAs for findings follow Vulnerability Management Policy
(`security/vulnerability-management-policy`) where the finding is a
vulnerability, and the internal cloud baseline for configuration findings.
*Example configuration SLAs:* critical 7 days, high 30 days, medium 90 days,
low next quarterly cycle.

## 13. Trend and metrics

<!-- Guidance: Show direction over at least four reviews when data exists. Use the same formulas every period so the trend means something. Pitfall: changing the CSPM rule set without noting it, which makes the pass rate jump for reasons unrelated to posture. -->

| Metric | Formula | Q4 prev. year | Q1 | Q2 | Q3 (current) |
|---|---|---|---|---|---|
| Configuration pass rate *Example* | passed checks / evaluated checks | 89.9% | 91.2% | 92.5% (16,380 / 17,700) | 93.6% (17,236 / 18,420) |
| Open critical findings *Example* | count at snapshot | 12 | 9 | 7 | 4 |
| Open findings, all severities *Example* | count at snapshot | 341 | 297 | 263 | 256 |
| Mean time to remediate, critical (days) *Example* | sum of days open for closed criticals / closed criticals | 19 | 14 | 11 | 8 |
| SLA adherence, critical and high *Example* | closed within SLA / closed | 71% | 78% | 83% | 88% |
| Accounts with full guardrail set *Example* | compliant accounts / accounts in scope | 84% | 88% | 91% | 95% |

Rule set changes in the period: [*Example:* the CSPM vendor added 120 checks
for managed AI services in Q3, producing 640 evaluations of which 541 passed
(84.5%). Excluding them, the Q3 like-for-like pass rate is (17,236 - 541) /
(18,420 - 640) = 16,695 / 17,780 = 93.9%, so the wider rule set lowered the
headline rate by about 0.3 points and the like-for-like gain over Q2 is 1.4
points (92.5% to 93.9%).]

```mermaid
flowchart LR
  A[Snapshot CSPM and inventory] --> B[Reconcile coverage]
  B --> C[Map to CCM domains]
  C --> D[Validate with owners]
  D --> E[Rate risk]
  E --> F[Agree actions and exceptions]
  F --> G[Track to closure]
  G --> A
```

### 13.1 Sign-off

Acceptance criteria for closing this review:

- Every critical and high finding has an action or an approved exception.
- Every High risk has a named treatment owner and appears in the risk register.
- Coverage gaps (section 3.3) have onboarding actions.
- Decisions in section 1 are recorded with the decision owner.

## 14. Glossary and references

<!-- Guidance: Define terms readers outside security will meet. Cite sources by name and version; do not copy their text. -->

### 14.1 Glossary

| Term | Meaning |
|---|---|
| CSPM | Cloud security posture management: tooling that evaluates cloud configuration against rules and reports deviations |
| CCM | Cloud Controls Matrix: the CSA control framework for cloud computing, organised into domains and control IDs |
| Guardrail | A preventive or detective control applied centrally across accounts, usually as policy as code |
| Drift | A difference between the approved configuration or guardrail set and what is deployed |
| Shared responsibility | The split of security duties between the cloud provider and the customer for each service model |
| Pass rate | Passed checks divided by evaluated checks for a fixed rule set |
| Exception | A time-limited, approved deviation from a baseline with compensating controls |
| Landing zone | The governed multi-account foundation into which workloads are deployed |

### 14.2 Related templates

| Template | Use |
|---|---|
| Cloud Security Reference Patterns Template (AWS SRA, MCSB, CCM v4.1) (`security/cloud-security-reference-patterns`) | Approved patterns this review checks against |
| Cloud Landing Zone Design Template (AWS, Azure, Google Cloud) (`architecture/landing-zone-design`) | Guardrails, account structure and policy as code |
| IAM Solution Design Template (NIST SP 800-63-4, SSO, PAM) (`security/iam-solution-design`) | Target identity model |
| Secrets Management Standard (`security/secrets-management-standard`) | Static key and secret rules |
| Vulnerability Management Policy (`security/vulnerability-management-policy`) | Remediation SLAs for vulnerabilities |
| Security Logging Standard (`security/security-logging-standard`) | Required log sources and retention |
| Kubernetes Cluster Design (`ops/kubernetes-cluster-design`) | Cluster baseline and endpoint exposure |
| Zero Trust Architecture Plan Template (NIST SP 800-207, CISA ZTMM 2.0) (`security/zero-trust-architecture`) | Programme context for identity and network findings |
| Security Architecture Document Template (NIST SP 800-160, STRIDE) (`security/security-architecture`) | System-level design for systems with recurring findings |
| Penetration Test Report Template (PTES, OWASP WSTG) (`security/pentest-report`) | Exploitation testing, which this review does not perform |

### 14.3 References

- Cloud Security Alliance, *Cloud Controls Matrix* v4.1 and CAIQ v4.1, released 27 January 2026 (207 control specifications in 17 domains): https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4-1
- Cloud Security Alliance, CCM and AICM licensing FAQ (terms for internal use, customisation and redistribution): https://cloudsecurityalliance.org/artifacts/ccm-aicm-licensing-faq
- Center for Internet Security, CIS Benchmarks for cloud providers (obtain the current version from CIS): https://www.cisecurity.org/cis-benchmarks
- NIST SP 800-53 Rev. 5, *Security and Privacy Controls for Information Systems and Organizations*, Release 5.2.0 (27 August 2025), for optional mapping of findings: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
- The cloud provider's published shared responsibility model and security recommendations for each estate in scope.

## Standard and licence note

Structure aligned with the Cloud Security Alliance *Cloud Controls Matrix*
v4.1 (January 2026). CCM domain names and identifiers are cited for mapping
only; no control specification text, implementation guideline or auditing
guideline is reproduced. The CCM is free for internal use under CSA terms,
and customisation or commercial reuse of its content requires a licence from
CSA; the free download may not be modified or redistributed (see the CSA CCM
licensing FAQ), so use your own licensed copy for control-level work. CIS Benchmarks
are named only; obtain and apply them under the CIS terms. NIST SP 800-53 is
a work of the United States Government. Check the current official versions
before relying on this review, as updates may have been published. Cloud
Security Alliance, CCM, CIS and CIS Benchmarks, and the cloud provider names
are trademarks of their owners; this template is not affiliated with or
endorsed by them. Original text written for this collection. Template
licence: MIT.