Cloud Security Assessment Checklist: A Practical Review Framework for AWS, Azure, and GCP

Why Most Cloud Security Assessments Miss the Actual Risk

Many cloud reviews look busy but stay shallow. They produce a spreadsheet of configuration findings, maybe a handful of screenshots, and a vague conclusion that the environment needs "hardening." That is not enough for a production environment.

A useful cloud security assessment answers four practical questions:

1. What identities can reach sensitive systems right now?
2. Which exposed paths could actually be abused by an attacker?
3. Which detections would fire if that abuse happened today?
4. What should the team fix first to reduce real breach risk?

That is the difference between a compliance-flavored review and an engineering-grade assessment.

This guide gives you a review framework that works across AWS, Azure, and GCP without collapsing into vendor-specific checklists.

---

What a Cloud Security Assessment Should Cover

A serious assessment should validate eight control areas:

1. Identity and privilege
2. Internet exposure and network paths
3. Logging, monitoring, and alerting
4. Data protection and encryption
5. Compute and workload hardening
6. Kubernetes, containers, and serverless controls
7. Backup, recovery, and incident response readiness
8. Governance, drift detection, and remediation workflow

If one of those areas is missing, the assessment is incomplete.

---

Before You Start: Gather Evidence, Not Just Screenshots

Ask for these artifacts before the review begins:

• Cloud account and subscription inventory
• Identity architecture and SSO flow
• Admin role list and break-glass accounts
• Internet-facing asset inventory
• VPC, VNet, and project network diagrams
• Logging destinations and retention settings
• CSPM or posture scan exports if the team already has them
• Backup policy documents and restore procedures
• IaC repositories for Terraform, CloudFormation, Bicep, or Pulumi
• Security incident runbooks

The goal is to understand how the environment is designed before you start looking for individual misconfigurations.

---

The 8-Domain Assessment Checklist

1. Identity and Privilege

This is usually the highest-value section of the assessment because identity mistakes turn small footholds into major incidents.

Review questions:

• Are human administrators using federated SSO, or are there still local cloud users with long-lived credentials?
• Is MFA enforced for all privileged access?
• Are there wildcard permissions, excessive directory roles, or broad service account grants?
• Are machine identities scoped to the workload they support, or do they have cross-environment access?
• Is there a quarterly access review with evidence?

What to validate in practice:

• AWS IAM roles with AdministratorAccess or equivalent broad policy attachment
• Azure roles such as Owner or User Access Administrator assigned too widely
• GCP roles using primitive roles instead of tightly scoped custom or predefined permissions
• Stale access keys, unused service principals, and dormant service accounts

Example:

A SaaS team migrated to SSO for employees but left a legacy AWS IAM user in place for a deployment script. That user still had a long-lived access key, no MFA, and permission to write to production S3 buckets. The official admin accounts looked clean, but the real risk sat in the forgotten automation identity.

2. Internet Exposure and Network Paths

The important question is not whether the cloud has a firewall. It is whether an attacker can move from an exposed service to something more sensitive.

Check for:

• Internet-facing load balancers, gateways, API endpoints, and storage services
• Security groups or NSGs with 0.0.0.0/0 access on administrative ports
• Flat peering or transit connectivity between production and lower environments
• Missing egress controls for critical workloads
• Publicly accessible object storage, snapshots, or database endpoints

Good assessment output here includes an attack path, not just a list of open ports.

3. Logging, Monitoring, and Alerting

A cloud environment can be technically hardened and still be unsafe if nothing meaningful is monitored.

Review questions:

• Are control plane logs enabled in every account, subscription, and project?
• Are data plane events captured for sensitive services such as object storage, databases, and secrets managers?
• Are logs centralized and protected from tampering?
• Are detections mapped to actual attacker behavior, not just generic severity rules?

Minimum evidence to confirm:

• CloudTrail, Azure Activity Logs, and GCP Audit Logs are enabled consistently
• GuardDuty, Defender for Cloud, Security Command Center, or equivalent tooling is actively sending findings
• Alerts exist for privilege escalation, disabling logging, suspicious token use, and public storage exposure

4. Data Protection and Encryption

Encryption is necessary, but a checkbox answer is not enough.

