Pick any well-run security program and look at the tools it runs on. There's a SOAR platform automating the incident response. There's a ticketing system tracking the work. There's a consulting engagement — a firm or a fractional CISO — that produced the roadmap everybody's working against. All three are doing real work. None of them is doing the same work.
I ran security at four companies before I started building, and in every one, some version of all three was in the stack. What none of them had was the piece in the middle: the part where you actually go into production and make the change. Each tool handed the ball off right before that part.
SOAR is genuinely good at what it does. An alert fires, a playbook runs, an endpoint gets isolated, an IP gets blocked, an account gets disabled. Fast, automated, no human in the critical path. That's exactly what you want when you're reacting.
But look at what those actions have in common: they're all reactive, and they're all fire-and-forget. The playbook assumes the action is correct and moves on. If you isolated the wrong host, the fix is another action — and that action doesn't put the host back the way it was, it builds a new state that resembles the old one. More to the point, SOAR doesn't touch the thing that generated the alert in the first place. It doesn't fix the over-permissioned role, rotate the key that shouldn't exist, or re-segment the network so the next alert never fires. Response is not architecture change. SOAR was never built to be.
The ticketing system is the system of record, and it's good at that. Every request has an owner, an SLA, a status, an audit trail. You can prove work was requested and prove when it closed.
What it can't do is close the ticket. A ticket that says "tighten this IAM role" is a description of work, not the work. Somebody still has to open the console, understand what depends on that role, make the change, and be the one holding it if something breaks at 2am. The ticket tracks that this needs to happen. It has no opinion on how to do it safely, and no way back if it goes wrong. So it sits — and I've written about why sitting is the rational move for the person who owns it. The tracking is honest. The completion is somebody else's problem.
The consulting deliverable is often the best artifact of the three. A real assessment, a prioritized roadmap, a clear picture of where you are and where you should be. The good ones are genuinely excellent.
Then the engagement ends. The roadmap is a document, and the document doesn't touch production. Implementation is scoped out, or it's "phase two," or it's handed back to the internal team that was already too busy to do it — which is why you hired the consultant. The hard part isn't knowing what to change. Most teams already have a decent idea. The hard part is safely executing the change against a live system nobody fully understands. That part gets designed and then handed back.
Line these up and the pattern is hard to miss. SOAR stops at the alert. ITSM stops at the ticket. The consultant stops at the roadmap. Each one owns a real fragment of the job and does it well. And each one hands off at exactly the same place — right before the sentence "now go safely make the change in production."
That's not three separate gaps. It's one gap, and every tool in the stack is drawing its boundary along the same edge of it. The reason they all stop there is that it's the hard, risky part: high-stakes changes to systems you don't fully understand, under time pressure, with no clean way back if you're wrong. Reacting is easier. Tracking is easier. Advising is easier. Doing is where you get paged.
So the completion gap — the actual safe execution of change, with a way to undo it — is the part nobody in a normal stack owns. It's not a missing feature in any one of these tools. It's the space between them. And it happens to be the whole game.
If you're running a security program, count the handoffs. I'd bet they all land in the same spot.