Risk Scoring That Doesn't Lie: How to Weight Reality

Pulse Insight

Risk scores fail when they become a debate instead of a measurement.

If your scoring model can be gamed with language ("low likelihood," "compensating controls"), you don't have a score—you have a story.

The fix is to weight what reality actually cares about:

• exposure
• control strength
• detectability
• time (freshness)
• blast radius

The principle: missing evidence is risk

A control that isn't evidenced is not a control.

That means the scoring model should penalize:

• unknown owners
• missing logs
• expired exceptions
• untested failover
• policies not in version control
• "temporary" access without expiry

This feels strict—until the first audit or incident.

A clean scoring structure (that scales)

1) Exposure

How reachable is the asset/path?

• open pathways
• segmentation boundaries
• privileged reachability
• external dependencies

2) Control strength

Do controls exist and are they enforced?

• least privilege
• TTL-based access
• change control
• configuration drift correction

3) Detectability

How quickly would you know?

• telemetry coverage
• alerting quality
• ability to replay decisions

4) Freshness (time decay)

Risk increases when things go stale:

• policies not reviewed
• tickets open too long
• "temporary" exceptions aging into permanence

5) Blast radius

If it goes wrong, how far does it spread?

• upstream dependencies
• identity lateral movement paths
• DNS redirection potential

The one metric I like for pipelines (and why it works)

This is a practical concept that translates well across domains:

Pipeline Health Index (PHI)

PHI = Σ(amount × stageweight × closeprob × freshness) / Σ(amount)

Where:

• stage_weight reflects true deal maturity
• close_prob is either modeled or default per stage
• freshness penalizes staleness (e.g., exponential decay)

Why it matters: big, quiet deals create silent risk—PHI exposes that.

The same idea applies to security:

• big, quiet exposures are your real liabilities

How to prevent risk scoring from becoming performative

• Use monotonic variables (if exposure increases, score must not improve)
• Make weights explicit and reviewable (board-ready)
• Require evidence links for "control present" claims
• Track "unknowns" as a first-class category
• Publish score movement rules (so people can't negotiate reality)

The board lens: risk is a capital allocation problem

I treat risk scoring like portfolio discipline:

• what gets funded
• what gets fixed
• what gets deferred
• what gets shut down

A good score helps leadership answer:

> "What should we do next week to reduce exposure most efficiently?"

Implementation checklist

• [ ] Define risk objects (asset, identity, pathway, DNS object, exception)
• [ ] Define evidence requirements per control
• [ ] Create freshness decay functions for "stale" conditions
• [ ] Calibrate blast radius using dependency graphs
• [ ] Publish score rules + reason codes
• [ ] Generate board-ready weekly deltas ("what changed and why")

Disclaimer

Informational only. Risk scoring models should be validated against real incident history, audit requirements, and organizational risk appetite.