up:: The Human & Organizational Side MOC

The Five-Piece Plan

The five-piece plan is the completeness test for a fundable post-quantum migration plan: five parts a board expects to see, and a good board notices the moment one is missing. The five are an exposure baseline (where your cryptography lives, and the years of harvest-now-decrypt-later exposure your sensitive data already carries), an honest map of your blind spots (where you can’t see, where nobody owns it, where governance doesn’t exist yet), your vendor dependency (whose roadmap is your roadmap), a prioritized sequence with a timeline (what moves first, ordered by data lifetime and exposure), and the investment justification (what it costs against what it protects, as a capital decision). Anyone can hold a draft plan against the five and name what’s missing without reading a line of code, which makes it a test rather than a template.

The short version:

• Five pieces make a migration plan fundable: an exposure baseline, an honest blind-spot map, the vendor-dependency picture, a prioritized sequence with a timeline, and the investment justification.
• It’s a completeness test, not a format. Anyone can audit any draft plan against the five and name the gap, which is why a board member with no cryptography background can still spot a hollow plan.
• A missing piece is itself the finding. The part a plan quietly leaves out is usually the exact risk the board most needs to see.
• The audience is the board that funds it, so it reads as a risk-and-investment decision, and the specific algorithm choices belong to a separate, later piece of work.
• On a single-system scope the middle pieces may be one line each, and the test still runs top to bottom.

Think of a bank underwriter reviewing a loan file. The board deciding whether to fund your migration is doing the same job: committing capital against a risk. A complete file carries the same handful of documents every time, the income, the collateral, the appraisal, the repayment schedule, and the amount.

A seasoned underwriter fans the stack once and notices the appraisal is missing, and the file stalls on that one gap no matter how polished the rest is. The five-piece plan is that fan-through for a quantum migration, and naming the five lets you run the underwriter’s eye over your own file before the board does.

What is the five-piece plan?

The five-piece plan is the answer to a question every leader eventually gets handed: what actually goes into a quantum migration plan that gets funded and survives the day an auditor or a regulator asks you to defend it? Most first attempts are a slide of vendor logos and the year 2035, and a board reads that for the placeholder it is in about 30 seconds. The five pieces are what a real one contains.

Each piece answers a different question a funder has, and the reason a missing piece is so visible is that its absence leaves one of those questions unanswered in a way no formatting can hide.

Piece	What it contains	What its absence tells a board
1. Exposure baseline	Where your cryptography lives across the estate, and for sensitive data, the years of secrecy already exposed under harvest-now-decrypt-later	The team hasn’t looked yet, so nothing downstream can be sized or trusted
2. Honest blind-spot map	Where you can’t see your own cryptography, where ownership is missing, where governance doesn’t exist yet	Either the estate is trivially small, or the gaps were hidden, and a board assumes the second
3. Vendor dependency	Which systems you can’t touch directly, and whose roadmap therefore sets your timeline	The plan is claiming dates it doesn’t control, which collapses on the first pointed question
4. Prioritized sequence with a timeline	What moves first, ordered by data lifetime and exposure, mapped against the years you actually have	It’s an unordered wish list, and the board can’t tell what the first dollar buys
5. Investment justification	What closing the exposure costs, against what it protects, framed as a capital decision	There’s nothing to approve, so the plan is a study, not a request

The five describe the parts a complete plan has by the time it’s done, in whatever order you assemble them, and the test is whether all five are present and honest. A plan can be beautifully written and still fail the test, because polish lives in a different place from completeness.

What goes into each piece?

Here’s each piece worked on a generic mid-sized company that has run a first-pass discovery effort and is assembling the plan it will take upstairs. Every number below is illustrative; yours come from your own estate.

