Security strategy advisory
Most security roadmaps are a list of everything. That is not a strategy, it is an inventory. Strategy is deciding what you do first, what you do later, and what you deliberately leave alone this year.
I have spent a little over two decades in information security, most of it in Denmark, and a good part of it sitting between a compliance requirement and the people who actually have to act on it. Translating between those two is most of the job. Advisory is where I do that translation before anyone starts building anything.
This is thinking work, not implementation work. I help you decide what is worth doing, in what order, and why, so that whoever does the building is building the right thing.
The same argument the rest of this site makes
Everything here argues for tested capability over filed documents. Advisory is that argument one step earlier, before anything gets built or filed. A severity score with no business context is noise. What makes it a priority is knowing which part of the business stops working, who has to act when it does, and whether those people have ever done it.
So the questions I ask are the boring, useful ones. What would actually hurt. Who would have to handle it. What you have already paid for and are not using. And what you can honestly postpone without pretending it does not exist.
A plan on paper vs a decision you can defend
Four steps, and the last one matters most
The last step is the one people skip. A priority list that never says no is just the same inventory in a different order, and it gives nobody cover for the things that did not make the cut. Writing down what you are not doing, and why, is what turns a list into a decision.
How an advisory engagement runs
What this is, and what it is not
What you actually get
A short, ordered list of what to do next, with the reasoning attached to each item so you can repeat the argument to a board, a budget holder or an auditor without me in the room. Written down, in plain language, short enough that people read it.
What I do not do
I do not write your policies, run your gap assessment, build your ISMS, or take you through certification readiness. That is implementation work and it needs a different kind of partner. If that is what you actually need, I will tell you that instead of selling you a strategy day you do not need.
Who this is for
The person accountable for security who has more to do than budget or people to do it with. Usually that is a head of security, an IT lead who inherited security, or a management team that has been told to have a position and does not yet have one.
How it fits with the workshops and the games
Advisory decides what matters. The workshops and the games are how you find out whether your people can actually do it under pressure. They work in either order, and plenty of engagements start with a game precisely because it surfaces the priorities faster than an interview does.
At a glance
| What it answers | What to do first, what to do later, what to leave alone |
|---|---|
| What you leave with | A short ordered list, and the reasoning you can repeat without me |
| Who is in the room | The people who set direction and the people who carry it |
| Where it runs | Copenhagen based, on site across Europe, or remote |
| Language | English or Danish |
| What it is not | Policy writing, gap assessments, or certification readiness |
Tell me what you are stuck on
Send me the thing you keep re-opening and never closing. That is usually where the real priority is hiding, and it is a better start than a list of controls.
