The Operational Risk Nobody Talks About

Every financial services firm I’ve worked with has one.

The person who “knows” the spreadsheet.

They built it, or inherited it, or have just used it so long they’ve become the de facto expert. If you need to know why a formula is structured a certain way, you ask them. If something breaks, you call them. If they leave — or worse, if they’re ill — the spreadsheet becomes a mystery.

This is the person whose name features most prominently in the “what happens if they get hit by a bus” question.

I call this the Spreadsheet Key Person Risk. And unlike most operational risks, it doesn’t show up on any register.

How a Spreadsheet Becomes Infrastructure

It always starts innocently enough.

A smart analyst — frustrated that the official system can’t quite do what they need, or that the IT queue is six months long — builds something in Excel to solve an immediate problem. It works. Others start using it. More data gets added. More logic gets bolted on. Before long, what started as a quick fix is underpinning month-end reporting, client valuations, or regulatory submissions.

Excel’s greatest strength is also its greatest risk. Almost anyone can build something that works. The barrier to entry is deliberately low, which is why Excel is embedded in every corner of every financial services firm I’ve ever walked into. But “works” and “robust, documented, and understood by more than one person” are very different things.

The critical moment — the one that most firms miss — is when the spreadsheet crosses the line from personal productivity tool to business-critical process. That transition rarely comes with a handover meeting or a documentation session. It just happens, quietly, over months or years.

And the person who built it is now a Managing Director. Or gone to a competitor. Or on maternity leave.

The documentation? You received that verbally in the hour before they left their role.

The Birth of the Frankensheet

Here is where things get particularly interesting — and particularly dangerous.

The original analyst doesn’t always leave. Sometimes they’re promoted. Their spreadsheet gets handed to the next person, who patches it, extends it, adds their own layer of logic. Then it gets handed again. And again. Each custodian leaves their mark.

I use the term “Frankensheet” deliberately. Like the famous monster, it’s assembled from parts, by multiple hands, over a long period, with no single person holding the complete picture. And like the monster, it has a tendency to behave unpredictably.

Even worse, everyone who had any meaningful understanding of how this spreadsheet worked is now long gone. The firm is depending on a black box for a business-critical function. Nobody knows exactly what it does. Nobody dares find out the hard way.

The “Dare Not Delete” Problem

One of the most telling signs that a spreadsheet has crossed into Frankensheet territory is what developers call the “dare not delete” problem.

When someone inherits a complex spreadsheet or its underlying VBA code, they frequently encounter logic that appears redundant or unused. Old routines. Commented-out code. Calculations that don’t seem to feed anything visible. The natural instinct is to clean it up. But in a Frankensheet, that instinct is overridden by a more powerful one: caution.

And so the redundant code stays. The unused ranges stay. The logic that nobody understands stays. The spreadsheet gets larger, slower, and more opaque with every passing year. The next person who inherits it faces an even more daunting task.

This compounds the key person risk significantly. It is not just that one person understood the spreadsheet — it is that over time, nobody fully understands it. The institutional knowledge that once existed has evaporated, leaving behind only the artefact itself.

For a business user without deep technical skills, this situation is even more precarious. At least a developer can read the code and form a view, however uncertain. A business user staring at an inherited Frankensheet has almost no tools to assess whether it is working correctly or not.

When Your Key Person Leaves: A Real Example

Consider what happens when the key person doesn’t just move to another team — but leaves the firm entirely.

At a large investment bank I worked with, half a dozen automated reporting spreadsheets started failing simultaneously one Monday morning. These spreadsheets had worked without fault for years. Nobody had touched them over the weekend.
After some investigation, the cause emerged.

The employee who had built and maintained these spreadsheets had embedded their own corporate credentials — their user ID and password — directly into the VBA code. This was how the spreadsheets connected to the firm’s corporate databases. When that employee left, IT security cancelled their accounts as standard procedure. The following Monday, every spreadsheet that relied on those credentials failed to connect and crashed.

This is the key person risk made viscerally real. The spreadsheets had “worked” for years. They continued to work right up until the moment they didn’t. And when they failed, they failed all at once, with no warning, and for a reason that took time and expertise to diagnose.

The lesson here is not simply that hardcoding credentials is bad practice — though it is. The lesson is that when a single person holds all the knowledge about how a business-critical system works, the firm is exposed in ways it may not even be able to articulate until something goes wrong.

The EUC Problem: Why It Keeps Happening

To understand why this situation is so persistent, it’s worth understanding the environment in which it arises.

What we’re describing has a formal name in financial services: End User Computing, or EUC. These are systems — most commonly spreadsheets, but sometimes Access databases or other tools — that are developed informally by business users rather than formally by an IT department.

EUC isn’t a failure of diligence. It’s a rational response to a real constraint.

This is exactly right. Business people in financial services firms face a recurring dilemma: they need a solution, they need it now, and the official route — through IT, through procurement, through project governance — is too slow, too expensive, or both. So they build it themselves.

The result is nearly always the same: a solution that solves the immediate problem, but that accumulates risk over time as it becomes more complex, more depended-upon, and less understood.

It is worth noting that this pattern is not limited to spreadsheets. I have encountered the same dynamic with Access databases. At one bank where Access was officially prohibited, a scan of the business departments’ network drives revealed approximately 200 Access databases operating in the shadows — each one a potential operational risk, and each one understood by very few people, if anyone.

This Is a Business Problem, Not an IT Problem

The instinct in many firms is to treat spreadsheet risk as an IT problem.

It isn’t.

IT departments at mid-tier financial services firms are typically small and focused on infrastructure, network management, and web development. They are not Excel specialists. They are not in a position to audit the logic of a 20-year-old compliance spreadsheet, or to assess whether a month-end reporting tool is correctly applying the fund mandate rules it was designed to enforce.

The Spreadsheet Key Person Risk sits in the business. It is owned by the operations team, the risk function, or the compliance department — even if none of them have formally recognised it as a risk. It belongs on the operational risk register. It should be subject to the same scrutiny as any other business-critical process.

Three Questions Every COO Should Ask

You do not need to conduct a full audit to start assessing your exposure. Three questions will tell you a great deal:

If the answer to the third question makes you uncomfortable, you have identified a Spreadsheet Key Person Risk. The question then becomes: what do you do about it?

What You Can Do About It

The good news is that this risk, once identified, is addressable. It requires deliberate effort, but it is not mysterious.

Document before the knowledge walks out of the door.

If your key person is still in the business, this is the moment to invest in documentation. Not a narrative description of what the spreadsheet does — although that is a start — but a technical record of how it does it. What are the data sources? What logic is applied, and where? What are the known limitations and workarounds? What should a competent person check each time the spreadsheet is run?

Bring in an independent expert to review.

An independent technical review of a business-critical spreadsheet — conducted by someone with no prior involvement — will surface things that the key person has long since stopped seeing. Hardcoded values that should be parameters. Dependencies on files or systems that may not always be available. Logic that worked correctly in 2015 but may no longer reflect the current business rules. This is not a criticism of the person who built it. It is simply the result of familiarity and the natural accumulation of debt in any complex system.

Consider whether the spreadsheet should remain a spreadsheet.

Some Frankensheets have grown beyond what Excel was designed to do. For these, the right answer may be to rebuild from scratch — with proper documentation, version control, and testing. Others can be refactored and stabilised within Excel, with their risk significantly reduced. The decision depends on the specific situation, but it should be a deliberate decision, not a default.

Conclusion

The Spreadsheet Key Person Risk is not a niche problem. It is one of the most common operational risks I encounter in mid-tier financial services firms, and it is almost always invisible until it isn’t.
The spreadsheets you are most worried about are probably not the dangerous ones. The dangerous ones are the ones you’ve stopped worrying about — because they’ve always worked.
Until the Monday morning they don’t.