up:: The Human & Organizational Side MOC

The Five-Name Test

The five-name test is a one-afternoon diagnostic for whether an organization actually has an owner for its post-quantum migration. Ask five people across engineering, procurement, and security a single question, “who owns the post-quantum migration?”, and read the answers. One name back, the same name every time, means you have an owner. Five shrugs, or five different names, means you have the vacuum, and that vacuum is the first problem to solve, ahead of any inventory and any algorithm. The test costs an afternoon and it returns something usable either way: a named owner you can then check for the three authorities that make ownership real, or documented proof of exactly why nothing has moved.

The short version:

• Ask five people across engineering, procurement, and security who owns the post-quantum migration, and listen for whether one name comes back.
• One name, repeated, means the owner exists. Divergent answers or blank stares mean the accountable seat is empty, which is the most common reason these programs never start.
• A name is only the beginning. A real owner carries three written authorities: over procurement language, a standing seat in architecture review, and a direct line to a board sponsor with committed budget.
• Both outcomes are worth having. You either confirm an owner and pressure-test the authorities, or you get an evidence-backed answer to why the migration is stalled.
• The test comes before the inventory, because commissioning the inventory that reveals the scope is itself an act of ownership, so someone has to hold the role before the scope can exist.

Think of it like calling five departments in a large building to ask who is responsible for the fire-suppression system. If every call returns the same name and a phone number, the building has a safety owner and you can go talk to them. If facilities points at operations, operations points at the landlord, and the landlord points back at the tenant, you have learned something more important than any equipment spec: nobody is actually accountable for the thing everyone depends on, and that is the first fact you have to fix.

What is the five-name test?

The five-name test is an ownership diagnostic. It answers one binary question, does a post-quantum migration have a single accountable owner, using the cheapest instrument available: a short conversation with a handful of people who would each know if an owner existed. Cryptography has run quietly in the background of most organizations for decades, so no one was ever put in charge of the whole of it, and the migration now sits in the seams between functions that each assume another one holds it. The test surfaces that gap in an afternoon instead of a year.

The procedure is deliberately simple:

1. Pick five people who would know. Draw them from the functions the migration actually spans: an engineering or platform lead, someone in procurement or vendor management, a security or risk leader, an enterprise architect, and one person from governance or the business who would carry the budget ask. The point is coverage across the functions, not a survey of the whole company.
2. Ask each one the same plain question. In these words, one at a time, separately: “who owns the post-quantum migration?” Resist rephrasing it into “who’s working on quantum stuff,” which invites a list of participants rather than an owner.
3. Read the pattern, not the individual answers. You are listening for convergence. The content of any single answer matters less than whether the five of them point at one person.

The output is one of two states. Convergence on a single name means an owner exists, and the test’s job shifts to checking whether that owner has the three authorities below. Divergence, or a set of shrugs, means the accountable seat is empty, and the vacuum is now documented rather than assumed.

Why five people, and why across three functions?

Because a migration’s ownership problem is a problem of coordination across functions that don’t share a mandate, so the test has to sample across exactly those functions to see it. A post-quantum migration needs engineering to do the work, procurement to hold vendor leverage, security to own the risk, architecture to design the target state, and governance and the board to fund it. Those levers sit in different reporting lines. Asking only within the security team would tell you what security believes, and security is the function most likely to assume the migration is theirs whether or not the authority actually follows.

Five is the smallest sample that reliably exposes the seam. One or two people can share a private assumption that turns out to be wrong the moment a third function is asked. Spreading the five across the functions that hold the split levers means that if an owner genuinely exists, the people who would have to answer to that owner will name them, and if no owner exists, the divergence shows up as each function naming itself, naming a different function, or naming no one. The number is a floor for reliable evidence: in a very large enterprise you might ask more, but fewer than a spread of five tends to miss the gap it exists to find.

