The report has been sitting on the shared drive for four months. 41 findings, neatly prioritised, colour coded. Seven are done, and they are the seven somebody had on their list anyway. A security roadmap in an SME rarely fails because the wrong items are on it. It fails because nobody worked out how much change an IT team of four can carry alongside the day job.
A security roadmap is a capacity and budget plan, not a catalogue of measures. What decides the outcome is the order, the owner per item and the free time in the team. Sort by risk score and you work the list from the top and never reach the bottom. Sort by business impact and the first quarter often funds the rest of the year.
Why security roadmaps stall in the second quarter
The list is usually good. In two weeks an assessment reliably finds what is missing and ranks it by criticality. That ranking describes the threat picture, not your operation.
The limiting factor in an SME with 50 to 500 employees is, in our experience, rarely the licence budget. It is the number of changes an organisation digests per quarter. Every measure means a policy someone reads, a process someone runs differently, a rollout someone supports. Multi-factor authentication on all administrator accounts is two hours of configuration and six weeks of conversation with the people whose workflow changes. On the roadmap it is one line.
Then there is the ownership question. If the "responsible" column holds a department instead of a person, nothing happens. Not out of reluctance. A department simply has no calendar. And third, the definition of done is often missing. "Revise the backup concept" can mean a document exists. It can also mean a restore was tested and worked. Twenty working days sit between the two.
Most companies that call us do not have a security problem. They have a sizing problem: too many tools, too little overview, too much cost for too little real protection. That is why a usable roadmap almost always names in its first quarter what goes away. More protection, fewer tools, lower cost, in that order.
What belongs in a security roadmap for an SME?
A security roadmap needs five entries per item: what changes in concrete terms, the business reason for it, who owns it, how many working days and francs it ties up, and by when it is finished. If one of the five is missing, the entry is a statement of intent. Statements of intent do not survive a quarter with a full operational load.
The business reason is the entry that goes missing most often and carries the most weight. It is the sentence with which your management team later justifies the spend to itself. "Reduces risk" does not do that. "The framework contract with our largest customer requires it by June" does.
On effort, your own working days count for more than the invoice amount. A quote is negotiated once and then paid. Twelve working days out of a team of three, by contrast, are a month in which something else is left undone, and that item appears in no budget. Roadmaps that show only francs therefore look affordable and still are not affordable in the calendar. We write both numbers side by side, because the second one is where items fail.
| Item | Business reason | Owner | Effort | Due |
|---|---|---|---|---|
| Reduce two overlapping endpoint tools to one | Lowers licence cost, one alert channel instead of two | Head of IT operations | 12 working days, no new licence | Q1 |
| Write down reporting paths and decision rights for incidents, and rehearse them once | Makes the contractual 24-hour reporting deadline achievable | Managing director | 3 working days plus half a day of exercise | Q1 |
| Rework access rights to the engineering data | Condition from the customer audit, blocks the contract renewal | Head of engineering | 20 working days, spread out | Q2 |
What does not belong on it matters just as much. Findings without an owner go back into the assessment, not onto the plan. Nobody can ever mark a line like "increase awareness" as done, because it describes no state you could reach. And a tool evaluation without a decision date runs until the vendor reissues the offer.
The order an SME can sustain
Sorting by risk score looks objective. In practice it rewards the person who assigned the score, and it produces a first quarter in which everything is red and nothing gets finished. Four criteria lead, in our experience, to an order an SME can actually sustain.
First comes what unlocks money. If a condition from a customer audit blocks a contract renewal, it is the most important item of the quarter, whatever colour it carries in the report. Security that enables a deal is rarely discussed internally as a pure cost centre afterwards.
Next comes what creates capacity. Switching off a tool nobody has opened since the pilot saves licence cost and, more importantly, the hours someone spends maintaining it. Those hours are the budget for everything else. Cleaning up is the one item on the roadmap that gives capacity back instead of consuming it.
Third comes what carries a date set from outside: contractual reporting deadlines and audit cycles. Since 1 April 2025, operators of critical infrastructure have had to report cyberattacks to BACS, the Swiss Federal Office for Cybersecurity, within 24 hours of discovery (BACS information on the reporting obligation, in German), and such deadlines are passed down through supply contracts. If you fall under the ISG, the Swiss Information Security Act, the ISMS deadline at the end of 2026 sits in your calendar as well. Dates are not negotiable. Scores are.
Last comes what prevents the largest realistic damage. Realistic means the scenarios that occur in your industry. A tested restore and tidy administrator accounts deliver more than the exotic scenario that reads well in the report and barely happens in your sector.
This order also changes the conversation about budget. If you start with an item that secures a contract renewal and cancel a licence in the same quarter, you sit differently in the room at the next request than someone who has described risks for twelve months. That is not a rhetorical trick. It is the difference between a security programme anchored in the business and one that lives off the patience of the management team.
How long does a security roadmap take in an SME?
In our experience, twelve to eighteen months sit between taking stock and a stable security operation. Do not confuse this with the ramp-up: security leadership is operational after roughly six weeks, while the roadmap it steers runs across quarters. The first 90 days decide the rest, because they bring order to inventory, owners and deadlines and produce the first visible results. After that it is operations, not a project.
This split has a practical reason. A management team rarely funds an eighteen-month programme on trust alone. It funds a quarter, sees a result and decides again. How that rhythm starts inside a mandate is set out in the process from kickoff to full operation. Where the starting picture comes from, if none exists yet, is covered in the article on the security assessment as a way of taking stock.
How this looks in a Swiss SME
A mechanical engineering company in central Switzerland, around 240 employees, three sites, a high export share. After the assessment, 38 findings lay on the table, eleven of them scheduled for the first quarter. The IT team consisted of three people who were supporting an ERP migration at the same time. After three months two of the eleven items were done, and the steering group had the feeling that the whole thing was too big for the company.
What was replanned was the volume, not the content. Three items per quarter, each with a person's name as owner. The first was a shutdown: a second vulnerability scanner whose reports nobody had opened for a year and a half. The second was the rework of access rights that a customer had made a condition. The third was reporting paths for incidents, including an exercise on a Friday afternoon.
After twelve months, 26 of the 38 findings were closed, seven consciously accepted and documented with a rationale in the risk register, five dropped because the ERP migration had resolved them. The licence budget came in below the previous year while coverage had grown. The board received one page four times. What is notable is not the result but that the list was the same as at the start. Only the order was different.
How do you know a security roadmap is alive?
By the fact that it changes. A roadmap that still looks like it did on the day it was approved, twelve months on, was filed rather than delivered. Three signs are reliable.
Things get deleted. In every quarterly review, items fall away because the business has changed or because the measure would never have solved the problem. A roadmap that only grows is a wish list.
Every open item carries a person's name, and that person sits at the table in the review. Whoever is not at the table does not deliver, in our experience. That is not a question of character but of the priorities of the day.
The management team and IT look at the same page. Not a technical version for IT and a polished one for upstairs. As soon as two versions exist, the two sides negotiate about different things, and the roadmap loses its function as a shared plan.
Frequently asked questions
Do we need an assessment first, before we can plan a roadmap?
Not necessarily, but you need a dependable starting picture. Once you know which systems are business critical, who holds which access and which contracts contain security requirements, a first order can be set even without a formal assessment. If that picture is missing, guessing at the start costs more than taking stock.
How many items realistically fit into one quarter?
In our experience two to four in an SME with a small IT team, and one of them should be a shutdown. The number sounds low until you count what else the team delivers in the same quarter. Three finished items beat eleven started ones by a wide margin.
What if the management team cuts the budget?
Then the roadmap does exactly what it is there for. It shows which items fall away and which business reason stays unmet. A cut turns from a savings decision into a deliberate risk decision with a name under it. That is less comfortable and considerably more honest.
The question we open mandates with is therefore not "what are you missing". It is: what did you actually finish last quarter. The answer sets what the next twelve months are allowed to look like.