Barrier effectiveness combines two judgements that are often confused:
- what the security capability could do when functioning as designed; and
- how consistently the organization makes it work in practice.
The first is inherent strength. The second is maturity or condition. Both matter. A capable firewall without governed changes, review and testing may offer less protection than its technical specification suggests.
A practical maturity ladder
Cyberkit uses a capability-maturity progression that can be assessed in ordinary language.
Not implemented
The capability is absent, only planned or present in name without operational effect. It receives no effectiveness credit.
Initial or ad hoc
The capability exists but depends on individual effort. Outcomes vary by person or situation, and important steps are not documented.
Repeatable
People perform the activity consistently enough to repeat it, but the organization has not yet fully formalized expectations, ownership and exceptions.
Defined
An approved policy, standard or process explains what must happen, who owns it and how exceptions are handled. “Defined” is more than a document on a shelf: practitioners can describe and follow it.
Managed
Tests, audits or operational measurements show that the capability performs as intended. Evidence belongs in the appropriate source, audit or GRC system; the bowtie records the assessment result and reference, not a copy of sensitive evidence.
Optimizing
Performance is measured, lessons are incorporated and the capability is systematically improved. Not every assessment needs to use this level, but the distinction can be useful for mature programs.
Evidence changes the conversation
Maturity should not be a confidence score or an expression of how professional a team appears. Tie it to observable evidence.
For example, ask:
- Is ownership assigned and understood?
- Is the expected process approved and current?
- Are exceptions recorded and resolved?
- Has operation been tested under realistic conditions?
- Do metrics or audit findings demonstrate performance?
- When did the evidence last apply to this scope?
“We have a tool” is evidence of presence, not of a managed capability.
Maturity belongs to the shared measure
One real-world measure may appear as barriers on many paths and in many bowties. Its condition should not vary merely because the diagram placement changes.
Cyberkit therefore keeps maturity on the shared measure. When central access management moves from Repeatable to Defined, every linked barrier reflects the new assessment. A placement can be unlinked only when it genuinely represents an independently managed instance.
This makes the portfolio useful. Improving one widely reused measure may reduce more risk than adding a new point solution to a single path.
Running a maturity assessment
A productive assessment separates three roles:
- The capability owner explains design, operation and evidence.
- The analyst applies the agreed maturity criteria consistently.
- The risk owner understands how uncertainty affects acceptance and action.
Record the level, rationale, scope, reviewer and date. If evidence is incomplete, choose the supportable level and create an action to improve either the capability or the evidence.
Common traps
- Giving credit for an approved policy that is not followed.
- Treating one successful test as evidence that every instance is managed.
- Using maturity as a substitute for inherent technical strength.
- Averaging different deployments into a reassuring portfolio score.
- Raising maturity because an improvement is planned rather than completed.
The honest maturity rating is sometimes uncomfortable. That is useful: it distinguishes installed technology from dependable protection.
Go to the source
Sources and further reading
Apply the method
Want to discuss this in your own risk model?
Keep the details high-level. We can start with scope, terminology and evaluation approach.