There is a second reason the cross-functional spread matters. The most dangerous failure state is not five blank stares, which at least everyone can see. It is five confident and different answers, where engineering is sure architecture owns it, architecture is sure the CISO owns it, and the CISO assumes the program office does. Each answer sounds like ownership to the person giving it, and the contradiction only appears when you lay the five side by side. Sampling one function would have returned one confident answer and hidden the vacuum completely.

Why is the same name coming back the thing that matters?

Because convergence is expensive to fake and cheap to verify, which makes it honest evidence. For five people in different reporting lines to independently name the same person, that person has to have done something visible across all their boundaries: convened them, made a decision that stuck, or carried an ask upward on their behalf. That footprint is what real ownership leaves behind, and it is very hard to manufacture for a test nobody knew was coming.

A single repeated name tells you three things at once. It tells you the role is filled, that a specific human is accountable. It tells you the role is known, that the accountability has been communicated across the functions the migration touches rather than living silently in one person’s objectives. And it tells you the role has reach, because a name that only engineering recognizes is an engineering lead, while a name all five functions recognize is an owner. The test is really measuring that reach, and reach is the property a stalled program is always missing.

The absence of convergence is equally diagnostic, and it is not a small finding. A migration with no accountable owner drifts, because there is no one with the standing to commission an inventory, resolve a cross-team dispute, or move budget. So a failed five-name test has located the actual blocker, and it has done so before a single dollar was spent on discovery or a single algorithm was debated. That ordering is the whole value: the vacuum is the first problem, and the test finds it first.

What are the three authorities that make an owner real?

Passing the test gets you a name. Whether that name is an owner or a scapegoat depends on three specific authorities, and without them the accountability is decorative. The most common way a migration fails with a name attached is that the organization hands someone accountability for the outcome, most often the CISO, without the authority to move the levers the outcome depends on. Owning the risk and being able to fix the risk are two different things, and the gap between them is where a well-intentioned program quietly stalls with somebody’s name on the slide.

A real owner carries all three of the following, written into the role in the same document that names them:

Authority	What it grants	What its absence looks like (decorative ownership)
Authority over procurement language	Post-quantum requirements go into vendor contracts, and the renewal calendar becomes leverage instead of a surprise. The owner can make a supplier’s roadmap a contractual obligation rather than a hope.	The owner is accountable for vendor-controlled surfaces they cannot move, because someone else signs the contracts and no clause requires the vendor to migrate on any timeline.
A standing seat in architecture review	The target-state design is built around the migration from the start, so new systems are born crypto-agile instead of adding to the backlog. The owner shapes decisions before they harden.	The migration is retrofitted after the fact onto architectures that were approved without it, and the owner learns about crypto-relevant decisions once they are already in production.
A direct line to a board sponsor with committed budget	The program outlives the quarter it was funded in, survives reorganizations, and has a fast escalation path when a team refuses to move. The owner can spend and can unblock.	The owner has responsibility but no money and no escalation, so the program competes for scraps against every team’s real targets and loses, and the “owner” becomes a name to blame when it slips.

Write those three authorities into the role at the moment you name the owner, in the charter or memo that names them, because the authorities are what convert a name into a function. A name without them is the title trap: the person is accountable in name and powerless in fact, which is the worst of both states, because the organization now believes the problem is handled while nothing that would actually move it is within the owner’s grasp.

What does a real ownership model look like around the owner?

The owner is the load-bearing part, and two structures hold them up. A working ownership model has three components, and the test’s single name is only the first of them:

1. One accountable executive owner. A single named executive, most often the CISO or a direct delegate, answerable for the migration’s outcome and carrying the three authorities above. Accountability shared across a committee is accountability that belongs to no one, which is why the test looks for one name rather than a list.
2. A cross-functional working group chartered to decide. A standing group with real representation from engineering, security, procurement, architecture, and compliance, empowered to make decisions rather than only trade status. A group that can escalate but cannot decide moves at the speed of the slowest calendar, so the charter has to grant it decision authority explicitly.
3. Board-level sponsorship with committed budget. A named executive sponsor above the owner who has committed money and priority, so the program survives competing demands and the next reorganization.

