What Milano Cortina 2026 taught me about security design
An Olympic Village normally has a perimeter: a complex of buildings, controlled access points, athletes and delegations inside. From a security perspective, the advantage is obvious: it physically separates a protected space from its surroundings.
At Milano Cortina 2026, that model could not be applied everywhere. The Olympic and Paralympic Winter Games took place across a vast territory, with six Villages distributed across Lombardy, Veneto and Trentino-Alto Adige. Milan and Cortina had dedicated facilities; Predazzo used a refurbished existing facility. In Bormio, Livigno and Anterselva, by contrast, athletes were accommodated in existing hospitality facilities distributed across the territory.
It was a reasonable organisational choice, making use of infrastructure already available in the host locations. But from a security perspective, it raised a far from simple question.
How do you protect an Olympic Village when the Village, understood as a single physical space, does not exist?
The perimeter problem
In a major event, the perimeter organises access, controls flows, distributes responsibilities and establishes the conditions under which people, materials and vehicles enter a protected area. It works, however, only when there is something that can actually be enclosed.
A hotel is not a purpose-built Village: it has its own architecture, organisation, services and operational dependencies. When there is more than one hotel and they are not adjacent, the problem multiplies. We could not simply draw a larger boundary: a perimeter enclosing entire parts of a resort town would have had consequences that were hardly sustainable for the life of the community and for the functioning of the Olympic system.
On the other hand, abandoning a single perimeter could not mean abandoning security requirements.
It was not a quantitative problem. It was not a matter of multiplying controls.
It was a problem of architecture.
The decision in Livigno
During the planning phase in Livigno, as Security Manager for the Villages, it became clear to me that some elements of the master plan needed to be reconsidered. This was not about moving a barrier or changing an access point: we were trying to apply a model designed for a single structure to a group of separate buildings.
I discussed it with the people responsible for the Village function and for Venue Design & Overlay, the structure responsible for venue design and overlay. We arrived at a different solution: rather than treating the hotel complex as a single space to be enclosed, we organised protection into several autonomous areas, coordinated within the same system.
A model based on multiple bubbles.
Each facility would have its own security configuration, while security governance, responsibilities and relationships with the other functions would remain integrated.
The model was subsequently adopted in the hotel-based Villages in Bormio and Anterselva, with the adaptations required by each location.
The solution did not simply mean multiplying costs. It changed the way security was built. Each area required common standards and governance capable of keeping the system together, but the distributed model also made it possible to avoid measures that would have been necessary for a centralised structure: there was no need, for example, to create a “clean road” or to apply the same level of control to every individual transfer.
I am not claiming that this was the first time anyone had imagined distributed protection. For our project, it was a solution to a specific problem, developed through the interaction of different areas of expertise.
That, more than the originality of the solution, is what I consider important.
The physical boundary did not disappear. It simply stopped being the boundary of the risk.
Protecting the Village without stopping it
A Village is not simply a place where athletes sleep. It is a system that has to function continuously. People move, supplies arrive, services have to be provided, and activities have to continue without every operational need becoming an exception requiring special handling. In hotels, this interdependence is even more apparent.
Take athlete transportation. The security of the departure point, the journey itself and the destination venue are one process. If each function designs its own part without coordinating with the others, gaps appear, responsibilities become unclear and procedures become incompatible.
The same applies to logistics. Protecting a facility means understanding which services it depends on and how continuity will be maintained. A measure that appears effective in isolation becomes a problem if it prevents the activities it is supposed to protect from functioning properly.
That is why it is not enough to ask, “How secure is this facility?”
We also need to ask:
“How does this facility function when its security measures are active?”
The two questions need coherent answers.
This does not mean sacrificing security to operational requirements. It means designing measures that are proportionate to the risk and workable in the real context.
Security inside the project, not at the end
There is a recurring mistake: a project is designed, built and organised, and only at the end does Security arrive to check whether everything is sufficiently protected.
It is a bit like calling the structural engineer once the walls are already finished.
A function involved only at the end can still identify weaknesses and impose controls, but it will struggle to create its maximum value.
When Security is involved in the design phase, its role changes. It can help choose a solution that is safer and more sustainable from the outset, identify a bottleneck before it becomes a problem, and highlight a dependency that no other function had considered.
At Milano Cortina 2026, one of the most demanding aspects was the continuous coordination with other functions: Logistics, Villages, Transport, Venue Management, Protocol and Safety, each with its own objectives, constraints and responsibilities.
At the beginning, I was directly involved in many aspects, from reviewing the master plan to defining security requirements. As the organisational structure took shape and additional colleagues joined, the work became increasingly focused on coordination.
The need for integration, however, did not change.
Security’s role was not to replace those areas of expertise, but to make sure that protection requirements were incorporated into design and operational decisions.
And to translate: to turn a risk into an operational consequence that others could understand, and to understand how a decision made elsewhere could change that risk.
If addressed by Security alone, the hotel-based Village problem would have produced requirements that were difficult to implement.
If addressed only from a logistics or hospitality perspective, it would have overlooked essential protection requirements.
The solution came from bringing those perspectives together, not from mechanically applying a procedure.
Security should not be the final inspection of a project. It should be part of the project.
A lesson that goes beyond the Games
The reasoning behind the hotel-based Village model applies to many other organisations: a company with distributed sites, a campus made up of non-contiguous buildings, an event using multiple facilities, or an organisation in which people, services and activities depend on different parties.
The temptation is to apply the same model everywhere.
Yet what works at one site may be inappropriate at another. A measure that is effective but not coordinated with adjacent measures may create new vulnerabilities. A requirement introduced too late may force costly changes or avoidable compromises.
At Expo Milano 2015, I had described the need to reconcile rigidity and flexibility in the management of logistics controls. I called that approach flexgidity: rigid rules, flexible application.
At Milano Cortina, I encountered the same principle in a different form.
The challenge was not to make a procedure flexible, but to rethink the architecture of protection itself.
The security requirements had to remain fixed; it was the way we met them that had to become flexible.
The perimeter could not be a single one, but governance still had to remain integrated.
In that sense, I see flexgidity not as a technique tied to one particular problem, but as a broader principle:
keep rigid what must remain rigid, and make flexible what needs to adapt to the context.
This leads me to three convictions:
- A standard guides design; it does not replace it. First understand the context, then identify risks, dependencies and responsibilities, and finally define the measures, checking that they work in the real system.
- Protection can be distributed without fragmenting responsibility. Autonomous areas, integrated governance.
- Security should be designed together with the people who make the system work. Technical expertise is essential, but so is the ability to bring people who see the same problem from different perspectives to the same table.
Because security does not arise only from what we protect.
It also comes from how we make everything that needs to be protected work together.
Francesco di Castri
Security Manager, Villages, Ceremonies, IOC and IPC, Fondazione Milano Cortina 2026.
The views expressed are professional and personal. They do not constitute an official communication by Fondazione Milano Cortina 2026 and do not describe in detail the security measures adopted.
Leave a Reply