All resources
// Resources

Cloud Security Posture Review: A Buyer’s Evidence Checklist

Published July 19, 2026

Cloud posture review is evidence-led assessment of identity, exposure, data protection, logging, and recovery controls across named accounts, subscriptions, projects, and regions. It is not certification or proof that every risk is removed. CIS publishes cloud configuration benchmarks; AWS Security Hub CSPM maps controls to CIS and NIST references. Use them as a starting catalogue, then confirm deployed behavior and ownership.

Start with coverage, not score

A dashboard percentage cannot answer what was measured. Buyer should request a dated inventory: cloud tenants, accounts, regions, production tags, excluded resources, collection method, and access level used. Reconcile this list to billing or organization inventory. A result marked pass in only one region is not a pass for an unmeasured region.

AreaCompleted artifactEvidence criteriaOwnerPass / fail
Identityprivileged-access registerprincipal, role, scope, MFA method, last reviewIAM ownerevery privileged path attributable
Networkexposure registerpublic endpoint, port, source restriction, business approvalplatform ownerno unapproved public path
Dataencryption registerresource, key, key policy, rotation setting, recovery needdata ownerencryption and access match design
Loggingaudit coverage mapaccounts, regions, event classes, destination, retention, delete rightssecurity ownercollection and protection evidenced
Recoveryrestore-test recordbackup scope, test date, result, gap, corrective actionservice ownerrecent test meets stated need

For each row, record account or project ID, resource ID, capture timestamp, collector, and immutable export location. Screenshots may support discussion but are weak primary evidence: they omit query scope and are hard to reproduce. Prefer CLI or API exports, configuration snapshots, policy JSON, and control findings with control IDs.

Test control paths

Sample both dashboard claims and high-value resources. For AWS, confirm CloudTrail coverage, encrypted log destination, validation settings, and write/delete permissions; Security Hub documents controls such as CloudTrail.1 for multi-Region management events and CloudTrail.2 for encryption at rest. Also inspect IAM role trust policies, access-key inventory, root-account safeguards, public storage blocks, security-group ingress, KMS key policies, and break-glass access.

A minimal evidence record can be structured before collection:

control: audit-trail-protection
scope: "accounts 123456789012, 210987654321; all enabled regions"
artifact: "cloudtrail-export-2026-07-19.json"
owner: security-operations
result: fail
finding: "log bucket permits unexpected delete principal"
exception: null
remediation: "remove delete permission; export revised policy"
due: 2026-08-02

Do not mark a control pass because a setting exists. Test whether an unauthorized principal is denied, whether a permitted operator can perform intended work, and whether relevant events reach protected storage. For configuration rules, preserve raw result, evaluated resource count, and timestamp. For identity, use representative simulate-principal-policy or equivalent least-privilege tests only in approved scope.

Exception discipline

An exception is a risk decision, not an empty spreadsheet cell. Require control ID, affected resource, reason, compensating control, approving owner, expiry, and remediation ticket. Temporary administrator access without an expiry fails this evidence standard. Expired exception with no renewal becomes failed control until resolved. Keep exceptions separate from accepted findings so buyer can see whether pass status depends on waiver.

Prioritize public exposure, unmanaged privileged identities, absent audit coverage, and broadly writable keys or logs before cosmetic tagging gaps. Remediation needs owner and a completed artifact: revised policy export, ticket link, pull request, re-run result, or retest note. “Team notified” is not remediation evidence.

Deliverable and boundary

Useful output contains scope statement, method, control register, evidence index, findings, exceptions, remediation ownership, and residual limitations. It should say which cloud services were not tested and distinguish configuration evidence from attack-path testing. Re-run after material architecture change and on a defined review cadence. Infrastructure testing can validate selected control paths under agreed scope.

Worked case: stale public-exposure finding

Select one posture finding that reports external exposure. Trace it to current resource configuration, effective policy, reachable endpoint test from authorized external network, owner, and business purpose. Expected output classifies finding as confirmed, false positive with reason, accepted exception, or remediated; “acknowledged” is not closure. For confirmed issue, make minimum approved configuration change, rerun collection, and retain before/after evidence with timestamp.

Test rescans after resource deletion, policy rollback, account onboarding, and scanner permission loss. Measure queue age against agreed review target, not vendor severity alone. Closure record needs finding identifier, evidence links, decision maker, change reference, verification result, review date, and expiry where exception applies. Independent reviewer samples closed items and attempts to reproduce condition using stated method. Reopen result if source data cannot support prior classification.

Operational handoff: queue owner assigns every open finding to system owner or records missing ownership. Review scanner health and coverage, not findings alone. Export selected evidence before retention ends. This makes later recurrence review reproducible.

For each verified condition, record exact collection timestamp and configuration version. If either changes during triage, recollect before decision. This avoids closing a finding from stale evidence.

Closure reviewer records external test path, observed result, and retest date. If resource owner cannot demonstrate business need, remove exception rather than extend it. Evidence stays tied to finding identifier and current configuration snapshot.

Sources

Have a system that needs testing?