The detailed, function-by-function responsibility map that assigns who is responsible, accountable, consulted, and informed for discovery, algorithm decisions, rollout, vendor engagement, and governance is the next layer down, and it is built against a specific estate rather than described in the abstract. Cryptographic Ownership carries the full ownership model, and Why Is Quantum Readiness a Governance Problem places it inside the governance function where a board and an auditor already expect to find it.

Why does naming the owner have to come before the inventory?

Because the inventory cannot commission itself. The instinct is to understand the scope first and assign an owner once you know how big the problem is, and that ordering is backwards in a way that guarantees the program never starts. Commissioning the inventory that reveals the scope is itself an act of ownership, and nobody has the authority to perform it until someone holds the role. So waiting for scope before naming an owner means waiting for a thing that only an owner can produce, which is how a migration stays permanently one step before its own beginning.

The correct sequence front-loads the organizational work that technical roadmaps skip:

1. Name the accountable executive owner first, before discovery, before purchasing, before a line of new code, and write the three authorities into the role in the same breath.
2. Charter the working group so it has the authority to decide, rather than only to meet.
3. Then commission the cryptographic inventory, which is now something a specific person is accountable for delivering.
4. Prioritize, budget, and sequence against what the inventory finds, with an owner who can carry the budget ask to the sponsor.

Notice that the cryptography enters only after the ownership is settled. That ordering is the difference between a program that ships and one that has a beautiful roadmap and no motion, which is the pattern migrations stall on far more often than on anything cryptographic.

There is a federal precedent worth knowing, kept in its own scope. When the U.S. government told its civilian agencies to begin migrating off quantum-vulnerable cryptography, the very first required step was not an inventory and not a budget. It was a name. OMB Memorandum M-23-02 directed each agency to designate a cryptographic inventory and migration lead within 30 days of the memo and to identify that person upward, ahead of the inventory work itself. That is a rule binding federal agencies, not your enterprise, but it is a useful model, because the government reached the same conclusion the five-name test enforces: someone has to own the migration before the migration can be scoped.

Source: OMB, “Migrating to Post-Quantum Cryptography,” M-23-02, November 18, 2022, §II.B (designate a lead within 30 days; identify to OMB), whitehouse.gov.

What does running the five-name test actually look like?

Here is the test run end-to-end on a generic mid-size organization, a regional insurer, shown in both outcomes. The people and answers are illustrative; the shapes are what recur. The security leader picks five colleagues across the functions and asks each, separately, “who owns the post-quantum migration?”

Person asked	Answer in a stalled organization	Answer in an organization with a real owner
VP of Engineering	”That’s a security thing, I’d assume the CISO."	"Dana Okafor, our VP of Security. She chairs the crypto working group.”
Director of Procurement	”I haven’t heard about a quantum project."	"Dana Okafor. Her team gave us the PQC clauses we now put in renewals.”
CISO	”We’re waiting on the architecture team to scope it before I take it on."	"That’s me. I own the outcome and I sit on architecture review for it.”
Enterprise Architect	”There’s a working group forming, I think? Not sure who runs it."	"Dana. She has a standing seat in our review board for exactly this.”
VP of Finance / sponsor	”Nobody’s brought me a funding ask for it."	"Dana owns it, and I’m her board sponsor with budget committed through next year.”

Read the stalled column and the vacuum is unmistakable: five people, four different theories, and one person actively declining the role until scope appears, which is the ordering trap in the wild. No name converges, so the finding is that the accountable seat is empty. That is the organization’s real first problem, and the test has produced it, dated and documented, in an afternoon. The next move is not more discovery. It is naming an owner.

Read the owned column and one name converges from every function, which passes the first half of the test. The second half is then automatic, because the answers already reveal the three authorities: procurement names the PQC clauses (authority over procurement language), the architect names her standing seat (authority in architecture review), and the sponsor confirms committed budget and an escalation path (the board line). This owner is real, because the authorities show up unprompted in how other people describe the role. Had the sponsor said “I’ve heard of it but there’s no budget,” you would have found a name without the third authority, which is the title trap, and the test would have told you precisely which authority to go secure.

