The governance
Validation, monitoring, and the questions to ask
Migrating once is not the same as staying migrated — how to validate a claim, monitor for drift, and the specific questions worth asking your own teams.
6 min read · 5 min 17 sec film
What you'll be able to do
- Explain why validation and continuous monitoring are separate steps from migration itself.
- Recognize the organizational patterns that cause migrated systems to regress.
- Use a concrete set of questions to test whether a team's progress claim holds up.
Lesson film
Watch: Validation, monitoring, and the questions to ask
A system that migrated six months ago is not necessarily migrated today — and the six questions that find out.
5 min 17 sec · 7 scenes
5 min 17 sec, narrated by your browser's voice. Captions and a full transcript are below — nothing here needs sound.
There is one assumption left to take apart, and it is buried in how these programmes get reported.
With the player focused: Space plays or pauses, ← → seek ten seconds, Home restarts, M toggles narration.
Full transcript
1. Migrated is not a state
2. How systems regress
3. Two different things
4. Caught before it shipped
5. What good looks like
6. The questions
7. Takeaway
The written lesson
A system that migrated successfully six months ago is not necessarily migrated today. Dependencies get upgraded and quietly reintroduce an old default. A certificate renews through a process nobody updated. A new service ships from a copied, outdated configuration template. Post-quantum migration does not remove the need for the rest of a security program: a well-migrated system that nobody watches is still a system nobody watches.
This is why validation and continuous monitoring are separate line items from the migration itself, not an afterthought. Validation confirms a specific claim is true right now. Continuous monitoring confirms it stays true after the next release, the next dependency upgrade, and the next acquisition.
None of this replaces judgment. Ask your own teams directly, on a schedule, and expect specific answers, not reassurance.
| Question to ask | A good answer sounds like | A worrying answer sounds like |
|---|---|---|
| What is our cryptographic inventory coverage, including vendors? | Here is the known population and dated coverage, the gaps, and the owner of each closure action. | Yes, it is done. (With no detail on scope, vendors, or ownership.) |
| How did we prioritize what migrates first? | By secrecy, capture path, impact, evidence, and dependencies, with a documented first tranche and review trigger. | We started with whatever was easiest to change. |
| What happens when a system misses its migration deadline? | An authorized owner evaluates residual risk and alternatives, then records a scoped, time-bound decision if accepted. | It quietly drops off the list. |
| How do we know a migrated system has not regressed? | Continuous monitoring and a release gate catch reintroductions before they ship; here is the last time it caught one. | We checked it once when we migrated it. |
| What is our position on authentication, not just key exchange? | Here are the sampled negotiated groups by connection hop, signature and certificate status, gaps, and owned next checks. | We are fully post-quantum. (Without distinguishing key exchange from authentication.) |
| What would change our prioritization tomorrow? | A new regulatory deadline, a vendor announcement, or new evidence about a specific system, and here is who monitors for that. | Nothing — the plan is fixed. |
A credible coverage dashboard distinguishes configured support, observed negotiation, validated peer classes, certificate and signature migration, vendor answers, and unresolved exceptions. Use denominators and dates: “92 of 110 known internet-facing flows sampled this month” can be challenged; “mostly done” cannot. Show the trend and name the owner who investigates regression.
Work it through
L01: fund and govern the first tranche
This synthetic board case has one team and a provisional 12-month budget of 10 effort units. Units are illustrative capacity, not money. Choose an initial portfolio and write a short decision memo.
About 20 min of unscored practice
Evidence supplied for this exercise
| Candidate | Cost / lead time | Impact and evidence |
|---|---|---|
| A. Map customer-record flows | 2 units / 2 months | Known 18-year confidentiality; only 8 of 20 flows have current key-exchange evidence |
| B. Pilot hybrid edge-to-origin | 3 units / 4 months | A sampled CDN edge uses hybrid, origin group unknown; one partner needs testing |
| C. Replace firmware trust root | 6 units / 2 years total | Eight-year device life; OEM release dependency; first-year design phase costs 3 units |
| D. Retire batch service | 2 units / 6 months | Service owner confirms retirement date; data has one-year confidentiality need |
| E. Monitor negotiated groups | 2 units / 3 months | No current release gate; sampling covers 8 of 20 flows |
Your task
- Allocate no more than 10 first-year units and explain what is deferred.
- Name an executive sponsor, program owner, and system/vendor owner for key gaps.
- Decide whether to approve, reject, or return the vendor exception for evidence.
- State two dashboard measures and a fact that would change your plan.
Type here or copy the template. Your response stays in this page and is not submitted or scored.
Reveal model response and self-check rubric
A different answer can be sound when it states its assumptions and follows the evidence.
One defensible portfolio funds A (2), B (3), C design (3), and E (2): 10 units. It establishes data-flow evidence, tests a potentially exposed origin hop, starts the long device dependency, and measures negotiated coverage. Defer D with the confirmed retirement owner and date, subject to evidence that the one-year data lifetime is accurate. Another portfolio could favor D if its retirement removes a shared dependency; state why.
Name an executive risk sponsor, a day-to-day program owner, and owners for the origin service, device line, and vendor. Return the vendor exception for evidence: origin negotiation, residual exposure, controls, alternate migration paths, authority, and review trigger. Report “8 of 20 known flows sampled this month” and “0 of 1 origin partners validated for the proposed pilot” until testing changes them. A failed OEM commitment or a confirmed classical origin hop with long-lived data should trigger re-sequencing.
Self-check
For each point: 0 = absent or incorrect, 1 = partly supported, 2 = well supported.
- Allocate within capacity and articulate opportunity costs and alternatives.
- Use evidence, harm, dependencies, and lead times in the choice.
- Assign decision and system ownership.
- Evaluate residual risk before accepting an exception.
- Use dated measures with denominators and a reconsideration trigger.
Primary reading and claim sources
Publication status checked on the date shown. Draft guidance can change.
- CSWP 39-upd1: Considerations for Achieving Crypto AgilityNIST · Updated guidance; supersedes CSWP 39 · checked 2026-09-26
- TR 104 016: A Repeatable Framework for Quantum-Safe MigrationsETSI · Published technical report · checked 2026-09-26
- SP 800-30, Revision 1: Guide for Conducting Risk AssessmentsNIST · Final guidance · checked 2026-09-26
Marking a lesson complete only updates this browser.