Mental model
In the previous two lessons you built a roadmap (three horizons) and a cost methodology. This last M13 lesson focuses on governance: who is responsible for the program and how dependent it is on suppliers.
The vendor questionnaire: four areas
A migration program almost always depends on third-party suppliers (HSM vendors, CAs, TLS and crypto library providers, payment processors); so a vendor questionnaire should be an early step in the program. Four areas should be covered: (1) roadmap and dates, a concrete version number and date commitment (as you saw in M5, not “soon” but something like “in version X.Y, in quarter Q”); (2) which algorithms are supported at which status, applying M5’s status discipline (FINAL/DRAFT/SELECTED and so on) directly to the vendor; (3) crypto-agility architecture, whether there is an abstraction like the provider model you saw in M12, or whether an algorithm change depends on the vendor’s own product update; (4) certification status, at which stage a certification such as FIPS 140-3 or Common Criteria is (like M5’s CAVP/CMVP distinction).
Vendor lock-in: who benefits from delay
A risk specific to PQC migration: a vendor can profit by delaying its own transition, because the longer the customer stays dependent on the vendor’s existing, proprietary integration, the higher the cost of switching vendors. This is not an accusatory assumption (most vendors do not delay deliberately; there are real engineering difficulties), but trusting a vendor’s own roadmap statement without questioning whether this motivation might exist is a weak governance position. The practical response: tie concrete commitments to the contract (an SLA, service level agreement), ask for independent verification (third-party certification, a public roadmap page, not just the sales representative’s word), and keep a fallback or exit plan (an assessment of alternative vendors) for critical suppliers.
RACI: making supplier dependency visible
In a RACI matrix (Responsible, Accountable, Consulted, Informed), supplier-dependent work items must be marked explicitly: for example, an HSM firmware update is controlled not by a team inside the institution but by the vendor’s own delivery schedule. Planning this item on the same RACI line, with the same confidence, as an internal task leads to an assumption of control that does not really exist (the same logic as the dependency graph principle in M13’s first lesson, this time applied to supplier dependency).
KPIs and reporting
To track a migration program’s progress, at least these KPIs (key performance indicators) are meaningful: percentage of systems completed (in each of H1/H2/H3, the number of systems migrated over the total), supplier commitment fulfilment rate (how many of the dates vendors gave were really kept, a confidence score based on past performance), and number of high-risk systems remaining (how many critical systems, such as the 4 payment surfaces that really need PQC from M10, are still waiting for migration). Board reporting should present these KPIs tied to the three-horizon structure from M13’s first lesson: concrete, traceable language such as “80% of H1 is complete, the start of H2 was delayed by 2 months because of a supplier delay” is more trustworthy than vague language such as “overall we are doing well”. The same discipline applies to regulator communication: the progress presented to the regulator must rest on the same numbers as the internal KPIs, with no separate “external face” narrative.