The Walls Hold. The Seams Do Not
How one attack moves through security seams while each team sees only its own fragment.
This is Part 3 of “The Corporate Security Gap”, a series on why companies have security on paper but not as a function. Part 1: The Function That Never Got a Seat. Part 2: The Cost Center That Cannot Count.
Follow a composite incident through one company, assembled from patterns that recur. It starts as an email: a supplier invoice, slightly off, opened by someone in accounts. The cyber team will eventually log it as phishing. The credentials it harvests are used a week later to register a contractor badge, which physical security issues against a clean-looking request, because nothing in their system links badges to compromised mailboxes. With a badge and a mailbox, the attacker schedules a payment change, and the fraud team catches it only when the real supplier calls about a missing invoice, three weeks and one transfer too late.
Three teams. Three logs. Three partial stories. Nobody saw one attack, because the attack did not happen inside any single team’s territory. It happened in the joints between them.
This is the third article in this series, and it goes somewhere the first two did not: inside the security function itself. Part 1 argued that security is absent from the table where value is weighed against risk. Part 2 showed the mechanism that keeps it absent: a function that cannot count itself cannot defend itself. But suppose both problems were fixed tomorrow. Suppose the board offered security a seat and a budget. In most companies, there would be no one to take the seat, because there is no “security” to invite. There are four: physical security, cybersecurity, fraud prevention, business continuity, each with its own head, budget, KPIs, and reporting line. The company would have to send four people to fill one chair. That is the architecture problem, and it does not dissolve with money or goodwill.
Coordination is not convergence
The standard answer to silos is coordination: a monthly cross-team meeting, a shared incident channel, a liaison role. It is worth being precise about why this is not enough, and the distinction comes straight from the logic of Enterprise Security Risk Management, the ASIS framework this series has used as its benchmark for what a security function looks like.
Coordination means separate functions exchanging information while each keeps its own picture of risk, its own priorities, and its own definition of an incident. Convergence means a single picture of risk that all the disciplines feed and share, and a single owner for any incident regardless of which wall it touches first.
The difference shows up at the worst possible moment. Coordinated teams meet monthly; attacks move daily. A coordinated structure asks, in mid-crisis, “whose incident is this?”, and the honest answer for any incident that crosses domains is “partly everyone’s”, which in practice means no one’s. A converged function never asks the question, because ownership was settled by design, before the incident existed. The ASIS Foundation’s research on convergence found that only about one in five organisations have actually merged their security disciplines into anything like a single picture. The rest run some version of the four-walls model, and most of those that have not converged report no plans to. The architecture is not an oversight. It is the default.
Where the blind spots live
The gaps are not random; they sit at three predictable junctions, plus one structural reason they persist.
Get Oleksandr Butko’s stories in your inbox
Join Medium for free to get updates from this writer.
First, the physical-cyber seam. Badges, door controllers, cameras, and visitor systems are physical security’s domain, and they are also networked computers, which makes them cyber’s domain, which in practice often makes them no one’s. The traffic moves the other way too: a compromised mailbox becomes a convincingly “verified” request for site access, as in the incident above. Verizon’s 2025 Data Breach Investigations Report puts the human element in roughly 60% of breaches, and credential abuse as the single most common way in, at 22%. Credentials are exactly the asset that lives on both sides of this seam: harvested in the cyber domain, spent in the physical one, and logged by two systems that do not read each other.
Second, the cyber-fraud seam. A growing share of significant fraud now begins as a security event: a phished mailbox, a spoofed domain, an account takeover. The mechanism is well documented even where the exact proportion is not, because the credential is the hinge, stolen in the cyber domain and then spent as fraud. But in the silo model, cyber closes its ticket when the technical compromise is contained, and fraud opens its case when the money moves. Between the closed ticket and the opened case there is a quiet corridor, often days or weeks wide, in which the attacker holds compromised access and has not yet done the thing fraud is watching for. Each team performs well by its own KPI. The corridor belongs to neither KPI.
Third, the everything-continuity seam. Business continuity plans are routinely written by a separate team, against a separate scenario list, and tested on a separate calendar from the security disciplines whose failures would actually trigger them. The result was visible at global scale in July 2024, when a faulty update from a security vendor crashed more than eight million Windows machines in a morning. One event was simultaneously a cyber incident (the failure came through the security stack), an operational crisis (a quarter of the Fortune 500 disrupted, every one of its airlines), and a continuity test that much of the market failed in public, at an estimated 5.4 billion dollars in direct losses for the Fortune 500 alone, of which insurance was expected to cover perhaps a tenth. Companies whose continuity plans assumed “cyber incident means malicious attack” discovered that their recovery playbooks, their security tooling, and their crisis ownership lived in three different rooms.
Fourth, and this is the part that keeps the other three in place: the silos are individually rational. Each head of function is hired to optimise a wall, is budgeted for a wall, and is measured on a wall, and by those terms each is doing the job well. The blind spots are not anyone’s negligence. They are the predictable output of local optimisation: four functions, each maximising its own metric, produce a whole that no metric describes. This is the same trap Part 2 found in measurement, one level down. There, security counted activity instead of value. Here, even the activity is counted in four incompatible ledgers.
What a converged function changes
Set the two architectures side by side and the difference is not subtle. In the four-walls model, the incident above is three records in three systems; in a converged function it is one case with one owner from the first phishing alert. In the four-walls model, escalation means each team deciding separately whether its fragment looks serious enough to raise; in a converged function the fragments assemble into a picture that escalates itself. In the four-walls model, the board hears four reports in four vocabularies, which, as Part 1 argued, is one reason it hears none of them at the level where value is weighed against risk. A converged function reports one risk picture in one language, which is the precondition for everything the first two articles in this series asked for. A seat at the table presumes someone who can sit in it.
The line
Security without governance is just guarding, and guarding in four separate uniforms is still guarding, just with seams.
An attack does not read the org chart. It does not pause at the boundary between the cyber team’s mandate and the fraud team’s, and it is under no obligation to stay in the domain where it was first detected. The org chart is a map of who reports to whom. The attack follows a different map: where the assets are, and where the walls do not quite meet.
So here is the question this part of the series leaves behind. Count the units in your company with “security”, “fraud”, “resilience”, or “continuity” in their name. Now ask which single person would own an incident that crossed all of them, on day one, by design rather than by improvisation. If the count is four and the answer is nobody, then the company has multiplied guards and divided the function, and it is worth asking openly: how many security departments does it take before no one is responsible for security?
The next part of this series follows the seams past the company’s own walls, because the joints do not stop at the perimeter. They continue into every supplier, platform, and partner the company depends on, and that is where they widen.
Originally published at https://oleksandrbutko.substack.com on June 18, 2026.