Both runs are wins. One hands you a confirmed, pressure-tested owner. The other hands you the single most important finding about your migration, that it has no owner yet, which is worth far more than another month of scoping a program nobody is accountable for finishing.

Common misconceptions

1. “We named an owner, so the test passes.” A name is necessary and not sufficient. The test’s second half is the three authorities, and an owner without authority over procurement language, a seat in architecture review, and a board line with budget is accountable in title and powerless in fact. Check the authorities every time, because the title trap is the most common way a named program still stalls.
2. “Ownership can live with a committee.” A committee is where the split levers get coordinated, and it is not the accountable owner. When five people name “the working group” or “the steering committee,” the test has failed, because a group cannot be paged at 2 a.m. and a program with no single accountable human drifts. Name the person who chairs the group, then let the group decide.
3. “Security owns it by default.” The CISO usually owns the risk, and the risk is only one of the levers. Defaulting the whole migration to security hands accountability to a function that rarely controls the engineers who do the work or the contracts that move vendors, which is the exact setup the three authorities exist to repair. Security is the most common home for the owner, and it only works when the authorities travel with the name.
4. “Assign the owner once we understand the scope.” Backwards, and it is the ordering error that kills programs at the start. Commissioning the inventory that reveals the scope is itself an act of ownership, so the scope follows from the owner rather than preceding them. Waiting for clarity first guarantees you never get it.
5. “Five different answers just means we’re early.” Divergence is the broken state stated politely. “It’s a shared priority across the organization” describes a program with no accountable owner, offered as though it were the solution rather than the diagnosis. Early is fine; ownerless is the thing the test flags.
6. “The test is just an opinion survey.” It measures a structural fact, whether accountability has reached across the functions the migration spans, and convergence is expensive to fake. Five independent people naming the same person is evidence of real cross-boundary standing, not a popularity read.

Pro tips

1. Ask the five separately, never in a room together. The moment the question is asked in a group, the most senior or most confident voice answers and the other four nod, which manufactures a false convergence. The test only works when each answer is independent, so the contradictions have somewhere to surface.
2. Use the exact words “who owns it,” and refuse the participant list. When someone answers with a list of people working on it, that is a non-answer, and it is itself a finding. Follow up once, “of those, who is accountable if it slips?”, and if the follow-up still returns a list, record it as a shrug.
3. Treat a confident wrong answer as worse than a blank one. A blank stare admits the gap; a confident, mistaken “the CISO owns it” hides it, because the named person may not know the role is theirs. When answers diverge confidently, verify with the named person before assuming anyone owns anything.
4. Run the authorities check as three specific questions, not as a vibe. Ask the named owner, in order: can you put a clause in a vendor contract? do you have a standing seat in architecture review? do you have a sponsor with budget you can escalate to? Three yeses is a real owner. Any no names the exact authority to go secure this quarter.
5. Date and file the result either way. A passed test documents who owns the program and what backs them; a failed test documents that the seat is empty, which is the finding a board needs to hear. Both belong in the risk register with the date attached, because the failed test is the strongest possible argument for the one decision that unblocks everything.
6. Re-run it after any reorganization. Ownership that was real a year ago can quietly evaporate when the owner changes roles or the sponsor leaves, and the migration keeps drifting under a name that has quietly lost its authorities. The test is cheap enough to repeat whenever the org chart moves.

Where does the five-name test break down?

The test has honest limits, and naming them keeps it from being used where it does not fit:

