How the score is calculated.
Every security vendor gives you a number. Almost none of them will tell you how it was derived, which makes the number impossible to argue with — and therefore impossible to trust. Here is ours in full.
The score runs 0–100 and lower is better. It has two parts: a saturating measure of how many findings you have relative to how much infrastructure you run, plus fixed penalties for missing foundational controls. The two are added and capped at 100.
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.
| Severity | Weight |
|---|---|
| Critical | 10 |
| High | 4 |
| Medium | 1 |
| Low | 0.25 |
| Informational | 0 |
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.
| Gate | Max points | Basis |
|---|---|---|
| CloudTrail coverage gap | 12 | Scaled by share of regions without a trail |
| Admin port open to internet | 10 | Any all-ports or admin-port rule open to 0.0.0.0/0 |
| GuardDuty coverage gap | 8 | Scaled by share of regions without threat detection |
| Console MFA gap | 6 | Scaled by share of console users without MFA |
| Root without hardware MFA | 3 | Root protected by virtual MFA or none |
| S3 account public access block off | 3 | Any misconfigured bucket can be exposed |
| Root credentials recently used | 2 | Root used within the last 7 days |
| EBS default encryption off | 2 | New volumes created unencrypted |
| Stale IAM access key | 2 | Active key older than 365 days (1 point above 90 days) |
| Security Hub disabled | 2 | No aggregated findings or CIS benchmark scoring |
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
| Score | Band | |
|---|---|---|
| 0–20 | Low | |
| 21–40 | Moderate | |
| 41–65 | Elevated | |
| 66–85 | High | |
| 86–100 | Critical |
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.
| Component | Points | Basis |
|---|---|---|
| Weighted failure density | +34.2 | 1,207 weighted failures ÷ 418 resources = density 2.89 |
| CloudTrail coverage gap | +12.0 | 0 of 4 regions logging |
| Admin port open to internet | +10.0 | Security group exposes all ports to 0.0.0.0/0 |
| GuardDuty coverage gap | +8.0 | 0 of 4 regions with threat detection |
| Console MFA gap | +4.2 | 30% of console users have MFA |
| Root without hardware MFA | +3.0 | Virtual MFA only |
| S3 public access block off | +3.0 | Account-level block disabled |
| Root credentials recently used | +2.0 | Root used today |
| EBS default encryption off | +2.0 | Disabled in one region |
| Stale IAM access key | +2.0 | Oldest active key 1,414 days |
| Security Hub disabled | +2.0 | Not enabled in any region |
| Posture gate cap applied | −6.2 | Raw gate total 48.2 capped at 42 |
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.
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 — 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.
Genuinely — tell us. The weights reflect judgement calls about what matters most in a typical AWS estate, and yours may not be typical. That conversation is a good use of the walkthrough.
Book a walkthrough