Cloud security posture assessment work sounds like an audit and usually gets treated like one, which is why so many of them end as a 200-page report that nobody acts on. It is a narrower and far more useful exercise than that: a structured review of how your cloud accounts are actually configured right now, measured against a baseline you agreed in advance, producing a ranked list of things to fix and a named person responsible for each one.
The reason cloud security posture matters is unglamorous. Most cloud incidents do not begin with a clever exploit against the provider. They begin with a storage container someone made public for a demo, an access key committed to a repository in 2023, a service account with permanent administrative rights, or logging that was switched on in one region and never in the other three. None of that is exotic. All of it is invisible until somebody deliberately goes looking, and going looking in a structured way is precisely what this checklist describes.
This guide walks the whole cloud security posture engagement in the order it should actually run. It covers scoping and access, the six technical domains worth checking, how to score what you find so the list is defensible, how to choose between native tooling and a dedicated platform, and what the work realistically costs in money and elapsed time. If you are earlier in the journey, our cloud adoption guidance and the cloud migration business case article cover the ground before this one.
One framing point before the checklist begins. Cloud security posture is not a score you achieve and keep. It decays continuously, because engineers deploy things, contractors get access, providers ship new services, and every one of those events moves the configuration away from the baseline. A cloud security posture assessment is a measurement of that drift at a moment in time, and it is only worth doing if something continuous follows it.
Table of contents
- What a cloud security posture assessment actually is
- Before you start your cloud security posture assessment
- Step 1: Identity and access, the biggest cloud security posture wins
- Step 2: Network exposure, the most visible cloud security posture gap
- Step 3: Data protection, encryption and retention
- Step 4: Logging, detection and incident readiness
- Step 5: Configuration baselines and cloud security posture drift
- Scoring your cloud security posture assessment findings
- Choosing cloud security posture tooling: native, platform or people
- What a cloud security posture assessment costs and how long it takes
- How often to reassess your cloud security posture
- Cloud security posture assessment FAQs
- References
What a cloud security posture assessment actually is
Half the disagreements in the kick-off meeting come from people using the phrase to mean four different things, so it is worth being precise about the boundaries before anyone opens a console.
It reviews configuration, not code and not patches
The subject of a cloud security posture review is the control plane: identity policies, network rules, encryption settings, logging configuration, resource-level permissions and the guardrails applied above them. It is not a code review, it is not vulnerability scanning of operating systems inside virtual machines, and it is not a test of whether your application logic can be abused. Those are separate exercises with separate skills, and conflating them is how an engagement doubles in cost while getting shallower in every direction.
The shared responsibility line defines the scope
Every provider publishes a shared responsibility model, and it is the single most useful scoping document you have. AWS, Microsoft and Google all secure the underlying infrastructure; you remain responsible for identity, data, configuration and access. Your cloud security posture lives entirely on your side of that line. If a finding sits on the provider’s side, it belongs in a vendor assurance conversation, not in your remediation backlog.
Point-in-time review versus continuous monitoring
The assessment gives you depth: a human looking at whether the configuration makes sense for your business, not just whether it matches a rule. Continuous cloud security posture monitoring gives you currency: an alert the day somebody opens a security group. You need both, and the common failure is buying the second and assuming it replaces the first. A tool will tell you a bucket is public. Only a person will tell you that the bucket being public is fine because it serves your marketing site, and that the adjacent one holding payroll exports is the actual emergency.
How it differs from an audit or a penetration test
An audit asks whether you can evidence a control to a third party. A penetration test asks whether an attacker can get in through a specific path. A cloud security posture assessment asks whether the configuration itself is defensible. They answer different questions and the outputs are not interchangeable, which matters when a customer questionnaire asks for one and somebody sends the other.
| Factor | Posture assessment | Compliance audit | Penetration test |
|---|---|---|---|
| Question answered | Is the configuration defensible? | Can we evidence the control? | Can an attacker get in? |
| Primary evidence | Console and API configuration state | Policies, records, sampled artefacts | Exploited paths and proof |
| Access needed | Read-only across all accounts | Documents and interviews | Scoped target, often unauthenticated |
| Typical duration | 1 to 3 weeks | 2 to 6 weeks | 5 to 15 days |
| Main output | Ranked findings plus remediation plan | Certificate or gap report | Exploit narrative and fixes |
| Sensible cadence | Annual, plus continuous tooling | Annual or per certification cycle | Annual or per major release |
| Best trigger | Growth, migration, new team | Customer or regulator demand | New internet-facing service |
Before you start your cloud security posture assessment
Most engagements that go badly go badly in the first three days, because the scope was assumed rather than written down and half the estate turned out to be invisible.
Build the account inventory first, and expect surprises
Ask for a list of every AWS account, Azure subscription and Google Cloud project, then verify it against the billing console rather than trusting the list. Nearly every organisation over about fifty people has at least one account nobody remembered: a proof of concept from a departed engineer, a marketing site on a personal card, a subsidiary acquired with its own tenancy. Those forgotten accounts hold a disproportionate share of the worst cloud security posture findings, precisely because nobody has looked at them.
Insist on read-only access, not screenshots
A cloud security posture assessment run from screenshots and questionnaires is guesswork. The reviewer needs a read-only role in every account, applied consistently, so that findings come from the API rather than from what someone believed to be true. This is also the moment to agree that the reviewer will not change anything, will not access customer data, and will work from a named account that gets removed on the final day.
Choose the baseline before you start counting
You cannot report a cloud security posture gap without a standard to measure against. In practice that means the CIS Benchmarks for the relevant platform, the provider’s own well-architected security guidance, and where relevant the control set behind whatever certification you hold or want. Pick these in the kick-off meeting. Choosing the baseline after the findings are in invites arguments about whether a given item is really a problem.
Write down what is deliberately out of scope
Software as a service tenancies, on-premises systems, endpoint estate, application code and third-party integrations are all commonly excluded, and all commonly assumed to be included by whoever commissioned the work. Say so explicitly. If Microsoft 365 matters to you, that is a Microsoft 365 security audit, which is a genuinely different checklist.
Agree the reporting format up front
Decide now whether the deliverable is a spreadsheet of findings, a narrative report for the board, or both. The engineering team wants a ticketable list with resource identifiers. The board wants five slides and a trend line for cloud security posture over time. Producing one and discovering the audience wanted the other wastes a week at the end, when patience is thinnest.
Step 1: Identity and access, the biggest cloud security posture wins
If you only have three days, spend all three here. Identity is the control plane of a cloud estate, and identity findings are consistently the ones that turn a minor incident into a serious one.
Root and break-glass accounts
Check that the root or global administrator account has hardware multi-factor authentication, no access keys, a monitored mailbox and an alert on every use. Check that emergency access accounts exist, are excluded from conditional access policies deliberately rather than accidentally, and are stored somewhere physically controlled. Organisations discover the gap here during the incident where they least want to.
Multi-factor authentication coverage, measured not assumed
Everybody says multi-factor authentication is enforced. A cloud security posture assessment measures it: what percentage of human identities have it registered, which policies grant exclusions, how many legacy authentication paths remain open, and whether service accounts are quietly bypassing the whole thing. The gap between the policy and the reality is usually where the finding lives.
Standing privilege and role assignments
Look for permanent Owner, Contributor or Administrator rights at the top of the hierarchy, direct assignments to named users rather than groups, wildcard actions in custom policies, and roles created for one migration and never removed. Time-bound elevation with approval turns a permanent risk into a logged event, and it is the single highest-value cloud security posture change most estates can make.
Access keys, service principals and secrets
Enumerate long-lived access keys and their age, service principals with client secrets that never expire, and credentials sitting in environment variables, pipeline definitions or repositories. Anything older than ninety days deserves a question. The OWASP secrets management guidance is the reference worth handing to the engineering team alongside the finding.
Cross-account trust and federation
Review every trust relationship into your accounts: partner roles, continuous integration systems, monitoring vendors, and any external identity that can assume a role. Check that conditions actually constrain them. A role assumable by any principal in any account is not a theoretical problem, and it is a common cloud security posture finding in estates that grew through experimentation.
Step 2: Network exposure, the most visible cloud security posture gap
The second domain answers a blunt question: what of yours can a stranger reach, and did anyone mean for that to be true?
Enumerate everything with a public address
List every public IP, load balancer, gateway, managed database with a public endpoint and function exposed to the internet, then reconcile that list against what the business believes is published. The reconciliation is the deliverable. A list of internet-facing resources is only interesting when somebody senior looks at it and says they did not know about the third one.
Management ports and administrative planes
Remote desktop and secure shell open to the whole internet remains one of the most reliably present findings in any cloud security posture review, usually on a jump host built during a migration weekend. Check the security groups and network security groups for wide inbound rules, then check whether a bastion or identity-aware proxy exists and is actually the path people use.
Object storage and blob containers
Public buckets are the canonical cloud mistake for good reason. Verify that account-level public access blocks are on, that per-container exceptions are documented, and that anonymous read has not been granted through an access control list nobody remembers writing. Then check the storage that is not public but is readable by every identity in the account, which is the quieter version of the same problem.
Segmentation and egress control
Look at whether workloads of different sensitivity share a flat network, whether private connectivity is used for provider services or traffic hairpins over the public internet, and whether outbound traffic is constrained at all. Egress filtering is frequently absent, and it is the control that turns a compromised container into a contained incident rather than an exfiltration event. Where the network design itself weakens cloud security posture, that is a cloud architecture conversation rather than a quick fix.
Step 3: Data protection, encryption and retention
Encryption findings rarely top the list on their own, but they determine how bad every other cloud security posture finding becomes if it is exploited.
Encryption at rest, and who holds the key
Almost everything is encrypted at rest by default now, so the useful question is not whether but with whose key. Provider-managed keys are appropriate for most workloads. Customer-managed keys matter where you need the ability to revoke access cryptographically or to evidence separation for a regulator. Check that key rotation is enabled and that key policies do not grant use to every identity in the account.
Encryption in transit and certificate hygiene
Check for services still accepting deprecated protocol versions, load balancer policies that permit weak ciphers, internal traffic moving unencrypted because it is “internal”, and certificates expiring inside the next ninety days with no automated renewal. The last one causes more outages than breaches, which is why it belongs in the report anyway.
Backup, immutability and recovery
A cloud security posture assessment should always test the ransomware question: can an identity that compromises the production account also delete or encrypt the backups? If the answer is yes, the backup strategy is decorative. Look for immutable storage, separate accounts or subscriptions for backup data, and evidence that a restore was tested rather than assumed. Our guide to backup, disaster recovery and high availability sets out how those three differ.
Classification, residency and retention
Confirm you know which storage holds personal data, where it physically sits, and how long it is kept. The ICO guide to data security is the reference for UK organisations, and storage limitation is the principle most often broken by cloud defaults, because nothing in a bucket expires unless somebody writes a lifecycle rule.
| Finding | Why it matters | Severity | Fix window |
|---|---|---|---|
| Storage container open to anonymous read | Direct data exposure, no attacker skill needed | Critical | Same day |
| Root account without multi-factor authentication | Total estate compromise from one credential | Critical | Same day |
| Management port open to the internet | Continuously scanned and brute forced | Critical | 72 hours |
| Access key older than one year | Long-lived credential, often in a repository | High | 30 days |
| Backups deletable by the production identity | Removes recovery from a ransomware event | High | 30 days |
| Control plane logging disabled in a region | Incident becomes uninvestigable | High | 30 days |
| Standing administrative rights for engineers | Blast radius of any phished account | High | 90 days |
| No egress filtering from workload subnets | Unconstrained exfiltration path | Medium | 90 days |
| Resources missing mandatory ownership tags | Nobody can be assigned the fix | Medium | 90 days |
| Deprecated transport protocol accepted | Weakens confidentiality in transit | Low | 180 days |
Step 4: Logging, detection and incident readiness
This domain decides whether a future incident is a two-day investigation or a three-week one with an external firm and a lawyer on the call.
Are the logs on, everywhere, and retained long enough?
Control plane audit logging should be enabled in every account and every region, delivered to a location the source account cannot delete from, and retained for a period that matches how long intrusions typically go unnoticed. Ninety days is common and usually too short. Check the regions nobody uses, because that is exactly where an attacker will operate.
Alerting that actually reaches a person
An alert routed to a shared mailbox that four people mute is not detection. Trace a handful of real alert types end to end: who receives them, what the response is meant to be, and whether anyone has responded to one in the last quarter. Where there is no in-house capacity, managed detection and response is the usual answer, and a cloud security posture report should say so plainly rather than listing an unfixable gap.
Detection coverage against realistic techniques
Rather than counting rules, map coverage against the cloud techniques adversaries actually use: credential access, persistence through new identities, disabling logging, and unusual data transfer volumes. Both major providers ship threat detection services that cover much of this without custom engineering, and finding them switched off is common enough to be worth checking first.
Can you respond inside a cloud account?
Ask the practical questions. Who can suspend a compromised identity at two in the morning? Is there a documented process to isolate a workload without deleting the evidence? Does the incident response plan mention the cloud provider at all, or was it written for a server room? Continuous monitoring without a rehearsed response is an expensive way to be told bad news.
Step 5: Configuration baselines and cloud security posture drift
The first four steps find the problems. This one decides whether they come back six months later, which is the difference between an assessment worth commissioning and one that was not.
A published benchmark makes findings defensible
Measuring cloud security posture against a recognised benchmark rather than reviewer preference changes the conversation with engineering teams. “This fails control 3.2 of the benchmark you adopted” is a discussion about scheduling. “I think this is risky” is a discussion about opinions, and it is one the reviewer usually loses.
Drift is the real adversary
Nearly every estate that was built correctly has drifted, because emergency changes get made in the console and never written back into code. Measure the gap between the declared infrastructure and the deployed reality. A large drift percentage is itself a cloud security posture finding, and often a more important one than any individual misconfiguration in the list.
Scan the templates, not only the running estate
If infrastructure is defined in code, the cheapest possible fix is catching the misconfiguration in a pull request rather than in next year’s report. Static analysis of templates belongs in the pipeline, and a review that ignores the pipeline is only measuring the symptom. This sits naturally alongside DevOps practice rather than as a separate security activity.
Guardrails beat findings
The strongest recommendation any review can make is to convert a repeated finding into a preventive control: a policy that denies public storage outright, a rule that blocks the deprecated protocol version, an organisation-level restriction on unused regions. One guardrail removes a whole class of future findings. A well-built Azure landing zone bakes much of that cloud security posture work in before the first workload arrives.
Scoring your cloud security posture assessment findings
A list of four hundred findings sorted by tool severity is not a plan. Turning it into one is the part that most distinguishes a good review from a generated report.
Rank by exploitability in your estate, not by tool label
Tools assign severity to a control, not to your situation. A public bucket containing a static logo and a public bucket containing exported invoices carry the same label and completely different consequences. Every high or critical item should be re-scored against what it actually exposes, who could reach it, and what an attacker gains next. The CVSS specification is a reasonable scaffold for the vocabulary, provided the environmental context is genuinely applied rather than left at defaults.
Deduplicate before anyone sees the number
Four hundred findings frequently means eleven problems repeated across accounts. Group by root cause, report the group, and quote the instance count inside it. A board told there are four hundred issues stops listening. A board told there are eleven, of which three need fixing this week, engages with cloud security posture as a manageable programme rather than a crisis.
Split remediation into waves with real dates
Same-day items are the ones an opportunist could exploit before the report is even circulated. Thirty-day items are serious but need a change window. Ninety and one-hundred-eighty-day items are structural, and they are where the guardrails live. Anything without a wave and a date is a wish.
Name an individual, never a team
“Platform team” is not an owner. A named engineer with the change in their backlog is an owner. This is the single most reliable predictor of whether a cloud security posture assessment produces change or produces a document, and it costs nothing to insist on it during the walkthrough.
Re-test and close the loop
Agree a re-test date at the same time as the plan, typically thirty days out for the critical wave. Findings marked resolved without verification have a habit of reappearing in the next review, and unverified closure quietly corrodes trust in the whole exercise.
| Wave | Timeframe | What belongs in it | Typical owner |
|---|---|---|---|
| Wave 0 | 24 to 72 hours | Public exposure, missing root protection, open management ports | Platform engineer on call |
| Wave 1 | 30 days | Credential rotation, logging gaps, backup isolation | Named platform engineer |
| Wave 2 | 90 days | Privilege reduction, segmentation, egress control | Platform lead with change board |
| Wave 3 | 180 days | Guardrail policies, pipeline scanning, drift remediation | Platform lead with security |
Choosing cloud security posture tooling: native, platform or people
Nobody does this entirely by hand any more, and nobody should buy a platform before understanding what the provider already gives them for nothing.
Native tooling covers more than most teams realise
Every major provider ships cloud security posture management in some form, complete with a benchmark-aligned score and remediation guidance. These are enabled with a few clicks, cost little or nothing at the basic tier, and immediately answer perhaps seventy percent of a first review. Any assessment that recommends a purchase before confirming the native services are switched on has skipped a step.
Where a dedicated platform earns its licence fee
Multi-cloud estates, container-heavy workloads, and organisations that need one queue of findings across three providers are the genuine cases for a dedicated cloud security posture platform. The features worth paying for are cross-provider normalisation, attack path analysis that chains findings into a route, and integration into the ticketing system engineers already use. The features not worth paying for are dashboards nobody opens.
Open-source scanners for a point-in-time run
For a one-off review, open-source benchmark scanners produce respectable coverage at zero licence cost, and they are the pragmatic choice for a small estate or a first look before committing budget. They lack the continuous element, which is fine, because the continuous element is what the native services are for.
The human layer no tool replaces
No scanner knows which system is revenue-critical, which exception was signed off by a director, or which finding is genuinely acceptable given a compensating control. That judgement is the deliverable. Where the capability does not exist internally, cloud security posture ownership belongs with a managed IT services partner rather than with whoever happens to have console access.
| Option | Strengths | Limits | Indicative annual cost |
|---|---|---|---|
| Native provider services | Already integrated, benchmark scoring, low friction | Single provider, shallow attack path analysis | £0 to £6,000 |
| Dedicated platform | Multi-cloud, attack paths, workflow integration | Licence cost, tuning effort, alert volume | £12,000 to £60,000 |
| Open-source scanners | No licence cost, good benchmark coverage | No continuous view, needs skilled operator | Effort only |
| Consultant-led review | Context, prioritisation, board-ready narrative | Point in time, quality varies by reviewer | £4,000 to £25,000 per review |
What a cloud security posture assessment costs and how long it takes
Budget for the review honestly, then budget separately for the remediation, because the second number is invariably larger and invariably forgotten.
Effort scales with account count, not with spend
A single-account estate spending fifty thousand pounds a month is quicker to review than a twelve-account estate spending five. Cloud security posture work is per boundary: each account has its own identity configuration, its own logging setup and its own network. Anyone quoting from your cloud bill rather than your account inventory is guessing.
What pushes the price up
Multiple providers, regulated data, container platforms, a large historical estate with no infrastructure as code, and any requirement to map findings onto a specific certification control set. Each of those adds days. A UK organisation pursuing certification will find the overlap with an ISO 27001 readiness assessment substantial, and running both together is usually cheaper than running them apart.
The remediation cost nobody budgets
The review is the cheap part. Rotating credentials, rebuilding network segmentation, introducing time-bound privilege and retrofitting logging is real engineering work, and a realistic rule of thumb is two to five times the assessment fee in internal effort over the following six months. Commissioning a cloud security posture review without reserving that capacity produces a report and no change, which is worse than not asking.
How often to reassess your cloud security posture
Cadence is where good intentions quietly expire, so decide it while the findings are still fresh and put the dates in a calendar somebody owns.
Continuous tooling plus one deep review a year
For most organisations the right pattern is native cloud security posture monitoring running permanently, a lightweight quarterly check on the critical controls, and one properly scoped deep review annually. That combination catches the drift early and still gets a human perspective on whether the whole shape of the estate still makes sense.
Events that should trigger an unscheduled review
An acquisition, a new regulated workload, a significant architecture change, the departure of the engineer who built the platform, a security incident, or a major customer contract with security terms attached. Each of those changes either the estate or the risk appetite enough to make last year’s conclusions unreliable.
Who owns the posture between reviews
Someone must own cloud security posture by name. In smaller organisations that is realistically the platform lead with support from a provider; in larger ones it belongs to a security function with a defined relationship to the engineering teams. This is fundamentally an IT governance question, and leaving it unanswered is why estates reviewed thoroughly in one year look untouched by the next.
Feed the findings into strategy, not just the backlog
Recurring themes tell you something structural: a lack of guardrails, a skills gap, an architecture that fights the controls. Those belong in the cloud strategy conversation, alongside decisions like portability and your cloud exit strategy, rather than being treated as an endless stream of tickets.
Cloud security posture assessment FAQs
How long does a first cloud security posture assessment take?
For a typical three-subscription estate with cooperative access, ten to twelve working days end to end, of which roughly half is genuine analysis and half is scoping, validation and reporting. Delays almost always come from access provisioning rather than from the technical work, so start that on day one.
Can we do this ourselves instead of hiring someone?
Yes, and many capable platform teams should. Enable the native cloud security posture service, adopt the relevant benchmark, work through the domains in this checklist, and be honest about the findings. The argument for an external reviewer is independence and pattern recognition across many estates, not access to secret tooling.
Does a good result mean we are compliant?
No. A clean cloud security posture review is strong evidence for the technical controls behind most frameworks, but certification also requires policies, training, supplier management and records that no configuration scan can produce. It shortens the path to certification considerably; it does not replace it.
What if the assessment finds something already exploited?
Stop the assessment and start the incident response process. This happens, particularly with exposed credentials and public storage. Agree in the kick-off meeting who gets called and how quickly, so the reviewer is not deciding it at half past four on a Friday.
How does this relate to a supplier questionnaire?
They pull from the same evidence in opposite directions. Your cloud security posture review answers a customer’s security questionnaire credibly, and the questionnaires you receive should be informed by whether your own estate would pass the questions you are asking others.
Which providers does this checklist apply to?
All of them. The specific service names differ across AWS, Azure and Google Cloud, but identity, exposure, data, logging and drift are universal, which is why a cloud security posture assessment structured around domains rather than product names survives a change of provider.
References
NCSC: Using Cloud Services Securely
NCSC 10 Steps to Cyber Security
NCSC Cyber Essentials Overview
NIST SP 800-145: The NIST Definition of Cloud Computing
NIST SP 800-53 Rev. 5: Security and Privacy Controls
NIST SP 800-207: Zero Trust Architecture
NIST SP 800-61 Rev. 3: Incident Response Recommendations
CIS Critical Security Controls
Cloud Security Alliance Cloud Controls Matrix
AWS Shared Responsibility Model
Microsoft: Shared Responsibility in the Cloud
AWS Well-Architected Security Pillar
Microsoft Defender for Cloud Secure Score
Google Security Command Center Overview
Cyber Security Breaches Survey 2025
