Chapter 3 — Authorized practice and evidence handling
Lesson map
Lesson 03 published. Map, example, EX011.
flowchart TD
N0["Learning outcomes and connection"]
N1["3.1 Why authorization is a coordination problem"]
N2["3.2 What a valid authorization contains"]
N3["3.3 Decision records"]
N4["3.4 Evidence handling for a coordinator"]
N5["3.5 Sharing: the Traffic Light Protocol"]
N6["3.7 Practical activity"]
N7["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX011"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["3.1 Why authorization is a coordination problem"]
N2["3.2 What a valid authorization contains"]
N3["3.3 Decision records"]
N4["3.4 Evidence handling for a coordinator"]
N5["3.5 Sharing: the Traffic Light Protocol"]
N6["3.7 Practical activity"]
N7["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX011"]
[Learning outcomes and connection]
|
v
[3.1 Why authorization is a coordination problem]
|
v
[3.2 What a valid authorization contains]
|
v
[3.3 Decision records]
|
v
[3.4 Evidence handling for a coordinator]
|
v
[3.5 Sharing: the Traffic Light Protocol]
|
v
[3.7 Practical activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX011]
Learning outcomes and connection
After this chapter you should be able to:
- explain who may authorize security work on an essential service and what a valid authorization contains;
- write a decision record that would survive a regulator's or auditor's questions a year later;
- manage the evidence a coordination programme produces: what to keep, where, for how long, and who may see it;
- share sensitive information with partners using an agreed marking scheme (the Traffic Light Protocol).
Chapter 2 identified who decides. This chapter makes their decisions explicit, recorded and safe to share.
3.1 Why authorization is a coordination problem
Security work on an essential service — an assessment, a vulnerability scan, a supplier maintenance session, a penetration test, even "just looking" at a controller's configuration — can affect the service. In control environments, NIST notes that some routine IT activities, including active scanning, can disrupt operations (NIST SP 800-82 Rev. 3). Authorization exists so that the person responsible for the consequence agrees in advance to what will happen, and so that everyone can later show what was agreed.
The coordinator is usually the person who assembles an authorization: drafts the scope, gets the right signatures, distributes it and keeps it. The coordinator is rarely the person who grants it.
3.2 What a valid authorization contains
Use the following elements for any assessment, test or third-party work on operational systems. NIST's testing guide describes rules of engagement with similar content for technical assessments (NIST SP 800-115).
| Element | Question it answers |
|---|---|
| Purpose | Why is this work being done? |
| Systems in scope — and out of scope | Exactly which sites, systems, accounts; and which are excluded (for example dosing controllers, safety systems) |
| Activities permitted — and prohibited | What may be done (read configuration, review documents) and what may not (write, reboot, active scan) |
| People | Who will do the work, by name, and who supervises |
| Window | Start and end date and time, with time zone |
| Conditions | Operations present; stop conditions; communication channel |
| Data handling | What may be copied, where it is stored, when it is destroyed |
| Authority | Name, role and signature of the service owner (and of the supplier's manager where relevant) |
A stop condition is a pre-agreed event that ends the work immediately — "any unexpected alarm at the station; any operator request; any loss of view on the operator screens". Stop conditions turn "be careful" into something checkable.
3.3 Decision records
Coordination produces decisions: accept a risk, delay a patch, isolate a station, notify a regulator. A decision record is a short, dated note that captures:
- the decision, in one sentence;
- who made it, and under what authority;
- the options considered and why this one was chosen;
- the information available at the time, and what was unknown;
- conditions and review date ("revisit if the supplier releases a fix, or by 30 June");
- who was informed.
The point of item 4 is fairness to the decision-maker. A decision made at 02:00 with partial information can be good even if the outcome is bad. Without a record, hindsight rewrites history. With one, an organization can learn which decisions were poor and which were unlucky.
3.4 Evidence handling for a coordinator
A coordinator handles evidence of three kinds:
- Governance evidence — authorizations, decision records, risk acceptances, meeting minutes, exercise reports. Kept as the organization's record; protect integrity (who changed what) and retain according to policy.
- Incident evidence — logs, images, emails gathered during an incident. Its collection is technical work; the coordinator ensures it is requested early, its custody is recorded and access is limited. NIST's incident response guidance stresses preparing for evidence collection before incidents happen (NIST SP 800-61 Rev. 3).
- Sensitive design information — network diagrams, vulnerability reports, supplier access lists. Not evidence of wrongdoing but highly useful to an attacker. Store in an access-controlled location, never in general email threads.
Three practical rules: one authoritative location per record type; a named owner for each location; and no secrets (passwords, keys) in any record.
3.5 Sharing: the Traffic Light Protocol
Partners — the national CSIRT, a sector information-sharing group, the hospital — need information to protect themselves. The Traffic Light Protocol (TLP) is a widely used marking scheme that tells recipients how far they may share it (FIRST, TLP 2.0):
- TLP:RED — for the named recipients only;
- TLP:AMBER — recipients may share within their organization and its clients on a need-to-know basis; TLP:AMBER+STRICT limits it to the recipient's organization only;
- TLP:GREEN — may be shared within the recipient's community, not publicly;
- TLP:CLEAR — no restriction beyond normal copyright.
TLP marks sharing permission, not confidentiality classification, and does not replace legal duties. Mark the subject line and the start of the message, and choose the least restrictive label that still protects people.
3.6 Worked example: authorizing a supplier assessment (synthetic)
ScadaCo offers a free "security health check" of the treatment works' control system. The coordinator drafts the authorization:
- Purpose: review configuration of the supervisory servers against ScadaCo's hardening guide.
- In scope: the two supervisory servers at KW-TW and their documentation. Out of scope: all station controllers, the dosing system, the network firewall.
- Permitted: read-only review of exported configuration files, supervised interview with J. Tan. Prohibited: network scanning, installing software, changing any setting, copying data off site except the final report.
- People: M. Ilic (ScadaCo), supervised by J. Tan.
- Window: 21 April 2026, 09:00–13:00 local time.
- Stop conditions: any operator request; any alarm at KW-TW.
- Data handling: the report is marked TLP:AMBER+STRICT, delivered by the agreed secure file-transfer service and stored in the security record library; ScadaCo deletes working notes within 14 days and confirms in writing.
- Authority: A. Mensah (operations manager, owner of KW-TW); ScadaCo's service manager countersigns.
On the day, M. Ilic asks to "quickly run a discovery tool to check versions". J. Tan refuses, because the authorization prohibits scanning, and records the request. The decision record notes the refusal and that the version check will be done from documentation instead. This is the authorization working as intended.
3.7 Practical activity
Take any routine supplier visit at an organization you know and write its authorization in the table format of 3.2. Mark which elements you could not fill in; those are the gaps in that organization's practice.
Choose a visit that touches a system someone would worry about, such as a maintenance session on a controller, rather than a cleaner or a delivery. Write the stop conditions as events anyone on site could recognise. Then ask the person who would sign as service owner whether they agree with your scope and exclusions; their answer usually reveals a system you forgot. Keep your draft and their comments together as evidence of the gap you found.
3.8 Common errors and limits
- "Verbal OK" from someone without authority over the service.
- Scope written as "the OT network" with no exclusions.
- No stop conditions, or stop conditions nobody on site knows.
- Decision records written after the outcome is known.
- Sending design information as ordinary email attachments.
-
TLP used as if it were a legal classification or to hide information from people who need it.
-
Letting the supplier redefine the work on the day, as ScadaCo's request to run a discovery tool would have done if J. Tan had not refused it.
- Keeping no record of a refusal, so a later reviewer cannot see that the authorization was enforced.
Exercises — chapter 3
EX011 — Repair an authorization. Objective: find missing elements. Inputs: "OK for Northgate to do a pentest on the OT network next week — A. Mensah (via chat)". Steps: list the missing elements and rewrite it. Expected evidence: gap list and rewrite. Rubric: 3 = identifies purpose, scope and exclusions, permitted/prohibited activities, named people, window with time zone, stop conditions, data handling and written authority; rewrite excludes safety and dosing systems and prefers non-intrusive methods; 2 = most elements; 1 = minor edits; 0 = none.
EX012 — Write a decision record. Objective: record a decision fairly. Inputs: at 02:10 the duty manager decided to keep KW-05 in automatic despite an unexplained remote login, because manual operation needed a staff callout of 90 minutes. Steps: write the six-part record. Expected evidence: the record. Rubric: 3 = all six parts, with unknowns stated at the time (whether the login was malicious), conditions (watch dosing values, revisit at 06:00) and who was informed; 2 = missing options or unknowns; 1 = narrative only; 0 = none.
EX013 — Choose a TLP label. Objective: apply TLP 2.0. Inputs: (a) indicators of a phishing campaign targeting water utilities, to send to the sector group; (b) a report naming Kestrel Water's unpatched controller models, for KVROC; (c) a public advice note for customers. Steps: choose labels and justify. Expected evidence: three labels. Rubric: 3 = (a) GREEN (community benefit), (b) AMBER+STRICT or RED (sensitive to the utility; KVROC needs it), (c) CLEAR; reasons given; 2 = labels without reasons; 1 = everything RED; 0 = none.
EX014 — Evidence locations. Objective: organise governance evidence. Inputs: authorizations in an engineer's inbox, risk acceptances in board minutes, exercise reports on a shared drive, supplier access lists in a spreadsheet emailed monthly. Steps: propose a scheme. Expected evidence: one-paragraph scheme with owners. Rubric: 3 = one authoritative access-controlled location per record type, named owners, retention, version history, stop emailing access lists; 2 = location without owners; 1 = "use SharePoint"; 0 = none.
EX015 — Stop condition test. Objective: make caution checkable. Inputs: a supplier firmware update at KW-09 scheduled for 13:00–15:00. Steps: write three stop conditions and say who has authority to invoke them. Expected evidence: conditions and authority. Rubric: 3 = observable conditions (unexpected alarm, loss of view, overrun beyond 15:00, operator request) and the operator on shift or operations manager can stop without justification; 2 = vague conditions; 1 = supplier decides; 0 = none.
Chapter synthesis
Authorization makes the owner of the consequence agree in advance to exactly what will happen, and lets everyone prove it later. A valid authorization has scope with exclusions, permitted and prohibited activities, named people, a window, stop conditions, data handling and written authority. Decision records capture what was known at the time; governance evidence lives in owned, controlled locations; TLP tells partners how far they may share.
Continue studying — chapter 03 of 12
← Chapter 02 · Course chapter index · Chapter 04 →
Continue to the next authored lesson.