Building a security roadmap that gets funded

A roadmap that lists projects without costs is a wish list. The version that gets funded has four columns: what, why now, how much in Canadian dollars, and who is accountable. Everything else is commentary.

Last reviewed 2026-09-01Written by Jacob Masse, TrazTech Inc.

A security roadmap is a sequenced list of changes with a date, a Canadian dollar cost and an accountable owner against each one, ordered by what the business is actually exposed to rather than by control number. For a company of 50 to 200 people it should fit on two pages and cover four quarters, and about half of it should be work the company can do with people it already employs. A roadmap that requires all new spending has not been prioritised, it has been transcribed from a framework.

The four columns that make it fundable

Internal engineering days are the line most roadmaps leave out, and it is why funded roadmaps still fail. Six engineering days at a loaded cost of roughly $900 CAD a day is $5,400 of real money competing with the product backlog. Show it, and the conversation about priority happens before the work is late rather than after.

How to order the work

Framework order is the wrong order. A control catalogue is written to be complete, not to be sequenced, and working through it top to bottom means the company spends the first quarter on documentation while the thing that is going to hurt it stays open.

1. Anything that is blocking revenue right now. A stalled deal, a stalled audit, a declined insurance application. These are not always the largest risks and they are always first, because they buy the credibility for everything after.
2. Anything where a single failure ends the company. Backups you have never restored from, one person holding the only cloud root credential, no path to revoke access for a departing administrator.
3. Anything cheap that removes a whole class of problem. Multi-factor authentication everywhere, removing standing production access, turning on logging you will need later.
4. Framework gaps that are not covered above. This is where the control catalogue finally gets read, and it is usually a third of the roadmap rather than all of it.
5. Everything that requires a new tool. Last, deliberately, because tooling bought before the process exists becomes shelfware with a renewal date.

What belongs in the strategy rather than the roadmap

Strategy, one page, reviewed yearly

What the company is protecting, from whom, what level of risk it accepts, which standard it will be measured against, and how security decisions get made. This changes rarely and is the document the board approves.

Roadmap, two pages, reviewed quarterly

The sequenced changes. This moves every quarter and does not need board approval, only board visibility.

Risk register, live

What is currently open, who owns it, and what has been formally accepted. Feeds the roadmap. Covered on the risk register.

Metrics, monthly

Whether the changes are actually landing. Covered on security metrics and KPIs.

Companies conflate the first two and end up asking a board to approve a list of engineering tasks, which boards are not equipped to do and rightly resent. Separate them, and the board conversation becomes a governance conversation. How that is presented is on reporting security to a board.

Who should write it

The roadmap should be written by whoever is accountable for security and reviewed by whoever will do the work, in that order. Written by engineering, it becomes a list of things engineering already wanted to do. Written by a consultant with no contact with the delivery team, it becomes a list of things nobody will do. A vCISO produces one in month three of a normal engagement, which is the schedule on the first 90 days.

Common questions