Cloud Security Assessment: What It Is and Who Needs One
By Yonatan Hoorizadeh, CISSP, CISM, CRISC, AAISM
Published By: Purple Shield Security
A cloud security assessment is a structured review of how your cloud environments are configured, who has access to them, and what an attacker could reach with one stolen credential. It covers infrastructure such as AWS and Azure, productivity platforms such as Microsoft 365, and the identity layer connecting them. The output is a prioritized remediation plan, not a scan report.
What is a cloud security assessment?
A cloud security assessment is an independent review of the security configuration, identity controls, logging, and data exposure across the cloud services a business actually runs. Unlike a one-time scan, it measures configuration against a named baseline, tests whether the controls a company believes it has are enforced in practice, and ranks findings by what an attacker could realistically do with each one.
The scope question matters more than the methodology question, and it is where most engagements go wrong. Most businesses run three distinct clouds while thinking of only one as "the cloud."
Infrastructure. AWS, Microsoft Azure, Google Cloud Platform. Where engineering builds and where servers, storage, and databases live.
Productivity and SaaS. Microsoft 365 or Google Workspace, plus Salesforce, Dropbox, HubSpot, a payroll platform, an e-signature tool. Where the business itself actually operates.
Identity and integration. Microsoft Entra ID, Okta, single sign-on, OAuth tokens, service principals, API keys. The layer that connects the first two, and the layer nobody clearly owns.
That third layer is where most assessments are thin and where a growing share of incidents actually begins. It is also the part a scanner cannot see well, because a stolen token used by a trusted application looks exactly like the trusted application doing its job.
There is a practical consequence here for smaller organizations. A 40-person law firm or medical practice usually has no AWS account at all. Its entire cloud footprint is Microsoft 365 plus five SaaS tools. An assessment scoped like an enterprise infrastructure review will produce a polished report about a footprint that does not exist, and miss the tenant where every contract and patient record actually sits.
How it differs from a pen test, a vulnerability scan, and a SOC 2 audit
These four exercises answer different questions and are routinely sold as substitutes for one another. They are not.
Vulnerability scan: what software is unpatched or running a known vulnerable version?
Penetration test: can a specific attack path be exploited within a fixed testing window?
SOC 2 or HIPAA audit: can you produce evidence that a control existed and operated over a period of time?
Cloud security assessment: does the configuration of your cloud tenants and accounts match a defensible baseline, and how far does the damage spread when one credential fails?
A clean SOC 2 report and a wide-open third-party app consent policy coexist very comfortably. The audit asks whether you followed your own stated process. The assessment asks whether that process left your data reachable.
Why do cloud breaches keep happening when AWS and Microsoft are secure?
Because the provider secures the platform and the customer secures the configuration, and attackers work on the configuration. AWS and Microsoft harden the facility, the hypervisor, and the service itself. Access policy, MFA coverage, sharing defaults, logging retention, and third-party application permissions belong to the customer. Gartner has projected for years that nearly all cloud security failures would trace to customer-side error rather than provider failure.
The Verizon 2026 Data Breach Investigations Report gives that shape some hard edges. Exploitation of software vulnerabilities became the leading initial access vector this year at 31% of breaches, up from roughly 20% in the prior dataset. Breaches involving a third party reached 48%, an increase of about 60% year over year.
The cloud-specific numbers in the same report are the uncomfortable ones. According to the 2026 DBIR, 37% of organizations had at least one administrative account with multi-factor authentication disabled on an infrastructure-as-a-service platform. Only 23% of third-party organizations had fully remediated missing or improperly secured MFA on cloud accounts. For weak passwords and permission misconfigurations in third-party cloud environments, the time to resolve half of all findings was close to eight months.
That eight-month figure is the one worth sitting with, because it is not a detection failure. Somebody already found those issues. They were written down. They sat in a report with no named owner and no due date, which is the single most common way a cloud security assessment produces no security at all.
The Salesloft Drift incident of August 2025 shows what the identity layer failure looks like in practice. Between August 8 and 18, a threat actor tracked by Google Threat Intelligence Group as UNC6395 used OAuth tokens stolen from the Drift chatbot integration to query Salesforce environments at more than 700 organizations, pulling credentials and case data out of them. Salesforce was not breached. Customer passwords were not cracked. A trusted third-party application held broad, persistent, delegated access, and its vendor got compromised. No endpoint tool and no password policy was ever going to catch that. A review of which applications hold standing permission to read your data would have.
What does a Microsoft 365 security assessment actually check?
A Microsoft 365 security assessment reviews tenant configuration across Microsoft Entra ID, Exchange Online, SharePoint, OneDrive, Teams, and Defender against a documented baseline. The recurring findings are remarkably consistent from tenant to tenant: legacy authentication left enabled, Conditional Access policies with old exclusions, permissive OAuth application consent, too many standing Global Administrators, application secrets with no expiry, and audit logging nobody turned on.
In practical terms, a competent reviewer is answering questions like these:
How many accounts hold Global Administrator standing, and is every one of them on phishing-resistant MFA?
Can an ordinary user consent to a third-party application reading their mail, files, and calendar without an administrator approving it?
Which enterprise applications hold broad Microsoft Graph permissions, who inside the business owns each one, and are any of them from unverified publishers?
Which service accounts and integrations were excluded from Conditional Access "temporarily" and never put back?
What are the external sharing defaults in SharePoint and OneDrive, and what do they mean for documents shared five years ago?
Does unified audit logging cover the window an investigation would actually need?
There is a free, authoritative baseline for this that almost no small business has heard of. CISA runs the Secure Cloud Business Applications project, known as SCuBA, which publishes secure configuration baselines for Microsoft 365 and Google Workspace. CISA built it after the SolarWinds compromise exposed how little visibility organizations had into their own cloud tenants. The Microsoft 365 baselines run to more than 200 policies across seven products, and CISA also ships ScubaGear, which it describes as "a no-cost assessment tool" that compares a tenant against those baselines and produces an as-is report.
Two things follow from that, and they are the parts most vendor content leaves out. First, if a firm quotes you for a Microsoft 365 review and cannot tell you whether they assess against SCuBA, CIS Microsoft 365 Foundations Benchmark, or something proprietary, they are selling you an opinion rather than a measurement. Second, a strong Microsoft Secure Score is not the same thing as a secure tenant. Secure Score largely measures adoption of Microsoft security features. A tenant can score well and still be exposed through an OAuth consent phishing attack or an inherited Conditional Access exclusion, because Secure Score was never designed to evaluate either.
What does an AWS or Azure cloud security assessment cover?
An AWS cloud security assessment is identity-first, because most AWS incidents trace back to a credential that carried more permission than it needed. The core review covers IAM users, roles, and policies; root account protection; long-lived access keys; storage exposure; CloudTrail coverage across all regions; network segmentation; and whether Service Control Policies bound what any single account is capable of doing.
The concrete checks that produce most of the value:
Root account: MFA enforced, access keys deleted entirely, credentials stored somewhere a departing engineer cannot reach.
Human access through AWS IAM Identity Center or federated single sign-on rather than standing IAM users holding permanent access keys.
IAM Access Analyzer enabled at the organization level, including its unused-access findings, which surface roles and policies holding permissions nobody has actually exercised.
CloudTrail enabled in every region, including the ones your business never uses. Empty regions are attractive precisely because nobody is watching them.
Storage exposure: which buckets and shares are reachable from outside the organization, and whether that was ever a deliberate decision.
A named baseline. The CIS AWS Foundations Benchmark and the security pillar of the AWS Well-Architected Framework are the two most defensible starting points.
The finding that shows up in almost every multi-account estate is the account nobody owns. A sandbox from a project that ended two years ago, still billing, still holding a role that can be assumed from outside the organization, still invisible to security tooling that only ever got deployed into production. A useful test costs nothing: ask for the name of the human being responsible for each AWS account. Every shrug is a finding.
Azure and Google Cloud follow the same identity-first logic, but Azure carries a wrinkle that matters for any Microsoft 365 business. Entra ID is the same directory for both. Compromise a Global Administrator and the attacker may not simply have email and files. They may have the subscription that runs your production systems. Assessing the two in isolation misses the connection between them, which is exactly why scope is worth negotiating before price.
Who needs a cloud security assessment?
Company size predicts far less than trigger events. The businesses that most need a cloud security assessment are the ones approaching a moment when somebody outside the company is about to inspect their controls: an insurance renewal, an audit, a diligence process, a customer security questionnaire, or a breach notification from a vendor. Headcount mostly determines scope and cost, not urgency.
The triggers worth acting on:
A cyber insurance application or renewal. Carriers have moved away from taking attestation at face value. Many now run their own external scans before binding and verify controls after a claim.
SOC 2, HIPAA, PCI DSS, CMMC, or state privacy obligations. For HIPAA-covered entities, the required Security Rule risk analysis includes cloud systems whether or not the assessment you were sold happens to look at them.
An acquisition, on either side of it. Buyers inherit the seller's tenant, its admin accounts, and its integrations. Sellers who cannot answer configuration questions quickly lose negotiating room in diligence.
A completed cloud migration. Migration projects optimize for cutover, not for cleanup. The temporary permissions and open paths that made the migration work are almost never revisited afterward.
Changing, adding, or firing an IT provider. Both an exit review and an onboarding baseline are far cheaper than discovering nine months later what was left behind.
A vendor breach notification. If a SaaS vendor tells you they were compromised, the first question is what their integration was permitted to read in your environment.
Rolling out AI tools. Copilot and similar assistants inherit the permissions that already exist. Documents that were technically overshared but practically buried become instantly searchable by every employee who has access.
It is worth naming who probably does not need one right now. A five-person business on Microsoft 365 Business Basic, with MFA on every account, no third-party integrations, and no regulated data, is better served by running the free tooling, verifying its backups, and spending the money elsewhere. A cloud security consultant who cannot tell you that is not assessing your risk, they are selling an engagement.
What are the benefits of a cloud security assessment?
The practical benefit is a defensible answer to questions a business would otherwise have to guess at: whether the MFA it attested to on an insurance form is genuinely enforced everywhere, what one compromised account actually reaches, and which of forty cloud risks is worth money this quarter. A good assessment converts opinion into evidence, and evidence is what every other party in the chain now demands.
Where that evidence pays for itself:
Insurance accuracy. This is the most underrated financial benefit and the easiest to quantify. In the widely reported dispute between Travelers and International Control Services, the insured stated on its application that MFA protected administrative and privileged access. In reality it covered the firewall and not the systems the attackers used. The carrier moved to rescind the policy and the court sided with the insurer. The misrepresentation did not have to cause the loss for coverage to disappear.
Audit and questionnaire evidence. A configuration review mapped to NIST CSF 2.0 or CIS Controls answers most of a customer security questionnaire without a scramble.
Blast radius reduction. Least privilege is difficult to sell as a project and easy to justify once someone shows what a single admin account currently reaches.
Faster incident response. Logging is only useful if it was already on. The gap between a two-day investigation and a six-week one is usually a retention setting decided years earlier.
Budget defensibility. A ranked list of findings with cost and effort attached is a far better basis for a board conversation than a vendor quote.
One caution belongs here, because it is the benefit most assessments fail to deliver. A report that arrives as a PDF, gets circulated to three people, and is never assigned changes nothing at all. The value of a cloud security assessment is not the document. It is the remediation plan attached to it, with a named owner and a date on every finding, and a scheduled re-check to confirm the fixes actually held. Configuration drifts back. Ask any provider how they handle that before you ask what they charge.
How much does a cloud security assessment cost?
Most cloud security assessments for small and mid-market businesses land between roughly $2,000 and $40,000, driven by scope rather than headcount. A Microsoft 365 tenant review sits at the low end. A multi-account AWS estate reviewed against a named benchmark, with staff interviews and a compliance mapping attached, sits at the high end. Published market figures are consistent enough to budget against.
Several 2026 pricing analyses converge on similar ranges. Atlant Security puts a standard assessment covering cloud services such as AWS, Microsoft 365, or Google Workspace alongside a NIST 800-53 review for a roughly 100-person company at about $15,000. IBSSCORP reports that organizations under 50 employees can complete basic security assessments for under $10,000, while formal compliance audits typically start around $15,000 and climb toward $40,000. For larger mid-market organizations, Cleared Systems budgets $25,000 to $75,000 for companies of 100 to 500 employees with hybrid cloud environments and complex regulatory scope. Cloud penetration testing is priced separately, commonly $5,000 to $35,000 per Blaze Infosec's 2026 buyer guide.
What actually moves the number: how many tenants and cloud accounts are in scope, whether compliance mapping is included, whether the deliverable stops at a report or continues into remediation support, and whether a human being reviews the environment or a scanner does.
Two pricing signals are worth treating as warnings. A quote well under $3,000 for a "complete cloud security assessment" is almost always an automated scan with a cover page on it. And any quote that arrives before anyone has asked how many tenants and accounts you run is a price for a template, not for your environment.
How do you choose the right cloud security consultant?
Start with independence. The most common structural failure in this market is asking the people who built and manage an environment to grade their own work. A cloud security consultant should hold no financial interest in the tools you buy, no managed services contract on the environment under review, and no referral fee waiting on the other side of a recommendation. Everything else is secondary to that.
The independence test
If your IT provider configured your Microsoft 365 tenant, their assessment of that tenant is a self-review. This is not usually about dishonesty. It is that almost nobody writes "the Conditional Access exclusion we added in 2021 is now the largest single risk in this environment" about a decision they made themselves. The same logic applies to a security vendor offering a free cloud security assessment that concludes, after careful analysis, that you should buy their platform. Ask three direct questions: do you resell or earn commission on any product you might recommend, do you currently manage any part of what you would be assessing, and does your compensation change based on what I decide to buy.
The scope test
Ask what they will cover before they quote a price. If the entire conversation is about AWS and Kubernetes while your business runs on Microsoft 365 and three SaaS tools, you are being sold a standard engagement rather than an assessment of your environment. A firm offering cloud security assessment services across both infrastructure and productivity platforms should be able to describe, in specific terms, what it checks in each and which baseline it uses.
The output test
Ask to see a redacted deliverable from a prior engagement before you sign anything. What you want to see is findings written in business language, each with a named owner, a due date, an effort estimate, and a plain explanation of the consequence if it is left alone. What you do not want is a 180-page tool export sorted by severity score, or a maturity rating with no path attached to it. If the sample deliverable is a dashboard screenshot, the engagement is a product trial.
The evidence test
Ask how they verify a control rather than accept an answer about it. "Do you have MFA everywhere" is a question. Reviewing sign-in logs for every account holding an administrative role over the past 30 days is verification. Underwriters have already made this shift from attestation to evidence. Anyone assessing your environment should be at least that rigorous, because the gap between what a company believes is deployed and what is actually enforced is where nearly all of this lives.
Who actually does the work
Ask which named person will be in your tenant and what they have run operationally. Certifications such as CISSP, CISM, CCSP, and cloud-specific credentials tell you someone has been tested. Prior responsibility for a security program tells you they have had to make the tradeoffs you are about to make. Many firms sell with a senior name and deliver with a junior analyst running a script. This is the practical argument for fractional CISO services rather than a one-off project vendor: the person interpreting the findings should be capable of telling you which three of forty items matter this quarter and which twenty can wait, and then standing behind that judgment.
Purple Shield Security operates as a vendor-neutral cloud security consultant for exactly these reasons. No product resale, no managed services contract on the environments we review, and no referral fees on anything we recommend. Whether that describes us or someone else you are evaluating, the structure is worth confirming in writing before an engagement starts.
Five questions worth asking before you sign
Do you sell, resell, or take referral fees on any product you might recommend to us?
Do you currently manage any part of the environment you would be assessing?
Which baseline will you assess against, by name, for each platform in scope?
Who specifically will do the work, and what have they been responsible for operationally?
What does the deliverable look like, and does every finding carry an owner and a date?
Frequently asked questions
Is a cloud security assessment the same as a penetration test?
No. A penetration test asks whether a specific attack path can be exploited within a fixed window. A cloud security assessment asks whether your tenant and account configuration matches a defensible baseline and how far a single compromised credential reaches. Most mid-market businesses get more value from the assessment first, because a penetration test against an environment with unresolved configuration issues largely confirms what a configuration review would have surfaced faster and cheaper.
How often should a cloud security assessment be repeated?
Annually as a floor, plus after any material change: a migration, an acquisition, a change of IT provider, a new SaaS integration with broad permissions, or a vendor breach notification. Configuration drift is the reason. The Verizon 2026 DBIR found that weak passwords and permission misconfigurations in third-party cloud environments took close to eight months to reach 50% resolution, which means an annual snapshot on its own leaves a long unmonitored window between checks.
Does my cyber insurance carrier require a cloud security assessment?
Most carriers do not require the assessment itself. They require accurate answers about MFA coverage, endpoint detection, and backup immutability, and many now run their own external scans against your perimeter before binding. Two practical points follow. Start verification 60 to 90 days before the renewal date rather than the week of, because brokers can usually negotiate a cure period for a disclosed gap but not for a discovered one. And treat "we have MFA" as a claim to be tested rather than a fact, since the questionnaire wording almost always joins email, VPN, and remote access with the word "and."
Can my MSP or IT provider do the cloud security assessment?
They can run the tooling, and many do it competently. The structural problem is that a provider assessing an environment it configured and manages is reviewing its own work, and the findings that reflect on its own past decisions are the least likely to appear. If your provider does run the assessment, have an independent party read the report. Many mid-market businesses use vCISO services for precisely this split: an outside security leader owns the risk picture and the roadmap, while the IT provider owns operations and execution.
What is the first thing to fix after a cloud security assessment?
Almost always identity. Standing administrative accounts without phishing-resistant MFA, third-party applications holding broad permissions that nobody in the business owns, and long-lived credentials that never expire account for a disproportionate share of real incidents across both Microsoft 365 and AWS. Those fixes are usually configuration changes rather than purchases, which means they can start the week the report lands. Buy nothing new until they are done.
If your business runs on Microsoft 365, AWS, or both, and you cannot say today which accounts hold administrative access or which third-party applications are permitted to read your data, the assessment has effectively answered itself. Purple Shield Security provides independent cloud security assessment services and fractional CISO support to businesses across Los Angeles and nationally, with no product resale and no managed services contract on the environments we review. Contact us to scope the work before you spend anything on it.
