Chapter 7 — Critical infrastructure and sector security: controls and verification

Chapter 7 — Critical infrastructure and sector security: controls and verification

Lesson map

Lesson 07 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["7.1 What a control is, for a manager"]
  N2["7.2 Levels of assurance"]
  N3["7.3 Who verifies"]
  N4["7.4 Exceptions"]
  N5["7.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["7.1 What a control is, for a manager"]
  N2["7.2 Levels of assurance"]
  N3["7.3 Who verifies"]
  N4["7.4 Exceptions"]
  N5["7.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX031"]

[Learning outcomes and connection]
    |
    v
[7.1 What a control is, for a manager]
    |
    v
[7.2 Levels of assurance]
    |
    v
[7.3 Who verifies]
    |
    v
[7.4 Exceptions]
    |
    v
[7.6 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes and connection

After this chapter you should be able to:

• describe a control in terms a manager can own: objective, owner, operation and evidence;
• distinguish levels of assurance — stated, documented, observed, tested — and decide which level each control needs;
• plan a proportionate verification programme for the controls that protect level-5 consequences;
• manage exceptions to controls as time-limited, owned risk decisions.

Chapter 6 made the programme run. This chapter asks whether its protections actually work.

7.1 What a control is, for a manager

A control is a measure that modifies risk (NIST SP 800-53 Rev. 5 catalogues thousands of them). For coordination purposes, describe each important control on one card:

• Objective — which risk it addresses and how ("prevents use of a stolen supplier password to log in to stations");
• Owner — who answers for it working;
• Operation — what happens, how often, by whom ("remote access gateway requires a second factor for every supplier account");
• Evidence — what would show it is working, and where it is kept;
• Failure signal — what you would see if it stopped working.

Controls without owners decay just like risks without owners.

7.2 Levels of assurance

How sure are you that a control works? Four useful levels:

Higher levels cost more. A proportionate programme aims for tested on controls protecting level-5 consequences, observed for level 3–4, and accepts documented for the rest. Continuous monitoring guidance from NIST describes maintaining ongoing awareness of whether controls remain effective (NIST SP 800-137).

7.3 Who verifies

• First line — control owners check their own controls (self-assessment, routine checks).
• Second line — the coordinator or security function reviews evidence and samples.
• Third line — internal audit or an independent assessor gives assurance to the board.

The coordinator usually designs the verification plan and runs second-line checks. Tests on operational systems must be authorized like any other work (Chapter 3), and in control environments a "test" is often a review of configuration and logs rather than an active attempt.

Second-line checks should sample evidence directly rather than accept the owner's summary.

7.4 Exceptions

Sometimes a control cannot be applied: an old station controller cannot support a second factor; a medical device cannot be patched without losing its certification. An exception is a recorded, owned decision to operate without the control, which is a form of risk acceptance (Chapter 4). It needs: the control and system concerned; the reason; compensating measures; the accepting authority; an expiry date; and a plan to remove the exception. An exception register is reviewed with the risk register.

At Kestrel Water, the KW-10 controller exception went to the board with an expiry in March.

7.5 Worked example: verifying three controls (synthetic)

The coordinator chooses three controls that protect level-5 risks and checks each:

The verification plan that follows: fix C1 within 30 days (owner A. Mensah); schedule a restore test for C2 within 60 days with a timed result (owner J. Tan); repeat C3 check after any logic change. The coordinator reports each control's assurance level, not a single "controls effective" statement.

7.6 Practical activity

Write control cards (objective, owner, operation, evidence, failure signal) for two controls at an organization you know, and assign each a current assurance level with justification.

For each card, say what the failure signal would look like in practice, such as a supplier login with no second-factor event in the gateway log. Explain why you chose the assurance level, citing the evidence you actually saw. Then decide what level the control should reach, given the consequence it protects, and what one step would raise it, for example a restore test for a backup that has only been observed succeeding. Keep cards short enough that an owner will update them.

7.7 Common errors and limits

• Equating "the job succeeded" with "the control works" (backups, patches).
• Verification only at the stated or documented level for critical controls.
• Active testing of operational systems without authorization and operations' agreement.
• Exceptions without expiry, which silently become the design.

• Reporting controls as "effective" without saying how that was established.

• Treating a supplier's own statement that MFA is enabled as observed evidence, when only the gateway export shows it.

• Verifying a control once and never again, so a later configuration change silently removes it.
• Testing a spare or bench system and forgetting to confirm that production matches, as C3 did by checksum.

Exercises — chapter 7

EX031 — Write a control card. Objective: make a control ownable. Inputs: "Supplier accounts are removed when contracts end." Steps: write the five-part card. Expected evidence: card. Rubric: 3 = objective tied to a risk, owner with authority (operations manager or contract owner), operation with trigger and time limit, evidence (monthly reconciliation of accounts against contracts), failure signal (accounts for ended contracts exist); 2 = missing failure signal; 1 = restates sentence; 0 = none.

EX032 — Assign assurance targets. Objective: apply proportionality. Inputs: controls: MFA for supplier access; password policy for office laptops; manual-operation procedure for stations; visitor badges at head office. Steps: assign target assurance levels and justify by consequence. Expected evidence: four targets. Rubric: 3 = tested for supplier MFA and manual operation (via exercise or drill), documented or observed for the others with reasoning; 2 = targets without reasons; 1 = all tested; 0 = none.

EX033 — Design a restore test. Objective: verify C2. Inputs: worked example. Steps: outline the test, success criteria and authorization. Expected evidence: outline. Rubric: 3 = restore to isolated environment, not production; timed against 24 h objective; checks data completeness for a chosen period; authorized by service owner; result recorded with date and evidence; 2 = no success criteria; 1 = "check backup logs"; 0 = none.

EX034 — Write an exception. Objective: manage a control gap. Inputs: KW-10's controller cannot support MFA for local engineering access. Steps: draft the exception. Expected evidence: exception record. Rubric: 3 = control and system, reason, compensating measures (no remote path, physical access control, change monitoring), accepting authority matched to consequence, expiry, removal plan; 2 = no expiry; 1 = "not possible"; 0 = none.

EX035 — Report assurance. Objective: communicate verification honestly. Inputs: worked example table. Steps: write three lines for the executive, one per control. Expected evidence: three lines. Rubric: 3 = each states assurance level reached, gap or result, owner and date; avoids "effective" without evidence; 2 = missing dates; 1 = "controls effective"; 0 = none.

Chapter synthesis

A control is something a manager can own: objective, owner, operation, evidence and failure signal. Assurance rises from stated to documented, observed and tested; aim for tested on controls protecting the worst consequences. Verify proportionately through three lines, authorize tests like any other work, and keep exceptions owned, compensated and time-limited.

Continue studying — chapter 07 of 12

← Chapter 06 · Course chapter index · Chapter 08 →

Continue to the next authored lesson.