For most of the past three decades, cryptography sat quietly in the back office of financial services. Security and PKI teams managed it, compliance teams rarely thought about it, and everyone treated it as a technical detail. GDPR helped end that era. Encryption is now a governance and compliance concern that shows up in board conversations, regulatory examinations, and breach response plans.
That shift is good news if you know how to use it. Under GDPR, strong encryption is not only a cost of compliance. It is a lever. Well-implemented encryption of financial data can reduce your breach exposure, remove your breach notification duties, and speed up the audits and due diligence reviews that increasingly gate business relationships. This article explains how GDPR treats encryption for financial data, and how to turn Article 32 into an advantage rather than an obligation.
Why GDPR still sets the bar for financial data
GDPR (Regulation (EU) 2016/679) has been in force since May 2018, and it remains the global reference point for data protection. Its influence reaches well beyond Europe. GDPR applies across the EU and EEA on two independent bases. Article 3(1) catches processing carried out in the context of the activities of an EU establishment, wherever the processing physically happens. Article 3(2) reaches organizations with no EU establishment at all, where they offer goods or services to, or monitor the behavior of, people who are in the Union. Note the test: it turns on where the individual is, not on citizenship or residence. That reach matters for financial services in particular. Cross-border payment networks, correspondent relationships, and cloud-hosted core banking platforms mean that most institutions touch the data of people in the EU somewhere. Because so many organizations must meet GDPR’s standard, it shapes what regulators everywhere consider reasonable security, even in markets where GDPR does not directly apply.
The data financial institutions actually process
Financial firms handle data that is frequently high-risk under GDPR’s risk-based standard. Three categories stand out:
- Transaction histories that reveal customers’ behavior, relationships, and finances.
- Credit and affordability data used in lending and underwriting decisions.
- Biometric authentication data used in fraud prevention.
The sensitivity and volume of this data raise the stakes for how it is protected. When the underlying information is this revealing, encryption stops being a nice-to-have and becomes central to demonstrating appropriate security.
What is at stake: fines and the breach notification exemption
GDPR presents financial firms with two sides of the same equation.
On the downside, fines can reach EUR 20 million or 4% of global annual turnover, whichever is higher. The sector of financial services has consistently been among the more heavily fined, given the volume and sensitivity of the data it processes. Insufficient technical and organizational security measures is now the most common ground for fines in the finance and insurance sector. Because Article 32 is risk-based rather than prescriptive, supervisory authorities and courts look at the encryption and key-management practices that were actually in place at the time of an incident, not what a policy document claimed.
On the upside, encryption has a direct payoff written into the regulation. Under Article 34(3)(a), a controller does not have to notify individual data subjects of a breach if the exposed data was rendered unintelligible to unauthorized parties, typically through strong encryption. The exemption is not self-executing. You must be able to show the algorithm was state of the art, the key was outside the scope of the breach, and key material was held separately from the data. Strong, properly keyed encryption can be the difference between a quiet regulatory filing and a public notification to every affected customer.
Who is responsible: controllers, processors, and DPOs
GDPR assigns clear roles, but not equally. Responsibility for cryptography sits with the controller under Article 24 and, where applicable, the processor. The DPO advises and monitors under Article 39 and cannot be made the owner of encryption or key management.
- Data controllers are the financial institutions that determine the purposes and means of processing customer, account, and transaction data.
- Data processors are the payment processors, cloud providers, and outsourced service providers that process personal data on a controller’s behalf.
- Data Protection Officers are typically mandatory for financial firms, given the large-scale, systematic monitoring inherent in risk-scoring and fraud detection.
Understanding who owns each obligation helps you place accountability for encryption, key management, and vendor assurance where it belongs.
How GDPR maps to cryptographic controls
The key insight for financial firms is that Article 32 is risk-based rather than prescriptive. It does not hand you a checklist of algorithms. Instead, supervisory authorities look at the cryptography and key-management practices actually in place when an incident occurs, not what a policy claimed. That makes demonstrable, well-governed cryptography the goal. Seven interlocking control areas show where encryption does the work.
Security of processing (Article 32(1)(a))
Encrypt and pseudonymize customer and transaction data both at rest and in transit, calibrated to the risk of the processing activity. Higher-risk processing calls for stronger protection.
Data protection by design and by default (Article 25)
Embed cryptographic controls at the system design stage. Encrypted data stores and APIs should be the default configuration, not a control bolted on after the fact.
Breach notification exemption (Article 34(3)(a))
Maintain demonstrable strong encryption that can exempt you from notifying individual data subjects when exposed data was rendered unintelligible. The emphasis is on being able to prove it, not just assert it.
Key management and access control (Article 32(1)(b))
Operate a managed key lifecycle with restricted key access. This supports the ongoing confidentiality, integrity, availability, and resilience of processing systems that GDPR expects.
Testing and restoration (Article 32(1)(c) and (d))
Article 32(1)(d) requires a process for regularly testing and evaluating whether your measures still work, which is the provision that turns algorithm deprecation into a compliance event. Article 32(1)(c) requires restoration capability, and it connects directly to the breach exemption: encrypted data with no recoverable copy is still an availability incident.
Cross-border transfer safeguards (Article 46)
Use encryption of data in transit as a supplementary technical measure that supports international transfer mechanisms such as Standard Contractual Clauses.
Processor and vendor cryptographic assurance (Article 28)
Maintain a cryptographic component inventory that supports due diligence on the payment processors and sub-processors that handle personal data on your behalf.
Getting audit ready: what examiners actually ask
Assessments and examinations focus on demonstrated evidence, not policy statements alone. That reality favors institutions that can show their work. Use the following as a self-assessment checklist:
- A documented Article 32 risk assessment behind your choice of encryption and pseudonymization measures.
- Encryption or pseudonymization coverage across all systems that process personal data, not only external-facing ones.
- Documented evidence that data exposed in a hypothetical incident would remain unintelligible.
- Data protection by design records, with cryptographic controls reflected in Data Protection Impact Assessments.
- Evidence of regular testing and evaluation of your cryptographic controls, including a documented position on algorithm deprecation.
- Processor and sub-processor agreements that address cryptographic practices.
- Evidence that access to keys protecting personal data is restricted and logged.
- A cryptographic inventory and a migration plan for post-quantum readiness.
If you can answer each point with documentation rather than assurances, you are in a strong position when an examiner asks.
How Keyfactor can help
Meeting these obligations at scale is a matter of visibility, automation, and lifecycle control. Keyfactor connects each GDPR control area to practical capability, so you can operationalize Article 32 rather than just describe it.
- AgileSec provides the cryptographic component inventory that supports processor and sub-processor due diligence (Article 28).
- EJBCA delivers certificate issuance and scalable, future-proof PKI. It enables the protection of data at rest and in transit (Article 32(1)(a)), supports the breach-notification exemption (Article 34(3)(a)), and underpins cross-border transfer safeguards (Article 46).
- Bouncy Castle offers a wide catalog of strong cryptographic primitives that enable data protection and facilitate compliance.
- Keyfactor Command supports data protection by design (Article 25) and a managed key lifecycle with restricted, auditable key access (Article 32(1)(b)).
The common thread is maturity. Institutions that build mature cryptographic visibility and lifecycle management move faster through due diligence and examinations, and they recover more quickly when certificates or algorithms change. In that light, cryptographic governance becomes a competitive capability, not just a defensive one.
Conclusion and next steps
Under GDPR, well-implemented encryption plays two roles at once. It is a shield against fines that can reach EUR 20 million or 4% of global turnover, and it is a exemption that can spare you from notifying every affected customer after a breach. Both benefits depend on cryptography you can actually prove, not cryptography you merely claim.
The first practical steps are consistent regardless of where you start. Gain visibility into the cryptographic assets you have and where they are deployed. Assess them against Article 32 expectations. Then automate certificate and key lifecycles before gaps become incidents. Ready to see how? Request a Demo.
Got GDPR encryption questions? We’ve got answers.
Does GDPR require encryption of personal data?
GDPR does not mandate encryption outright. Article 32 names encryption and pseudonymization as example measures appropriate to the risk, so the requirement is risk-based. For high-risk financial data, encryption is generally expected.
What personal data do financial institutions need to protect under GDPR?
Typically high-risk categories such as transaction histories, credit and affordability data, and biometric authentication data used in fraud prevention. These carry heightened obligations because of their sensitivity and volume.
How large can GDPR fines be for financial services?
Fines can reach EUR 20 million or 4% of global annual turnover, whichever is higher. Financial services has consistently been among the more heavily fined sectors, given the volume and sensitivity of data it processes.
Can encryption exempt us from notifying customers after a breach?
Yes, under Article 34(3)(a). If exposed data was rendered unintelligible to unauthorized parties, usually through strong encryption, the controller does not have to notify individual data subjects. This makes encryption a direct cost-avoidance control.
Which GDPR articles matter most for cryptography?
Article 32 (security of processing, including pseudonymization and encryption), Article 25 (data protection by design and by default), Article 5(1)(f) and 5(2) (the confidentiality principle and the duty to demonstrate compliance), and Articles 33 and 34, where encryption is not just mitigating but can remove the duty to notify individuals altogether.
What do supervisor authorities look for?
Documented evidence, not policy statements alone. Expect questions about the Article 32 risk assessment, encryption coverage across all processing systems, breach safe-harbor support, data protection by design records, processor assurance, and restricted, logged key access.
Do our payment processors and vendors fall under GDPR encryption expectations?
Yes. Under Article 28, processor agreements should address the cryptographic practices of payment processors and sub-processors. A cryptographic component inventory helps support that due diligence.
Is GDPR only relevant to organizations based in the EU?
No. GDPR applies in the EU and EEA but has extraterritorial reach to any organization processing the personal data of EU residents, which is why it shapes what regulators worldwide consider reasonable security.
