Cybersecurity Operating Model Design for a Distributed Enterprise

Design the security operating model around decisions, not the organization chart. Settle who may accept risk, approve an exception, declare an incident, choose a tool and sign off a supplier. Then build the structure that makes those decisions workable. Most operating model work does it the other way round, and ends up with a diagram that nobody can use at two in the morning.

“Distributed” covers several situations: business units with their own P&L, subsidiaries in different jurisdictions, acquired companies still on their own technology, product teams that ship daily, and IT delivered by outside providers. In each, the central security team cannot see everything and the local teams cannot each afford everything. The failure modes are predictable. Either the central team becomes a queue the business routes around, or local teams make inconsistent risk decisions that nobody adds up.

Three models, and how each one fails

In our view, most large distributed organizations end up federated, usually with embedded capability in product engineering. The label matters less than the answers to the next section.

Design around decisions

NIST Cybersecurity Framework 2.0 gives a usable checklist. Its Govern function covers organizational context, risk management strategy, roles, responsibilities and authorities, policy, oversight, and cybersecurity supply chain risk management. CSF 2.0 positions Govern at the center of the framework because it informs how an organization implements the other five functions. An operating model is the practical form of that governance layer.

Start with the decision rights. The table below is illustrative. Titles and thresholds have to be set by the organization.

Two details separate a working table from a decorative one. Every risk acceptance needs a named owner and an expiry date. And incident declaration should rest with a role, because committees do not convene fast enough.

Split capabilities by scale and by context

Centralize what benefits from scale or has to be consistent. Localize what depends on context or speed.

• Usually central: control baseline and standards; the detection and response platform; the identity platform; enterprise risk aggregation and board reporting; the third-party risk framework; incident command for major events.

• Usually local or embedded: ownership of assets and data; risk acceptance within appetite; application security inside delivery teams; first-line incident coordination; business continuity; liaison with local regulators.

Regulator liaison deserves a caution. Some jurisdictions and sectors expect a locally accountable person or locally held records. Check the position for each jurisdiction rather than assuming a central team can cover it.

The operability test

Modernizing a security program usually means adding things: roles, forums, platforms, processes. The constraint is what the organization can operate. For every addition, require five answers: a named owner, funded capacity, a defined service level, an escalation path and one measure. If any is missing, it is a proposal, not a capability.

Then run a scenario through the model. A ransomware indicator appears at 02:00 in a subsidiary with no overnight staff. Who sees the alert? Who decides to isolate systems? Who calls legal? Who tells the group CISO? If the honest answer depends on who happens to be reachable, the model is not designed yet.

Measures that show whether it works

These are our suggestions, chosen because they test the design rather than the activity:

• Time from detection at a subsidiary to a named decision-maker acting.

• Share of risk acceptances with a named owner and a live expiry date.

• Policy exceptions by age and by business unit.

• Baseline control coverage by business unit, reported on one definition.

• Time to bring an acquired company up to the baseline.

Sequence the work

Begin with decision rights and incident command. They cost little and change behavior quickly. Move to the control baseline and a single reporting standard next. Introduce shared services after that, and change reporting lines last. Reorganizing first is the most common mistake: it consumes the goodwill needed for the work that matters, and it fixes a structure before anyone knows what the structure must carry. That is our judgment, not a published finding.

NEXT STEP

---

Take the six decisions in the table and write who makes each one today, in practice, in your two least mature business units. The gap between that answer and the intended one is the first investment priority.

Sources

• NIST. The NIST Cybersecurity Framework (CSF) 2.0.