Information Security and GDPR in the Financial Sector

In finance, data is the raw material. An account, a transaction history, a credit score, a national ID number, are all pieces of information that lead straight to fraud in the wrong hands. That is why the financial sector is among the most attacked in Romania and, at the same time, among the most regulated. A customer rarely forgives a leak of their banking data. Neither do the regulators.

The good news: the requirements are not a maze. They are a handful of clear frameworks that, taken together, describe roughly the same thing. Know what data you hold, protect it properly, and be able to prove it.

Which regulations apply, in short

A bank or a non-bank lender in Romania juggles three frameworks in practice, plus the expectations of its supervisors.

• GDPR — protection of personal data for customers and employees. This covers the legal grounds for processing, individual rights, breach notification within 72 hours, and fines of up to 4% of global turnover.
• DORA — the Digital Operational Resilience Act, applicable since 17 January 2025. It requires financial entities to manage their IT risk, report major incidents, test the resilience of their systems regularly, and keep external IT providers under control.
• NIS2 — many financial entities also fall under the cybersecurity directive, transposed into Romanian national law. Where DORA is more specific, NIS2 covers the general security framework.
• BNR and ASF requirements — guidance and rules on operational and IT risk that a supervisor checks during an inspection.

Rather than treating them separately, it is simpler to see them as layers over the same core: an information-security management system that works day to day.

DORA, explained for a CFO

DORA changed the tone of the conversation. Before it, IT resilience was a recommendation. Now it is a direct obligation, with no national transposition, and it applies to a wide range of entities: banks, non-bank lenders, insurers, investment firms, payment processors, crypto service providers.

Four things it asks for concretely:

• an IT risk management framework, owned by senior management rather than left to the technical team alone;
• reporting of major incidents to the authority, within strict deadlines;
• testing the resilience of systems, including penetration tests for larger entities;
• control over third-party providers, because an attack on a payment processor hits you directly.

That last point catches many companies off guard. If you outsource your cloud, your payments or your IT support, their risk becomes your risk, and it has to live in your contracts and your plan.

What happens when things go wrong

The most common incidents in a financial institution are not spectacular attacks. They are mundane things. An employee sending a file of customer data to the wrong address. A vendor with access that is far too broad. A reused password that turns up in a public leak. A lost laptop with no encryption.

Under GDPR, the fine can climb to 20 million euros or 4% of turnover. But in a bank, the real problem comes after the fine: customers moving their money, and a press headline you keep finding on Google for years. Reputation is harder to rebuild than a penalty is to pay.

The practical steps for a financial institution

Real compliance does not start with buying a security product. It starts with an honest map of where you stand.

• An inventory of data and systems. What personal and financial data you process, where it sits, who accesses it and on what legal basis. Without this, everything else is guesswork.
• A GAP analysis and risk assessment. You compare what you have against what GDPR, DORA and NIS2 require, and prioritise by risk, not by trend.
• Governance and policies. Rules on access, retention, erasure, encryption and incident handling, written for your reality rather than copied off the internet.
• Vendor control. Security clauses in contracts, a right to audit, and a plan for what you do if a provider goes down.
• People. Most incidents start with human error. Role-based training, from the front desk to the board, changes more than a new firewall.
• Testing and monitoring. Incident drills, penetration tests, periodic audits. Security is not a project with an end date, it is a routine.

A programme like this is exactly what you manage in a single platform with askGDPR: records, risk assessments, policies and incident logs in one place where you can prove compliance when an inspection arrives. For the standards side, see also our information security service and audits and testing.

Frequently asked questions