Assess · Targeted maturity
A whole-program assessment tells you a function needs work; it rarely tells you how good that function actually is. When you want a deep, defensible read of a single capability, you measure it against the maturity model designed for that discipline, not a generic checklist. We score vulnerability management, application security, or security operations against the model their own communities built.
Scope agreed in writing before any work. No obligation.
A particular capability, your AppSec program, your SOC, your vulnerability management, is under question from a customer, a board, or your own instinct, and a whole-program score is too blunt to answer it.
You are about to invest in one discipline and want the baseline first, scored on a recognised model, so the spend is targeted and the improvement is measurable afterwards.
You want to know how your function compares to peers, in the language the discipline uses, rather than an internal opinion dressed up as a rating.
What you are commissioning
One named engagement from the Assess track backs this page. The function in scope and its model are agreed in writing before any work begins.
Assess trackTypically 2–3 weeks
Score a single security function against the model built for it.
Best for a deep read of one capability, not the whole program.
Includes
Deliverables
The method
Vulnerability management is scored against the SANS VMMM; application security against BSIMM or OWASP SAMM; security operations against the SOC-CMM. These are the models practitioners in each field recognise, so the score means something to them.
Maturity reflects what we can see operating, not what a policy claims. Interviews, artefacts, and technical sampling back every score, and where the story and the evidence diverge, the evidence wins.
Because the scope is one function, the read goes deep: the sub-practices, the handoffs, the tooling, and the places the capability quietly breaks down. A whole-program assessment cannot afford this depth on any single area.
The same model applied again measures movement rather than re-litigating the baseline, which makes it the natural before-and-after for a funded improvement program.
Where it fits
The Domain Maturity Assessment is the focused counterpart to the whole-program read. You can run either first.
Run it standalone when one function is the question
Run it after a Security Program Assessment to go deep where that flagged a gap
Re-run it under Operate to track the function as it matures
Questions
Most commonly vulnerability management (SANS VMMM), application security (BSIMM or OWASP SAMM), and security operations (the SOC-CMM). Where a recognised model exists for the discipline you care about, we can scope against it; where one does not, a whole-program or compliance assessment is usually the better instrument, and we will say so.
If you want the complete picture, do that, it is the flagship. The Domain Maturity Assessment is for when you already know which function matters and want depth on it rather than breadth across everything. Many teams use the program assessment to find the weak function, then this to go deep on it.
BSIMM is observational, describing what your program does against a large body of observed practice; SAMM is prescriptive, scoring against a defined model you can then target. We help you choose against what you want from the exercise, a benchmark or a roadmap, and can work to either.
Typically two to three weeks for a single function, because the scope is bounded even though the read is deep. The exact timing depends on the size of the function and the access available.
A function maturity scorecard, a capability gap analysis, and a targeted improvement roadmap, scoped to that one discipline and expressed in its own model's language.
One conversation, then the scope and the price in writing. Your enquiry arrives already marked for domain maturity assessment.