There is a line in DORA's technical standards that most financial institutions have never mapped to a named control. It is eight words long, it applies to every entity in scope, and it is the reason file security has moved from a hygiene topic to a board-level evidence problem.
“the identification of security measures against malicious codes”
That is Article 11(2)(d) of Commission Delegated Regulation (EU) 2024/1774, the regulatory technical standard that expands DORA's ICT risk management requirements. It does not name a technology. It does not name a vendor. What it does is place a documented obligation on the firm to identify what its measures against malicious code actually are, and to defend that identification when a supervisor asks.
For most banks, insurers and investment firms, the honest answer today is a detection stack: antivirus, sandboxing, an email gateway. Those are real controls. But they produce one kind of evidence, which is what they caught, and DORA's question is closer to the opposite. It asks what measure you have identified, whether it operates, and what residual risk remains on the file paths into your critical services.
This resource walks through what DORA requires, maps the regulation's actual wording to what Content Disarm and Reconstruction can demonstrate, and sets out the BFSI workflows where that mapping matters most.
DORA is Regulation (EU) 2022/2554. It has applied since 17 January 2025. Because it is a regulation rather than a directive, it took effect directly in every Member State on the same day, without national transposition.
Roughly 22,000 financial entities are in scope across some 20 categories: credit, payment and electronic money institutions; investment firms, trading venues, central counterparties and securities depositories; insurers, reinsurers and intermediaries; crypto-asset service providers; fund managers and occupational pension institutions; credit rating agencies and crowdfunding platforms. It also reaches the ICT providers serving them, and a non-EU group with an authorized EU subsidiary is in scope through that subsidiary.
The regulation rests on five pillars: ICT risk management, incident management and reporting, digital operational resilience testing, ICT third-party risk, and information sharing. For a CISO, three consequences matter more than the pillar structure:
Proportionality applies throughout, with a simplified framework for smaller entities. Proportionate does not mean optional. It means the depth of your controls has to be defensible against your own risk profile.
Consider what a financial institution ingests on an ordinary Tuesday. Mortgage applications with scanned identity documents. Claims evidence photographed by policyholders. KYC packs from correspondent banks. Invoices and payment instructions from suppliers. Board packs, term sheets and spreadsheets from external counsel. Every one is a file from an untrusted source, arriving at a process with a defined tolerance for disruption.
Detection-based controls answer a single question about each of those files, and they answer it probabilistically: "Have I seen something like this before?"
That is a reasonable question for known threats. It is a weaker one for a novel file, a deliberately malformed structure, a polyglot, an evasive payload that waits out a sandbox, or active content that is technically legitimate but unnecessary. When the answer is uncertain, the firm chooses between letting the file through and blocking it. Blocking a customer's mortgage document is not a neutral act. It is operational friction inside an important business service, which is precisely what DORA asks firms to measure and control.
So the CISO ends up holding two uncomfortable positions at once. Residual risk they cannot quantify, and false positives that damage the customer experience in the services the regulator cares most about.
Content Disarm and Reconstruction takes a Zero Trust position on files. It does not try to decide whether a file is malicious. It treats every file as untrusted and rebuilds it to a known-good state, which means the outcome does not depend on having seen the threat before.
Glasswall CDR runs a four-stage process on every file:
Inspect. The file format is deconstructed into its document object model and validated against the manufacturer's specification.
Rebuild. Unknown, invalid or non-conforming structures are repaired to specification.
Clean. High-risk active content such as macros, embedded objects and scripts is removed according to policy.
Deliver. The rebuilt file passes semantic verification and is returned to the user in a safe, fully usable form, together with a processing report.
%20Vertical.jpg)
For a DORA program, the significant output is not only the clean file. It is the processing report. Every file produces a record of what was inspected, what was non-conforming, what was removed and under which policy. That converts a security control into an auditable one, and it is the difference between telling a supervisor that you have a measure against malicious code and showing them that it ran, on this file, at this time, under this configuration.
Three properties matter to a CISO building a DORA case:
This is the table to bring to a control mapping workshop. The middle column quotes the regulation and its technical standards directly. The right column is what Glasswall CDR puts on the table as evidence.
Two notes on using this table. Quotations are verbatim from the official English text, which uses British spellings. And DORA is risk-based, so the mapping is a demonstration of how a specific control satisfies a specific requirement in a specific workflow, not a claim that the requirement can only be met this way.
The deployment points follow the file, not the network. In practice, BFSI programs tend to start with one high-volume workflow, prove the control and the evidence, then extend.
Articles 28 to 44 make ICT third-party risk the pillar with the largest ongoing administrative footprint. Article 30(2)(c) requires contractual “provisions on availability, authenticity, integrity and confidentiality in relation to the protection of data”, and for critical or important functions Article 30(3)(e) requires “the right to monitor, on an ongoing basis, the ICT third-party service provider's performance”.
Contract terms and audit rights are necessary, but they are assurances about a supplier's controls rather than controls of your own. A file arriving from a supplier is a file whose safety you have contracted for and cannot independently verify. Applying CDR at that boundary converts a contractual assurance into an enforced technical control, and RTS Article 11(2)(k) asks for precisely that: requirements to maintain digital operational resilience for assets and services operated by third parties.
The same logic applies in reverse when your own institution is the supplier, for example a custodian or an asset servicer sending files to clients. Sanitizing on egress protects the relationship and evidences integrity in both directions.
When a supervisor, internal audit or a client's due diligence team asks how you address malicious code in files, a Glasswall deployment supports a documented answer built from:
That pack answers the question DORA actually asks, which is not whether you bought something, but whether you identified a measure, implemented it on the paths that matter and can show it working.
If question three or five gives you pause, the gap is at the file layer.
Book a technical briefing with our financial services team and we will work through your file ingress points, the policy configuration for each, and the evidence Glasswall CDR produces in a live workflow, including the register and Article 30 documentation your procurement team will need. Or try Glasswall CDR in the browser and watch a file get rebuilt in real time.
Our Senior Technical Writer and Product Marketing Manager, Riyya, is exceptional at authoring, organizing, and simplifying our product documentation. Using her keen eye for detail and wealth of experience in tech, Riyya helps our clients and partners seamlessly integrate with industry-leading Zero Trust CDR.
A tailored walkthrough of how Glasswall rebuilds files to a known-good state, removes hidden threats, and provides the intelligence you need to understand file risk.
What's in the demo
“
Beazley's security is paramount, and this integration has significantly reinforced our cybersecurity framework.
