The DORA Evidence Traceability Gap

Host: Welcome to today's deep dive. We've got a really massive, highly relevant operational knot to untangle for you today in the financial tech world.

Co-host: I'm genuinely excited to get into this one, because it's a knot a lot of companies are currently tripping over.

Host: Our mission today is to look at the reality of complying with DORA, the Digital Operational Resilience Act. We're pulling from European Banking Authority regulatory guidance, operational resilience white papers and tech industry implementation reports.

Co-host: Sounds dry, but the implications are huge. We want to understand why the evidence required to prove compliance is frankly dangerously fragmented across different departments, and how organisations can actually fix it.

Host: To understand the problem, we first have to map out how organisations are currently structured, which is usually a bit of a mess. Think about buying a high-end sports car today. You expect it to function as a single flawless machine: you press the accelerator, fuel goes to the engine, sensors monitor the traction, the suspension adjusts, all in milliseconds.

Co-host: The engineering behind that experience relies on a completely unified system. The engine is constantly talking to the brakes, the brakes to the tyres, a central computer acting like a nervous system so every component is aligned with what the driver wants to do.

Host: Now imagine buying that exact same car, except instead of a central computer, the manufacturer crammed six different engineers into the back seat. One handles the accelerator. Another, who only speaks French, controls the brakes. Another is blindfolded and manages the steering wheel purely by feel. And the rule is that none of these engineers are allowed to speak to one another.

Co-host: Merging onto a busy highway in that vehicle would be a catastrophe. And the wild part is, when you look at financial technology and operational resilience compliance, that chaotic car ride is closer to reality than anyone wants to admit.

Host: It really is. We're looking at an organisational landscape that is heavily siloed, and that introduces systemic vulnerabilities that only become obvious once the system is under stress. The responsibilities for DORA compliance don't live in one department. They're distributed across completely different fiefdoms.

Co-host: ICT risk handles one piece. Operational resilience looks at another. Vendor management manages the contracts. Incident response handles live threats. Add internal audit and general business operations on top, and you end up with six or seven distinct departments, each holding a different piece of the puzzle.

Host: It's the corporate equivalent of a university group project. A professor assigns a grade-defining presentation, and to divide the work, everyone takes a section and goes home. One person writes their part in a Google Doc. Another uses some obscure desktop software from 2005. Another jots bullet points in an email. Nobody compares notes until the moment they have to stand in front of the class.

Co-host: That silo effect runs on the exact same premise in the corporate world. Each department has its own systems, its own metrics for success, basically its own language. Historically that made sense: ICT cared about server uptime, risk management cared about exposure, vendor management cared about contract negotiation. Different tools for different mandates.

Host: And that fragmentation doesn't look like a problem on a normal Tuesday. Markets are calm, systems are online, the silos appear to be functioning perfectly, because nobody is asking to see the whole presentation yet.

Co-host: The cracks only show when the professor asks a question that spans two different sections. That's the trigger: an audit, a major regulatory change, or worst case a severe operational incident, when an assurance request comes down from the board requiring the organisation to prove how a specific DORA obligation operates in practice across the whole company.

Host: Cue the panic. The scramble begins, and the organisation realises its critical functions, ICT assets, third-party vendors, risks, controls and testing evidence are not represented end to end in any single place.

Co-host: I have to push back for a second, though. Walk into any major financial institution today and they have mountains of compliance paperwork. Warehouses of it. They invest millions in governance, risk and compliance platforms, risk registers, incident reports. Why can't a company just export their logs, hand the register to an auditor and call that DORA compliance?

Host: That question highlights the exact trap a lot of organisations fall into. Registers and reports absolutely exist. Companies are drowning in data. But the underlying weakness isn't a lack of documentation. It's a lack of traceability. Existing risk registers are weakened by dependency gaps and inconsistent evidence formatting.

Co-host: DORA doesn't just ask for a static list of risks. It demands an unbroken chain of evidence, and that chain has very specific, non-negotiable links.

Host: Let's define that chain, because it matters. It starts with the obligation, the regulatory rule itself. Then it flows to the process, to the owner, to the system, to the control, to the execution, and finally to the retained evidence. If a single link in that chain can't communicate with the next, the audit fails.

Co-host: One broken link and you fail?

Host: Regulators view a broken link as a fundamental lack of control over the environment. Take a real scenario. Say the obligation, the regulatory rule from DORA, is that a financial entity must ensure its cloud-based interbank payment processing is secure from unauthorised access. That's the baseline. The next link is the process: the bank has to document a specific operational process for encrypting that data and monitoring for breaches.

Co-host: Then the owner. DORA requires clear accountability, a named human being or a specific role, say the head of cloud security, responsible for ensuring that process is actually managed.

