IT security is not a department: it is a condition of operation. No firewall, no EDR and no phishing awareness campaign can protect a process that nobody has ever documented, because risk is not measured where nobody knows what is happening. This is why the most effective sentence in IT security remains an uncomfortable one: we cannot protect what we do not know we have.
The symptom: the ticket gets closed and the risk stays
The typical case is recognisable. A user reports a suspicion, the ticket is taken on, the user is briefed, the case is closed. From the SOC's point of view it is resolved. But nobody asked what data was at stake, and so nobody could establish whether the case was a false positive or the beginning of a data loss that nobody has noticed yet.
The process closed, the risk did not. This is the operational difference that separates a real control from an apparent saving: the former measures, the latter files things away.
The four questions only the business can answer
Collaboration is not about holding more meetings. It is about obtaining four pieces of information that exist nowhere except inside the organisation:
What is the data that, if lost, would actually cause harm? Not "sensitive data" in the abstract: the revenue from a specific customer, the continuity of a service in a given window, the legal liability on a document.
How long can we stay down? A manufacturing company with a line stoppage costing 40,000 euros an hour and a professional firm have opposite needs over the very same vulnerability.
Who has access to what, really? Not what the access matrix says: what people do. The matrix is a document, the process is a habit.
Which process holds up, and which one only holds up because nobody has touched it yet?
Anyone who works in IT security knows that the fourth one is the damaging one. It is the reason why the most effective exploit is almost never technical, but social: it goes through a process that "has always worked this way" and through a user who was right to trust it.
It is not a novelty: separation of duties is a principle from 1790
It is worth remembering where the idea comes from. The concept of separation of duties was born with the Industrial Revolution and the first double-entry accounting, where nobody could be both the author and the verifier of their own records. The principle is that no single act should be able to pass unobserved.
In IT security the same logic has a more recent but well-established tradition: from the early work on honeypots in the late 1980s — recounted in From false maps to buckets — two operational conclusions emerge. The first is that detection is not an accessory, it is the product. The second is that no control works if the person who is supposed to apply it does not know what they are doing.
Put plainly: a security department that holds all the decision-making power and no operational responsibility produces perfect, ignored procedures. A department that has no power but knows the processes produces real improvements. The first scenario is easier to sell.
The hidden cost of isolation
An IT function that only talks to IT produces a very specific and underrated risk: it optimises its own work instead of reducing the organisation's risk.
A team that measures its success by the number of tickets closed, by uptime, by patches applied on time, is incentivised to close the ticket. A team that measures its success by risk reduction is incentivised to ask the uncomfortable questions: why that access is needed, who created it, and what happens if we revoke it. These are two incompatible behaviours, and both are rational relative to the metric you choose.
The same applies to training. A phishing awareness campaign "with the click rate falling" can be won by running the most unpleasant training in the world. A useful campaign is recognisable by a different effect: reports of suspicion increase, because people have learned that reporting is useful and not punished. A fall in clicks with an increase in reports is a success. A fall in both, very often, only means that nobody is looking any more.
How to do it, without it becoming an annual memo
Collaboration that works has three characteristics: it is small, it is frequent and it produces artefacts. Concrete proposals:
A point of contact for each area. Not a committee: a single person per department, who knows the processes and answers for the questions. It costs a few hours a month.
A register of critical processes. Only the ones that keep the business running. Ten lines per process, written by the person who does it, not by the person who imagines doing it.
Review without surprises. Quarterly, in the calendar, with the same regularity as the budget. If it is skipped twice in a row, the decision log says so and needs to be revisited.
Decisions are written down. Minutes are worth as much as the meeting: without a record, collaboration is a personal habit that disappears with whoever promoted it.
The test to understand whether it works
The most useful question a security officer can ask the organisation is not about controls, but about people:
If tomorrow your IT manager, your revenue department were to ask in what way IT security supports them? And does he/she know?
If the answer is vague, the problem is not technical. If the answer is "I don't know, but I imagine it depends on...", the defence perimeter is a list of intentions, and intentions don't hold.
In summary
Technical controls are necessary and never enough: they cover known vectors, and attackers do not read your lists. The control that closes the circle is organisational: knowing what you are protecting, knowing how much it costs to stop, knowing who does what. That control cannot be bought and cannot be installed, it is built with people, one conversation at a time.
It is also the only security activity that improves when the budget goes up. All the others improve when the budget doubles.