1. The exposure baseline: where cryptography lives, and how exposed it already is. This is an accounting, not a vibe. Where does the quantum-vulnerable cryptography actually run, and for the sensitive data behind it, how many years of secrecy are already unprotected? The exposure-years number is what makes the risk real to a board, because it converts an abstract future threat into a present liability the company is already carrying. The years come from the shelf-life question put to each data owner, and the reason harvest-now-decrypt-later makes those years count today is that an adversary can record the traffic now and decrypt it once a machine exists. When it’s missing: the plan opens with a threat and no measurement of the company’s own share of it, and every later piece rests on a number that was never established.

2. The blind-spot map: what you couldn’t see, who doesn’t own it, where governance is absent. A plan that lists only what discovery found, and stays quiet about what it couldn’t reach, is worth less than no plan, because it hides the risk in exactly the places risk collects. The version borrows the posture from the three zones: the cryptography beyond your reach goes on the record as a dated, owned finding. Blind spots come in three flavors, and a board should see all three: cryptography that stays invisible to you, cryptography you can see but nobody owns, and surfaces where no governance process keeps it current. When it’s missing: the plan looks complete, which is the tell. Every real estate has blind spots, so a plan that shows none was drawn from documentation rather than evidence.

3. The vendor dependency: whose roadmap is your roadmap. For the systems you can’t touch directly, the vendor’s release schedule is your migration timeline, and a fundable plan names that honestly rather than pretending it owns dates it doesn’t. This is the plan-level view of what vendor-controlled surfaces means: some of your most exposed cryptography changes only when a supplier decides to ship, and until then your job is to bound it, date it, and apply what leverage procurement gives you. When it’s missing: the plan presents a single clean timeline the company fully controls, and the first board member who has ever managed a vendor relationship stops trusting it.

4. The prioritized sequence with a timeline: what moves first, and against what clock. This is where the exposure math becomes a schedule. The order runs by how long each dataset must stay secret against how long you have left, so the systems bleeding today lead and the long-lead trust anchors open in parallel. The ranking method is the two-lens rule, sorting by data shelf life and blast radius, and the sequencing rule puts key establishment ahead of signatures, the half exposed to harvesting right now. The timeline maps that order against the years you have, with the federal deadlines where they bind: key establishment by the end of 2030 and signatures by the end of 2031 under Executive Order 14412. When it’s missing: the plan is a list of everything that needs doing with no order, and a board can’t fund “all of it, eventually.”

Source: Executive Order 14412, “Securing the Nation Against Advanced Cryptographic Attacks,” 91 FR 38483, June 25, 2026, federalregister.gov.

5. The investment justification: cost against what it protects, framed as a capital decision. A board funds risk reduction and approves investment, so the final piece states what closing the exposure costs and what that spend protects, in the language a finance committee already uses. The cost is built by pricing the prioritized sequence, and the mechanics live in the business case and what a migration costs. The public scale anchor is the U.S. government’s projection of roughly $7.1 billion in 2024 dollars to migrate priority federal civilian systems from 2025 to 2035. When it’s missing: the plan describes a problem and asks for nothing specific, so the board nods and defers it another budget cycle.

Source: Office of Management and Budget, “Report on Post-Quantum Cryptography,” July 2024, OMB PQC Report.

The federal figure is a sense of scale for a very large estate, never a number you divide down to one organization. Your investment justification is built from your own inventory, and the value of piece 5 is the framing, cost against protected value as a capital decision, more than any single number.

Why is a fundable plan a risk-and-investment document?

Because the people who fund it are deciding whether to commit capital against a risk, and they weigh it against every other risk and investment on the table. The most common first mistake is bringing the board an engineering answer to a governance question: which algorithms, which libraries, which configurations. A board doesn’t fund algorithms, so a plan built around them reads like a purchase someone is trying to justify rather than an honest account of where the company stands.

The audience decides the shape. A board-ready plan answers “how exposed are we, and what should we invest,” and it leaves the specific algorithm choices to a separate, later piece of engineering work. That’s why the five pieces are all risk-and-investment parts and none of them is “which product we picked.” The moment the plan starts recommending specific vendors, it has quietly switched audiences and stopped being the document the board asked for. The ML-KEM and ML-DSA target-state decisions are real and necessary, and they belong downstream of the funding decision, not inside the case for it.

