Chapter 7 — Critical infrastructure and sector security: organizational integration | Postgraduate Critical infrastructure and sector security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 7 — Critical infrastructure and sector security: organizational integration

Lesson map

Lesson 07 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["7.1 Operating models"]
  N2["7.2 Ownership: RACI and separation of duties"]
  N3["7.3 Suppliers and concentration"]
  N4["7.4 Integrating with emergency management"]
  N5["7.5 Information sharing"]
  N6["7.7 Practical activity: concentration and ownership"]
  N7["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["7.1 Operating models"]
  N2["7.2 Ownership: RACI and separation of duties"]
  N3["7.3 Suppliers and concentration"]
  N4["7.4 Integrating with emergency management"]
  N5["7.5 Information sharing"]
  N6["7.7 Practical activity: concentration and ownership"]
  N7["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]

[Learning outcomes and connection]
    |
    v
[7.1 Operating models]
    |
    v
[7.2 Ownership: RACI and separation of duties]
    |
    v
[7.3 Suppliers and concentration]
    |
    v
[7.4 Integrating with emergency management]
    |
    v
[7.5 Information sharing]
    |
    v
[7.7 Practical activity: concentration and ownership]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes and connection

After this chapter you should be able to:

Compare operating models for OT and IT security in an essential-service organization and choose one with reasons.
Assign ownership so that every critical security activity has exactly one accountable role and conflicts of duty are visible.
Measure supplier concentration within an organization and across a region, and plan for common-mode supplier failure.
Integrate cyber incident response with emergency management, business continuity and regional resilience arrangements.
Design information sharing among operators that is useful, lawful and trusted.

Chapters 1–6 equipped the specialist to decide, evidence and evaluate. This chapter places that work inside an organization and a region, because most failures in essential services are failures of integration — between IT and operations, between an operator and its suppliers, between a cyber incident team and the people running emergency response. Chapter 8 tests integration in the hardest cases; Chapter 9 leads and assures it.

7.1 Operating models

Three common models for security in an organization that runs both IT and OT:

Model	Description	Strengths	Weaknesses
Central	The CISO's team owns security for IT and OT	One standard, one risk view, efficient tooling	Distance from plant; controls designed for IT; operations may route around
Federated	Operations owns OT security with its own specialists; CISO sets policy and assures	Close to the process; safety culture; credible with operators	Inconsistent standards; duplicated tools; gaps at the IT/OT boundary
Integrated	A joint OT security function reporting to operations with a formal line to the CISO, shared standards, shared incident process	Combines process knowledge and security depth	Needs explicit ownership and conflict resolution; depends on people

There is no universally right model. NIST SP 800-82 recommends forming a cross-functional team including control engineers, operators, IT security and safety staff (NIST, 2023); NIST CSF 2.0 places roles, responsibilities and authorities under governance (NIST, 2024). Merrow Water's choice of the integrated model — a Principal Security Specialist reporting to the Director of Operations with a dotted line to the CISO — follows from its size and from the weight it places on operators' trust. The model must then be made real through ownership, budget and incident process; an organization chart alone integrates nothing.

7.2 Ownership: RACI and separation of duties

For each critical activity, one role is Accountable (owns the outcome and approves), one or more are Responsible (do the work), others are Consulted or Informed. Two rules catch most ownership failures: every critical activity has exactly one accountable role; and where a single role both performs and approves an activity with security consequence — an emergency firewall change, a payment, a vendor access grant — the conflict is either removed or covered by a compensating control such as an after-the-fact review of every instance. Separation of duties is a long-standing control principle in NIST's catalogue (NIST SP 800-53 Rev. 5). Two accountable roles for "declare a cyber incident" sounds like extra safety; in practice it creates a gap at 3 a.m. when each assumes the other has decided.

7.3 Suppliers and concentration

Essential services depend on suppliers for control systems support, managed detection, telecoms and cloud hosting. Concentration has two levels:

Within an operator. If one supplier provides all of a critical function, its failure — technical, commercial or a compromise — is the operator's failure. A standard measure of concentration is the Herfindahl–Hirschman index (HHI): the sum of squared percentage shares, from near 0 (many small suppliers) to 10,000 (one supplier) (U.S. Department of Justice, HHI). It is a coarse but useful flag.
Across a region. If one supplier is a majority dependency for several operators, a single event becomes a regional event. The global outage of July 2024 caused by a faulty security-software update, which affected an estimated 8.5 million Windows devices according to Microsoft (Microsoft, 2024), showed how a trusted supplier can become a common-mode failure across sectors. Financial regulation has moved furthest on this: DORA requires registers of ICT third-party arrangements and creates oversight of critical ICT third-party providers (Regulation (EU) 2022/2554).

Concentration is not automatically bad — one well-managed supplier can be safer than three poorly managed ones. The specialist's task is to make it visible, decide which concentrations are acceptable, and prepare exit and continuity plans: what would we do if this supplier were unavailable for a week, or compromised? Contracts should give rights to logs, notification of incidents, security requirements and support during the supplier's own incidents. Software supply-chain practices — software bills of materials (CISA, SBOM), secure development (NIST SP 800-218) and secure-by-design commitments (CISA, Secure by Design) — help with the product side.

7.4 Integrating with emergency management

A major cyber incident at an essential service is also an emergency: boil-water notices, hospital diversions, port closures. The cyber incident team must therefore fit into the organization's emergency and business-continuity command rather than run in parallel. Practical integration points:

A shared incident classification that maps cyber severity to service impact, so the duty manager can escalate without a security specialist present.
Cyber representation in the emergency command structure, and emergency management representation in cyber exercises.
Manual-operation and continuity plans owned by operations and tested with security scenarios (Chapter 6).
Pre-agreed regional arrangements: who tells neighbouring operators, health services and local authorities; how mutual aid works; how public messages are coordinated. The EU CER Directive frames critical-entity resilience as all-hazards and cross-sector (Directive (EU) 2022/2557); U.S. policy on critical infrastructure security and resilience similarly emphasizes sector coordination (NSM-22 overview, CISA).

7.5 Information sharing

Operators learn faster together, but sharing carries legal, commercial and security risk. Useful sharing is specific (indicators, techniques, affected product versions, mitigations that worked), timely, protected (agreed handling rules, such as traffic-light labels), and reciprocal. A sharing agreement for a regional forum should cover: what is shared and in what format; handling and onward-sharing rules; personal data (minimize; check the lawful basis, GDPR); competition-law care for commercially sensitive information; liability; and how shared information may reach regulators. Trust is built mostly by behaviour: sharing first, protecting what others share, and giving credit.

7.6 Worked example: Merrow Bay's dependencies and a draft RACI (synthetic)

The resilience forum asked each operator which suppliers serve its essential functions and what share they provide. At the same time, Merrow Water's specialist drafted a RACI for five critical security activities, to be agreed with operations and the CISO. Lab 7 analyses both.

The questions were deliberately simple: which supplier serves each essential function, and roughly what share. Operators answered from contracts and asset registers rather than from memory, and the forum agreed in advance that answers would be used only for the regional analysis. The RACI draft covers approving and making emergency OT firewall changes, granting vendor remote sessions, declaring a cyber incident and restoring from offline backup, each chosen because a mistake in ownership there would delay response or weaken control.

7.7 Practical activity: concentration and ownership checks

# Lab 7 - concentration and ownership checks for an integrated security function (offline, stdlib only)
# Synthetic: which suppliers Merrow Bay operators depend on for essential functions, and a draft RACI.
from collections import defaultdict
DEPENDS = [  # (operator, function, supplier, share of that operator's function served by the supplier)
    ("Merrow Water", "SCADA support", "Corvane Systems", 1.0),
    ("Merrow Water", "managed detection", "Lumen Watch", 1.0),
    ("Merrow Water", "telemetry links", "BayTel", 0.7), ("Merrow Water", "telemetry links", "radio (own)", 0.3),
    ("Merrow Health", "EPR hosting", "Halden Cloud", 1.0),
    ("Merrow Health", "managed detection", "Lumen Watch", 1.0),
    ("Merrow Health", "pathology LIMS", "Corvane Systems", 1.0),
    ("Merrow Energy", "SCADA support", "Corvane Systems", 0.6), ("Merrow Energy", "SCADA support", "in-house", 0.4),
    ("Merrow Energy", "telemetry links", "BayTel", 0.5), ("Merrow Energy", "telemetry links", "private fibre", 0.5),
    ("Port of Merrow", "terminal OS hosting", "Halden Cloud", 1.0),
    ("Port of Merrow", "managed detection", "Lumen Watch", 1.0),
]
by_op_fn = defaultdict(list)
for op, fn, sup, share in DEPENDS: by_op_fn[(op, fn)].append((sup, share))
print("Herfindahl-Hirschman index per operator function (10000 = single supplier):")
for (op, fn), lst in by_op_fn.items():
    hhi = sum((100 * s) ** 2 for _, s in lst)
    print(f"  {op:15s} {fn:20s} HHI {hhi:6.0f}")
reach = defaultdict(set)
for op, fn, sup, share in DEPENDS:
    if sup not in ("in-house", "radio (own)", "private fibre") and share >= 0.5: reach[sup].add(op)
print("Suppliers that are a majority dependency for 2+ operators (regional common mode):")
for sup, ops in sorted(reach.items(), key=lambda x: -len(x[1])):
    if len(ops) >= 2: print(f"  {sup:16s} {len(ops)} operators: {', '.join(sorted(ops))}")
RACI = {  # activity -> {role: letters}
    "approve OT firewall change":   {"OT engineer": "R", "OT manager": "A", "CISO": "C"},
    "emergency OT firewall change": {"OT engineer": "RA", "OT manager": "I"},
    "grant vendor remote session":  {"OT engineer": "R", "Service desk": "R"},
    "declare cyber incident":       {"CISO": "A", "Duty manager": "A", "OT manager": "C"},
    "restore from offline backup":  {"OT engineer": "R", "OT manager": "A", "IT ops": "R"},
}
print("RACI findings:")
for act, roles in RACI.items():
    a = [r for r, l in roles.items() if "A" in l]
    if len(a) != 1: print(f"  {act}: {len(a)} accountable roles {a}")
    for r, l in roles.items():
        if "R" in l and "A" in l: print(f"  {act}: {r} both does and approves (needs compensating control or record)")

Expected output:

Herfindahl-Hirschman index per operator function (10000 = single supplier):
  Merrow Water    SCADA support        HHI  10000
  Merrow Water    managed detection    HHI  10000
  Merrow Water    telemetry links      HHI   5800
  Merrow Health   EPR hosting          HHI  10000
  Merrow Health   managed detection    HHI  10000
  Merrow Health   pathology LIMS       HHI  10000
  Merrow Energy   SCADA support        HHI   5200
  Merrow Energy   telemetry links      HHI   5000
  Port of Merrow  terminal OS hosting  HHI  10000
  Port of Merrow  managed detection    HHI  10000
Suppliers that are a majority dependency for 2+ operators (regional common mode):
  Corvane Systems  3 operators: Merrow Energy, Merrow Health, Merrow Water
  Lumen Watch      3 operators: Merrow Health, Merrow Water, Port of Merrow
  BayTel           2 operators: Merrow Energy, Merrow Water
  Halden Cloud     2 operators: Merrow Health, Port of Merrow
RACI findings:
  emergency OT firewall change: OT engineer both does and approves (needs compensating control or record)
  grant vendor remote session: 0 accountable roles []
  declare cyber incident: 2 accountable roles ['CISO', 'Duty manager']

Interpretation. Within operators, seven of ten function–operator pairs have HHI 10,000 — a single supplier — which is common and not alarming in itself. The regional view is more important: Corvane Systems is a majority dependency for three operators (SCADA support at water and energy, pathology systems at health), Lumen Watch provides managed detection to three, and BayTel and Halden Cloud each to two. A compromise of Lumen Watch would blind three operators' detection simultaneously; a Corvane remote-support compromise could reach three sectors' operational systems. These are forum-level risks no single operator's register will show. The RACI check finds three problems: the emergency firewall change has the OT engineer both doing and approving, which may be acceptable at night if every instance is reviewed the next working day; granting vendor remote sessions has no accountable role — the most dangerous finding, given Chapter 3's Hollin event; and declaring a cyber incident has two accountable roles, which should become one (the duty manager, who is always available) with the CISO consulted.

7.8 Common errors and limits

Choosing an operating model by copying another organization rather than by size, risk and culture.
Drawing an organization chart and calling it integration.
Leaving critical activities with no accountable owner, or two.
Assessing supplier risk one contract at a time, missing regional concentration.
Treating a supplier's certification as evidence of resilience during the supplier's own incident.
Running cyber incident response in parallel with emergency command.
Sharing information without handling rules, or never sharing because rules are unclear.

The limit of structural analysis is that integration ultimately depends on relationships and practice. RACI tables and HHI values identify where to look; exercises and real incidents show whether integration works.

Exercises — chapter 7

EX031 — Repair the RACI. Objective: fix ownership defects and verify. Inputs: Lab 7. Constraints: every activity exactly one A; any R+A conflict either removed or documented with a compensating control. Steps: (1) edit the RACI; (2) rerun and show no unaddressed findings; (3) write the compensating control for any conflict you keep. Expected evidence: edited table, output, control text. Rubric: 3 = vendor session grant given one accountable role (OT manager) with the service desk and OT engineer responsible, incident declaration single-accountable, emergency change conflict either removed or kept with next-day review of every instance; 2 = output clean but control missing; 1 = not rerun; 0 = none.

EX032 — Regional common mode. Objective: plan for a concentrated supplier. Inputs: Lumen Watch serving three operators. Constraints: forum has no authority over contracts; operators keep their own choices. Steps: (1) describe two failure scenarios (outage; compromise of the provider); (2) propose operator-level and forum-level actions; (3) define contract clauses to request at renewal. Expected evidence: plan. Rubric: 3 = scenarios distinct (blindness versus provider as attack path), actions include local minimum detection or logging retained by each operator, joint exercise, notification clauses, log access and exit plan; 2 = one scenario; 1 = "change supplier"; 0 = none.

EX033 — Choose an operating model. Objective: justify a model for another organization. Inputs: Port of Merrow: 600 staff, a two-person IT security team, terminal OT run by a contractor, a harbour master's operations centre. Constraints: use §7.1. Steps: compare models; choose; state the three conditions that would make your choice fail. Expected evidence: one-page recommendation. Rubric: 3 = choice argued from size, contractor dependence and operations culture, failure conditions specific; 2 = generic pros and cons; 1 = no choice; 0 = none.

EX034 — Cyber within emergency command. Objective: integrate response structures. Inputs: Merrow Water's existing emergency plan (boil-water, loss of supply) and its cyber incident procedure, which currently do not reference each other. Constraints: one shared classification; no duplicated command. Steps: (1) draft a combined classification table from service impact; (2) define the cyber lead's place in emergency command; (3) list the regional notifications and who makes them. Expected evidence: table and diagram description. Rubric: 3 = classification by service impact usable by a duty manager, cyber lead advising the incident commander rather than running a parallel structure, regional notifications assigned; 2 = parallel structures remain; 1 = cyber-only severity; 0 = none.

EX035 — Concentration arithmetic and judgement. Objective: compute and interpret HHI. Inputs: Merrow Health telemetry and network services split 40% / 40% / 20% across three carriers, two of which share the same duct along the harbour road. Constraints: show the calculation. Steps: (1) compute HHI; (2) explain why the number understates the real concentration; (3) propose how to represent shared physical paths. Expected evidence: calculation and paragraph. Rubric: 3 = HHI 3,600, recognition that 80% of service shares one physical route so effective concentration is far higher, proposal to compute concentration on physical paths or failure domains; 2 = number only; 1 = arithmetic wrong; 0 = none.

Chapter synthesis

Integration is where essential-service security usually fails. Choose an operating model for your size, risk and culture, then make it real with ownership: exactly one accountable role per critical activity and visible handling of conflicts of duty. Measure supplier concentration within the organization and across the region, and prepare exit and continuity plans for common-mode supplier failure. Put cyber response inside emergency and continuity command with a shared, service-based classification. Share information specifically, under agreed handling rules, and build trust by behaviour.

Continue studying — chapter 07 of 12

← Chapter 06 · Course chapter index · Chapter 08 →

Continue to the next authored lesson.