When everyone does their job correctly, but no one governs the problem as a whole.
Incidents happen. Like rain, they are not entirely within our control: we can anticipate them, reduce their effects, prepare for them, but we cannot decide that they will never occur. What does depend on us is something else: knowing who does what when they do.
Imagine a major event. It is evening, thousands of people are leaving the venue and everything is proceeding normally. Security has opened the planned access points, stewards are directing the crowd, the police are managing traffic, and the transport system is handling passenger dispersal.
Then a metro station is temporarily closed.
The information reaches the control room, but no rule establishes who should pass it on to the operators on the ground, through which channel, or within what timeframe. Some receive it, others do not. People continue heading towards the station, while others turn back looking for an alternative route. Within minutes, two flows collide in a space that was never designed for that situation.
No organisation has violated its own procedures. Each has carried out its responsibilities within its defined roles and competencies.
And yet the system has failed.
The problem was not inside one of the organisations. It was in the space between them.
Security organised in compartments
Modern organisations are structured around functions. That is normal, and necessary. Security deals with intentional threats, safety with accident prevention and the protection of people, IT with information systems, and operations with business activities. Then there are human resources, maintenance, logistics, suppliers and public authorities. Each has its own responsibilities, competencies and procedures.
The problem begins when a risk cuts across several functions at the same time.
Think of a logistics warehouse. A failure in the access control system may initially look like a technical problem. But if it prevents employees from entering, it disrupts operations. If it leaves some access points open, it becomes a security issue. If it affects emergency exits, safety becomes involved as well. The same event produces different consequences that need to be assessed and managed together.
Yet in many organisations, each function continues to look at it through the boundaries of its own responsibilities.
Risk does not respect the organisation chart.
Responsibilities correctly assigned, risk still exposed
One of the most insidious situations occurs when every responsibility has been assigned, but nobody is responsible for assessing the consequences of how those responsibilities interact.
One supplier manages video surveillance, another access control. Guarding is outsourced to a private security company, maintenance sits with a technical department, and emergency procedures belong to another function. Everything is perfectly legitimate.
But who checks that these elements actually work together? Who decides what should happen if one system fails while another reports an anomaly? And, above all, who has the authority to decide which activities should remain operational and which should be suspended?
These are not theoretical questions. They need to be answered before an incident occurs, because during an emergency, time spent establishing who has the authority to decide is time taken away from managing the problem itself.
Coordination does not mean commanding everyone
This is where a fairly common misunderstanding comes in. Coordination is often imagined as a hierarchical structure in which someone gives orders and everyone else follows them. In complex systems, it does not work that way.
During a major event, the organisations involved retain different responsibilities, competencies and chains of command. No Security Manager can replace public security authorities, emergency services or infrastructure operators, and should not try to.
Coordination is instead about building a system in which information flows, responsibilities are understood, and decisions are taken by those who actually have the authority to make them. This is the subject explicitly addressed by ISO 22320:2018, which deals with incident management: roles, responsibilities, information flows and cooperation between different organisations.
Coordination does not remove individual responsibilities. It prevents them from becoming watertight compartments.
Procedures are not enough
An organisation can have an impressive number of procedures and still remain vulnerable: an emergency plan, a business continuity plan (the relevant reference here is ISO 22301), access procedures, communication protocols, and contracts that define suppliers’ obligations in minute detail. All useful documents. But their existence does not prove that the system is capable of dealing with a complex situation. To find that out, you have to test it.
One of the most effective tools is the tabletop exercise: an exercise in which people from different functions work through a simulated scenario together and have to decide how to respond. You do not need special effects or hundreds of participants. Sometimes a room, a floor plan and a well-designed question are enough.
For example: it is 6:30 p.m., the warehouse is fully operational, the access control system is down and the supplier says recovery will take at least four hours. Meanwhile, an unauthorised person is reported inside the logistics area. Who is informed? Who assesses whether operations should be suspended? What compensating measures can be adopted, and who authorises them? Who communicates the decision to employees?
It is often precisely in these exercises that the most interesting weaknesses emerge. Not because procedures are missing, but because each person discovers that their own procedure assumes an action that someone else did not know they were expected to take.
Where to start
Identifying the problem is only half the job. The other half is building, before the event, a few simple and verifiable elements:
- A person responsible for cross-functional risks. Every risk that cuts across several functions should have a name attached to it, not a committee: someone who monitors it and brings it to the attention of whoever has to decide.
- An escalation and decision-authority matrix. Who can suspend an activity, who can accept residual risk, who decides when information is incomplete, and what happens if two managers assess the same situation differently.
- A shared risk register. Not one for each function, but a single register that makes dependencies between functions, suppliers and systems visible.
- Communication channels and timing defined in advance. Who informs whom, through which channel, within what timeframe, and how it is verified that the message has been received.
- Regular exercises with everyone around the table, including suppliers, followed by a review of procedures based on what emerges.
This is not about creating new layers of bureaucracy. It is about verifying whether the structures already in place are genuinely capable of working together.
Governance starts with uncomfortable questions
Risk management is not simply about assigning probability and impact to every threat. It is also about understanding how an organisation makes decisions about those threats. ISO 31000:2018 explicitly emphasises integrating risk management into governance, strategy and decision-making. ISO 22361:2022, which addresses crisis management, carries the same principle into the most critical moment: leadership, decision-making and communication when information is incomplete and time is limited.
If the answers to the questions above are unclear, we have identified an organisational vulnerability. Not necessarily an error, but certainly something that deserves attention.
Security is not the sum of its parts
When we conduct a security assessment, we naturally tend to look at what we can see: access points, fences, cameras, lighting, procedures, personnel and technology. These are all important elements. But some of the most significant vulnerabilities are not visible during a site survey. They have no place on a floor plan and cannot be photographed. They are found in handovers of responsibility, in communications we take for granted, and in decisions that nobody knows they are supposed to make.
An open gate is an obvious vulnerability. An organisation in which nobody knows who is authorised to order it closed may be a much harder vulnerability to identify, and perhaps a more dangerous one.
A system made up of excellent individual components is not automatically an excellent system: its effectiveness also depends on the relationships between those components, the ability to share information, and the clarity with which decisions are made. This is where security stops being merely an operational function and becomes a matter of governance.
We cannot decide when it will rain. But we can decide, in advance, who has the umbrella and who has the authority to decide when to open it. When something goes wrong, the problem rarely has the courtesy to respect the boundaries of our responsibilities.
Are we really sure that every risk in our organisation has someone responsible for it? Or have we distributed responsibilities so effectively that we have left uncovered the things that connect them?
Essential sources
- ISO 31000:2018 — Risk management — Guidelines. Principles, framework and process for risk management.
- ISO 22320:2018 — Security and resilience — Emergency management — Guidelines for incident management. Roles, responsibilities and cooperation in incident management.
- ISO 22361:2022 — Security and resilience — Crisis management — Guidelines. Leadership, decision-making, communication and preparation for crisis management.
- ISO 22301:2019 — Security and resilience — Business continuity management systems — Requirements. Business continuity. (Likely to be updated soon; ISO/CD 22301.)
The scenarios described are hypothetical examples used to illustrate organisational vulnerabilities and do not refer to specific events or organisations.
Francesco di Castri
Leave a Reply