One property runs quietly under all five pieces and decides whether the plan survives a skeptical room: every number in it should trace back to something a challenger can check. The exposure-years to the owner who gave them and the date they gave them, the dependency counts to the artifact they came from, the cost to the inventory line it was priced against. A plan whose claims all have a checkable origin answers “how do you know that?” with a source instead of an assurance, and that’s the difference between a plan a board interrogates and one it defends on your behalf.

How do you audit a draft plan against the five?

You fan it once for presence, then a second time for honesty. Here’s the audit run end-to-end on a generic draft a team has handed up, the kind that looks finished until you hold it against the five.

The draft in front of you reads well. It opens with a clear explanation of the quantum threat and harvest-now-decrypt-later. It names ML-KEM and ML-DSA as the targets and lists the systems the team plans to migrate. It closes with a confident timeline ending in 2035 and a request to “begin the migration.” Now run the five:

1. Exposure baseline: partial. The plan describes the threat in general, but nowhere does it state how many years of secrecy the company’s own sensitive data already carries under harvesting, or where its vulnerable cryptography actually lives beyond the systems the team happened to know about. The threat is generic; the baseline is the company’s specific share of it, and that’s missing.
2. Blind-spot map: absent, and hidden. The plan lists systems to migrate and says nothing about what discovery couldn’t reach. There’s no mention of SaaS internals, embedded vendor cryptography, or systems with no named owner. A gap-free plan for a real estate is the tell that the gaps were left out, not that they don’t exist.
3. Vendor dependency: absent. The single 2035 timeline implies the company controls every date, and the plan never separates the systems it can change on its own schedule from the ones waiting on a supplier’s release. That’s the piece whose absence most reliably collapses under a board question.
4. Prioritized sequence: weak. There’s a list of systems, and nothing orders it, because the plan gives no reason one moves before another and never ties the order to data lifetime or exposure. “Begin the migration” is a starting gun, and a board can’t tell what it’s starting.
5. Investment justification: absent. The plan asks to “begin” and never states a cost, a first-move scope, or what the spend protects. There’s nothing a finance committee can vote on.

The audit’s verdict writes itself: this is a threat briefing wearing the title of a plan. Three of five pieces are missing and one is hidden, and the fix isn’t more polish, it’s the four missing pieces. The value of running the test is that it turns “this doesn’t feel ready” into a specific, ordered list of what to go get, which is a far easier conversation to have with the team that wrote it.

Notice what the audit didn’t require: no cryptography expertise, no reading of the technical appendix, no judgment about whether ML-KEM was the right choice. The five pieces are checkable by anyone in the room, which is exactly why the test survives being handed to a board.

Common misconceptions

1. “A plan is a list of algorithm choices.” The algorithm choices are a later, smaller piece of engineering work, and they’re not what a board funds. A plan that leads with ML-KEM and ML-DSA has answered a question the board didn’t ask and skipped the five it did: how exposed are we, what can’t we see, who controls our timeline, what moves first, and what should we invest.
2. “Length equals rigor.” A thick plan reads as diligence and often is padding, and a board that reads for a living can tell the difference. The five pieces are what rigor looks like, present and honest, and a complete plan can be short. A 40-page document missing the blind-spot map is less fundable than a five-page one that has all five.
3. “The plan is IT’s document.” It’s the board’s decision document, produced with IT’s evidence. The distinction matters because it decides who the plan is written for: a plan written for engineers optimizes for technical correctness and buries the risk-and-investment story a board needs to act.
4. “Leading with the technology makes it credible.” In the room, the board hears algorithms and tunes out. Lead with exposure and investment, and the technology becomes an implementation detail the board is happy to leave to you. Credibility with a board comes from a defensible number, not from technical depth it can’t evaluate.
5. “Hiding the gaps keeps the plan strong.” Presenting only what discovery found, and hoping nobody asks about the blind spots, produces a plan that fails the moment a good board does ask, which it will. The plan that names its own dead zones first is the one still standing after the questions, because a board is testing whether you know where you’re weak.
6. “A confident, complete-looking plan is a complete plan.” Missing pieces hide best inside polish. The single clean timeline that implies total control is the vendor-dependency piece quietly deleted; the gap-free system list is the blind-spot map quietly omitted. The audit exists precisely because a hollow plan is engineered to look whole.

