Tools · Vulnerability management
How mature is our vulnerability management?
Answer 28 questions about how your programme works today, and get the three next actions most likely to reduce risk. Free, no account, and nothing is stored.
Part 1 of 8 · 0 of 28 answered
Asset scope & coverage
Knowing which systems must be scanned, and whether they actually are.
Pick the description that matches what actually happens today, not what a policy says should happen. If you are between two, choose the lower.
You can move on with questions unanswered. They are left out, never counted as Not in place. Nothing is saved, so reloading the page starts again.
- About 15 minutes
- Nothing is stored, not even in your browser: reloading starts again
- Also as a workbook: Vulnerability Programme Maturity Self-Assessment
How this is worked out, and what it is not
- Each part's level is the average of the answers you gave for it, rounded to the nearest level. Exactly half-way rounds down, the same as choosing the lower of two. Questions left blank or marked as not applying are left out.
- Written rules decide which action a part gets, two for each part: at Not in place or Informal, the action that sets the practice up; at Defined, the action that makes it measured and checked. A part at Managed, or with nothing answered, gets none. Nothing else chooses an action.
- A part's priority is how many levels it sits below Managed, times its weight. The three highest priorities are your actions. A tie goes to the part earlier in the list, which runs in the order a programme depends on: scope before scanning, scanning before prioritising.
| Part | Weight | Why |
|---|---|---|
| Asset scope & coverage | 3 | Everything else depends on it: a system that is never scanned has no findings to prioritise or fix. |
| Scanning quality | 2 | Poor scans give false comfort, but coverage and prioritisation matter more at first. |
| Prioritisation | 3 | It decides where limited fixing time goes: the biggest single lever for reducing real risk. |
| Ownership & triage rhythm | 3 | Without a named owner and a weekly routine, findings are found but never fixed. |
| Remediation within deadlines | 2 | It improves mostly as a result of prioritisation and ownership; measure it, but fix the causes first. |
| Verification of fixes | 2 | Without confirmation, reported progress cannot be trusted by you or by an auditor. |
| Exceptions & risk acceptance | 1 | It matters once deadlines exist; it is worth less until prioritisation and ownership work. |
| Reporting & governance | 2 | It keeps management support and resources, but needs reliable figures from the other dimensions first. |
Nothing here is scored out of 100 and there is no percentage. Levels are stated in words, and the priority number is shown only to explain why one action comes before another. The questions, levels, weights and actions are the workbook's, and the same answers give the same three actions in both.
- This is a self-assessment. It is only as accurate as the answers, and people tend to answer for what should happen rather than what does. The workbook version has room to note the evidence behind each answer, and noting it is the best check.
- It measures how the programme works, not how exposed you are today. A Managed programme can still have a serious open vulnerability; use the Remediation Tracker and the Metrics Workbook for that.
- The weights and the action wording are a starting point for a typical small or mid-sized organisation. They are not a benchmark, and the levels cannot be compared with other organisations or with certification requirements.
- It does not cover patch deployment, penetration testing, secure development or incident response, each of which affects vulnerability risk.