Under DORA, banks encrypt confidential email where their data classification calls for it, but encryption alone proves little. Italian and EU banks must also show who accessed the content, how keys and exceptions were governed, and which records prove it, and they stay responsible when a vendor runs the service.
A message can be perfectly encrypted and still reach the wrong person. When a supervisor starts asking questions, the bank has to show who opened it, not just that it was encrypted.
For banks in Italy and across Europe, encrypting a confidential message does not, on its own, make its handling secure. An unauthorised recipient, a compromised credential, or access left active after an engagement ends can undo that protection without anyone touching the cipher. The bank’s responsibility covers the entire process through which the content is delivered, accessed, and retained.
For Italian institutions, the distinction has practical consequences. A lending file sent to an external adviser carries information about customers, directors, and counterparties. If something goes wrong, the bank has to reconstruct who had access, which checks were performed, and what options remain for containing the incident. The label “protected message” answers none of those questions.
The people who own that reconstruction are the readers here: security, compliance, and IT teams at banks, and the advisers and suppliers who touch bank files. If you work at a smaller institution with a lean IT team, the vendor tests later in this piece matter most, because you will lean harder on a supplier’s defaults. If you sit inside a larger group with its own security function, the sections on key governance and exceptions are where your internal policies need the most detail.
DORA compliance has to be demonstrated with documented rules, assigned responsibilities, and records, because the regulation treats encryption as one control inside a risk management framework rather than as proof of compliance. The DORA regulation has applied since 17 January 2025. Article 9 of the regulation places encryption, strong authentication, and the protection of cryptographic keys within the management of ICT risk, and it ties encryption to the results of the bank’s approved data classification and ICT risk assessment processes. Purchasing a product that presents security as a problem already solved is not enough; the measures have to follow from the bank’s own view of what it is protecting.
“They have to answer to their own regulators, to be even more transparent than ever,” Derek Christiansen, Engagement Manager at Echoworx, observed of financial institutions in the 2026 Encryption Trends webinar. His point concerns the gap between a commercial promise and verifiable evidence: documented rules, assigned responsibilities, and records that allow events to be reconstructed.
Article 28 keeps that burden with the bank even when the technology is outsourced. Under Article 28(1)(a), financial entities remain fully responsible, at all times, for compliance with their obligations when they use external ICT services. A supplier contract may allocate tasks and provide safeguards, but it does not transfer the bank’s regulatory responsibility to the other party. If you are building the wider vendor oversight program around this, our comparison of third-party risk management software platforms shows how compliance automation, continuous cyber ratings, and enterprise GRC tools divide that work.
In practice, demonstrable means three things exist before anyone asks for them. The first is a written rule that says which classes of content require which protection. The second is a named owner for each rule and each exception. The third is a record that can show, for any given message, who received it, how they authenticated, and when their access ended. If any of the three lives only in a vendor’s sales material, the bank cannot produce it when a supervisor or auditor asks.
When an encrypted message still ends up in the wrong hands, the bank faces supervisory scrutiny, operational cost, and customer fallout, even if the encryption itself worked exactly as designed. Article 50 of DORA gives competent authorities supervisory, investigatory, and sanctioning powers, including the power to require corrective and remedial measures, and it leaves each Member State to lay down the framework of administrative penalties. An established infringement may therefore trigger regulatory intervention and financial consequences. An incident, however, does not automatically establish a breach: the applicable obligations, the facts, and the actual adequacy of the safeguards all matter.
Operational exposure often arrives before any penalty risk. Reconstructing communications without reliable records consumes time, pulls in outside advisers, and can slow ordinary business while the review runs. Explaining to a customer why a document remained accessible to the wrong person is difficult even when the encryption algorithm itself has no defect, because the customer does not care which layer failed.
The GDPR points the same way. Article 32 of the GDPR requires controllers and processors to implement technical and organisational measures appropriate to the risk, including, where appropriate, encryption of personal data, the ongoing confidentiality and resilience of processing systems, and a process for regularly testing the effectiveness of those measures. Treating email protection as a purely technical choice skips the organisational half of that sentence. Businesses outside banking are reaching the same conclusion from a different direction; our look at why GDPR compliance is turning into a customer trust strategy covers the vendor oversight side for consumer brands.
Identity, keys, and access are separate controls because each one fails in a different way, and an encrypted message is only as safe as the weakest of the three. Encryption makes content unreadable without the necessary key. Authentication seeks to verify who is accessing it; authorisation determines what that person may do. Confusing these layers leads to overstated protection. A compromised account can pass a check intended for the legitimate user and receive information that is perfectly encrypted. The fundamentals that protect any business holding customer data, from multi factor authentication to role based access and regular permission reviews, apply with more force when the data is a lending file.
Keys require equally precise governance. The bank should know who can create, use, replace, or disable them, and what operations the supplier performs during normal processing. Storing data in Europe and controlling keys are related but distinct matters: jurisdiction, subcontractors, and administrative access still require assessment even when the data never leaves the EU.
Revocation deserves particular attention. A portal may allow subsequent access to be blocked, but an unencrypted copy already downloaded does not disappear when access is revoked. Sales demonstrations must distinguish content still controlled by the service from copies that have already left its boundaries.
Each exception also needs clear accountability. A concession granted to an adviser for one engagement should not become a permanent rule for the entire relationship. Expiry dates, scheduled reviews, and documented reasons help distinguish a deliberate decision from a forgotten configuration. Security, legal, and compliance teams need to settle this before an urgent request turns an exceptional procedure into everyday practice.
Protection that is hard to use stops protecting because people route around it, and the urgent attachment ends up in whichever channel opens fastest. “It has to be user focused at every step, or no one will use it,” Christiansen explained in the same discussion. For a bank, that observation also applies to professional advisers, small businesses, and customers who lack equivalent expertise or infrastructure.
When a procedure prevents someone from opening an urgent attachment, the temptation to forward it through another channel grows. The recipient’s experience therefore needs testing alongside security: registration, authentication, access recovery, and expiry management. Tests must include realistic errors, rather than simply a successful delivery between two accounts prepared for the demonstration.
Pick your test recipient deliberately. Whether your counterparties are a national law firm with its own security team or a two person accounting practice working from a webmail account, run the trial with the least technical recipient you actually serve. If that person can register, open the file, recover a lost password, and reply securely without calling your help desk, the more sophisticated recipients will manage too. If they cannot, you have found the exception that will become everyday practice six months after launch.
Four approaches worth testing are Microsoft Purview Message Encryption, Proofpoint, Mimecast, and Echoworx, and each suits a different starting point rather than one being better for every bank. Microsoft Purview Message Encryption combines encryption with rights management policies inside Microsoft 365. Administrators can define mail flow rules that encrypt messages meeting set conditions, and recipients on Gmail, Yahoo, and other services read through a portal. For banks already on Microsoft 365, integration is the natural starting point. Licensing, supported attachments, and the conditions on advanced features need checking: Microsoft’s documentation states that revocation and expiration apply only to external recipients who read the message through its portal.
Proofpoint combines encryption with data loss prevention. Messages can be encrypted automatically when they meet sensitive data or policy criteria, and recipients can gain access through a web portal or browser. This approach is relevant when the priority is connecting sensitive data detection with the handling of outbound email.
Mimecast Secure Messaging delivers through a secure web portal, with sender controls that include message expiration, read receipts, and restrictions on printing or replying, and messages are checked against content control and data leak prevention policies. Its public overview does not describe recalling a message after sending, so confirm that capability directly if your process depends on it. For organisations already using Mimecast, workflow consistency and the experience of external counterparties are worth evaluating.
Echoworx focuses on managing encrypted communications through multiple methods: TLS, S/MIME, PGP, an encrypted web portal, and protected PDF and attachment formats. It works alongside existing email infrastructure, for example through a Microsoft 365 Exchange rule that routes outbound mail for encryption, and its Manage Your Own Keys option runs on AWS Key Management Service. This combination deserves attention when a bank must serve diverse recipients without imposing the same technical process on everyone.
Flexibility can deliver practical value if it reduces manual exceptions and enables consistent controls across channels. It does not, however, automatically establish superiority or compliance. Every supplier’s features, configuration, contractual responsibilities, and test results must be assessed against the same banking process. The licence price tells only part of the cost story: recipient support, certificate renewal, exception management, and the staff time needed to produce evidence during a review all count. An apparently secondary feature can become decisive if it saves staff from deciding how to protect each attachment, but that benefit has to be measured through repeatable demonstrations and checked with the people who will use the service. For a smaller bank already on Microsoft 365, testing what the existing licence covers before adding a second platform is the sustainable first move, because two overlapping systems create exactly the exceptions this article warns about.
The test that matters runs before signing: push a realistic case file through each shortlisted service, then examine the records it produces. Send the document, change access, simulate an expired credential, and check what happens to the recipient’s reply. Then read the logs. An opened message documents a technical event, not necessarily the intended person’s understanding of its contents, so check whether the record ties the open to an authenticated identity. Vendor logs can serve as the bank’s evidence, provided the bank can export them, retain them on its own terms, and still read them after the contract ends.
The comparison must also cover service unavailability, retention of evidence, and exit from the contract. DORA’s Article 30 makes those questions concrete by listing what ICT service contracts must address, including where data is processed and stored, access to and return of data when the contract ends, termination rights with minimum notice periods, and, for critical or important functions, rights of access, inspection, and audit plus an exit strategy with an adequate transition period. Ask each vendor to show you, not tell you, how its service meets each item.
The final question is which architecture allows the bank to explain and demonstrate its conduct, rather than which brand promises greater security. Once scrutiny begins, that capability carries more weight than any general assurance. A vendor that produces clean records, clear exception reports, and an honest answer about what revocation cannot do is giving you evidence; a vendor that answers every question with a feature name is giving you a promise.
If you sell software or services to EU banks, expect DORA’s evidence burden to arrive in your contract, because the bank stays responsible and will pass its requirements down to you. Software vendors, fintech integrations, hosting and data providers, and any agency that runs ICT services for a bank can fall within the regulation’s definition of ICT third-party service providers, and the Article 30 terms above are the questions a bank’s procurement team will put to you.
Your stage changes what to do about it. An early stage vendor answering its first bank security questionnaire needs a clean map of where data lives, a documented incident process, and an honest list of what its product does not do, long before it needs a compliance platform. A scaling vendor serving several financial institutions is the one for whom dedicated compliance tooling starts to earn its cost, because the same evidence requests repeat across every client. In both cases, the lesson from the bank’s side of the table holds: the supplier that can demonstrate its controls wins more trust than the one that can only describe them.
DORA does not mention email by name, but it requires banks to protect data in transit and to encrypt it where their own data classification and ICT risk assessment call for it, which usually covers confidential email. Article 9 asks financial entities to keep data available, authentic, intact, and confidential at rest, in use, and in transit, and it sets expectations for strong authentication and the protection of cryptographic keys. It does not name a specific product or protocol. The bank has to decide which classes of content need which protection, apply that decision consistently, and keep records showing the controls worked. Encryption chosen without that classification step is hard to defend under review, even when the technology itself is sound.
Yes, a bank remains responsible under DORA even when an external vendor operates its email encryption. Article 28(1)(a) says financial entities remain fully responsible, at all times, for complying with their obligations when they use ICT third-party services. A contract can allocate tasks, set service levels, and give the bank audit and termination rights, but it cannot transfer regulatory responsibility to the supplier. That is why banks need records they control, not just a vendor’s assurance, showing who received a message, how they authenticated, and when access ended. Whether a specific incident amounts to a breach still depends on the facts and the adequacy of the safeguards in place.
You can revoke access to an encrypted email only while the content is still held inside the provider’s service, typically a web portal. Once a recipient downloads an unencrypted copy, revoking portal access does not remove that copy. Capabilities also vary by provider and licence. Microsoft’s documentation, for example, states that revocation and expiration in Advanced Message Encryption apply only to external recipients reading through its portal, while Mimecast’s public overview describes message expiration but not recall. Before relying on revocation in a policy, test it on the exact recipient types you serve and confirm what happens to attachments that have already been opened or saved.
A bank should test a realistic case file end to end and then examine the records the service produces. Send a realistic sample document to an external test recipient, change their access, simulate an expired credential, and check how replies are protected. Then review the logs to see whether each event is tied to an authenticated identity. Test registration and password recovery with your least technical counterparty, not a prepared demo account. Finally, compare contract terms against DORA Article 30: data locations, return of data at exit, termination rights, audit access, and an exit strategy for critical or important functions. A vendor that can show all of this is giving you evidence.
GDPR Article 32 requires security measures appropriate to the risk, and it names encryption of personal data as one of those measures where appropriate. For a bank, that means client emails containing personal data need protection matched to their sensitivity, alongside the organisational side of the rule: ongoing confidentiality and resilience of systems, the ability to restore access after an incident, and a process for regularly testing whether the controls work. Article 32 applies in parallel with DORA rather than instead of it. Treating email encryption as a purely technical purchase misses the testing and organisational duties both regulations share.