Pro tips

1. Run the missing-piece read on any plan you’re handed. The fastest way to assess someone else’s migration plan is to fan it for the five and name what’s absent, rather than reading it front to back for correctness. Whichever piece is missing is almost always the one carrying the real risk, because the pieces teams leave out are the ones hardest or most uncomfortable to fill: the blind spots nobody wants to admit, the vendor dates outside their control, and the cost they’d rather not name.
2. When a piece is present but thin, ask the one question that exposes it. For the exposure baseline, “how many years must our most sensitive data stay secret, and who told you that?” For blind spots, “what did discovery fail to reach, and what’s it costing us to not know?” For vendor dependency, “which of these dates do we actually control?” For the sequence, “why does this system move before that one?” For investment, “what does the first dollar buy, and what does it protect?” An evasive answer to any of these is the missing piece surfacing.
3. Treat the blind-spot map as a strength. A plan that names what it can’t see reads as more trustworthy, because it demonstrates the team knows the shape of its own ignorance. Frame each blind spot as a dated finding with an owner, the way the three zones does, so it lands as a managed risk rather than a hole.
4. Build the pieces in dependency order, present them in board order. You assemble the baseline first because everything downstream needs it, then the blind spots, then vendor dependency, then the sequence, then the cost. In the room you often lead with the exposure and the ask, and keep the rest as the evidence a director reaches for when they probe. The order you build is not the order you present.
5. Keep every number’s origin attached to it. When a board member points at a figure and asks where it came from, “the head of product gave us that on the third, and here’s the record” ends the challenge, while “our analysis shows” invites ten more questions. Provenance is cheap to capture while you’re building and expensive to reconstruct under fire.

Where does the five-piece plan break?

Published limits, because a completeness test that can’t fail is one nobody has stress-tested:

1. Single-system scopes. When the plan covers a single system rather than an estate, pieces 2 and 3 can each be a single line: the blind spots are whatever stays invisible inside that system, and the vendor dependency is either “we control it” or “our supplier does.” The test still runs top to bottom, and the one-line answers are legitimate answers. What breaks is the assumption that every piece needs paragraphs; on a narrow scope, “no blind spots inside this boundary, confirmed by direct configuration access” is a complete piece 2.
2. Greenfield builds with no legacy. For a system being built new to a post-quantum target from day one, the exposure baseline is close to zero and the plan is a design decision rather than a migration. The five pieces still frame it usefully, but piece 1 shrinks to “no legacy exposure, built quantum-safe,” and the weight shifts to piece 3, because a greenfield build still inherits whatever cryptography its dependencies and vendors ship.
3. Completeness is what it tests, and correctness is a separate question. The five pieces can all be present and the plan can still be wrong, if the exposure-years are guesses, the dependency counts are stale, or the cost is optimistic. The test guarantees a plan asks and answers the right questions, and it stays silent on whether the answers are true, which is why the checkable-origin property matters alongside the five, and why the audit fans twice, once for presence and once for honesty.
4. A board that doesn’t know to look. The framework assumes a board or a reviewer who notices the missing piece. A rubber-stamp board will fund a hollow plan, and then the gap surfaces later as an audit finding or a stalled program instead of a question in the room. The test protects a diligent funder; it can’t substitute for one.

How do you use the five-piece plan in the boardroom?