Host: Next is the system, and this isn't waving your hands and saying 'the cloud.' It means identifying the actual technology stack, the specific servers, the third-party software vendors, the APIs facilitating the payment processing. Mapped directly to that system is the control, the specific safeguard: a mandatory multi-factor authentication protocol, an automated firewall rule blocking unrecognised IP addresses.

Co-host: The chain feels solid up to this point. Most companies can document an obligation, assign an owner and point to a firewall.

Host: That's standard. The breakdown happens at the final two links: execution and retained evidence. Execution asks did the control actually fire when it was supposed to. Did the firewall actively block a suspicious login attempt last Tuesday at 2am? Retained evidence is the undeniable proof that execution happened, the actual system log enforced by the control, on the system, managed by the owner, following the process, to satisfy the obligation.

Co-host: Laid out like that, the danger becomes obvious. If the head of cloud security keeps her policy documents in a centralised GRC platform, but the execution logs sit with an outsourced managed service provider using a proprietary logging tool in a different country, the chain is broken.

Host: It is. And when the auditor asks for proof, the bank spends three weeks manually digging through emails, ticketing systems and vendor portals just trying to tape the chain back together.

Co-host: Three weeks of copying and pasting. And that manual assembly is where the whole system collapses at enterprise scale, because for most organisations assurance is a manual, periodic exercise. Reviews run once a quarter or once a year, usually in a blind panic right before an inspection.

Host: Here's where it gets genuinely dangerous, because the velocity of modern business is moving far too fast for that. Operational change happens so quickly it creates new gaps faster than manual review cycles could ever hope to find them. We're talking continuous integration and deployment pipelines pushing code to production daily.

Co-host: A critical software vendor pushes an automated security update overnight. A junior engineer tweaks a server configuration to handle a spike in mobile banking traffic. A risk officer drafts a revised data policy on a Friday afternoon. Every one of those actions alters the dependency chain we just described.

Host: If a company relies on a manual review cycle that only runs every three months, it's flying blind for eighty-nine days at a time, generating new blind spots and compliance gaps faster than anyone reviewing spreadsheets by hand could ever keep up with.

Co-host: It's the equivalent of trying to paint a moving train. By the time you finish inspecting the final car, the engine has already been replaced twice.

Host: And that gap between the speed of operational change and the speed of manual audits is causing genuine regulatory concern. The European Banking Authority isn't suggesting administrative improvements here, it's mandating them. Under Regulation (EU) 2022/2554, they strictly require comprehensive registers of all ICT third-party contractual arrangements, and a fully documented, dynamically updated ICT risk management framework covering incident management, testing and third-party risk.

Co-host: Dynamically updated is the key phrase. The tolerance for best-effort compliance is gone. Regulators want the receipts for everything, on demand, because they need to know the European financial system has genuine structural resilience, not just the appearance of it.

Host: A nice binder on a shelf, a box ticked on a delayed review cycle, proves nothing to them anymore. They want proof that a third-party database vendor operating three countries away isn't going to suffer an outage that cascades and takes down a primary payment network.

Co-host: So if manual reviews are too slow and the silos are too disconnected to satisfy the EBA, the only logical step is a systemic solution.

Host: Precisely, and the material we're reviewing points to what it calls a connected operating model. Let's go back to the sports car analogy, but apply it to human biology instead. Right now, most companies operate like a body where the nervous system is disconnected. Touch a hot stove, and the hand has to file a report. Three days later the brain reads it and decides the hand should probably move. By then you've got a third-degree burn.

Co-host: A connected operating model upgrades the organisation to a live, interconnected nervous system. Touch the stove and the nerve endings, the operational controls, send the signal instantly. A change in one extremity is felt and reacted to by the whole organism in real time.

Host: That's exactly it. A connected operating model shifts a company from keeping static records to managing dynamic, interconnected operational work. Change and assurance stop being separate annual administrative tasks and become connected work, with accountable remediation built directly into the daily workflow.

Co-host: Which changes how a company prepares for an audit entirely. You're not scrambling to assemble data, the evidence is a natural byproduct of doing the work. You get defensible DORA mapping because the evidence is inherently linked to the process from day one, and clear visibility into third-party dependency and resilience gaps.

Host: You can visually map where a minor vendor's failure might cascade through the architecture, like dominoes, and eliminate the surprise of a seemingly insignificant cloud provider outage suddenly taking down your primary customer portal. It also drastically reduces the manual assembly needed for inspection: no more paying consultants to spend weeks copying data from an incident response tool into a compliance spreadsheet.

Co-host: Because the data is already synthesised, which leads straight to faster regulatory impact assessments. When the EBA issues a new technical standard, the connected system instantly highlights which parts of the architecture are affected. Earlier detection of control gaps becomes the norm, instead of waiting for a quarterly review to discover a mandatory encryption protocol failed.

Host: The connected system just flags the missing execution evidence immediately. That's how an organisation achieves unbroken, defensible traceability from regulatory duty all the way down to technical execution.

