How the score is calculated.

Component one: weighted failure density

Every failed check contributes points according to its severity. Those points are then divided by the number of resources audited, so an estate with 4,000 resources is not penalised simply for being large. Two hundred failures across 4,000 resources is a very different posture from two hundred across forty.

The result is passed through a saturating curve rather than scaled linearly, because an account with 600 failures is not twice as compromised as one with 300. Past a point, more findings of the same kind tell you very little that is new. This component contributes at most 50 points.

Component two: posture gates

Counting alone badly under-weights certain risks. “CloudTrail is disabled in all regions” is a single failed check, but it means the account has no forensic capability whatsoever. If you are breached, there is nothing to investigate. A tidy account missing one foundational control should still read as dangerous.

So these are scored separately, as fixed penalties. Several scale with coverage: missing CloudTrail in two of four regions costs half of the full penalty.

Gates are capped at 42 points in total. Without a cap, an account failing every gate would score near 100 on gates alone, which would flatten the distinction between “bad” and “catastrophic”.

Banding

A worked example

This is the calculation for the account in our sample report. It has 34 critical, 153 high and 226 medium findings across 418 resources in four regions, with CloudTrail and GuardDuty disabled everywhere.

On calibration

The constants above are calibrated rather than derived from first principles. So is every risk score in this industry. Anyone claiming otherwise is selling something. What matters is that they are fixed, published, and applied identically to every account we assess, so two reports are comparable and your score moving means something real.

They are pinned to a reference account that must score exactly 76. Any change to the rubric that moves that number is a deliberate re-baselining, and it is caught automatically before it can ship.

How the cost figure is calculated

The audit also reports what the account is wasting. Three separate things have to agree before a number appears: that a resource is idle or abandoned, how large it is, and what AWS charges for something that size in that region. The first two come from reading your account. The third comes from AWS’s public price list, which we query with our own credentials - it is a catalogue of published rates, not anything about your usage, so it needs no additional permission from you.

Nothing is estimated. Where all three can answer, the item is priced and shown with the rate it came from, so you can check it against your own bill. Where they cannot, the waste is still reported but carries no figure and adds nothing to the total. An oversized instance is worth the difference between the one you have and the one you should have, and this audit does not presume to choose that for you.

The consequence is that the total is deliberately a floor. It is on-demand list pricing, so any Savings Plan, Reserved Instance or private rate you hold makes your real figure lower, and the items we decline to price make it higher. We would rather quote a number you can verify than a larger one you cannot.

What this score is not

It is a configuration assessment. It does not include a penetration test, application security review, source code analysis, or social engineering assessment. It cannot see what runs inside your instances or containers.

Framework mappings are indicative. They tell you which SOC 2 or ISO 27001 controls your current configuration breaches, which is useful for knowing where you stand but not a substitute for an audit performed by a licensed assessor.

A low score means your AWS configuration is sound. It does not mean you cannot be breached.