One level up, the five-piece plan is a director’s checklist. A board member with no cryptography background can govern the migration entirely by asking, of any plan they’re shown, whether all five pieces are present and honest, because the pieces were built to be checkable without technical knowledge. The question a director should keep in their pocket is simply “which of the five is thinnest, and why?”, and it works whether they’re reviewing the security team’s plan or a consultant’s.

For the person presenting, the five pieces are the pre-flight check you run on your own plan before the board runs it on you. Walk your draft against the table, find the piece a skeptical director would land on first, and either fill it or name it out loud before they do. Naming your own weakest piece is the move that converts a defensive meeting into a funded one, because a board’s trust comes from watching you find your own gaps faster than they can.

And the five pieces travel upward cleanly. A director can carry “our plan has all five, and the blind-spot map is the one we’re still filling” to the full board or an auditor without translating a word of it, which makes the framework a governance tool rather than only a drafting aid. Brief Your Board carries the fuller version of the room conversation, The Cryptographic Risk Register is where the pieces live as tracked risks between board meetings, and Own Your Quantum Risk is the same program seen from the executive owner’s chair.

Questions people ask

What are the five pieces, in one breath? An exposure baseline (where your cryptography is and how exposed it already is), an honest blind-spot map (what you can’t see or don’t own), your vendor dependency (whose roadmap sets your timeline), a prioritized sequence with a timeline (what moves first and by when), and the investment justification (what it costs against what it protects). If a plan has all five and they’re honest, it’s fundable.

Which piece do teams leave out most? The blind-spot map and the vendor dependency, because both require admitting a lack of control, and the sequence often collapses into an unordered list. Those three absences are the most common reason a plan that looks finished isn’t.

Is a missing piece always a problem? A missing piece is always a finding, and on a narrow scope it can be a one-line finding that’s perfectly fine (no blind spots inside a fully-controlled single system, for instance). The problem is a piece that’s missing silently, because then the board can’t tell whether the gap is real or hidden.

Does the plan recommend specific algorithms or vendors? No. It’s a risk-and-investment document, and the specific algorithm and product choices are a separate, later piece of engineering work. A plan that leads with vendor recommendations has switched audiences and stopped being the document the board asked for. The target-state facts, that ML-KEM replaces key exchange and ML-DSA replaces signatures, sit downstream of the funding decision.

How is this different from a cryptographic inventory? The inventory (CBOM) is raw material for piece 1 and piece 2; the five-piece plan is the fundable document built on top of it. An inventory tells you what cryptography you run and where. The plan turns that into an exposure baseline, a blind-spot map, a sequence, and an ask a board can vote on.

How long does it take to build a first version? The first defensible version is a few weeks of work on a crown-jewel scope, the same Phase 1 that Start a Migration walks. You’re producing a prioritized shortlist and a one-page ask, not a finished migration, so the plan exists long before the multi-year program does.

Can a plan pass the five and still be a bad plan? Yes. The test checks that all five pieces are present and answered, not that the answers are true. A plan with guessed exposure-years or a stale dependency count passes the presence test and fails on honesty, which is why the audit fans twice and why every number should trace to a checkable source.

Who’s supposed to build it? The named owner of the migration, using evidence from the security and architecture teams and the data owners. If nobody owns the migration, that’s the problem to fix before the plan, and ownership is how you find or create the owner. A plan with no owner is a document nobody is accountable for.

What if my board doesn’t know to ask for the five? Then present them anyway, and name the framework as you go: “here are the five things a fundable plan needs, and here’s where we stand on each.” You’re teaching the board the test at the same time you pass it, which makes the next plan, from anyone, easier for them to govern. Governance is the reason the migration stalls without a board that engages, so handing them the checklist is part of the work.

---

Everything here is the map, given freely: the five pieces, and the test you run against any plan with them. Building the version quantified against your own estate, exposure-years from your own data owners, dependencies from your own vendors, a cost from your own inventory, until the plan is one your board and your regulator would both sign, is the work I do. Request the workshop.

Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.