Why Spreadsheets Fail DORA Compliance: The Operational Reality

Sunday Night, 2am

The CISO of a mid-sized European bank sits in her home office. The glow of three monitors illuminates a scene that repeats itself across the continent every audit season.

On the left screen: a folder structure seven levels deep containing dozens of Excel workbooks. Some are named consistently. Most are not. Two different files claim to be the master asset register. Neither matches the version on the shared drive that the operations team uses.

On the center screen: an email thread with 23 replies, where three department heads argue about whether a tabletop exercise conducted in March qualifies as a "resilience test" under Article 25. The original test evidence consists of a calendar invitation, a PowerPoint deck, and a sign-off form. No recovery metrics were measured. No deviations were documented. Art. 25(1) requires tests that "assess the preparedness for handling ICT-related incidents" — a meeting with a slide deck does not meet that standard.

On the right screen: the audit notification. The competent authority examination team arrives in 36 hours.

This is not a hypothetical. This is Tuesday in financial services compliance.

The Structural Mismatch

Most institutions know spreadsheet-based compliance is painful. The question is why it fails specifically under DORA, in ways it did not fail under previous, less demanding regulatory frameworks.

The operational burden is real. Managing DORA compliance manually — maintaining ICT asset inventories per Article 8, tracking third-party arrangements per Articles 28-44, orchestrating resilience tests per Articles 24-27, managing incident classification per Articles 17-23, and assembling evidence for all five pillars — consumes significant staff time. The exact burden varies considerably by institution size, asset complexity, and number of third-party relationships. For a mid-sized bank, compliance teams may dedicate the equivalent of multiple full-time employees to activities that are fundamentally about data reconciliation and evidence assembly rather than risk analysis.

Audit findings compound. Institutions using manual compliance processes are more likely to receive audit findings, because manual processes create the exact evidence gaps that auditors are trained to identify: missing documentation, inconsistent data, broken traceability chains, and stale records. Each finding requires a remediation plan, management attention (Art. 5 makes the management body accountable), follow-up verification, and in some cases regulatory reporting. Under DORA, national competent authorities can impose administrative penalties and remedial measures (Art. 50-52). While DORA allows member states to set specific fine amounts, the NIS2 Directive (Art. 34) provides a reference point with penalties up to EUR 10 million or 2% of global annual turnover — a signal of the scale European regulators consider appropriate for systemic digital resilience failures.

Opportunity cost is the largest hidden cost. What compliance teams are not doing because they are buried in spreadsheet management matters more than the direct labor cost. They are not analyzing risk trends (Art. 6 requires continuous risk identification). They are not improving control effectiveness (Art. 13 requires continuous improvement based on lessons learned). They are not building the continuous assurance capability that separates leaders from laggards. They are copying data between workbooks.

Incident response delay. When an ICT incident occurs and the four-hour reporting clock starts (Art. 19(4)(a)), institutions relying on spreadsheets for asset mapping and impact assessment spend critical hours manually correlating which systems are affected, which customers are impacted, and whether the incident meets DORA materiality thresholds. The CrowdStrike outage of July 2024, which affected 8.5 million devices according to Microsoft, demonstrated how quickly an ICT disruption can cascade. Purpose-built platforms provide this correlation in seconds, potentially making the difference between meeting and missing the initial reporting deadline.

The Fundamental Mismatch

The core problem is not that Excel is a bad tool. It is an excellent tool for what it was designed to do. The problem is that DORA demands capabilities that no spreadsheet can deliver.

Regulators expect determinism. When an auditor asks "show me the evidence chain for this resilience test," they expect a deterministic, traceable sequence: test plan approval, team assignment, execution log with timestamps, evidence collection with integrity verification, deviation documentation, corrective action assignment, retest results, closure sign-off. Each step must be attributable to a specific actor at a specific time, with no ability to retroactively alter the record. Art. 6(8) requires financial entities to document their ICT risk management activities before and during disruption events — documentation that must be tamper-proof.

Excel has no access controls. No audit trail. No immutability. Any cell can be changed by anyone with file access, and there is no record of what it said before. An auditor cannot trust a spreadsheet because a spreadsheet cannot prove it has not been tampered with.

Regulators expect traceability. DORA Article 6 requires that the ICT risk management framework produce "a record of activities before and during disruption events." Article 13 requires post-incident reviews with lessons learned that demonstrably feed back into the framework. This requires linking incidents to affected assets, business services, and recovery actions, then linking recovery actions to deviations, and deviations to corrective actions, and corrective actions to evidence of remediation.

In Excel, these links are manual references: "See Sheet 3, Row 47 in the other workbook." They break on rename, on copy, on version conflict. They are impossible to validate at scale. An auditor following a traceability chain through five Excel workbooks is following a chain made of hope.

Regulators expect completeness. When you export an audit pack, regulators expect it to be complete: every test, every finding, every piece of evidence, every decision. An Excel-based process cannot prove completeness because it cannot prove it knows about everything that happened. If someone ran a test and forgot to update the spreadsheet, that test does not exist in the compliance record. If someone uploaded evidence to a different folder, the audit pack misses it.

A purpose-built operational resilience platform solves this structurally. When every test, every finding, and every piece of evidence flows through a single system with enforced workflows, completeness is a property of the system, not a hope of the process.

What the Alternative Looks Like

Imagine the same CISO, same bank, same audit notification, but with a different infrastructure.

She logs into the operational resilience platform. The compliance dashboard shows the current posture by DORA pillar. She clicks "Generate Audit Pack." Under a minute later, a ZIP file downloads containing every piece of evidence, every test result, every deviation, every corrective action, organized by DORA pillar, with a manifest listing contents and checksums for integrity verification.

She reviews the open deviations. Each has a clear owner, a remediation timeline, and a status. Those in progress have evidence of partial completion. Any that are risk-accepted have formal exceptions with compensating controls documented and review dates scheduled. She can explain each one to the auditors in under a minute.

She checks the continuous assurance feed. Automated assertions from monitoring tools confirm recent control validation results. Items that flagged have already generated deviations in the system.

She closes her laptop at 10pm. She will sleep well tonight.

This is not science fiction. Purpose-built operational resilience platforms deliver exactly this experience. The technology exists. The question is whether institutions choose to adopt it before or after their first audit finding.

The Decision Framework

For CISOs and compliance leaders evaluating whether to move beyond spreadsheets, the decision framework is straightforward:

If your compliance process cannot answer these questions in under 60 seconds, you have a tooling problem, not a people problem:

1. What is our current DORA compliance posture, by pillar, scored against Art. 5-49?
2. How many open deviations do we have, and what is the average remediation time?
3. When was each critical ICT asset (Art. 8) last assessed for risk?
4. Which third-party arrangements lack mandatory DORA contractual clauses (Art. 30)?
5. Can we produce a complete, integrity-verified audit pack right now?

If answering any of these requires opening a spreadsheet, calling a colleague, or checking email, the audit risk is real and growing. See our analysis of DORA readiness gaps for the specific areas supervisors will target.

The question is not whether you can afford to automate. It is whether you can afford not to.