What is spreadsheet key-person risk?

The operational dependency created when one person is the only human who understands the spreadsheet a business runs on: its formulas, its rituals, its exceptions. Their holiday becomes an outage, their resignation becomes an unplanned migration, and neither event announces itself in advance.

How do you assess key-person risk in a spreadsheet?

One test: could a competent colleague run this sheet correctly for two weeks, today, using only what is written down? If the answer involves phrases like "they would just ask" or "most of it", the knowledge lives in a person, not a system, and the risk is live.

How do you fix spreadsheet key-person risk?

Two stages. Immediately: document the rituals, the formulas’ intent, and the exceptions while the keeper is present and willing. Structurally: move the workflow into a small owned system where the rules live in code, validated and tested, instead of in one person’s memory of column Q.

Why is replacing the keeper not a fix?

Because the successor inherits the artifact without the memory: audits of operational spreadsheets found 94 percent contain errors, and the keeper’s undocumented workarounds are usually what stands between those errors and customers. Swapping people transfers the title, not the knowledge.

The spreadsheet key-person risk: when the sheet has a keeper

The short answer

When one person is the only human who understands the spreadsheet an operation runs on, the business carries an unpriced dependency: their absence is an outage, their departure is a forced migration. The two-week test measures it (could a colleague run the sheet correctly, today, from what is written down?), documentation buys time, and the real fix moves the rules out of one person's memory into owned, tested software.

Every operation has one: the person who is "just quick with the spreadsheet." The title undersells the situation. What they actually hold is the undocumented operating system of a business process, and the business finds out how much it depended on them at the exact moment it can no longer ask.

The shape of the risk

Keeper-dependency accumulates innocently. Someone competent builds the tracker; the tracker grows lookups, then macros, then rituals (the Tuesday re-sort, the paste-special that must never be a plain paste); exceptions get handled by memory; and after a couple of years the sheet's real documentation is a person. The artifact itself is no comfort: audits summarized in Panko's research found 94 percent of operational spreadsheets contain at least one error, and the keeper's unwritten workarounds are usually the only thing standing between those errors and your customers. It is sign two of the eight, and it compounds with every quarter the sheet survives.

The two-week test

Measure the risk with one question, asked honestly: if the keeper were unreachable for two weeks starting tomorrow, could a competent colleague run the sheet correctly using only what is written down? Grade the answer coldly. "Yes, the runbook covers it" is safety. "They would figure most of it out" is an outage with a delay. "They would call them on holiday" is the honest confession that the process has a single human point of failure, and that the business has been renting its continuity from one person's goodwill.

After enough years, the spreadsheet's real documentation is a person.

Triage: buying time this month

01Document with the keeper, not about them. Two or three sessions while they walk the weekly cycle: what each ritual is for, what each strange formula protects against, where the exceptions come from. Record it; the intent matters more than the mechanics.
02Name a second operator. Someone runs the sheet for a full cycle with the keeper watching and not touching. The gaps that surface are the real documentation backlog.
03Freeze the cleverness. No new macros, no new special cases, while the dependency is being unwound. Every addition deepens the hole.

Triage is real but temporary: it converts one keeper into two and a binder, which halves the risk without removing its cause. The cause is that business rules live in a medium with no validation, no tests, and no access control.

The structural fix

The fix is the one the replacement triggers point at: move the workflow into a small owned system where the rules are code (reviewed, tested, versioned), the validations run on entry, and the knowledge survives any individual's notice period. The keeper, notably, is not the casualty of this project but its most valuable contributor: their exception knowledge becomes the system's edge-case handling, captured while it is still available. Done as a fixed-scope build, the economics now favor it in weeks, and the two-week test flips from threat to formality: anyone competent can run a documented system, which is the entire point of having one.