The CSP Cloud Assessment Method
Every cloud security assessment we deliver follows a single, repeatable process we call the CSP Cloud Assessment Method. We developed it over thousands of engagements across AWS, Azure, and Google Cloud, and it reflects what our team has learned about where cloud environments actually break down.
The method moves through five phases:
- Scope: confirm the estate, priorities, and decision-makers before anything else.
- Evidence Gathering: collect configuration exports, identity data, architecture diagrams, and logging details using read-only access.
- Testing and Validation: run over 200 automated checks alongside manual review, then validate the real-world impact of each finding.
- Findings and Severity: document affected resources, conditions, evidence, risk, and a practical fix for every issue.
- Remediation and Retest: assign owners, agree on timelines, and verify fixes against the underlying condition, not just ticket status.
The method applies to single-account reviews and multi-cloud programs alike. It maps to CIS Benchmarks, NIST SP 800-53, and the CSA Cloud Controls Matrix, so results align with whatever compliance framework your organization already follows.
Methodology at a Glance
The table below summarizes each phase: what goes in, what comes out, and how long it typically takes for a single-account engagement. Multi-account or multi-cloud work extends the timeline, mainly because of cross-team coordination rather than additional testing.
For a focused single-account review, the first four phases typically complete within a few weeks. Remediation and retest continue on a schedule agreed with your team. Many clients move to quarterly retesting to track improvement over time.
Principles Behind the Method
Four principles guide every engagement. They explain why the method works the way it does, not just what happens at each step.
Evidence over opinion. Every finding rests on documented evidence (configuration exports, API responses, or policy files) so a second reviewer can reach the same conclusion independently. We retain that evidence throughout the engagement and reference it in the final report.
Risk before compliance. Compliance frameworks provide useful structure, but passing a checklist does not mean the environment is secure. We assess actual risk first: what is exposed, what can be reached, what an attacker could do with it. Then we map findings to the relevant framework controls. This gives your compliance team the mapping they need without letting a framework gap distract from a genuine threat.
Scope defines quality. A thorough assessment of ten accounts is more valuable than a shallow pass over fifty. We invest time at the start to identify the systems that are internet-facing, handle sensitive data, or grant administrative access, then focus testing there. If the estate is larger than the engagement window allows, we say so upfront and help prioritize.
Findings must be fixable. Every finding includes a practical remediation path: a specific action tied to the affected resource and the team responsible, with a realistic timeline. When a fix introduces trade-offs, we document those too, so your team can make an informed decision rather than following a report on faith.
Phase 1: Scope
The assessment begins before any configuration is reviewed or any automated check is run. In the scoping phase, we confirm what the engagement will cover, why it matters, and who needs to be involved.
We start with a straightforward inventory: which cloud accounts, subscriptions, or projects are in scope? Who owns them? What is their business criticality? We ask about tagging conventions, naming standards, and any recent changes (migrations, acquisitions, decommissioned services) that might affect what we find. We identify orphaned resources and shadow accounts here rather than discovering them mid-assessment.
A finding in a development sandbox carries different risk than the same finding in a production environment processing financial data. We ask about the data each account handles, the regulations that apply, the internal teams that manage it, and any previous assessments or known issues. This context shapes how we assign severity later and ensures the report speaks to the risks your organization actually faces, not generic cloud security concerns.
We identify the people who will provide access, answer questions during testing, receive the report, and own remediation. Requesting credentials and architecture artifacts early avoids delays once testing begins. We also confirm the identity provider in use, logging destinations, deployment pipelines, and whether any recent disaster-recovery or restore tests have been performed. These details inform what we look for during evidence gathering.
The phase produces a scoping document that records the agreed boundaries, priorities, timeline, and access requirements. Both teams review and sign off before evidence gathering starts. If the estate turns out to be larger or more complex than initially anticipated, we adjust the engagement plan here, not halfway through testing when surprises cost more time and erode coverage.
The scoping phase typically takes one to two days for a single-account engagement. For multi-account environments, we schedule a dedicated kickoff session with representatives from each team to ensure nothing is missed and every account owner understands what to expect.
Phase 2: Evidence Gathering
With the scope agreed, we collect the raw data that testing will run against. Everything in this phase uses read-only access. We examine the environment without changing it.
We request the minimum permissions needed to enumerate resources, read configurations, and pull policy data. Typically this means a read-only IAM role scoped to the in-scope accounts. We never request write access during evidence gathering, and the credentials we use are documented in the scoping record so your team can audit exactly what was accessed.
The evidence set varies by provider, but it generally includes:
- Identity and access data: IAM users, groups, roles, policies, federation settings, and MFA status across every in-scope account.
- Network configuration: VPC layouts, security groups, network ACLs, route tables, public IP assignments, and load-balancer configurations.
- Logging and monitoring: audit log coverage, log destinations, retention periods, and whether alerting rules exist for critical events.
- Encryption settings: encryption-at-rest and in-transit configurations for storage, databases, and messaging services.
- Resource inventory: a full enumeration of active resources, their regions, their tags, and their relationships to one another.
- Architecture artifacts: diagrams, deployment documentation, and any infrastructure-as-code templates your team can share. These help us understand intended architecture versus actual state.
We use a combination of automated methods and manual queries to pull this data. Automated collection ensures broad coverage across hundreds of configuration points. Manual queries fill in what automation misses: conditional policies, resource relationships, and context that only appears when you look at how services connect to one another.
The collected evidence is a point-in-time snapshot of the environment. We retain it for the duration of the engagement and reference it directly in findings, so every issue we report can be traced back to a specific configuration, policy, or resource state.
The evidence-gathering phase typically takes one to two days, depending on the number of accounts and the responsiveness of access requests.
Phase 3: Testing and Validation
This is where the assessment does its real work. We take the evidence collected in Phase 2 and subject it to over 200 automated checks and structured manual review, then validate the actual impact of anything that surfaces.
Our automated methods cover the full breadth of the environment in a systematic pass. These checks examine IAM policies, network exposure, encryption settings, logging coverage, resource configurations, and dozens of other controls across every in-scope account. Automation ensures nothing is skipped. A human reviewer might focus on what looks interesting, but the automated pass treats every resource equally. Each check maps to one or more framework controls (CIS Benchmarks, NIST, or CSA CCM), so the results feed directly into compliance reporting.
Automation catches misconfigurations. It does not catch architectural gaps, overly complex permission chains, or the difference between a configuration that is technically compliant and one that is genuinely secure. Manual review fills that gap. Our consultants examine four areas in depth:
IAM analysis. We trace permission chains from users and roles through group memberships, inline policies, managed policies, and resource-based policies. The goal is to answer a practical question: who can do what, and is that intentional? We look for overly permissive roles, unused credentials, cross-account trust relationships that widen the blast radius, and privilege-escalation paths that an attacker could chain together.
Public surface detection. We identify every resource that is reachable from the internet: public storage buckets, open security groups, exposed management ports, misconfigured load balancers, and cloud functions with public endpoints. We then assess whether that exposure is intentional, documented, and adequately protected.
Configuration review. Beyond the automated checks, we review configurations that require human judgment: logging completeness, backup and retention policies, infrastructure-as-code drift, container image provenance, and whether the deployment pipeline itself is protected from tampering.
Risk analysis. We assess not just whether a misconfiguration exists, but what an attacker could do with it. This is where findings move from a list of issues to a picture of actual risk. We construct theoretical attack paths, sequences of findings that, taken together, could allow an attacker to escalate from an initial foothold to sensitive data or administrative control. For example, an overly permissive IAM role combined with a public-facing service and insufficient logging might allow lateral movement that goes undetected. These attack paths appear in the final report as an Attack Path Summary, giving your leadership team a concrete narrative of what could happen rather than an abstract severity score.
Not every automated flag is a real issue. A security group that allows inbound traffic on port 443 might be exactly what a public-facing load balancer requires. A policy that grants broad read access might be intentional in a data-analytics account. Before anything enters the findings list, we validate it against the business context established in Phase 1 and the architecture artifacts collected in Phase 2. Validation answers three questions:
- Is the condition real? (Not a false positive or an expected configuration.)
- Is it exploitable? (Could an attacker use it, or does a compensating control reduce the risk?)
- What is the business impact? (What data, systems, or operations are at stake?)
Only issues that survive validation proceed to Phase 4. This step is what separates a useful assessment from standard scanner only output. Your team receives a report of genuine risks and not a list of alerts to triage themselves.
The testing and validation phase is the longest, typically taking three to five days for a single-account engagement. For multi-account environments, we run automated checks in parallel and prioritize manual review based on the criticality rankings established during scoping.
Phase 4: Findings and Severity
Every validated issue is documented as a formal finding with a consistent structure. This phase transforms raw test results into a report your teams can act on.
Each finding receives one of four severity ratings:
Severity is assigned based on the exploitability, business impact, and compensating controls identified during validation, not on a generic formula. A misconfiguration that would be High in a production account handling payment data might be Low in an isolated sandbox with no sensitive resources.
Each finding in the report follows a standard format so that readers, whether they are engineers, managers, or auditors, find the information they need in the same place every time:
- Finding title and category: a short name and the domain it belongs to (e.g., Broken Authentication, Network, Encryption, Misconfiguration, Data Exposure).
- Severity rating: High, Medium, Low, or Informational.
- Description: what the issue is and where it exists.
- Affected resources: the specific accounts, services, and resources involved, enumerated individually.
- Impact: what could happen if the issue is exploited or left unresolved.
- Recommendation: a specific remediation action tied to the affected resources, not a generic best-practice statement.
- References: links to provider documentation, framework controls, or CIS Benchmark sections.
Beyond the individual findings, the report includes an Analysis section that explains the results in context. This section contains two components that give leadership a view beyond the finding list:
- High Risk Overview: a brief narrative for each high-severity finding, summarizing the issue and its potential impact in one or two sentences. This allows a senior stakeholder to understand the most urgent risks without reading every technical detail.
- Attack Path Summary: a theoretical attack scenario constructed from the combination of findings. It traces how an attacker could move through the environment, chaining one weakness into another, and identifies the findings that enable each step. The attack path makes the relationship between individual findings concrete and helps prioritize remediation based on which issues create the most dangerous chains.
The full list of affected resources for each finding is provided in a companion spreadsheet delivered alongside the main report. This format lets your teams filter, sort, and import the data into ticketing systems or risk platforms without copying from a PDF.
Phase 5: Remediation and Retest
A report that sits in someone’s inbox does not reduce risk. The final phase ensures findings move from documentation to resolution.
Once the report is delivered, we walk through it with your team, typically in a findings review session that includes both technical staff and the stakeholders identified during scoping. During this session, we assign an owner to every finding, agree on a remediation timeline, and record any approved exceptions. An exception is not a dismissal: it documents a conscious decision to accept a risk, the business justification behind it, and the conditions under which it should be revisited.
Our consultants are available during the remediation window to answer questions, clarify recommendations, and review proposed fixes before they are implemented. If a remediation introduces trade-offs (for example, tightening an IAM policy that a production workflow depends on), we help your team evaluate the options rather than leaving them to sort it out from the report alone.
When your team has addressed a set of findings, we retest. Retesting is not a checkbox exercise. We verify the underlying condition, not just whether a ticket was closed or a setting was changed. If a finding was "overly permissive network access," we confirm that the security group rules now restrict traffic to the intended ports and sources, not merely that someone edited the rule.
Retest results include a remediation status for every finding from the previous assessment (remediated, partially remediated, or not remediated) so your team has a clear picture of progress. For organizations on a quarterly testing cadence, this tracking is particularly valuable: each cycle shows what improved, what remains, and where new risks have appeared.
Many clients move to a quarterly assessment cycle after the initial engagement. Each subsequent assessment uses the prior report as a baseline, so your risk posture becomes a measured trend rather than a one-time snapshot. The method stays the same (Scope, Evidence Gathering, Testing and Validation, Findings and Severity, Remediation and Retest), but subsequent passes are faster because the scoping context and stakeholder relationships are already established.
What You Receive
Every engagement produces two deliverables designed to serve different audiences, from the engineer remediating a finding to the executive reporting to the board.
Assessment report. The main deliverable. It contains the executive summary, findings overview, each individual finding with severity, description, affected resources, impact, and recommendation, and the Analysis section with the High Risk Overview and Attack Path Summary. A senior stakeholder can read the first few pages and understand the risk posture; the engineering team can jump to any finding and know exactly what to fix.
Resource spreadsheet. A companion Excel file listing every affected resource across all findings, filterable by severity, category, account, and region, built for import into your ticketing system, risk register, or compliance platform.
Framework Alignment
The CSP Cloud Assessment Method maps findings to the compliance and risk frameworks your organization already follows. This means a single assessment produces results you can use for both security improvement and audit preparation, without running separate reviews for each framework.
Where applicable, we extend mappings to these frameworks at the domain level, so findings can inform broader audit and compliance activities.
The framework mapping is included in the assessment report and in the companion data exports. If your organization follows a framework not listed here, we can adjust the mapping during the scoping phase.
How the Method Changes by Provider
The five phases stay the same regardless of cloud provider. What changes is the services we examine, the evidence sources we pull from, and the provider-specific configuration patterns we test for.
Amazon Web Services. AWS assessments emphasize IAM policy complexity (inline, managed, resource-based, and SCPs), S3 bucket exposure, CloudTrail and Config coverage, and the security posture of services like Lambda, ECS, and EKS. We pull evidence from AWS Config, Security Hub, and CloudTrail, and validate findings against AWS-specific CIS Benchmarks.
Microsoft Azure. Azure engagements focus on Entra ID (formerly Azure AD) configuration, role-based access control across management groups and subscriptions, network security group rules, and Azure Policy compliance. Evidence sources include Defender for Cloud, Azure Policy, and Activity Logs. Conditional access policies and PIM configurations receive close attention.
Google Cloud. Google Cloud assessments examine IAM bindings at the organization, folder, and project level, VPC firewall rules, Cloud Audit Logs coverage, and the configuration of services like GKE, Cloud Functions, and BigQuery. We pull data from Security Command Center, Cloud Asset Inventory, and Cloud Audit Logs.
Kubernetes. For organizations running managed Kubernetes (EKS, AKS, or GKE), we extend the assessment to cover cluster-level RBAC, network policies, pod security standards, container image provenance, and secrets management. Kubernetes findings appear alongside cloud-level findings in the same report, linked to the cluster and namespace where they apply.
How This Compares
Most organizations weigh three options for evaluating cloud security posture. The table below shows where the CSP Cloud Assessment Method sits.
A scanner tells you what is misconfigured. An audit tells you what does not meet a standard. Our method tells you what actually puts your environment at risk, and how to fix it.
Frequently Asked Questions
How long does an assessment take? A focused single-account review typically completes within two weeks from kickoff to report delivery. Multi-account or multi-cloud engagements take longer, usually three to four weeks, mainly due to cross-team coordination and access provisioning rather than additional testing. We confirm the timeline during the scoping phase so there are no surprises.
Do you need write access to our environment? No. Evidence gathering and testing use read-only credentials. We examine the environment without modifying it. The specific permissions we request are documented in the scoping record, so your team can audit exactly what was accessed during the engagement.
What happens if you find a critical issue mid-assessment? If we identify a finding that poses an immediate risk (for example, publicly exposed credentials or an open administrative interface), we notify your designated contact straight away rather than waiting for the final report. Early notification gives your team the chance to act before the assessment concludes.
How is this different from a penetration test? A penetration test asks whether an attacker can exploit a specific weakness to achieve a defined objective. A cloud security assessment examines the broader environment: configuration, access controls, logging, encryption, and architecture. The two are complementary. Many clients run both. The assessment identifies the issues, and a follow-up penetration test confirms whether the highest-risk findings are exploitable in practice.
Can we test multiple cloud providers in a single engagement? Yes. The CSP Cloud Assessment Method applies across AWS, Azure, and Google Cloud. Multi-cloud engagements follow the same five phases, with provider-specific checks and evidence sources layered in during the testing phase. Findings from all providers appear in a single consolidated report, making it straightforward to compare posture across your estate.
How often should we run an assessment? We recommend quarterly assessments for production environments. Cloud infrastructure changes frequently: new services are deployed, IAM policies are updated, and configurations drift. A quarterly cadence catches new risks early and tracks whether previous findings have been resolved. Each subsequent assessment builds on the prior baseline, so the process becomes faster and the differential reports become more valuable over time.
Start a Conversation
If you want to understand the real security posture of your cloud environment, not a score, not a checkbox, but a clear picture of what is at risk and how to fix it, we should talk. Reach out to schedule a scoping call and see how the CSP Cloud Assessment Method applies to your environment.
Book a Scoping Call → View our pricing → Get an Instant Estimate → or just say hi
About the Author
Michael McCabe founded Cloud Security Partners in 2017 to create and implement security solutions for a select number of clients.
Stay in the loop.
Subscribe for the latest in AI, Security, Cloud, and more—straight to your inbox.
