Cloud Infrastructure Security Assessment Checklist

Introduction

Cloud environments change faster than any security team can track by hand. A developer spins up a public server with shared credentials, a role picks up permissions nobody revisits, a log source gets skipped. Each one becomes a hidden attack path.

Google Cloud's threat team observed weak or absent credentials in 27.2% of its H2 2025 initial-access cases and misconfiguration in 21.0%. That is a subset of the cases it saw, not a breach rate for everyone.

This checklist helps you set scope, review controls, prioritize findings, assign owners, and verify fixes. It fits single-cloud, multi-cloud, hybrid, and regulated environments, and it accounts for the shared responsibility model.

Key Takeaways

  • Look beyond vulnerabilities to identities, configurations, exposure, data, workloads, logging, and governance.
  • Rank findings by data sensitivity, exposure, privilege, and blast radius.
  • Finish with owners, deadlines, evidence, and a retest plan.
  • Reassess continuously, on a schedule, and after major changes.

What a Cloud Infrastructure Security Assessment Should Cover

A cloud infrastructure security assessment is a structured review of your cloud foundation, identities, workloads, data flows, and configurations. It shows where you are exposed and whether controls work as intended.

Know Who Owns What

Providers secure the underlying infrastructure. You own what you put in it. AWS frames this as security "of" the cloud versus "in" the cloud. Customer-side items typically include:

  • IAM and access policies
  • Network rules and firewall configuration
  • Encryption settings and key handling
  • Workload and OS configuration
  • Logging and data protection
  • Compliance evidence

The split shifts between IaaS, PaaS, and SaaS, so map your assessment scope to the services you actually run.

With ownership clear, run the assessment through a repeatable workflow.

The Six-Step Workflow

  1. Define scope and produce a scope statement.
  2. Inventory assets and identities into an asset register.
  3. Establish control baselines in a control matrix.
  4. Review and test controls and log a findings register.
  5. Prioritize findings into a risk-ranked roadmap.
  6. Remediate and reassess and keep a validation record.

Scope. Name the providers, accounts, subscriptions, projects, regions, production and non-production environments, connected SaaS, critical applications, sensitive data, and third-party integrations before testing begins.

Inventory. Tie every asset and identity to an owner, purpose, environment, data classification, exposure level, and dependencies. Cover:

  • Human users and privileged roles
  • Service accounts and workload identities
  • Secrets and APIs
  • Containers, databases, and storage
  • Serverless functions and Kubernetes resources

Baselines. Pick your standards and evidence requirements up front. NIST, CIS Benchmarks, the CSA Cloud Controls Matrix, internal policy, and contracts can work together, but they are not interchangeable.

HIPAA, PCI DSS, SOC 2, and ISO 27001 each answer different questions: a regulation, a payment standard, an attestation, and a management-system standard.

Six-step cloud infrastructure security assessment workflow

Cloud Infrastructure Security Assessment Checklist

Capture each item in a workbook with columns for control status, evidence, risk, owner, due date, and retest result.

Identity and Access Management

  • Enforce MFA for privileged users, admin consoles, and remote access; document approved exceptions.
  • Review human, federated, service, and workload identities, trust relationships, and long-lived credentials for excess, stale, or unused permissions.
  • Confirm least privilege, separation of duties, just-in-time access, break-glass procedures, access reviews, credential rotation, and offboarding.
  • Collect evidence: IAM policies, access review records, privileged-session logs, MFA settings, role assignments, and recent permission changes.

Network Exposure and Segmentation

  • Identify internet-facing assets, public IPs, open ports, load balancers, APIs, remote admin paths, and storage endpoints.
  • Review VPC/VNet, subnet, routing, security group, firewall, and private endpoint controls to see whether segmentation limits lateral movement.
  • Compare architecture diagrams to the live environment. Investigate undocumented exposure and links between development, testing, and production.
  • Tie each network finding to the assets, identities, and data stores it can reach.

NetFlow data helps here: it can reveal east-west traffic between systems that normally never talk.

Data Protection, Encryption, and Secrets

  • Locate sensitive and regulated data across databases, object storage, snapshots, backups, logs, caches, and replicas. Document owners and classifications.
  • Verify encryption at rest and in transit, key ownership, rotation, access restrictions, and certificate management.
  • Confirm secrets and API keys live in approved secret managers, not code, images, scripts, or logs.

According to GitGuardian's State of Secrets Sprawl 2026, public GitHub commits exposed 28.65 million new hardcoded secrets during 2025.

  • Check retention, deletion, backup, and data-residency rules against US regulatory, contractual, and internal obligations.

Workloads, Applications, APIs, and Containers

  • Assess VMs, containers, Kubernetes, serverless functions, managed databases, and images for unsupported software, missing patches, and insecure defaults.
  • Review vulnerability scanning, image scanning, infrastructure-as-code checks, code review, and pipeline controls.
  • Test that public apps and APIs enforce authentication, authorization, rate limiting, and input validation.
  • Use penetration testing for high-exposure or critical systems, with rules of engagement set in advance.

