The real cost of silos in a control system

How silos are installed

A new obligation appears: a function is created to handle it, along with its procedures and tool. An incident occurs: the relevant control is reinforced, locally. An entity is acquired: it keeps its own arrangements, pending harmonisation — a timeframe that stretches on. Software is acquired for a specific need: it becomes the system of record for that function, with no connection to the others.

Over the course of a few years, the organisation has acquired multiple mapping systems, multiple control plans, and multiple recommendation frameworks. Each of them is defensible; their juxtaposition is no longer so.

First cost: the blind spots

The most serious cost is also the least visible — by definition. When each function assesses its scope using its own scale, a significant risk may not appear anywhere as major.

The mechanism is always the same: aggregation does not happen by itself. A sum of partial views does not produce an overview; it produces the illusion of complete coverage.

Second cost: locally optimal decisions

A second, more subtle effect concerns trade-offs. A decision may be perfectly rational with regard to the objectives of the person making it, and unfavourable for the organisation as a whole.

The classic case is that of a group entity that optimises its own results — by reorienting its production, reducing a cost item, or choosing a cheaper service provider — to the detriment of another entity that depended on it. The former's indicators improve; those of the group deteriorate.

This question goes beyond risk management: it touches upon governance. However, it can only be addressed if someone has a cross-functional overview — which the rigid compartmentalisation of departments makes precisely impossible.

Third cost: the burden imposed on the business units

That cost is felt directly by the operational teams. Over the course of the same quarter, a department manager might be contacted by compliance for a review, by risk management to update a mapping exercise, by internal control to provide evidence, and by internal audit for an assignment. Four requests, often on similar topics, with four formats and four different contacts.

The consequences are predictable: fatigue, rushed responses, a declining quality of information transmitted — and, ultimately, the perception of control functions as an administrative burden rather than as support. Coordinating requests is one of the most immediate benefits of an orchestration approach.

Fourth cost: inconsistency with the supervisor

For a regulated entity, this cost can become a risk in itself. When a supervisor questions the framework, they expect consistent answers. If the risk map, the control plan and the audit plan point to different priorities without explanation, the difficulty is no longer merely organisational: it is the credibility of the internal governance framework that is at stake.

The same logic applies to traceability. A decision documented in a tool, an approval kept in an email system and evidence stored on a shared server can all exist perfectly well — but if piecing them back together takes several days, demonstrating compliance becomes laborious.

Where to begin

Breaking down silos does not mean merging functions or rebuilding everything from scratch. A few steps produce rapid results:

• Compare the mappings. Bring together the control functions and compare their major risk registers. The gaps constitute the diagnosis.
• Adopt a common language. A shared rating scale and taxonomy are often enough to make the work comparable.
• Coordinate the outreach schedule. Group requests sent to the same team, even without unifying the methods.
• Consolidate the reporting. A unique view intended for the management and the board, fed by each function in its domain.
• Centralise the evidence. A single location for decisions, approvals and supporting documents, with clear traceability.

These steps are primarily a matter of method and governance. Tools make them considerably easier, but they do not replace them.

The ARCAD approach

ARCAD is stepping in on this diagnostic: identifying overlaps, blind spots, and redundancies between functions, and then proposing a realistic target architecture — a common language, clarified responsibilities, consolidated reporting — tailored to the size and profile of the entity.