I work across a lot of different organisations, and there’s a pattern I run into so often now that I’ve stopped thinking of it as unusual: a security function with genuinely good people, doing real work, that cannot tell you with any confidence how much of that work there is.
If you are to ask how many access requests came in last month, or how many risk exceptions were raised and by whom, often I see an honest admission that finding out would take a couple of weeks and a fair amount of manual digging across several systems that don’t talk to each other.
The assumption is usually that a team drowning in requests must at least know how many requests it’s drowning in, but in practice the busier the function, the less time anyone has had to step back and build a way of seeing the whole picture, and the more that picture has fragmented over the years without anyone deciding it should.
How it usually gets to that point
Typically this comes from a long series of individually reasonable choices by people or teams. A team that’s been getting swamped starts using a SharePoint page to bring some order to it, another team has been on the same ticketing tool since before most of the current staff joined, and migrating off it has simply never been anyone’s top priority, and a third team ends up mostly reachable through direct Teams or Slack messages.
Run that pattern for the better part of a decade, across several specialist teams, and you end up with a security function where nobody, including the people leading it, can produce a full and current picture of everything coming in.
What that actually costs, in practice
This is the part I think gets underestimated, because it doesn’t announce itself as a cost, but it does accumulate. Here’s what I see happening time and time again:
Work gets duplicated, because two teams end up solving the same problem without either one knowing the other is involved, since there’s no shared view of what’s currently in flight.
Requests go quiet, not through any individual’s fault, but because something lands in a channel that isn’t being actively watched and simply never gets picked up.
Compliance gets harder to prove. If a request never had a documented owner or a record of when it was picked up, there’s nothing to produce when GRC or an auditor asks for evidence it was handled.
And almost always, one team ends up acting as an informal switchboard for the rest of the function, spending a disproportionate amount of its week working out whose job a given request actually is rather than doing security work itself.
Why the obvious fix, mandating one tool, doesn’t hold up
The instinct is to force all teams onto a single system but as anyone who has worked in a large, complex organisation will understand in practice it isn’t the most effective route. Asking an established team to give up a way of working it built for itself, on somebody else’s timeline, using somebody else’s tool, is fundamentally a dispute about ownership and control, even though it gets framed as a straightforward technology decision. That dispute rarely resolves the way an org chart would suggest it should. If forcing consolidation genuinely worked in practice, most of the organisations I’ve worked with would have done it years ago. The fact is that it’s a genuinely difficult thing to pull off internally, for reasons that have very little to do with technology.
Here’s how we address it
The approach I’ve found actually holds up doesn’t touch any of the tools teams already rely on. Instead, it puts one clear, well-understood way in, in front of whatever is already running behind it, and it’s usually built in three stages.
The first stage is mapping what the function actually does, based on what teams are genuinely being asked for day to day rather than what a policy document says they’re responsible for. That produces a small, manageable number of named capabilities, mapped against something recognisable like NIST CSF, so that leadership, audit, and the teams themselves are finally working from a shared reference point.
The second stage turns that map into a proper service catalogue. Every distinct thing the business can reasonably ask for gets a name, a named owner, an agreed route, and a response time that’s actually been agreed to rather than assumed. This stage takes the longest, as it’s about negotiation and getting team leads to agree, in writing, on where one team’s remit ends and another’s begins.
The third stage is building a single door in front of all of it. Search-first, so that whoever is asking is routed automatically to whichever system already owns that type of request. The person asking doesn’t need to know which of the different systems sits behind the door, they ask once, in one place, and it reaches the right team.
Below is an illustrative example for a typical large security team of what that mapping looks like once it’s been done properly.
An example capability map , mapped to NIST CSF 2.0, with the request types underneath each one.
And this is the pattern that sits behind the door itself, showing how a request actually moves once someone has asked for it.
Architecture showing the front-door pattern: one entry point, routed to the team that already owns the work.
What changes once this is in place
Improved user experience. Nowusers know exactly where to go and can see their requests are being processed.
Operational efficiency. Reduced noise, better triage and less manual effort.
Scalability. Structured workflows enable growth without linear team expansion. More demand can be absorbed by the same headcount.
Risk reduction. Clear ownership, reduced misrouting and defined escalation paths lower operational and security risk across the business.
Better decision making. Accurate metrics and reporting, like the illustrative dashboard below, allow data-driven prioritisation and evidence-based resource allocation.
This is a mock-up built on illustrative data to show what good reporting looks like once the front door and routing exist.
An illustrative example of the kind of reporting a mapped, routed function can produce once demand is visible in one place.
If this sounds like a familiar challenge, here’s where I’d start…
Get each team to write down what they actually spend their time being asked for, not what’s in their job description, in a normal week. That alone tends to surface the first surprise, because it’s usually the point where two teams realise they’ve both been handling the same type of request without ever comparing notes.
From there I’d map those against a small number of capabilities, five or six is typical, and check whether leadership, audit, and the teams themselves would even recognise the same map if you showed it to each of them separately. If they wouldn’t, that gap is the real starting point.
I’d only look at the front door itself once that groundwork existed. Building a single entry point in front of different teams that haven’t yet agreed what they each own just moves the confusion somewhere more visible.
And of course, if this is something you are looking at and would like a discussion on how we’ve handled it in the past, please get in touch.
