Start Where You Are
You don’t need to burn it all down. You need to be honest about what you have, connect what’s worth keeping, and let go of what was always fiction.
You’ve read the first eight chapters. Hopefully I managed to articulate how security programmes become performances. You understand why connections matter, why the cadence works, why proportionality is the missing conversation. And you’re sitting in front of your own programme — the one with the stale risk register, the policies nobody remembers exist, the evidence folder with screenshots from 2019, and the spreadsheet that only one person understands — and you’re thinking: where do I start?
This is the hardest moment. Not because the method is complex. It isn’t. But because the gap between where you are and where you want to be looks enormous from this side. It looks like starting over. It looks like a project that will take months and produce nothing visible until it’s finished.
None of that is really true. But it feels true, and feelings drive decisions more than logic does.
What is true: you don’t need to start from scratch. You start from what you have. And what you have is probably better than you think — it’s just disconnected.
The honest inventory
The first step is the least comfortable: look at what you actually have and assess it honestly.
Not what you told the auditor you have. Not what the policy documents describe. What you actually have, in practice, right now.
This means sitting down — alone, initially, because honesty is easier without an audience — and answering uncomfortable questions:
Your risk register. Does it reflect your actual risks, or does it reflect the risks you identified two years ago for the audit? Have any of the risks changed? Have any new ones appeared that aren’t captured? Are the risk scores still accurate, or were they set to pass a threshold and never revisited? Just be honest. If the register hasn’t been meaningfully updated since the last certification, it’s stale. That’s okay. That doesn’t make it useless — it makes it a starting point that needs updating, not a foundation you can trust as-is.
Your controls. Which ones are genuinely operational — meaning someone is actually doing the thing the control describes, on the schedule it prescribes? Which ones exist on paper but not in practice? The password policy that says 12 characters minimum but the system enforces 8. The access review that’s supposed to happen quarterly but happened once this year. The business continuity plan that nobody’s tested since it was written. You know which ones are real and which aren’t. Write it down.
Your evidence. Is it contemporaneous — created when the work is done — or assembled before the audit to prove that work was done? There’s no judgement here. Retrospective evidence is common, and acknowledging it is the first step to not needing it anymore. But you need to know which is which, because contemporaneous evidence tells you the programme is working. Retrospective evidence tells you the programme can pass an audit. Those are different things.
Your policies. Do they describe what people actually do, or what someone imagined people would do when the policy was written? Read your access control policy and compare it to how access actually gets requested, approved, and revoked in your organisation. If there’s a gap — and there usually is — note it. The policy isn’t wrong. Reality changed, and the policy didn’t follow.
Your tools. What are you actually using, and what’s shelfware? The GRC platform someone bought two years ago but only uses for the risk register. The vulnerability scanner that runs weekly but whose output nobody reviews. The ticketing system that the security team uses but nobody else touches. Tools you use are assets. Tools you pay for but don’t use are waste. Know which is which.
This inventory isn’t a formal assessment with scoring and maturity levels. It’s a list. Two columns: what we have, and what state it’s actually in. If you recognise this as a clarity exercise — the same principle from Chapter 3, applied to the programme itself rather than a task — you’re right. You can’t improve what you can’t own honestly. The act of writing it down is clarifying in a way that no maturity model can replicate, because you’re the one doing it, and you can’t lie to yourself as easily as you can lie to a spreadsheet.
What you’ll probably find
Do this exercise and a pattern emerges. It’s a recognisable pattern almost every time, and it’s more encouraging than people expect.
You have more than you think. Many organisations that have been through at least one audit cycle have a reasonable set of building blocks. Policies exist, even if they’re stale. Controls exist, even if some aren’t operational. A risk register exists, even if it’s dated. Evidence exists, even if it’s scattered. The raw material is there. What’s missing is the connections between the pieces and the operational discipline to keep them current.
The gap is smaller than it looks. When you stare at a framework checklist — 93 ISO 27001 controls, or the full NIS2 requirements — and compare it to your current state, the gap looks massive. But much of what the framework requires, you’re already doing in some form. You manage access. You handle vulnerabilities. You have an incident process, even if it’s informal. You assess vendors, even if it’s ad hoc. The gap isn’t “everything” — it’s the consistency and connection of things you’re mostly already doing.
Some things are genuinely fiction. Not everything passes the honesty test. Some controls were implemented for the auditor and were never real. Some policies describe a world that never existed. Some evidence was really stretched. That’s fine. Identifying fiction is progress, because fiction you know about is a gap you can plan for. Fiction you don’t acknowledge is a landmine.
One person holds most of it together. We talked about the knowledge concentration problem. The honest inventory will help make it visceral. Ask yourself: if the person who manages the security programme left tomorrow, what would the next person be able to pick up from the documentation alone, without any handover? The answer is usually “very little.” That’s not a criticism of the person — it’s a structural observation about where the knowledge lives. It lives in their head because the programme hasn’t externalised it.
The parallel operation problem
One thing worth warning you about: you can’t stop running your current programme while you build the new one.
The auditor is still coming. The controls still need maintaining. The evidence still needs collecting. Customers still send security questionnaires. Vulnerabilities still need triaging. You can’t tell anyone “we’re restructuring, come back in six months.”
This means, for a period, you’re running two things: the existing programme (however imperfect) and the transition to a connected approach. That’s extra load on a team that’s already stretched. If you don’t plan for it, the transition will either stall — because the day-to-day always wins — or the day-to-day will suffer because everyone is focused on the transition.
The way through this is scope discipline. You don’t transition everything at once. You pick one area, connect it properly, prove it works, and then move to the next. The existing programme continues as-is for everything you haven’t transitioned yet. The new approach takes over one part at a time.
This is slower than a big-bang transformation. It’s also the only approach that actually works for teams of fewer than fifty people who have a day job alongside security. The big-bang alternative goes like this: four months spent building the new system, during which the existing programme degrades badly. When the switchover finally comes, there’s a beautiful connected model — and six months of missing evidence. Everything in the next audit is caveated with “we are transitioning to the new system…”
One area at a time. The old world shrinks as the new world grows. Nobody needs to hold their breath.
Choosing your first area
The first area you connect matters more than you’d think. Not because the method is different per area — it’s the same — but because this is where people will form their opinion of whether the approach works.
Pick the area that causes the most recurring pain. Not the highest risk, not the most important — the most painful. This is a proportionality argument: at the start, momentum matters more than coverage. You need people to feel the difference before they’ll trust the approach with everything else. And pain is a better motivator than logic. Nobody gets excited about connecting their most important domain. Most people get excited about making their most hated quarterly task stop being miserable.
For you, maybe that’s access reviews. They happen frequently, they involve non-security staff who don’t understand what’s being asked, they require evidence that’s annoying to collect, and they touch multiple entities — people, systems, controls, requirements. Everything broken about a disconnected programme shows up here. Maybe it’s vendor management and vulnerability management, for similar reasons: high frequency, multiple stakeholders, multiple dependencies.
Whichever it is for you, start by importing what you have. For access reviews, pull the current access lists for the systems in scope — however messy, however incomplete. Don’t clean them up first. The point isn’t to have perfect data; it’s to have a starting point that reflects reality rather than aspiration.
Then you connect. Link each system to the people who have access, the controls that govern that access, and the requirements those controls satisfy. This is the step that transforms a list of names in a spreadsheet into something you can reason about. Now you can see: 23 people have access to the support system, it’s governed by access control policy section 4.2, which satisfies ISO 27001 A.5.18 and SOC 2 CC6.1, and the last review was 14 weeks ago.
Then you run one cycle. Generate the review task — with context, the way Chapter 7 described. Send it to the team lead in sales operations, but this time it includes: here are the 23 people, here’s what to check, here’s why it matters, here’s what “done” looks like. When they complete it, the evidence record is created by the completion itself. No screenshots. No separate documentation step.
Then you compare. How long did this take versus the old way? Did the support ops lead actually understand what they were doing? Was the evidence something the auditor would accept without a supplementary explanation? That comparison — old way versus new way, same people, same systems, same quarter — is feedback. It tells you whether the approach works, not in theory, but for your organisation, for your people.
The comparison is usually stark enough that the next transition is easier, because the people involved ask “can we do it this way for everything?”
The pleasant surprise
When you connect your existing data — even imperfect, stale, incomplete data — you usually discover that your actual security posture is better than the checklist made it look.
Here’s why. In a disconnected programme, every framework requirement looks like a standalone question: “Do you do X?” If you can’t immediately point to a documented, evidenced control that specifically addresses X, it feels like a gap. And since you have dozens of requirements across multiple frameworks, you end up with dozens of apparent gaps.
But many of those requirements overlap. The access review you do for ISO 27001 also satisfies SOC 2 CC6.1 and NIS2 Article 21(2)(i). Your incident response process covers ISO 27001, GDPR Article 33, NIS2 Article 23, and DORA Article 17. The vulnerability management control satisfies requirements across every framework you’ll encounter.
In a disconnected programme, you can’t see this overlap. Each requirement lives in its own silo, and the relationship to your existing controls is invisible. So you count gaps per requirement and get a terrifying number.
When you connect the data, the overlaps become visible. That terrifying number of gaps shrinks, often dramatically. Not because you’ve done anything new, but because you can finally see the coverage that was already there.
This matters beyond team motivation. It changes the scope of work. Instead of 40 gaps to close, you might have 12. Instead of needing 30 new controls, you might need 8, because the existing ones cover more ground than they appeared to. The transition from disconnected to connected is diagnostic. It tells you what you actually need to do, not what the checklist implies you need to do.
When to start over
I’ve been making the case for reorganising what you have, but sometimes what you have isn’t worth reorganising.
If your programme was built entirely for the auditor — if the policies don’t describe reality, if the controls aren’t operational, if the risk register is a work of fiction, and if the evidence is all retrospective — then connecting it will give you a connected picture of fiction. That’s not useful.
The test is simple: how much of your current programme would survive an honest conversation with someone who understands your actual operations? Not the auditor, who checks documents. Someone who walks around, talks to people, watches how work actually gets done.
If the answer is “most of it, with some gaps,” reorganise. The foundation is sound. Connect it, update it, fill the gaps, and build the cadence around it.
If the answer is “very little — we built this to pass, not to run,” then be honest about that. Keep what’s real. Let go of what isn’t. Start fresh in the areas that were fiction, and don’t waste time connecting data that was never accurate.
This isn’t a failure. It’s a realistic assessment of where you are. A programme that starts from an honest “we have very little” is in a better position than one that starts from a dishonest “we have everything.” The first knows what to build. The second doesn’t know what it’s missing.
The timeline question
People always want to know: how long does this take?
The honest answer is: it depends on where you’re starting from, how much of your existing programme is real, and how much time you can dedicate to the transition alongside the day-to-day.
But here are some rough markers from what I’ve seen:
First area connected and running: 2–4 weeks. This is your pilot — one domain (access reviews, vendor management, vulnerability management) imported, connected, and running one cycle.
Three to four areas connected: 2–3 months. By now the pattern should be established and each new area could transition faster than the last, because the connected model grows incrementally. Adding a new area means connecting to entities that already exist.
Full programme operating on the cadence: 6–12 months. Every control connected to its requirements. Evidence generating as a byproduct. The annual wheel running. This is the point where audit preparation becomes audit packaging.
First audit under the new approach: Whenever your next surveillance or certification audit falls. If you start the transition now, the goal is to have the programme running continuously before that date. Not perfectly — perfectly takes longer. But running, with real connections, and a genuine operational cadence.
These aren’t deadlines. They’re horizons. The value starts accumulating from day one — the first connected access review is better than the last disconnected one, even if the rest of the programme hasn’t transitioned yet. You don’t need to cross the finish line to benefit.
What to do Monday morning
Do the honest inventory. Two hours. Alone. Two columns: “what we have” and “what state it’s in.” Risk register, controls, policies, evidence, tools. Mark what’s real and what’s fiction. Don’t optimise — just see clearly.
Have the conversation with your team. Share the inventory. Ask: “Does this match your experience? What am I missing? What did I mark as real that you think is fiction?” This is uncomfortable and necessary. The people doing the work know which controls are theatre. They’ve been waiting for someone to ask.
Pick your most painful area and scope its first cycle. One page: what’s in, what’s out, what “done” looks like in six weeks, who owns it. Date it. The work will start later; the decision is Monday’s work. The contrast between old and new is your business case.