In M11 you saw the Europol/FS-ISAC/CFDIR risk-based prioritization methodology, and in M12 five-layer discovery and the CBOM. This lesson combines them to produce a concrete, three-horizon migration roadmap for a synthetic bank.
Three horizons: a real methodology, this course’s concrete interpretation
The Europol/FS-ISAC/CFDIR report proposes a risk-based “Phased Transition Framework”: first a focused transition program, then remediation of high and medium-risk use cases, and finally maintaining policy and regulatory compliance after quantum-vulnerable algorithms have been removed completely. But the document itself gives no concrete month or year boundaries for these phases (the methodology classifies risk levels as red, amber and green from “Quantum Risk x Migration Time”, not as a calendar); that is a deliberate design, because every bank’s risk profile is different. This lesson turns that general frame into three concrete horizons: H1: 0-12 months, H2: 12-36 months, H3: 36+ monthsESTIMATED, with discovery (M12), inventory and quick wins (for example shutting down weak protocols that are no longer supported) in H1; migration of high-risk systems (such as the 4 payment surfaces that really need PQC from M10) in H2; and the remaining systems and institutionalizing the full crypto-agility you saw in M12 in H3.
The concrete month boundaries of these three horizons are not a verbatim quote of the Europol/FS-ISAC/CFDIR text; they are this course’s attempt to turn the methodology’s risk-based spirit into a workable timeline. When presenting this structure to an auditor, keeping that difference open (the methodology itself is real and official, but the specific month boundaries are this course’s operational interpretation) is the same honesty discipline you saw in M11’s “reflection policy” lesson.
A dependency graph: the horizons are not independent
It is critical to see that the three horizons are not just sequential but dependent: a migration task in H2 usually depends on H1’s discovery output (you cannot put a system into migration without knowing which algorithm it uses), and full crypto-agility in H3 is built on the provider models set up in H2 (which you saw in M12). Drawing a dependency graph shows that these horizons move largely in sequence, not in parallel; you can answer a board’s proposal “let’s accelerate H1 and H2 at the same time” with this dependency graph, showing which task depends on which.
Numbers to know
Three horizons (this course's own operational frame: concrete month ranges based on the spirit of the Europol/FS-ISAC/CFDIR 'Phased Transition Framework', not quoted from it): H1 (0-12 months, discovery + inventory + quick wins), H2 (12-36 months, migration of high-risk systems), H3 (36+ months, remaining systems and full crypto-agility)
An honest note: the Europol/FS-ISAC/CFDIR document itself does NOT give concrete month or year ranges; it only defines a phased frame (first a focused transition program, then remediation of high and medium-risk use cases). The concrete boundaries of H1/H2/H3 are this course's own operational interpretation
Lab: Fill in the three horizons for a synthetic bank
[not run] This is a planning exercise, not a runnable command
# Take the crypto inventory you built in M12 (or a hypothetical one for your own bank); for each crypto surface (such as the 10+1 payment surfaces in M10) mark which of H1/H2/H3 it falls into, and draw the dependencies (e.g. a task in H2 depends on discovery in H1 being complete)
Recorded output
A table or simple diagram: each work item, which horizon it is in, and which earlier task it depends on
At the table
How to say this in a bank meeting.
To an executive
Our migration program is not one big project but a three-horizon roadmap: discovery and quick wins in the first 12 months, high-risk systems in the next 24, and the rest in the third horizon. This structure turns the risk-based logic of the Europol/FS-ISAC/CFDIR methodology you saw in M11 into a concrete timeline.
To an architect
The dependency graph is critical: a migration task in H2 usually depends on H1's discovery output (such as the CBOM you saw in M12); planning H2 independently of H1 without seeing this dependency leads to an assumption of parallelism that does not really exist.
Objection
“"Why 0-12/12-36/36+ months? Where do these boundaries come from? Does Europol say so?"”
Answer
Honestly: no, the Europol/FS-ISAC/CFDIR document itself does not give these specific month boundaries; it only proposes a phased frame. These three horizons are this course's attempt to turn that frame into a concrete, workable timeline; the boundaries can be adjusted to your bank's real risk profile and are not a fixed rule.
Europol, FS-ISAC, CFDIR, 2026. The primary source for the risk-based methodology you saw in M11, the frame this lesson applies to a synthetic bank
Phased Transition Framework section / 15 min
Checkpoint
Answer first, then compare with the model answer and score yourself against the rubric. Saved in this browser only.
01Recall
What are the three horizons, and which work items does each cover?
Model answer
H1 (0-12 months) covers discovery, inventory and quick wins. H2 (12-36 months) covers migration of high-risk systems. H3 (36+ months) covers the remaining systems and institutionalizing full crypto-agility.
02Recall
Do the concrete month boundaries of H1/H2/H3 come from the Europol/FS-ISAC/CFDIR document itself, or are they this course's own interpretation?
Model answer
They are this course's own interpretation. The Europol/FS-ISAC/CFDIR document proposes a risk-based phased transition frame but gives no concrete month or year boundaries; the month ranges of H1/H2/H3 are this course's translation of that frame's risk-based spirit into a workable timeline.
03Scenario
A team plans to start a migration task from H2 at the same time as H1, without noticing that it depends on H1's discovery output. How do you show this dependency?
Model answer
I draw a dependency graph: I show that the H2 migration task cannot start without knowing which system uses which algorithm, and that this information comes from H1's discovery output (such as the CBOM in M12). This makes concrete that the horizons move largely in sequence, not in parallel, and shows that planning H2 independently of H1 assumes a parallelism that does not really exist.
A complete answer includes
Your score: 0/3
04Hostile
An auditor asks 'Which official standard are these three horizons based on?' Explain honestly which part comes from the real methodology and which from this course's operational interpretation.
Model answer
The risk-based approach itself rests on the Europol/FS-ISAC/CFDIR 'Phased Transition Framework', which is a real, official source. But that document gives no concrete month or year boundaries; it only defines a phased frame. The specific month boundaries, H1 (0-12 months), H2 (12-36 months) and H3 (36+ months), are this course's attempt to turn the methodology's risk-based spirit into a concrete timeline, not a verbatim quote.
A complete answer includes
Your score: 0/3
Project linkThe direct skeleton of Project 4's (capstone) migration roadmap; the three horizons are the section headings of the capstone's own timeline.