Cloud security posture audits: what to check beyond the score

A cloud posture audit can produce hundreds of recommendations and one reassuring — or alarming — score. The problem is that a score describes a calculation method, not the actual risk of an environment on its own.

Microsoft describes CSPM as continuous visibility into the security state of cloud assets with recommendations intended to reduce misconfiguration and security risk.2 AWS, meanwhile, calculates Security Hub CSPM scores from the proportion of passed controls among enabled controls that have evaluation data.4 A number such as “82%” therefore only makes sense with its scope and methodology.

EXPOSUREPublic serviceReachable from the internet

IDENTITYPermissive roleExcess privilege

ASSETCritical dataHigh business impact

PRIORITYCombined contextAddress before an isolated finding

1. Verify scope before reading the result

A report should not begin with the score. It should begin with what was observed: AWS accounts, Azure subscriptions, GCP projects, regions, organisations, services covered, the collection window and the permissions used.

A missed environment creates a blind spot; insufficient permissions can make results incomplete; resources that are not recorded by the underlying service may never contribute to a score. AWS notes, for example, that some Security Hub CSPM scoring depends on resource recording through AWS Config.45

The first audit question is therefore: “what does this result actually represent?”

2. Separate score, finding and risk

A control checks a condition. A finding records a result or issue. A score aggregates results using a particular method. Risk depends on context: exposure, exploitability, privileges, data sensitivity, dependencies and business impact.

Microsoft explicitly documents risk factors such as internet exposure, data sensitivity, lateral movement and attack-path context when prioritising recommendations.3 The same configuration issue can therefore receive a different practical priority depending on the affected resource.

This distinction avoids two common errors: mechanically working through every “High” finding without understanding context, or optimising a score while a small number of critical risk chains remain open.

3. Review identity before cosmetic details

In cloud environments, identities connect users, workloads, services and accounts. A useful audit considers highly permissive roles, trust relationships, long-lived credentials, dormant accounts, strong authentication and workload identities.

The goal is not to treat every broad permission as an incident. It is to identify combinations that create a path: an identity reachable from an exposed resource, able to assume a privileged role and reach sensitive data deserves more attention than an equivalent permission in an isolated sandbox.

4. Connect network exposure to what sits behind it

“Public” does not mean “vulnerable”, and “private” does not mean “secure”. An internet-facing endpoint may be necessary. It should be read alongside authentication, application protection, allowed flows and the criticality of the service behind it.

Dependency mapping helps move beyond the isolated finding. If an exposed service can reach an internal API that uses an identity with access to a sensitive data store, the priority comes from the chain rather than one rule.

Context
Information system mapping: ANSSI’s five stages turned into an operational plan →

5. Identify the data and assets that genuinely change impact

Two misconfigured databases do not necessarily represent the same risk. Distinguish public data, internal information, secrets, personal data, health data, backups and information essential to a critical service.

ANSSI’s recommendations for sensitive cloud hosting explicitly consider the type of information system, data sensitivity and threat level when guiding hosting decisions.1 That reinforces a broader point: cloud posture is not a universal checklist detached from context.

6. Verify logging, detection and investigative capability

A configuration audit should ask whether the organisation can understand what happened. Are administrative logs enabled and centralised? Is access to sensitive data observable? Is retention suitable? Do alerts actually enter a response process?

A compliant configuration at one point in time does not prevent a later change. Logging and history help explain drift, detect regressions and investigate incidents.

7. Read standards and scores through their methodology

AWS explains that its score is the proportion of passed controls among enabled controls included in the calculation, and that a control can be counted once in the summary score even when it belongs to several standards.4 A score is useful for tracking a trend within the same measurement system, but it should not be naively compared with a different product or perimeter.

There is another consequence: improving the score can be useful without being the best immediate risk priority. Microsoft explicitly notes that its risk prioritisation is distinct from secure score.3

8. Build a real remediation queue

The output of an audit should not be a raw list. Each important finding needs at least:

• an affected asset and owner;
• a concise explanation of risk context;
• a proposed action;
• a target date or documented exception;
• a verification method after remediation;
• a status that distinguishes fixed, accepted, not applicable and pending review.

AWS exposes workflow statuses for investigating and resolving Security Hub CSPM findings.5 The exact tool is secondary; the useful principle is that remediation has a traceable lifecycle of its own.

9. Check drift after the fix

A one-off correction is not a guarantee. A policy can be changed, a resource recreated, a new region enabled or an IaC pipeline can reintroduce an unwanted configuration.

The value of CSPM is therefore temporal as well: observe continuously or on a regular cadence, detect regressions and compare change over time. In Infrastructure-as-Code environments, the strongest remediation is often twofold: fix the resource and fix the source configuration.

10. The report should explain, not merely rank

A useful posture report can be read at several levels:

1. executive / risk: which scenarios matter most and why;
2. security / cloud security: which control families and attack chains dominate;
3. technical teams: which resources should change and how to verify the result;
4. governance: which deviations are accepted, for how long and by whom.

This prevents one score being used to answer every question.

Checklist: ten questions to ask when someone presents a cloud score

Before using a posture score as a management indicator, ask:

1. Which accounts, projects and regions are included?
2. Which resources cannot be evaluated?
3. Which standards and controls are enabled?
4. How is the score calculated?
5. Which findings affect exposed assets?
6. Are identities and trust relationships analysed?
7. Does data sensitivity influence priority?
8. Are exceptions documented?
9. Is a fix verified and monitored over time?
10. Can the score move without real-world risk changing in the same direction?

The score remains useful because it provides a repeatable reference. Audit maturity, however, is visible in the ability to explain what sits behind the number and connect findings to systems, data and remediation decisions.