Last updated: October 1, 2026
Key person risk in data means one employee is the sole route to the numbers the business runs on, such as which file is current, which override applies, and why two systems disagree. You find it by running one real cycle without them and logging every question.
The workbook had 46 tabs. Eleven of them held no formulas at all, only typed numbers. The file name ended in _v9_final_MK.
MK resigned that morning.
Nobody at the fund thought of MK as a risk. MK was the reliable one. The quarterly LP report came out of that workbook. So did the borrowing base roll-forward for two ABL facilities, and so did the answer every time the administrator’s NAV and the internal NAV came apart by more than a rounding error. For four years it had worked. It worked because MK remembered things. Which servicer file got restated in March. Which borrower’s EBITDA had a one-time add-back the credit team agreed to on a call and never wrote down. Which of the two “final” loan tapes was the one that tied.
The notice period was three weeks. The next report was due in five. Two weeks short.
I get called into some version of this a few times a year. The fund had bought decent tools. It had hired smart analysts. The work that mattered was still done by hand, and all of it ran through one head. One person is the database, and everyone knows their name.
Where you’re reading this matters, so here it is plainly. The piece runs on KORE1’s site, and KORE1’s data engineering and data science recruiting team fills the two seats I describe toward the end. You don’t need either seat to run the test below. It costs one week of someone’s calendar.
What Key Person Risk Looks Like When the Asset Is Data
Key person risk is the exposure a business carries when one individual holds knowledge or authority no colleague can reproduce on short notice. In data work, the knowledge is rarely a skill. It’s a set of undocumented decisions about sources, overrides, and exceptions, and it lives in one person’s memory and one person’s files.
Private credit already understands the concept. It just points it at the wrong people.
Every LPA I’ve read has a key person clause. ILPA’s Principles 3.0 says key persons should be “the individuals that will determine the investment outcomes of the fund,” and not only the founders, whatever their title. It recommends that a key person event suspend the investment period automatically. Investors negotiate hard over who goes on that list. Partners, mostly.
Nobody puts the analyst on it.
And yet if the analyst who holds the reporting pack leaves in the wrong month, the quarterly report slips, the covenant package goes out late, and the explanation to LPs is some version of “we’re transitioning a team member.” The same ILPA document says, a few lines further on, that LPs should be told about personnel changes “not solely key person” that could affect fund performance. I’m not predicting what any LP does with that. I’m pointing out that the standard already covers people who aren’t partners.
AI Readiness Is the Same Question With a Different Budget
I define AI readiness as whether the work that matters can be run without the one person who knows where the data is. It’s an operations property, and no purchase order produces it.
That sounds like a slogan, so let me make it concrete. Say you point a language model at MK’s workbook and ask it to produce the LP report. What does it need?
Three things, at minimum. It needs to know which of the two loan tapes is current. It needs the add-back nobody wrote down. It needs to know that the servicer’s March file was restated and the April file quietly includes the correction. None of it is written. The model will produce a confident, well-formatted report built on the wrong tape, and the one person who could catch it has just resigned.
The model can’t tell. So it inherits the key person risk, and it hides it better.
This is why I don’t start AI conversations with tools. I start them by asking who they’d call if the number looked wrong. If the answer is a name rather than a place, the firm isn’t ready, and the tool you already bought won’t change that.
Six Signs It’s You, or Someone Who Reports to You
The title of this piece asks whether you’re the database. Plenty of readers are. Heads of portfolio operations especially, because they were the person who fixed it the first time and then never stopped fixing it, usually on the weekend before the report went out. Go through these honestly.
- The close date moves when one person takes a vacation. I mean the date the numbers go final, and the draft date doesn’t count.
- File names carry initials. _final_MK, _JR_checked. The initials are the version control.
- Somebody overrides a number every month and there’s no note saying why. Ask them. You’ll get a good reason, spoken aloud.
- When the administrator emails a question, it’s forwarded to the same inbox every time, whoever it was addressed to.
- Your newest analyst spent their first three months shadowing instead of doing, and still can’t close a month alone.
- You were the one who said, reading this list, “that’s just how it works here.”
Two of six is normal. Four is a problem you’re already paying for. You just haven’t seen the invoice, because it arrives the month the person is out, and what that absence costs a credit fund is usually larger than the hours suggest.
The Test: Run One Cycle Without Them
Every piece of advice on key person risk I’ve seen says the same three things. Document the process, cross-train a backup, buy key person insurance. All reasonable. None of them tells you how exposed you are right now, which is the thing you actually need to know before spending anything.
So test it on something that already happened.
Pick a month-end or a quarterly report that has already closed and been signed off, ideally one with an awkward moment in it, such as a restated servicer file or a late borrower certificate, because the awkward moments are where the judgments hide. You have the inputs. You have the answer. Hand the inputs to someone competent who didn’t produce it the first time. They rebuild the output. Same inputs, same deadline. The key person is available the whole week, with one rule. They answer questions in writing only, in a shared log. No touching the files.
Then you read the log.
The number of questions matters less than their kind. After running this a handful of times I sort every question into four buckets, and each bucket points at a different fix.
| Question type | What it sounds like in the log | What’s actually missing | The fix |
|---|---|---|---|
| Where is it | “Where does the March servicer file live?” | An inventory of sources and where each one lands | Land every source in one place, dated and untouched |
| Which one is right | “There are two loan tapes. Which one ties?” | A written rule for which source wins each field | Source precedence, per field, signed off by the business |
| Why is it different | “Our NAV is $212,400 off the administrator’s. Is that normal?” | A tolerance and a known list of reconciling items | A validation rule that runs on every load |
| What did we decide | “Is the Q1 add-back for this borrower still allowed?” | A decision that was made once, out loud | A decision log with a date, an owner, and an expiry |
Read the last row twice. “Where is it” questions are cheap. An engineer can fix most of them quickly. Two weeks, roughly. “What did we decide” questions are the expensive ones, because the answer only exists in the key person’s memory, and some of the decisions they’ll describe were never really decided. They were improvised under deadline and then repeated because they worked.
Show the log to the key person afterward, and pay attention to their face. In my experience it’s relief more often than defensiveness. They’ve known for years.
Why the Usual Advice Stalls
Documentation fails here for a specific reason. A process document records steps. Open file, paste tab, refresh pivot. The person writing it skips the judgments because to them those aren’t steps. They’re just knowing.
Software engineering has measured this more carefully than finance has. A 2016 study by Avelino and colleagues, presented at the International Conference on Program Comprehension, estimating the truck factor of 133 popular GitHub projects, found that 65% had a truck factor of two or less. Truck factor is the number of people who’d have to leave before a project stalls. These are public projects where every change is recorded in version history and anyone in the world can read it, which is about as far from a fund’s shared drive as data work gets. Knowledge still pooled in one or two people.
A fund’s reporting workbook has no version history. Worse odds, then.
Cross-training has the same weakness. You can train a backup on the steps in a week, but the judgments come from having been in the room the month a servicer restated three prior periods and somebody had to decide, that afternoon, which version the LP report would carry. A backup who wasn’t there has only the steps. Insurance pays money. It doesn’t produce a covenant compliance package on the 15th.
What works is moving the judgments out of the person and into the data itself. Precedence rules, validation rules, and a decision log, each one tested every cycle. At that point the person stops being the database and becomes the owner of the rules. That’s a better job, and people who get it tend to stay.
What Changed When the Knowledge Moved
The closest I’ve come to a clean before-and-after was a month-end close that took 26 days and ended at three. I’d like to say a model did that. It didn’t, at least not first.
The first four weeks were the question log, run on the prior quarter, and then writing down answers. Which source won each field. Which differences were expected and how big they could get before somebody looked. Which exceptions had an owner, and which had simply been carried forward for two years because nobody remembered agreeing to them and nobody wanted to be the one who asked. A lot of the second kind got deleted. Nothing was automated yet.
Week five, the build started. Automation went in only then, and it went in fast, because there was finally something written down to automate. The person who had been the database spent the next quarter reviewing exceptions rather than producing the numbers. Their days changed shape. Review is where the days actually go now, mostly in the afternoons. The rebuild I cover in the close replay diagnostic is the formal version of that first month, if you’d like the structure. The same count across everything a desk does by hand, with one automation built inside it, is on the four-week diagnostic page.
I wouldn’t promise 26 to 3 to anyone. Every book is different. But the order doesn’t change. The knowledge comes out of the head before anything gets built on top of it, and that’s the same argument behind one canonical record per borrower, approached from the people side rather than the records side. The names side is how one borrower gets matched across systems.
Who Takes It Over
Two seats, usually, and sometimes a fractional head of data above them. One person can hold both seats at a smaller manager, but I’ve rarely seen it hold up past the first year.
The first seat owns the definitions. Somebody has to run the decision log, chase sign-off on precedence rules, and say no when a portfolio manager wants a one-off override without writing it down. That’s a data governance analyst, and at a credit fund it has to be someone who can sit with the person who would do the work and argue about an add-back definition from the credit agreement itself. Governance people who only know policy templates won’t last in the room.
The second seat builds it. Landing sources untouched, writing the validation rules as tests, making the reconciliation run on every load rather than on the day someone remembers. That’s a data warehouse engineer who’s comfortable with messy servicer files and doesn’t need the business logic handed over clean, because it won’t be.
The key person stays. They become the reviewer both seats answer to. Be explicit about that when you start, or you’ll lose them halfway through, and then the log becomes the last record you have.
Either seat can start on a contract basis while you find out how much of the log is real work. KORE1’s average time-to-hire on IT searches is 17 days. Your own timing will depend mostly on how clearly you can describe the work, which the question log also happens to help with.
What Operators Ask After Reading the Log
Doesn’t Key Person Insurance Already Cover This?
It covers money, and money is rarely what’s short when the analyst leaves. A policy pays out on death or disability, often not on resignation, and it doesn’t produce a report.
Keep the insurance if your partners want it. Just don’t count it as the fix for data that lives in one head.
I’m Fairly Sure the Database Is Me. Where Do I Start?
Start by running the test on yourself, with a colleague rebuilding last quarter while you answer only in writing.
It’s uncomfortable. It’s also the fastest way to see which of your judgments are real policy and which are habit. Most people in your seat find a third of their overrides could be deleted outright. Then test it again. Take your next vacation during a close, deliberately, once the log is written.
How Many Questions in the Log Mean We Have a Problem?
Count only the “what did we decide” questions.
Twenty “where is it” questions add up to an afternoon of cleanup. Five “what did we decide” questions on one borrower mean a credit process that’s partly unwritten. Those five matter more.
Will the Person Think We’re Planning to Replace Them?
They might, so say otherwise before the test starts and mean it.
Frame it as moving them from producing the numbers to owning the rules the numbers follow. In practice that’s what happens. The people who resist hardest are usually the ones who’ve been covering for a gap nobody funded, and they tend to come around once they see the log turn into a budget line.
Can an AI Tool Take Over What This Person Knows?
Not until the knowledge is written down, because a model can only read what’s in the files.
Once precedence rules and the decision log exist, a model can do a great deal with them, from drafting reconciliations to flagging exceptions against a written tolerance and explaining which rule each flag came from. Before that, it produces the same report the key person would have produced, minus the corrections they’d have made in their head.
Do LPs Ask About This in Operational Due Diligence?
More often than they used to, though it’s rarely phrased as key person risk.
ILPA’s Due Diligence Questionnaire 2.0 gives succession planning and key persons a section of their own. The data version of those questions comes as operational ones, such as who produces the quarterly report, what happens to it when that person is out for a month, and whether loan-level data can be pulled on request without waiting for them to get back. A fund that answers with a name rather than a process has told the allocator what they wanted to know.
Book the Week Now
Pick your last completed quarter. Put a week on the calendar within the next month, name the person who’ll rebuild it, and tell the key person the one rule. Written answers only, in one shared log.
At the end of the week, count the “what did we decide” rows. That count is your key person risk, measured on your own book, and it’s a better starting number than any vendor assessment you could buy, because it came from your own files and your own people. Read the record before anyone buys a model to read it for you.
If you run it, send me the counts. Connect with me on LinkedIn. And if the log shows you need one of the two seats, KORE1 can help you scope and fill it.
