Chapter 26 — Quantum and post-quantum security: operational handoff | Technologist Quantum and post-quantum 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.

Lesson map

Lesson 26 published. Map, example, EX051.

flowchart TD
  N0["Learning outcomes"]
  N1["26.1 Handoff package"]
  N2["26.2 Runbooks"]
  N3["26.3 Ownership"]
  N4["26.4 Training"]
  N5["26.6 Practical activity"]
  N6["26.7 Acceptance criteria"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX051"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["26.1 Handoff package"]
  N2["26.2 Runbooks"]
  N3["26.3 Ownership"]
  N4["26.4 Training"]
  N5["26.6 Practical activity"]
  N6["26.7 Acceptance criteria"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX051"]

[Learning outcomes]
    |
    v
[26.1 Handoff package]
    |
    v
[26.2 Runbooks]
    |
    v
[26.3 Ownership]
    |
    v
[26.4 Training]
    |
    v
[26.6 Practical activity]
    |
    v
[26.7 Acceptance criteria]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX051]

Learning outcomes

You will (1) prepare a service for handoff to operations; (2) write runbooks for post-quantum-specific failures; (3) define ownership of profiles, certificates and exceptions; and (4) train operators.

26.1 Handoff package

Operations need: architecture and trace for the flow; the applied crypto profile and its version; the inventory entries; dashboards and alerts; runbooks; residual-risk register; exception list with expiries; vendor and partner contacts; and the evaluation report.

Every item is a link in the service repository, not an attachment, so operations always see the current version. KLS's package index lists 12 items with owner and last review date.

KLS tested this at handoff: an SRE who had not seen the SFTP work answered a simulated "hybrid handshake failures above threshold" alert from the package alone, using the runbook's isolate-and-exception steps.

26.2 Runbooks

Write runbooks for: hybrid share drop; handshake failures through a proxy; partner no_shared_group; certificate verification failures after PKI changes; HSM or KMS errors in issuance. Each has symptoms, checks, safe actions, rollback and escalation.

KLS's runbook for a hybrid-share drop starts with the three checks that solved its real incident: the last deployment, the ingress annotations and the live profile hash against the approved one. The safe action restores the approved profile without touching application code; rollback restores the previous profile version; escalation goes to the platform on-call and, for provider hops, the CDN contact. Every runbook is tested in a tabletop before it counts.

26.3 Ownership

Name owners for the central profiles, the internal CA, exception approvals, the CBOM feeds and the dashboards. Ownership gaps are where regressions live.

At KLS, the Platform Team owns the central profiles and CBOM feeds, the PKI team owns the internal CA, the security office approves exceptions and SRE owns the dashboards and alerts. Each owner is a team with an on-call rotation, recorded in the service catalogue, never a single named person who might leave.

The first quarterly review found the CBOM feed for the VPN appliances still listed under a team that had been merged into the Platform Team; the feed had kept running, but its alerts went to an empty channel.

26.4 Training

Run a short session for operators: what changed, how to read the dashboard, what the runbooks say, and one tabletop exercise. Record attendance and questions; update runbooks with answers.

KLS's session for SRE took 45 minutes: 10 on what changed, 10 on the dashboard, 10 on the runbooks and 15 on the tabletop. The question "can we just remove the hybrid group if handshakes fail?" came up and is now answered in the runbook: no, isolate the path and use an exception.

The hybrid-group question and its answer are linked from the handoff record, together with the names of the SRE staff who attended and one question still open: how to read the dashboard when a partner connects only monthly.

26.5 Worked example

KLS hands the customer API flow to the SRE team with a package in the service repository. The tabletop: "hybrid share drops to 5 % after a release". Operators follow the runbook, identify the annotation, restore the profile, and confirm recovery in 12 minutes. One gap found: the runbook assumed access to a dashboard SREs did not have — fixed before sign-off.

The 12-minute recovery is the baseline for future drills. The access gap is the kind of finding a tabletop exists for: on paper the runbook was correct, in practice its first step was impossible for the people who would follow it.

26.6 Practical activity

Write the handoff package index and one runbook for your studio flow.

The index lists each item from the handoff package with its location, owner and last review date: trace, applied profile and version, inventory entries, dashboards, alerts, runbooks, residual-risk register, exceptions with expiries, contacts and evaluation. The runbook covers one failure your studio flow can produce, with symptoms, the first three checks, the safe action, rollback and escalation. Test it by having a teammate who did not write it follow it on the lab.

26.7 Acceptance criteria

Operations should accept a handoff only when criteria are met: dashboards visible to the on-call team, alerts routed and tested, runbooks exercised in a tabletop, owners named in the service catalogue, and the residual-risk register reviewed. Writing the criteria down turns handoff from a meeting into a checklist, and it gives operations a fair basis to say "not yet".

KLS's SRE team declined the first handoff because alerts were routed to the platform channel, not to on-call.

The handoff passed a week later, once routing was fixed and an alert was tested end to end.

26.8 Common errors and limits

Handoffs without runbooks.
Unowned profiles or exceptions.
Training without exercises.

Before KLS required runbooks, a fallback alert fired at night and the on-call engineer, with no guidance, disabled the alert. An exception for a customer proxy had no owner, so it passed its expiry and nobody renewed or closed it. And a slide-only training left operators unable to find the profile hash check when they needed it. Each gap was found in an incident rather than in the handoff, which is the most expensive place to find it.

Exercises

EX051 — Runbook. Write a runbook for "partner reports no_shared_group on SFTP". Rubric: 3 = symptoms, checks, actions, rollback, escalation.
EX052 — Acceptance criteria. List five handoff acceptance criteria. Rubric: 3 = five verifiable criteria.

Synthesis

A complete handoff gives operations the map, the controls, the alarms, the runbooks, the owners and the practice to keep post-quantum protections in place.

Continue studying — chapter 26 of 30

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