Consider an Italian bank sending a corporate lending file to an external lawyer. The attachment contains financial statements, directors’ identity documents and commercially sensitive correspondence. Encrypting the message protects it against certain forms of interception. It does not, by itself, establish that the recipient is authorised, that the sender is genuine or that access can be withdrawn after a relationship ends.

The consequences can outlast transmission. A misdirected encrypted file may expose a customer’s finances if the unintended recipient can open it. Access left active after an engagement ends creates disclosure risks. If records cannot establish who obtained the information, the bank may struggle to contain the incident or account for its scope.

What the law actually requires

The Digital Operational Resilience Act, known as DORA, has applied since 17 January 2025. Its requirements give encryption a place within a wider framework of technology risk management. Article 9 addresses the availability, authenticity, integrity and confidentiality of data. It also requires strong authentication, protection of cryptographic keys and encryption measures informed by approved data classification and ICT risk assessment.

Buying encryption does not establish compliance. A bank may face supervisory questions even where encryption worked. “They have to answer to their own regulators, to be even more transparent than ever,” Derek Christiansen, cybersecurity specialist at Echoworx, said of financial institutions in the 2026 Encryption Trends webcast. His observation reinforces the practical requirement: retain evidence that proportionate controls operate effectively.

Outsourcing does not remove that responsibility. Under Article 28, financial entities using third party ICT services remain fully responsible for meeting their obligations. For Italian institutions, a supplier’s assurance therefore needs to be tested against contractual rights, technical architecture and operational evidence.

Key control is a practical question

Encryption converts readable information into a form that requires the appropriate cryptographic key to recover. The algorithm matters, but so does the surrounding machinery: how keys are created, stored, accessed, replaced and ultimately destroyed. A strong lock offers limited reassurance if nobody can explain who holds a working key.

Customer control over keys can help a bank establish clearer authority over access. It should nevertheless be examined as an implementation, not accepted as a label. Does the customer control permissions alone, or also key material? Can the service decrypt information during normal processing? Which administrators can change the policy, and are their actions independently recorded?

Location is a separate issue. Hosting data in Europe does not, on its own, establish exclusive control over it. The bank still needs to understand the provider’s corporate structure, subcontractors, support arrangements and applicable legal exposure. Key custody, data residency and jurisdiction answer different questions.

Withdrawal of access also has limits. Disabling a key may prevent future decryption within a particular service, but it cannot reliably retrieve plaintext already downloaded by an authorised recipient. Any claim about revocation should identify precisely which copies and delivery methods remain under control.

Secrecy does not establish identity

A fraudulent instruction can travel through an encrypted channel. The encryption may function perfectly while protecting a message sent by an impostor or from a compromised account. Confidentiality therefore needs to be considered alongside sender authentication, recipient verification and approval procedures.

Digital signatures can support checks on message integrity and the identity associated with a signing certificate. They do not prove that the signer had authority to approve a payment, or that every statement in the message is true. Similarly, a valid domain signature using DKIM does not establish the personal identity or business authority of an individual sender.

For sensitive banking exchanges, the practical response is layered. Verify the recipient before releasing documents, apply stronger authentication where the risk warrants it, and confirm unusual financial instructions through an independently established channel. A familiar display name should never substitute for a reliable verification process.

The delivery method changes the risk

Banking correspondence rarely fits a single technical pattern. One counterparty may support certificate based encrypted email; another may need a secure portal. Transport encryption protects a connection, while message encryption can protect the content beyond an individual connection. The distinction affects what happens when messages reach intermediary systems or recipient mailboxes.

Echoworx illustrates this category of policy driven infrastructure: its platform supports delivery through TLS, S/MIME, PGP, secure portals and encrypted documents, alongside customer managed key options using AWS Key Management Service. For a bank assessing such systems, the important comparison is how each delivery route handles identity, access, retention and evidence.

“It has to be user focused at every step, or no one will use it,” Christiansen said in the same discussion. If recipients cannot open legitimate documents promptly, staff may improvise with another channel. Testing should include advisers and customers, realistic attachments, expired credentials and failed authentication.

Ask for evidence before assurances

The most revealing procurement exercise is a demonstration built around a real banking workflow. Ask the supplier to send a sensitive file, change the recipient’s access, rotate a relevant key and reconstruct the sequence from available records. Identify which events are logged, who can alter those records and how long they remain available.

Contracts should also distinguish an audit trail from unrestricted surveillance. Logs may themselves contain personal or commercially sensitive information, so access and retention deserve scrutiny. A record that a portal message was opened is useful evidence of a system event; it is not conclusive proof that the intended individual read and understood its contents. Legal teams should resist translating technical timestamps into stronger factual claims than the underlying system can support.

Then test failure. What happens if the key service is unavailable, a certificate expires or a supplier relationship ends? Can the bank preserve necessary records without retaining access indefinitely? Recovery, retention and deletion requirements need to be reconciled before an incident makes the conflict urgent.

For Italian banks, encryption governance must withstand scrutiny: the right person received the right material under defined conditions, and the institution can demonstrate how its controls worked in practice, under pressure.