◇ OpenCyber Academy
Professional · Chapter 6 · English

Chapter 6 — Quantum and post-quantum security: operational workflow

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 6 — Quantum and post-quantum security: operational workflow

Lesson map

Lesson 06 published. Map, example, EX026.

flowchart TD
  N0["Learning outcomes"]
  N1["6.1 The cycle"]
  N2["6.2 Roles"]
  N3["6.3 Tracker states"]
  N4["6.4 Dependencies"]
  N5["6.5 Outcome measures"]
  N6["6.7 Practice task"]
  N7["6.8 Cadence"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX026"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["6.1 The cycle"]
  N2["6.2 Roles"]
  N3["6.3 Tracker states"]
  N4["6.4 Dependencies"]
  N5["6.5 Outcome measures"]
  N6["6.7 Practice task"]
  N7["6.8 Cadence"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX026"]

[Learning outcomes]
    |
    v
[6.1 The cycle]
    |
    v
[6.2 Roles]
    |
    v
[6.3 Tracker states]
    |
    v
[6.4 Dependencies]
    |
    v
[6.5 Outcome measures]
    |
    v
[6.7 Practice task]
    |
    v
[6.8 Cadence]
    |
    v
[Worked example] --> [Exercise EX026]

Learning outcomes

You will (1) run the migration workflow as a repeatable cycle; (2) define roles, inputs and outputs for each step; (3) use a tracker with clear states; (4) manage dependencies on suppliers and partners; and (5) report progress with outcome measures.

6.1 The cycle

  1. Scope services and confirm authorization. 2. Inventory with graded evidence. 3. Prioritise by lifetime, exposure and change route. 4. Plan each item: control, owner, date, dependencies. 5. Implement through the owning team's change process. 6. Verify with negotiation evidence. 7. Record residual risk and exceptions. 8. Report and repeat each quarter.

Each step produces an input for the next: authorization for inventory, graded evidence for prioritisation, a plan for implementation. At MTI the cycle runs quarterly, so a slipped step shows up in the next report rather than at the end of the programme.

6.2 Roles

Coordinator (you): runs the cycle, keeps the tracker, writes reports. System owners: implement changes. Data owners: confirm lifetimes. Procurement: supplier clauses. Security architecture: standards. Executive sponsor: decisions and risk acceptance. Internal audit: independent checks.

At MTI the infrastructure team is the system owner for the reinsurer SFTP servers, underwriting confirms the archive lifetime, and the sponsor approves exceptions. Write the roles into the tracker so each item names a person, and agree with each one what they will provide and by when.

6.3 Tracker states

Use simple states: Unknown → Assessed → Planned → In progress → Implemented → Verified → Closed (or Exception). An item moves to Verified only with evidence of negotiation, not just a change ticket.

Each state needs its own evidence: an inventory record for Assessed, an owner and date for Planned, a change ticket for Implemented and negotiation logs for Verified. Record the date of each state change so the tracker shows how long items take. A move back to an earlier state is also recorded, with a reason, as happened with the broker portal (Chapter 10).

6.4 Dependencies

Many items wait on suppliers or partners. Record the dependency, the request sent, the answer and the follow-up date. Escalate unanswered requests through procurement or account management.

At MTI the reinsurer SFTP item depended on partners upgrading their clients, and the archive item depended on the vendor's signature roadmap. Each had a request date and a follow-up date in the tracker. When a dependency is resolved, record the answer as evidence and update the item's grade and state together. Keep this short.

6.5 Outcome measures

Report: share of tier-1 items Verified; share Unknown; number of open exceptions and how many are past expiry; supplier answers received. Avoid activity counts such as "meetings held".

Each measure answers a question an executive can act on: how much is protected, how much is still unknown, how much risk is accepted and whether suppliers are engaging. Define each measure once, in writing, and keep the definition unchanged between quarters, or note any change in the report. Show each measure next to last quarter's.

6.6 Worked example

MTI's tracker after one quarter (synthetic): 64 tier-1 items — 6 Verified, 9 Implemented, 14 In progress, 18 Planned, 11 Assessed, 6 Unknown; 3 exceptions. Report headline: "9 % of tier-1 items verified, 9 % unknown; reinsurer SFTP and archive transfers in progress; 3 exceptions, none past expiry."

The headline reports outcomes rather than effort. It also makes the gap visible: 9 Implemented items are not yet counted as Verified, because no negotiation evidence exists for them. The figures will look modest; that is accurate. The sponsor can see which items need a push and which need evidence collection rather than more changes.

6.7 Practice task

Set up a tracker for ten MTI items and move three through the states with evidence.

Give each item a source, an owner and a current state. For the three you move, attach the evidence that justifies each transition: an inventory record, an owner and date, a change ticket, then negotiation logs before Verified. Ask a peer to check that no item jumps a state without evidence, and that dependencies carry follow-up dates. Keep a record of what evidence you used for each move.

6.8 Cadence

A monthly working meeting with system owners keeps items moving; a quarterly report goes to the sponsor; an annual review revisits the standard, priorities and lifetimes. Keep each meeting short and driven by the tracker: blocked items first, then items due, then new unknowns.

At MTI the monthly meeting is where the reinsurer SFTP dependency was chased, and the quarterly report carried the result to the sponsor. Cancel a meeting rather than hold one with nothing on the tracker to discuss, and send a short note of decisions and new due dates after each.

6.9 Common errors and limits

Each error inflates progress or hides delay. A change ticket shows intent, but MTI's broker portal regression showed that configuration can revert. A dependency without a follow-up date can sit unanswered for quarters. Activity metrics such as meetings held tell an executive nothing about protection and crowd out the measures that do. Check the tracker and report for all three before each quarterly report.

Exercises

Synthesis

A repeatable cycle with clear roles, tracker states, managed dependencies and outcome measures turns migration into routine, reportable work.

Continue studying — chapter 06 of 12

← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →