The spreadsheet that runs your compliance program (and why it's a ticking clock)

Every compliance operations team I've ever worked with has The Spreadsheet.

You know the one. It started as a simple tracker — maybe 5 columns and 200 rows. Someone built it three years ago to solve an immediate problem. It worked. People started adding to it. New columns appeared. New tabs were created. Conditional formatting was added. Macros were written. VLOOKUP formulas started referencing other tabs that reference other tabs that reference a hidden tab that nobody remembers creating.

Today, The Spreadsheet has 47 tabs, 15,000+ rows, and formulas so nested that opening it takes 45 seconds while Excel recalculates. Two people in the organization understand how it works. One of them built it. The other inherited it after the first person changed roles and spent three weeks reverse-engineering the logic.

The Spreadsheet is the operational backbone of the compliance program. It tracks cases, calculates metrics, generates reports, and serves as the system of record for data that exists nowhere else. It was never intended to be any of these things. It became them by default, because it was the only tool flexible enough to evolve with the program's needs — and because nobody ever replaced it with real infrastructure.

I am not here to tell you that spreadsheets are bad. They're not. Spreadsheets are the most versatile analytical tool ever created. I use them daily. The problem is not the spreadsheet. The problem is when a spreadsheet becomes infrastructure — when an entire operation depends on a file that has no version control, no access logging, no automated backup, no validation rules, no documentation, and no owner.

The Risk Model

I've developed a framework for quantifying the risk that The Spreadsheet creates. It isn't theoretical — it's based on actual failure events I've witnessed or been called in to remediate.

Risk 1: The Formula Break. Someone edits a cell that feeds a formula chain they don't know exists. The downstream calculation silently produces incorrect data. Reports based on that data go to leadership. Decisions are made on wrong numbers. Nobody discovers the error until an external audit or a stakeholder question reveals a discrepancy.

Probability: near-certain over any 12-month period in a spreadsheet with complex formula dependencies. Impact: ranges from embarrassing (incorrect internal report) to material (regulatory submission based on wrong data). Average time to detection: 3–8 weeks, because the error doesn't cause the spreadsheet to crash — it causes it to produce plausible but incorrect results.

Risk 2: The Key-Person Departure. The person who understands The Spreadsheet leaves the organization. Nobody else can maintain it. The replacement inherits a file they don't understand and are afraid to modify, so they build a new spreadsheet alongside it. Now there are two systems of record. They will diverge. Nobody will know which one is correct.

Probability: high — the average tenure for the person who maintains The Spreadsheet is 2–3 years in my experience. Impact: 3–6 months of degraded operational capability while the replacement rebuilds institutional knowledge. Cost: $150,000–$300,000 in lost productivity, recruiting, and remediation.

Risk 3: The Concurrent Edit. Two people edit the same file at the same time. Even with cloud-based spreadsheets (Google Sheets, OneDrive), concurrent editing in complex files with macros, formulas, and conditional formatting creates merge conflicts that are difficult to detect and resolve. One person's edits overwrite another's. Data is lost.

Probability: weekly, in any spreadsheet used by more than 3 people. Impact: usually minor (a few cells lost), but occasionally severe (an entire tab's data overwritten). The compounding issue: after a few concurrent edit incidents, people start making local copies "just in case" — and now you have multiple divergent versions of the system of record.

Risk 4: The Scaling Failure. The program grows. Case volume doubles. New regions or business units are added. The Spreadsheet, which performed adequately at 5,000 rows, now has 50,000. It takes 2 minutes to open. Filtering crashes it. Formulas time out. The tool that enabled the program's growth now prevents it.

Probability: certain, given sufficient time. Impact: operational paralysis — the team can't process, track, or report at the volume the program now requires.

What To Do

I'm not going to tell you to immediately replace The Spreadsheet with a Tableau dashboard and a Jira board. That's the right end state, but it's not the right first step.

The first step is documentation. Take The Spreadsheet and, before anything else, document what it does. Every tab. Every formula chain. Every data input. Every output that feeds a report or a decision. This documentation alone reduces your key-person risk by 60–70%, because if the person who understands it leaves, the replacement has a map.

The second step is identifying what's actually critical. In every Spreadsheet I've audited, roughly 30–40% of the tabs and fields are actively used. The rest are legacy — created for a purpose that no longer exists, maintained out of habit. Identifying the critical subset reduces the scope of any future migration dramatically.

The third step is building a parallel system for the highest-risk functions. If The Spreadsheet is your system of record for processing data, that function gets migrated first — to a database, a configured Jira instance, or a purpose-built tool. The Spreadsheet can continue to serve its lower-risk functions (ad hoc analysis, planning, modeling) where its flexibility is actually an asset.

The fourth step is setting a sunset date. Not "we'll migrate eventually" — a specific date by which The Spreadsheet will no longer be the system of record for any critical operational function. Without a date, the migration will never complete, because The Spreadsheet is always good enough for today. It's only dangerous over time.

The Honest Assessment

Your organization's compliance program is probably running on a spreadsheet right now. That spreadsheet is probably maintained by one or two people. Those people are probably doing an excellent job with it. And one day — not today, maybe not this quarter, but eventually — something will happen that reveals how fragile the system actually is.

The question is whether you invest in infrastructure before that day or after it. Before is cheaper. Before is calmer. Before is a planned project. After is an emergency.

I've been called in for both. The planned projects take 6–8 weeks and cost five figures. The emergencies take 3–6 months and cost six figures. The infrastructure built is identical. The only difference is the price of waiting.

‍