Cloud Security Assessment: Scoping Cloud Work Without Overselling It

Ask four vendors for a cloud security assessment and you'll get four different scopes at four different prices, and at least one of them is a config export with a cover page on it. MSP Pentesting builds these for MSPs under your brand, channel-only, and the first ten minutes of every scoping call go to working out which of the four the client actually needs. A cloud security assessment is a bounded review of identity, configuration, data exposure and logging inside accounts your client controls. It isn't a pentest. It isn't an audit. And it can't touch the provider.

Most of the margin on these engagements gets lost at scoping, not at delivery.

So let's draw the edges properly.

What a cloud security assessment actually covers

Four things. Identity, configuration, data exposure, and whether anybody would notice an attack happening.

Identity and access

This is where the findings live. Standing administrative access nobody revoked. Cross-account trust policies that let a sandbox assume a role in production. Service principals and workload identities that got permissions once for a migration and never got trimmed. Conditional access policies with an exclusion group that quietly swallowed half the user base.

If the client only has budget for one part, buy this one.

Configuration against a named benchmark

Name the benchmark in the report or the report is just an opinion. The CIS Foundations Benchmarks exist for AWS, Azure and Google Cloud, they're free, and they give the client something concrete to argue with. Every finding should say which control it maps to and which version you used.

"Best practice" isn't a benchmark. It's a shrug in a PDF.

Data exposure

Public object storage, snapshots shared beyond the account, unencrypted volumes holding regulated data, secrets sitting in instance user data or environment variables, and long-lived access keys still attached to somebody who left two years ago.

Logging and detection coverage

Whether the control plane gets logged at all, whether those logs leave the account, and whether anything reads them. CloudTrail in every region, Azure activity logs plus diagnostic settings on the resources that matter, Google Cloud audit logs with data access logging enabled where it counts.

A tenant with clean config and no logs is one bad morning away from an investigation nobody can run.

What it doesn't cover, and say this out loud

The provider. AWS is explicit that customers may not run security assessments against AWS infrastructure or the AWS services themselves. Azure and Google draw the same line. You're testing your client's configuration of the platform, never the platform.

Exploitation. An assessment reads state. A pentest tries the path. If the client wants to know whether that over-permissioned role can genuinely be chained into production data, that's a scoped cloud pentest and it prices differently.

SaaS. Microsoft 365, Google Workspace, Salesforce and Okta are a different control plane, with different APIs and usually a different owner inside the client. That work belongs in a SaaS security posture review, not in a cloud assessment. Folding it in for free is how you donate a week you never quoted.

The application. A web app running in a container on EKS is still a web app. Its authentication logic, its injection flaws and its business logic need application testing against something like the OWASP Top 10.

An audit opinion. Nobody passes or fails a cloud security assessment. It produces findings and evidence. Auditors like that evidence. It still isn't a certificate.

Continuity. It's a point in time, and cloud drifts by the hour.

Where scope gets oversold

Five patterns, and we see all five most quarters.

Pricing off resource count. A client with 900 instances in one account is a smaller job than a client with 40 instances spread across 14 accounts and three organizations. Count accounts, subscriptions and projects. Then count identities. Resource totals barely move the number.

Scoping production only. Production usually isn't the problem. The dev account with a cross-account role into production is the problem, and it's the one that got cut to hit a price.

Calling the tenant "the cloud." Plenty of MSPs who ask us for a cloud assessment mean their client's Microsoft 365 tenant. That's a good engagement. It isn't this one, and quoting one while delivering the other burns the whole margin.

Promising a framework outcome. An assessment produces evidence a SOC 2 or ISO 27001 auditor will accept as input. It doesn't satisfy a control on its own, and no honest vendor says otherwise.

Selling continuous coverage nobody's staffing. If no named human is reading findings next month, don't sell the monthly.

The shared responsibility line, in plain terms

What you're allowed to assess moves with the service model, and clients don't intuit this at all.

Walk a client down that table and half the scoping argument disappears.

What each provider lets you do

These are published policies and they change, so read them the week you scope, not the week you sold it.

