Does Excel still belong in GRC?

TL;DR: The Excel-versus-platform debate misses what is actually happening in enterprise GRC programs. Compliance often splits into two layers: technical evidence collection (roughly 30%) and workflow execution (roughly 70%). Traditionally, evidence automation platforms were built to handle the first layer well; the workflow layer mostly runs on Excel, on purpose, until specific signals show the workbook has stopped working. The real tooling question is which layer is being discussed and whether the right tool exists for each.

The Excel-versus-GRC-platform debate keeps getting framed as a question of habit. The conventional take is that senior practitioners cling to Excel out of stubbornness, risk-aversion, or unwillingness to spend money. Get them onto a platform, the argument goes, and the spreadsheet problem dissolves.

Sounds reasonable, right? Well… not quite.

The many seasoned GRC professionals are still running Excel next to their compliance platform on purpose, because the platform and Excel are doing different jobs and the platforms are still trying to catch up. Both are necessary, and the debate has been answering the wrong question for years.

The two layers most tooling debates ignore

Compliance work splits into two layers, and the standard tooling argument only addresses one of them.

The first layer is technical evidence collection: pulling control evidence from AWS, Azure, Okta, and GitHub, running scheduled checks, mapping evidence to controls, and producing real-time visibility into control state. The category of platforms built for this layer (agentic GRC platforms, continuous control monitoring, evidence automation) has made this part close to boring, which is the right outcome. Boring is what you want from infrastructure.

The first layer is roughly 30% of an enterprise compliance program.

The second layer is workflow:

• Vendor onboarding (SOC 2 report received, COI checked, DPA signed, security review completed, owner approved)
• Quarterly access reviews (manager confirms, exceptions tracked, terminations closed out)
• Change management (what shipped, who reviewed, was the checklist actually run)
• Policy management (annual review cycles, training records, attestation)
• Incident response (runbook executed, action items tracked to closure)
• Multi-framework mapping when an enterprise runs ISO 27001, PCI-DSS, HIPAA, and FedRAMP at the same time

The second layer is the other 70%. Evidence platforms have started adding workflow modules in recent years (access reviews, vendor risk tracking, policy attestation), but the capabilities are typically thin compared to what an enterprise GRC program actually runs on. The platform helps trigger the workflow; executing it still happens somewhere else.

That gap is why many senior practitioners still run Excel next to the platform. The platform handles the first layer well, and Excel fills the gap on the second one.

{{ banner-image }}

Where Excel still earns its place

Once the two layers are visible, Excel stops looking like a guilty pleasure and starts looking like the tool the workflow layer never got. It works well when:

• A single experienced practitioner owns the workflow and is also the only editor
• The control count is modest and the framework set is stable
• The work is new, exploratory, or one-off (scoping a new framework, an ad hoc vendor assessment)
• Excel is feeding modeling or calculation work into a system of record elsewhere, rather than acting as the system of record itself

That last point is where the trouble starts. Excel works in any program as a calculator or scratch pad. The trouble is when Excel slowly becomes the source of truth for an enterprise GRC program.

Four signals Excel has aged out of your workflow layer

The shift happens quietly: the workbook keeps working until it doesn't. Four signals tell you when it has stopped.

1. You cannot answer "what changed?"

Version history lives in filenames (control-matrix-FINAL-v3-USE-THIS.xlsx, you know the one). An auditor asks who approved a specific control update in March, and answering it requires forensic work in old email threads. No reliable change history is the cleanest signal that the workflow has outgrown the file.

2. The same data lives in five places.

The vendor list lives in one workbook, the risk register in another, and the evidence tracker in a third. They disagree with each other, and reconciling them has become a job in itself. The team trusts none of them at the moment of decision, which is exactly the moment trust matters.

3. The workbook only makes sense to one person.

If the analyst who built it leaves, the program loses institutional memory, and formulas no one else can read become operational risk. Every quarter-end becomes a single point of failure.

4. Compliance prep takes weeks instead of days.

Pulling evidence turns into archaeology: right tab, right version, right screenshot, then mapping it back to the right control. Those hours add up, and they come straight out of the strategic work the team was hired to do.

None of these are failures of Excel. Excel is doing exactly what it was designed to do: a flat, file-based, single-user calculator. The work outgrew the format.

What replacing the Excel layer actually looks like

Buying an evidence collection automation platform does not fix the workflow layer. Traditionally, this has meant 2 separate platforms. 

The category that handles the workflow layer often goes by different names: compliance ops, GRC workflow, governance workflow. The function is consistent across them. Vendor onboarding, access reviews, change management, policy cycles, and incident workflows live in a structured place where ownership is explicit, change history is tracked, and the workflow connects to the evidence layer rather than competing with it.

Three things change when the workflow layer moves out of files:

1. State becomes explicit, with ownership, stage, and overdue status visible without anyone asking.
2. Reviewers stop being the bottleneck, because reviews happen in the system rather than in a shared workbook with conflicting copies.
3. The team gets hours back, and those hours go to actual risk work rather than reconciliation and version-hunting.

The migration is incremental. Most teams move one workflow first (vendor risk and access reviews are common starting points), prove the pattern, then expand. The teams that try to migrate everything at once tend to abandon the project.

The question worth asking your team

If your senior practitioners are running Excel next to your evidence platform, the question worth asking is whether they tried a workflow tool that did not fit, or whether they have never had one to try.

The first answer is a migration problem. The second is a tooling gap.

Excel will keep doing what it has always done well: modeling, ad hoc analysis, the first draft of a new framework before it is structured. That work is real work, and Excel is good at it. The trap is letting Excel slowly become the system of record for the 70% of compliance work that needs something else.

The Excel-versus-platform debate has been a single-layer conversation in a two-layer job. Once the layers are named, the tooling question stops being a debate and starts looking like a checklist: which layer, and which tool.

‍