Co-host: It sounds like the holy grail of compliance, but let's ground this for the leaders actually facing these mandates. How does an executive practically figure out whether their organisation has this connected model, or whether they're just experiencing the illusion of compliance?

Host: That's the real question. How do you know if you have a functioning nervous system, or just a very well organised room full of filing cabinets? The source material lays out five discovery questions, and they're not rhetorical. They're the exact lines an auditor will pursue to test the structural integrity of a firm's operational resilience.

Co-host: Put yourself in the shoes of an executive sitting at the head of a boardroom table. The EBA auditors don't ask for your policy binder. They open their laptops and ask question one: can every critical or important function be traced down to its ICT and third-party dependencies? Not the easy systems, the most complex legacy functions, all the way down to the subcontractors.

Host: Question two shifts to the mechanics of proof: where is DORA evidence assembled today? That's a loaded question, because if the honest answer is disparate emails, vendor portals and standalone spreadsheets, the auditor already knows the chain of traceability is fragile, if not broken.

Co-host: Question three is designed to expose the silos: which resilience gaps remain invisible between organisational silos? It's almost a trap, because without a connected model, a company fundamentally doesn't know what it doesn't know. The gaps are invisible by definition, and admitting that exposes a lack of overarching governance.

Host: Question four targets accountability: which obligation is hardest to trace to a named operational owner and control? That identifies the weakest link in the chain, pointing straight to where accountability vanishes.

Co-host: And question five is probably the most critical: what evidence would prove implementation rather than just policy publication? That distinction, implementation versus publication, is the absolute crux of DORA. Historically, many firms passed audits by presenting a beautifully formatted policy document: a published rule stating they mandate real-time backups and encrypted transfers, and an auditor checking a box based on the existence of that policy.

Host: DORA destroys that framework completely. Regulators no longer care what the policy says. They demand systemic evidence of actual implementation. Can you prove the backup initiated yesterday at noon? Can you prove the data stayed encrypted during transfer, using the specified control? Proven implementation is the only currency regulators accept now.

Co-host: An executive sitting in that boardroom, realising their current tech stack can't confidently answer those five questions, is going to be sweating. The problem feels insurmountable at an enterprise with tens of thousands of employees and thousands of vendors. What's the actionable first step, without halting daily operations to do it?

Host: The pragmatic starting point is to not try to boil the ocean. You don't attempt to map the entire enterprise overnight. You isolate and map the complete traceability of just one single critical function and its associated third-party dependencies, and prove the methodology works at a micro level before scaling it to the macro level.

Co-host: Make sure the steering wheel can successfully talk to the front tyres before you try to wire the rest of the car. The material notes this can be done using platforms like iGrafx and IGX360 Insights, advanced process mapping and operational intelligence platforms built to visualise these complex business architectures and link a high-level regulatory obligation directly to the underlying technical processes and vendor dependencies.

Host: They build the nervous system for you. By proving end-to-end traceability for one critical function, an organisation demonstrates to the board, and eventually to regulators, that it has the structural capability to build a connected operating model. Once that unbroken chain exists for one function, it's a verified blueprint, not a guess.

Co-host: You know exactly how much effort it takes to pull the retained evidence, identify the owner, verify the control. From there it's a matter of scaling that blueprint across the remaining critical functions, and scaling it isn't optional. Under DORA, presenting granular, connected evidence isn't a best practice anymore, it's the legal baseline for operating in the European financial sector.

Host: We've covered a lot of ground. We started with how a fragmented, siloed approach to compliance, where ICT risk, vendor management and audit operate in isolation, creates systemic vulnerabilities that only become visible when regulators demand proof. We looked at why manual, periodic review cycles are a losing battle against the speed of continuous operational change.

Co-host: And we unpacked why building a connected operating model, a true organisational nervous system, is the only way to achieve the end-to-end traceability DORA demands. What it means is that the era of static spreadsheets and the benefit of the doubt from regulators is over. Regulators aren't asking companies to tell them how they manage risk anymore. They're demanding systemic proof that the risk is actively being managed at the execution level.

Host: One final thought to leave you with. DORA is forcing financial entities to map every digital asset and third-party dependency just to survive a potential crisis. If an organisation successfully builds that transparent nervous system, could that extreme level of operational visibility reveal a completely unexpected vulnerability?

Co-host: It's a genuine paradox. We've spent this whole conversation mapping the technology, assuming the systems are the primary source of risk. But if the machines, the vendors and the software processes are perfectly tracked and completely visible, will we discover that an organisation's greatest unpredictable threat was never a third-party vendor at all, but the everyday human decisions made completely outside that tracked system?

Host: You can map a server's dependencies with perfect accuracy. Mapping the unpredictability of human nature might be the one variable no regulation can ever fully control. A perfectly connected machine is still operated by people, and human behaviour remains the most complex dependency of all. Something to think about the next time you navigate a compliance audit.