Maturity Scores vs Actual Defense: Reading Both

Maturity scores are popular with boards because they are easy to read. A number from one to five, a color on a chart, a trend line that goes up. They are useful. They are also easy to over-read.

A maturity score describes how consistently and deliberately a program is run. It does not tell you whether an attacker would get through. A well-documented program can still have a weak spot that tests would find in an afternoon.

The practical answer is to read both views side by side: the maturity level, and the evidence from actual testing.

TLDR

• A maturity score measures how well a program is managed, not how well it defends.

• High maturity and weak defense can coexist, especially in one domain.

• Pair every score with test-based evidence for the same domain.

• When the two views disagree, trust the evidence and investigate the score.

• Show boards both views in one table so the disagreement is visible.

What a maturity score does and does not say

Most scoring models grade process: is the work defined, repeatable, measured and improved. The tiers in NIST's CSF 2.0 guide are a good example. They run from Partial to Risk Informed, Repeatable and Adaptive, and NIST describes them as characterizing the rigor of risk governance and management outcomes.

That is a useful signal about discipline. It is not a measurement of resistance to attack. The score tells you how the program is run. Testing tells you how it holds up.

How the two views disagree

A few patterns show up often:

• High score, weak test. The process is documented and repeatable, but the control it describes has a flaw that nobody tested for.
• Low score, strong result. A small team with informal habits does the important things well, and tests confirm it.
• Uneven domains. A strong overall score hides one domain, such as recovery or vendor risk, that is much weaker than the rest.

An average hides all three. Only a side-by-side view shows them.

A dual-view scorecard

Pair each domain's maturity level with one piece of test-based evidence, and say plainly whether the two agree. The entries below are illustrative.

Domain (illustrative)	Maturity level	Test-based evidence	Views agree?
Identity and access	Repeatable	Sampled admin accounts: all reviewed in last 90 days	Yes
Recovery	Repeatable	Last restore test missed the stated recovery time	No, investigate
Third-party risk	Risk Informed	Top-vendor evidence on file for 4 of 10	Yes, both weak
Detection	Adaptive	Simulated attack not detected within target window	No, investigate

The last column does the work. Every row marked No is a conversation the board should have.

How a board should use it

Ask for the dual view once a quarter. Focus on the rows where the views disagree, and ask what is being done and by when. For more on measuring program effectiveness, see how to measure effectiveness with a maturity model.

Do not punish disagreement. It is the most valuable output of the exercise. A program that surfaces it is working. One that always shows agreement should be asked how it knows.

Frequently asked questions

Is a high maturity score a bad sign?

No. It usually means the program is well run. The point is that it does not prove the defenses work. Pair it with testing.

What counts as test-based evidence?

Results from restore tests, simulated attacks, access reviews, vulnerability scans or sampled control checks, with dates. Anything produced by actually exercising the control.

How often should the dual view be produced?

Quarterly is a good rhythm. It matches typical board cycles and gives teams time to act on gaps between reviews.

Who should build the scorecard?

The security lead, with an independent reviewer checking the evidence column. The person being scored should not be the only one who fills it in.

A Defensible Next Step

Take the last maturity score your board saw and add one test result beside each domain. Wherever the two disagree, you have found the next agenda item. Book a Decision-Clarity Call if you would like help building the pairing.