Chapter 26 — Security architecture and engineering: operational handoff | Technologist Security architecture and engineering

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 26 — Security architecture and engineering: operational handoff

Lesson map

Lesson 26 published. Map, example, EX076.

flowchart TD
  N0["Learning outcomes"]
  N1["26.1 Who runs it next"]
  N2["26.2 Runbooks"]
  N3["26.3 Readiness check"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX076"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["26.1 Who runs it next"]
  N2["26.2 Runbooks"]
  N3["26.3 Readiness check"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX076"]

[Learning outcomes]
    |
    v
[26.1 Who runs it next]
    |
    v
[26.2 Runbooks]
    |
    v
[26.3 Readiness check]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX076]

Learning outcomes

You will (1) prepare Brightwater's operations team to run new controls; (2) write runbooks; (3) confirm readiness before handover.

26.1 Who runs it next

Tomás's placement will end, and Brightwater's two-person IT team must run the controls he helped introduce. He lists every control and routine: weekly alert review, monthly updates, the leaver script, manifest checks, backups and restore tests, vendor session approvals and quarterly access reviews. For each he names the future owner and the backup person. Without a planned handoff, controls introduced by a temporary worker tend to decay within months, because nobody else knows why they exist or how to run them.

26.2 Runbooks

Tomás writes a runbook for each routine: purpose, when to run it, step-by-step instructions, what normal output looks like, what to do if it fails and who to call. He keeps each to one or two pages with screenshots. He asks Sam's colleague to follow the backup restore runbook without help. She gets stuck on one step where a password location was missing, and Tomás fixes the runbook. Testing runbooks with the people who will use them is the only way to know they work.

26.3 Readiness check

Before leaving, Tomás and Sam run a readiness check. Each owner runs their routine once while Tomás watches silently. All routines complete, though the vendor approval takes longer than expected because the approver role was unclear. They clarify it in writing. Sam signs off the handover. Tomás leaves his contact details for questions during the first month. Ruth notes that a good handoff is measured by how little the departing person is needed afterwards. The readiness record, with timings and the clarified approver role, is filed with the handover pack for later reference.

Worked example

Tomás lists controls with owners and backups, writes tested runbooks and runs a silent readiness check before sign-off.

Synthetic case. Routines and people are synthetic.

Errors and limits

Runbooks age as systems change. Two-person teams are fragile during holidays.

Exercises

EX076 — Why handoff. Why do controls decay without handoff? Rubric: 3 = nobody else knows why they exist or how to run them;; 2 = knowledge;; 1 = vague;; 0 = none.
EX077 — Runbook test. What did testing the restore runbook reveal? Rubric: 3 = a missing password location step;; 2 = gap;; 1 = vague;; 0 = none.
EX078 — Measure of handoff. How is a good handoff measured? Rubric: 3 = by how little the departing person is needed afterwards;; 2 = independence;; 1 = length;; 0 = none.

Synthesis

Operational handoff succeeds through named owners, tested runbooks and a readiness check before departure.

Continue studying — chapter 26 of 30

← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →