Cloud security review: evidence to collect
What to collect before an AWS or Azure security assessment, and why each item matters.
Evidence should reconstruct a path
A useful cloud review does not produce a pile of screenshots. It connects identities, reachable services, sensitive data, detection and recovery into paths that leadership can prioritise.
Each artefact should have a source, collection date, scope and owner. Without those fields, the reviewer cannot tell whether an export represents one workload or the entire tenant.
Identity evidence
Collect identity-provider configuration, privileged role assignments, workload identities, long-lived keys, MFA coverage, access-review outputs and emergency-access procedures. Separate human, machine and federated identities.
The key question is not only who is an administrator. It is which identities can become privileged through role assumption, group membership, token exchange or a poorly constrained service principal.
Exposure and data evidence
Inventory public endpoints, load balancers, storage, management interfaces, firewall or security-group rules, private connectivity and egress. Map each exposed service to an owner and data classification.
For sensitive data, collect access policies, encryption and key ownership, backup settings, replication, lifecycle, snapshot sharing and secrets-management configuration.
Detection and recovery evidence
Provide control-plane logs, central log destinations, retention, alert rules, incident tickets and examples showing that alerts are investigated. A configured service is not the same as an operating detection process.
Collect recovery objectives, backup status, restore-test evidence and responsibility for failover. Resilience claims need test records, not only architecture diagrams.
Use least privilege for the review
Prefer read-only roles or controlled exports. Record every permission granted to the assessor, its owner and expiry. Never send cloud credentials through an enquiry form or ordinary email.
The final evidence register should identify what was not available. A documented limitation is more honest and more useful than a silent assumption of coverage.