Validate:

• Sensitive data classification exists and is actually used
• Encryption at rest is enabled for storage, databases, snapshots, and backups
• TLS is enforced for administrative and application traffic
• Customer-managed keys are used where risk or regulatory requirements justify them
• Secret rotation exists for database credentials, API keys, and signing material

Common failure mode:

Teams enable encryption broadly but never audit who can decrypt, export, or share data. The storage layer looks safe while the identity layer quietly defeats it.

5. Compute and Workload Hardening

This is where cloud reviews often drift back into traditional server hardening, but cloud context still matters.

Check:

• Immutable image pipeline or unmanaged snowflake servers?
• Patch cadence for VM images and base containers
• EDR coverage for compute workloads
• Metadata service protections, especially on AWS and GCP
• Least-privilege instance profiles and managed identities

6. Kubernetes, Containers, and Serverless

For modern environments, this is not optional.

Validate:

• Private cluster endpoints or restricted admin access
• Workload identity instead of static cloud credentials in pods or functions
• Admission controls and image provenance checks
• Default service account misuse in Kubernetes
• Secrets mounted securely and rotated
• Function permissions scoped tightly to single-purpose actions

Example:

We often see serverless functions with broad read access to customer data because they were copied from an internal admin workflow. The function itself looks simple, but its execution role is powerful enough to turn a minor application flaw into a reportable breach.

7. Backup, Recovery, and Incident Response

Backups are only a security control if restoration is tested.

Review:

• Are backups immutable or at least protected from routine admin deletion?
• Can the team restore a critical database to a known clean point?
• Are cross-account or cross-project backups used for resilience?
• Is there a cloud-specific incident response playbook for credential theft, storage exposure, and malicious IAM changes?

8. Governance, Drift Detection, and Remediation Workflow

The best assessment does not end with a PDF. It feeds a remediation loop.

Look for:

• Policy as code and preventive guardrails
• Drift detection for manual changes outside IaC
• Severity definitions tied to business impact
• Named owners and due dates for findings
• Retest criteria for high-risk items

---

A Practical Severity Model

Do not rank findings by aesthetics. Rank them by attack value.

---

Example Review Outcome

Imagine a mid-market B2B platform running in AWS and Azure.

The initial posture scan shows 140 findings. That sounds dramatic, but the assessment narrows the real priorities to five items:

1. Production storage bucket exposed through a legacy policy exception
2. Azure service principal with broad Graph and subscription permissions
3. No alert for disabling CloudTrail in one AWS account
4. Kubernetes admin access allowed from any corporate IP without device trust
5. Backups configured, but no tested restore for the main customer database

That is what leadership needs. Not noise. A short list of breach-relevant work.

---

30-60-90 Day Remediation Plan

First 30 days

• Remove public exposure to sensitive storage and admin interfaces
• Rotate stale credentials and disable unused identities
• Turn on missing control plane logging and core detections
• Validate restore capability for one critical system

Days 31-60

• Reduce high-risk permissions for CI, automation, and break-glass accounts
• Enforce workload identity for Kubernetes and serverless
• Add policy checks to IaC pipelines
• Centralize cloud findings into one triage process

Days 61-90

• Introduce preventive guardrails for new accounts and projects
• Tune detections for identity abuse and storage exposure
• Run a focused retest on critical and high findings
• Convert repeated issues into engineering standards

---

What Good Assessment Deliverables Look Like

At the end of the review, you should have:

• An executive summary in plain language
• A technical findings section with evidence and reproduction context
• Attack-path diagrams for the highest-risk issues
• A remediation matrix with owners and priority
• A retest plan

If the report cannot tell engineering exactly what to fix next, it is not done.

---

Further Reading

• AWS Well-Architected Framework: Security Pillar
• Azure Security Benchmark
• Google Cloud Security Foundations Guide
• NIST SP 800-53 Rev. 5
• Cloud Security Alliance Cloud Controls Matrix

Related SecureCodeReviews guides:

• AWS Security Best Practices
• Kubernetes Security Complete Guide
• Multi-Cloud Security Guide

Bottom line: a cloud security assessment should show how an attacker would move, what would stop them, and what the team must fix first. Anything less is just inventory work.