The phase nobody hires for
Most security concepts are written, signed off, and then quietly stall. The gap is not the plan but the phase that turns it into practice, the implementation work nobody hires for. On why it is overlooked, why in protection it is a liability, and the role that belongs before the permanent one.
There is a moment in almost every security build where the document is finished and the work has not yet begun. The concept is written. The threat assessment is sound. The procedures exist on paper, signed off, filed. Someone senior has read it and nodded. By every visible measure the project is in good order. And then very little happens, or the wrong things happen, and six months later the organisation has a security function that looks correct on paper but does not hold together in practice, or holds together only partly.
I have watched this from both sides. Years ago I completed a postgraduate specialisation in project management, and the discipline has a clear name for the space I am describing. It is the implementation gap, the distance between a plan as designed and a plan as realised. Organisational scholars know a sharper version of it as the knowing-doing gap: the persistent failure of capable organisations to act on what they already know. The plan is not wrong. The knowledge is present. The execution simply never arrives, or arrives incomplete, in a degraded form that no one quite chose. Logistics lends us another phrase for the same terrain. The last mile. The final stretch where a clean design meets specific, awkward, physical reality and turns out to be far harder than the ninety-nine that preceded it. Software engineering made the same point as a joke against itself, in what became known as the ninety-ninety rule, attributed to Tom Cargill of Bell Labs: the first ninety percent of the work takes the first ninety percent of the time, and the remaining ten percent takes the other ninety percent.
In most fields the implementation gap costs time and money. In protection it costs a great deal more, and that difference is the reason I think the phase deserves more attention than it gets.
The sequencing error
The pattern I see most often runs something like this. An organisation recognises it needs to take security more seriously. It commissions a concept, often well, sometimes from an external advisor with real expertise. The concept is delivered. It is genuinely good. And then the organisation does the thing that feels logical and is in fact a sequencing error: it advertises for a permanent security manager and waits for that person to arrive and bring the concept to life.
This rarely works, and the reason is structural rather than a failure of the individual hired. A permanent security manager is built for steady state. The role is the day to day running of a function that already exists and already works, the, with all respect, nine to five of a system already in motion.
Implementation is a different job. It is high intensity, time bounded, and full of friction. It requires someone to walk into an organisation that has not yet absorbed the change, clarify roles that overlap or conflict, test procedures that look fine until they meet the building and the people, absorb the resistance that every real change produces, and translate a clean concept into the lived, granular routines that staff will actually follow. Asking the permanent manager to do all of that, from a standing start, on top of the role they were hired for, is asking one person to be two people at two different tempos. The concept stalls in the gap between the advisor who wrote it and the manager who is supposed to run it, because no one was given the distinct job of building the bridge. And building that bridge calls for an unusual mix: a degree of entrepreneurial instinct, enough human resources sense to handle team building and training, and the communication skills to work in both directions, up to leadership and down to the people on the ground.
I once spent a long conversation with a prospective client who could not see past that single permanent position. The whole picture had narrowed to the question of who would sit in the security manager's chair. The concept was sound, the intention was serious, a large project with a new concept integrated into an older one and an imminent security need, and the entire plan rested on finding the right nine to five hire to carry it. I tried, without much success, to make the case that the chair was not the first problem. The first problem was that the ground had not been prepared for whoever would eventually sit in it. There is a role before that role. Someone has to do the implementation so that the permanent manager inherits a function that runs and has already been tested and stressed, rather than a binder they are expected to animate alone while also keeping the lights on. After that phase the security manager can enter with a clean sleeve, because the interim has done the difficult part, including the storming phase among colleagues. Retention will be longer, and turnover will be low.
That triangle, the author of the concept, the implementer who prepares the ground, and the steady state manager who eventually runs it, is the structure most organisations collapse into a single hire. The collapse is the error. The implementer, once finished, can be retained as a supervisor or subject matter expert to support the operational phase, but that is a lighter role, and a deliberate one.
What the work actually is
Implementation sounds abstract until you are inside it, so let me make it concrete with a problem that looks trivial and was not.
During a build for a sensitive, complex, very high-end client, my 2ic and I spent an unusually large amount of time on a door that to many would seem a silly thing to dwell on. The client returned home along an approach of roughly eight metres of exposed, very busy open sidewalk before reaching the entrance. Security walked the approach with them and opened the door with a key card. On paper this is one line in a concept: control the transition from vehicle to residence. In reality it was a small knot of competing problems. The door hardware itself was not logical from a procedural standpoint. The sequence of who controlled what, and when, across the three transitions of vehicle, approach, and threshold, was not obvious. We watched camera footage of arrivals, repeatedly, over a long period, on and off, working out not the perfect way to manage that door but the least bad one, the option that kept control and awareness intact across the whole movement without making the client's daily homecoming an ordeal, while still holding the discreet, controlling position the situation demanded.
I will not set out the procedure we settled on, for obvious reasons. The point is not the solution. The point is that this is what implementation consists of. A concept can say control the transition in a few words. Turning those few words into something a team can execute the same way every night, under fatigue, without thinking, and as a logical SOP that can actually be trained, took a week of attention to one door. Multiply that by every door, every routine, every handover, every point where the clean sentence meets the awkward building, and you have the real shape of the phase. It is not management. It is a thousand last miles, each one client specific and operations specific.
And here is the protection specific cost I mentioned earlier. That door was not an efficiency question. It was an accountability question. If the transition had been designed badly and something had gone wrong on those eight metres, the failure would have had to be explained, to upper management and to the client, after the fact. In most disciplines a botched implementation produces a missed target. In ours it produces an exposure you have to answer for. That is why the phase cannot be left to absorb itself, and why treating it as overhead, as the soft part between the real work of design and the real work of running, is a category error.
Why it disappears
The cruelest feature of this phase is that when it is done well, it becomes invisible, which is precisely why it is undervalued and underfunded.
The build behind that door took a series of team meetings, training, and steady correction to reach the point where the team, the routines, and eventually the client, unknowingly, were all looking in the same direction. The alignment, the testing, and the slow work of getting people to do the same thing the same way until it became second nature. And then it ran. It still runs, eight years on. The effort dissolved into routine so completely that from the outside it looks as though it was always that way, as though no one ever had to build it.
That is the trap. Because good implementation erases its own evidence, it is easy to conclude it was never necessary. The function works, so surely it would have worked anyway. It would not have. The smoothness is the residue of the labour, not proof the labour was optional.
The role before the role
What I am describing is, in the end, a specific and nameable function: an interim implementation phase, led by someone whose job is explicitly to prepare the ground and then make themselves redundant. Not long term programme management, which can quietly create the dependency it claims to solve. The opposite. A focused, time bounded engagement that aligns the people, tests the procedures, solves the doors, and hands a working function to the permanent manager who comes after. Depending on the urgency, the work draws on strategic empathy, change management, team building, awareness, and plain operational tactics, in whatever proportion the organisation and the moment require. The aim is narrow and disciplined: to move the concept from paper into practice without breaking the organisation around it, and then to leave.
This is the phase most organisations skip, and the one on which the whole project most often stands or falls. It is overlooked because it is unglamorous, miscounted as overhead, and invisible once complete. It is, I have come to think, the most consistently underestimated part of building a security function, and the part where the difference between a concept that works and a concept that merely exists is actually decided.
Ombrex Consulting works in this transition phase. Where it is useful, that work is described at ombrex.org.
Ombrex