AWS lets customers test a published list of permitted services without prior approval, covering EC2, RDS, CloudFront, API Gateway, Lambda, ECS, Fargate and others. Command and control activity needs approval first. Denial of service simulation sits under a separate DDoS simulation testing policy. DNS zone walking through Route 53 is prohibited outright, and so is anything aimed at AWS itself.

Microsoft dropped the notification requirement years ago. You test Azure resources you own under the Microsoft Cloud Unified Penetration Testing Rules of Engagement, and third parties like you need explicit written authorization from the resource owner.

Google Cloud doesn't ask you to contact them either, as long as the testing stays inside your own projects and complies with the Acceptable Use Policy and the terms of service.

That written authorization line matters more to an MSP than to anyone else. You administer the tenant, so you can produce the document in an afternoon. You're also not independent, which is the other half of this conversation.

How to scope it so it holds margin

Get five numbers before you quote. Accounts, subscriptions or projects. Human identities. Non-human identities, which is usually the number that surprises everyone in the room. Regions actually in use. And how many workloads the client wants path-tested rather than reviewed.

Then ask the question that saves the engagement. Who holds the credentials, and can they issue read-only access in week one?

Delayed access is what turns a two week job into a six week one. Put the access date in the statement of work and start the clock there.

What the deliverable has to contain

The report is the product. A cloud assessment that hands over a spreadsheet of benchmark failures is a scan with better formatting, and your client's board will treat it that way.

Four things separate a report people act on from one that gets filed.

Findings tied to blast radius. Not "IAM policy uses a wildcard." Instead, this identity can read every object in the bucket holding customer records, here's the policy, here's the path, here's the evidence.

A remediation order somebody can follow. Sequenced by risk reduction per hour of effort, because the client's cloud engineer has a sprint, not a mandate.

Evidence an auditor accepts. Dated, method described, tester named, scope stated, and a clear line between what was reviewed and what was tested. If you want a structure to copy, our pentest report template shows the sections that survive an audit conversation.

A retest position. What gets retested, when, and at what cost. Findings without a retest date are wishes.

Where cloud security posture management fits

Cloud security posture management is the continuous version of the configuration half of this work. A CSPM platform watches for drift between assessments and catches the storage bucket somebody opened on a Tuesday. It's a decent recurring product and it pairs well with a periodic assessment.

It carries the same blind spot every scanner carries. It reports state, not consequence. It'll tell you a role is over-permissioned. It won't tell you that role is reachable from an internet-facing function, which is the finding a client actually acts on.

Sell the tool for coverage. Sell the assessment for judgment. When a client's footprint is heavily on one platform, the natural follow-on is AWS penetration testing scoped to the accounts that matter.

Questions MSPs ask about cloud security assessments

How long does a cloud security assessment take for a three-account tenant?

For a single organization with three or four accounts, plan two to three weeks from access to draft. Multi-account estates with federated identity run longer. The variable is almost never tooling. It's how long the client takes to issue read-only credentials.

Do we need written permission if we already administer the tenant?

Yes, and name the accounts and the window in it. Administrative access isn't authorization. Microsoft's rules of engagement specifically require third party testers to hold written authorization from the resource owner, and your own liability position wants the same page on file.

Can we run a CSPM tool and call it an assessment?

You can run one and hand over the output. Clients work out what happened fairly quickly, because tool output ranks everything by generic severity and has no idea which of the 400 medium findings sits next to customer data. The judgment is the product.

What about Kubernetes?

Cluster configuration, RBAC and workload identity mapping belong in a cloud assessment. Container escape work and attacks against what's running inside the pods are a separate scope with a separate price. Say which one you're selling before the kickoff call.

Does this help at cyber insurance renewal?

It helps you answer the application honestly, and that's the part that matters. Carriers ask about MFA coverage, privileged access and logging. An assessment gives your client documented answers instead of guesses, and nobody should be guessing on an insurance application.

Start with the account list

Pick the client whose cloud bill grew fastest last year and ask for the account list. If that takes more than a day to produce, you've already found the first finding.

Scope identity and configuration first. One benchmark, named accounts, a fixed window. Prove the value, then have the conversation about path testing.

The report has to carry the client's auditor over the line without a second vendor name on it. That's what white-labeled pentesting delivered under your logo is built for. Bring the account count and the benchmark you want measured against, then get a pentest quote.