1. Very small organizations, where one person obviously owns everything. In a company where the same person runs engineering, signs the contracts, and holds the budget, the test is trivially satisfied and tells you nothing you did not already know. Ownership is not the constraint at that scale; capacity and knowledge are. Skip the test and go straight to the inventory, because the owner is not in question.
2. Organizations mid-reorganization. During a live restructuring, the five answers can diverge because the roles themselves are in motion, not because ownership is genuinely absent. Run the test once the dust settles, and in the meantime treat the transitional ambiguity as expected rather than as a permanent vacuum.
3. When the sample is drawn from one function. Asking five engineers is not the test; it is a survey of engineering’s assumptions. If the five people do not span engineering, procurement, and security at minimum, the result is unreliable in both directions, and the cross-functional spread is what makes convergence mean anything.
4. As a substitute for the responsibility map. The test tells you whether an owner exists and whether the authorities are present. It does not tell you who does what across the program. That detailed allocation is a separate, estate-specific piece of work, and treating a passed test as if it were the full operating model is how a named owner ends up with no one clear on the actual division of labor beneath them.

How do you use the five-name test with a board?

The five-name test is one of the sharpest instruments a director has, precisely because it needs no technical fluency to run and it exposes the failure mode boards are best positioned to fix. A board cannot easily audit an algorithm choice, and it can absolutely ask three executives, in a single meeting, who owns the post-quantum migration and listen for whether the same name comes back. The question travels upward better than almost anything else in the transition, because its answer is a name and a director can act on a name.

Deployed one level up, the test becomes a governance check with two moves:

1. Ask the room. A director or an audit-committee member asks the executives present the plain question and reads the convergence live, which is the test running at the top of the house.
2. Press the authorities. When a name does come back, the follow-up is the three authorities: “does that owner control the PQC language in our vendor contracts, sit in architecture review, and have a funded sponsor?”

A program that can answer both is governed. One that returns a committee, a shrug, or a name with no authorities has handed the board the exact decision only the board can make, which is to name the owner and grant the authorities. Directors carrying this further can pair it with the governance framing and the full ownership model, and the empty-seat finding is usually the most valuable thing the board learns about the migration all year.

Questions people ask

How long does the five-name test actually take? An afternoon. Five short, separate conversations and a read of the pattern. That speed is the point, because it produces the migration’s most important organizational finding before any money goes into discovery or tooling.

Who should run it? Whoever needs to know the truth. Often the person who suspects they might be the owner and wants to confirm the authorities travel with the name, sometimes a new CISO taking stock, sometimes a director doing it from the board seat. It works from any vantage point because it only requires asking a question and listening.

What if the five answers all name me? Then you have passed the first half, and the second half is on you: verify you actually hold authority over procurement language, a seat in architecture review, and a board sponsor with committed budget. If any of the three is missing, you are in the title trap, and the specific missing authority is your first ask upward.

Is five a magic number? No, it is a practical floor. Fewer than a cross-functional spread of five tends to miss a vacuum by sampling agreement inside one function. In a very large enterprise you might ask more; the rule that matters is coverage across engineering, procurement, security, architecture, and the budget line, not the exact count.

We got five different names. What’s the first move? Name an owner, and write the three authorities into the role in the same document. The divergence is the finding, and the response is not more analysis; it is the single decision the test exists to force, which is filling the accountable seat before scoping anything further.

Does passing the test mean our migration is on track? No. It means the program has an owner with the standing to put it on track, which is a precondition rather than a result. Ownership is the keystone the rest of the program rests on, so a passed test unblocks the work rather than completing it.

How is this different from just building a RACI chart? A RACI chart is the detailed, function-by-function allocation of who is responsible, accountable, consulted, and informed across the whole program, and it is built against your specific estate. The five-name test is the fast upstream check for whether the single accountable owner that a RACI depends on even exists yet. The test comes first; the map comes after there is someone to own it.

Can a vendor or consultant own the migration for us? No. Control of individual systems can sit with a vendor, and accountability for the migration stays inside your organization. A migration owned by an outside party fails the test by design, because the accountable name has to be someone your board can hold responsible, and that is a role only an employee with the three authorities can fill.

---

Everything here is the map, given freely. When your team needs the accountable owner named, the three authorities written into the role, and the function-by-function responsibility map built and quantified against your actual estate, that’s the work I do.

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