Skip to content
Calcrivo

Cloud Misconfiguration Calculator

Convert CSPM findings into a 0-100 posture score by weighting critical, high, medium and low findings and normalising per 100 cloud resources.

Inputs

resources
findings
findings
findings
findings
findings
%
days

Cloud Posture Score

57.7/ 100

Grade

D — Weak

Severity-Weighted Findings

1,185points

Weighted Findings per 100 Resources

28.21

Raw Findings per 1000 Resources

174.3

Suppressed Share of Findings

8.7%

Score After Clearing Criticals

64.1/ 100

Manual Backlog at Current MTTR

9,992finding-days

Priority

Clear every critical finding — they carry ten times the weight of a medium and are what an attacker looks for first

Step by step

  1. Values used

    Cloud resources in scope = 4,200 resources; Critical findings = 18 findings; High findings = 74 findings; Medium findings = 210 findings; Low findings = 430 findings; Suppressed or accepted findings = 64 findings; Findings closed by auto-remediation = 35 %; Mean time to remediate = 21 days

  2. Cloud Misconfiguration

    Weighted findings = critical × 10 + high × 5 + medium × 2 + low × 0.5. Posture score = 100 − min(100, 1.5 × weighted findings per 100 resources).

  3. Remediation backlog

    Manual backlog = findings not auto-remediated × mean time to remediate, expressed in finding-days — the work-in-progress a human queue has to absorb.

  4. Cloud Posture Score

    = 57.7 / 100

  5. Grade

    = D — Weak

  6. Severity-Weighted Findings

    = 1,185 points

  7. Weighted Findings per 100 Resources

    = 28.21

  8. Raw Findings per 1000 Resources

    = 174.3

  9. Suppressed Share of Findings

    = 8.7

How it works

Raw finding counts scale with estate size, so a thousand findings across forty thousand resources is a better posture than two hundred across five hundred. Normalising weighted findings per hundred resources removes that bias, and the 1.5 penalty factor is calibrated so an estate with roughly one weighted point per two resources lands in the failing band. CSPM tools hand you tens of thousands of findings and no way to tell whether this quarter is better than last, and a density-normalised score is the only version of the number that survives the estate doubling in size.

Formulas

Cloud Misconfiguration

Weighted findings = critical × 10 + high × 5 + medium × 2 + low × 0.5. Posture score = 100 − min(100, 1.5 × weighted findings per 100 resources).

weightedFindings
Severity-weighted total finding load
findingsPer100
Weighted findings ÷ resources × 100
postureScore
0–100 posture score after the density penalty

Remediation backlog

Manual backlog = findings not auto-remediated × mean time to remediate, expressed in finding-days — the work-in-progress a human queue has to absorb.

manualBacklog
Findings left for a human after auto-remediation
mttrDays
Mean days from finding to closure

Frequently Asked Questions

How is Cloud Misconfiguration calculated?

Weighted findings = critical × 10 + high × 5 + medium × 2 + low × 0.5. Posture score = 100 − min(100, 1.5 × weighted findings per 100 resources). Raw finding counts scale with estate size, so a thousand findings across forty thousand resources is a better posture than two hundred across five hundred. Normalising weighted findings per hundred resources removes that bias, and the 1.5 penalty factor is calibrated so an estate with roughly one weighted point per two resources lands in the failing band.

Why does Cloud Misconfiguration matter?

CSPM tools hand you tens of thousands of findings and no way to tell whether this quarter is better than last, and a density-normalised score is the only version of the number that survives the estate doubling in size.

What values do I need to enter?

This calculator takes 8 inputs: Cloud resources in scope, Critical findings, High findings, Medium findings, Low findings, Suppressed or accepted findings, Findings closed by auto-remediation, Mean time to remediate. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why normalise by resource count?

Because otherwise every autoscaling event changes your security score. A team that launches 500 EC2 instances for a batch job would show a posture collapse using raw counts, even though the per-resource configuration is identical. Density answers 'how well do we configure things', which is the question you can act on.

Do suppressed findings still count?

Not in the weighted total here, but the suppression ratio is reported alongside it deliberately. Suppression is a legitimate risk-acceptance tool and also the easiest way to fake a posture score, so the two numbers belong on the same screen.

You might also need