Logging, Monitoring, Detection, and Incident Readiness

  • Confirm logging of identity activity, admin changes, network events, data access, workload activity, and API calls.
  • Review centralization, time sync, retention, tamper resistance, and searchability.
  • Map high-risk findings to detections: privilege changes, credential misuse, public exposure, exfiltration, destructive activity.
  • Run tabletop exercises to test escalation, evidence preservation, containment, communications, and provider contacts.

Resilience, Configuration Governance, and Third-Party Risk

  • Review backup coverage and isolation, restoration tests, failover, and recovery objectives. Do not assume the provider guarantees your backups.
  • Assess change management, infrastructure-as-code, policy-as-code, drift detection, and exception handling.
  • Evaluate cloud, SaaS, and managed providers for access scope, incident obligations, assurance reports, and exit options.
  • Keep evidence in a repeatable format: configuration exports, test results, log samples, diagrams, approvals, and retest records.

Cloud infrastructure security assessment coverage areas infographic

How to Prioritize Findings and Build a Remediation Plan

Scanner severity alone misleads. FIRST states that CVSS measures technical severity, not organizational risk, and that EPSS estimates exploit probability while ignoring your environment. Rank findings only after you add environmental context:

  • Internet reachability
  • Data sensitivity and privilege
  • Asset criticality and blast radius
  • Attack paths
  • Compliance consequences

Build a Findings Register

Record for each finding:

  • Affected asset or identity and the observed condition
  • Control gap and supporting evidence
  • Likely impact and risk rating
  • Recommended action, owner, and target date
  • Exception status and validation method

Contain First, Fix Durably Second

Contain exposure first, then fix the root cause. Immediate moves include:

  • Closing public exposure
  • Disabling unused credentials
  • Enforcing MFA
  • Rotating secrets
  • Isolating a workload

Durable fixes, such as architecture or process changes, come next.

Assign work to the team that can make the change: cloud platform, identity, application, data, or a vendor. "Security" is rarely the right owner for every ticket.

Retest and Report

Define how each material fix gets retested: rescan, configuration check, manual review, or attack-path analysis. Document residual risk when a finding cannot be fully eliminated.

Produce separate outputs:

  • An executive summary for leadership
  • A technical findings register for engineering
  • A control and evidence map for GRC
  • A remediation roadmap with milestones and dependencies

Cloud security finding remediation and validation workflow

Tools, Frameworks, and Ongoing Assessment Cadence

Match Tools to Risks

No single tool covers a cloud environment. CISA's cloud architecture describes CSPM as continuous monitoring for configuration, vulnerability, and compliance issues. Other categories cover different gaps:

  • CNAPP and cloud-native services for workload and posture coverage
  • Vulnerability and infrastructure-as-code scanners for known weaknesses
  • Identity analytics for permission sprawl
  • SIEM for detection and investigation
  • Attack-surface management for external exposure
  • Penetration testing for proving exploitable chains

A scanner flags a missing patch. A penetration test shows whether that patch gap leads to credentials, file servers, and backups.

When evaluating tools, check:

  • Provider and multi-cloud coverage
  • Agent or agentless needs, plus container support
  • API access, identity context, and policy customization
  • Evidence quality, ticketing, and SIEM integration
  • Fit with tools you already own

Frameworks and "CISA Assessments"

Use NIST, CIS Benchmarks, the CSA Cloud Controls Matrix, provider guidance, and your regulatory or contractual requirements.

Name any CISA resource precisely. Cyber Hygiene scans public IPs, CSET is a self-assessment, and SCuBA covers Microsoft 365 and Google Workspace baselines. None is a full cloud infrastructure assessment.

Three Review Modes

  • Continuous: monitor for drift and new exposure.
  • Periodic: run formal assessments for governance and audit readiness.
  • Event-driven: reassess after migrations, incidents, acquisitions, IAM or network redesigns, new critical applications, or major third-party integrations.

Formal intervals depend on your compliance obligations. PCI DSS requires vulnerability scans at least quarterly, while HIPAA sets no fixed risk-analysis frequency.

When You Need a Partner

Teams without assessment, GRC, offensive security, or 24/7 monitoring capacity can bring in help. DeepSeas offers strategic advisory, offensive security, governance, risk and compliance, cloud coverage, and managed detection and response. It works with existing SIEM, EDR, and CNAPP tools, and its GRC team includes ISO Lead Auditor-certified specialists.

Frequently Asked Questions

What are the six key steps to assess your cloud readiness?

Define scope, inventory assets and identities, select control baselines, review and test controls, prioritize risks, then remediate and reassess.

What are the three main types of security assessments?

Internal, independent or external, and compliance-focused. Many organizations combine them, such as an internal review before an external audit.

Which security tool is commonly used to assess cloud vulnerabilities?

CSPM is common for configuration and posture checks. Vulnerability scanners, CNAPP platforms, and penetration testing cover other parts of the assessment.

What is a CISA assessment?

It is not one assessment. CISA offers several resources, such as Cyber Hygiene, CSET, and SCuBA, each with a narrow purpose. None replaces a full technical cloud assessment.

What is included in a cloud infrastructure security assessment?

Scope and inventory, IAM, network exposure, data protection, workloads, logging, resilience, compliance alignment, remediation, and retesting.

How often should a cloud security assessment be performed?

Monitor continuously, schedule formal reviews by risk and rate of change, and reassess after migrations, incidents, major changes, or audits.