The Prioritised Remediation Roadmap

The assessment ends in a list of gaps. The roadmap turns that list into a ranked queue of corrective actions — each with an owner, milestones, and a due date — ordered by effort-to-impact so the highest-leverage work is always next.

Anatomy of one roadmap line

• The gap — the control objective id and what is missing (from the coverage assessment’s NO/partial rows).
• The fix — usually one or two skills from the pool, fitted to the function’s existing stack; never a new tool by default.
• Owner and dates — a name and milestones, including the contract-side fixes the ownership map surfaced.
• Evidence of done — what artefact will flip the answer to YES at re-assessment.

Why effort-to-impact, not severity

Severity-ordered backlogs stall: the hardest item blocks the queue while cheap, high-leverage fixes wait. Ranking by effort-to-impact ships defensible wins early — which funds the harder items, because every completed line moves a visible grade. This is also why the practice prescribes one or two fitted skills at a time rather than a programme of forty.

The roadmap is the budget conversation, pre-written: each line says what it costs, what it moves, and who is on the hook.

The cadence

The roadmap is not a one-off document; it is the standing agenda of the deployment loop on the Engage page: diagnose → prescribe → track → advance. Each cycle closes a few lines, re-runs the affected answers, and re-places the AI Security Maturity Model (AISMM) level. The worked example of one full line — gap to fitted skill to measured lift — is the StoryBond case study.

Honesty note: a roadmap line is projected until its before/after is measured on your own data. Boards should fund the queue, but only ever celebrate the measured lines.