Cybersecurity Insights & Research

Threat reports, research papers, webinars and whitepapers from the Mercurius security team — staying ahead of the adversary.

Information security and regulation for the financial sector

Information Security for the Financial sector: Regulation and risks

No sector carries a heavier security burden than financial services. It holds the data attackers want most, moves the money they are ultimately after, and operates under a web of regulation that few other industries face. For a CISO or technology leader in a bank, fintech, or insurer, the daily challenge is to manage a relentless threat landscape and a rising regulatory bar at the same time, without paralyzing the business. This article maps both sides of that challenge, the main cyber risks and the key regulations, and explains how a resilient program addresses them together rather than as separate problems.

Why the financial sector is the top target

Financial institutions are attacked more than any other industry for reasons that are structural and permanent. The motive is the clearest in all of cybercrime: money. Beyond direct theft, financial institutions hold concentrated troves of personal and financial data that are highly valuable on criminal markets, which makes them a target for data theft as well as fraud.

Three factors compound the exposure. First, the sector is deeply interconnected, through payment networks, correspondent banking, and increasingly through open finance and APIs that link institutions to a wide ecosystem of fintechs and third parties. Each connection is a potential path in. Second, the pace of digital transformation has expanded the attack surface faster than many institutions can secure it, as mobile apps, instant payments, and cloud services multiply. Third, the impact of a breach is unusually severe: beyond the direct cost, there is regulatory penalty, loss of customer trust, and systemic reputational damage. IBM’s Cost of a Data Breach research consistently ranks the financial sector among the industries with the highest average breach costs, second only to healthcare in most years.

The main cyber risks for financial institutions

The threats facing finance are broad, but a handful dominate the risk picture and the attention of regulators.

  • Ransomware and extortion. The most disruptive threat, capable of halting operations and now routinely combined with data theft to pressure payment. For an institution that must be available, downtime is itself a critical loss.
  • Fraud and account takeover. Attackers compromise customer accounts through phishing, credential theft, and social engineering, then move money. In markets with instant payments such as PIX in Brazil, authorized push payment fraud, where a victim is tricked into sending money, has become a major concern.
  • Application and API attacks. As open finance and digital services grow, web applications and the APIs behind them carry enormous value and become prime targets for abuse of logic, authentication, and access controls.
  • Third-party and supply chain risk. Modern finance runs on a dense network of vendors, fintech partners, and cloud providers. A weakness in any of them can become the institution’s breach, which is why regulators now scrutinize third-party risk directly.
  • Insider threats. Whether malicious or negligent, people with legitimate access remain a significant risk in an environment where access equals money.
  • Distributed denial of service (DDoS). Attacks that aim to knock services offline, sometimes as extortion and sometimes as a smokescreen for another intrusion.

What ties these together is that in finance, a technical compromise converts into financial and regulatory loss faster than in almost any other sector. The window between intrusion and damage is short, which places a premium on fast detection and response.

The regulatory landscape

Financial institutions operate under a layered set of regulations that increasingly treat cybersecurity as a core obligation, not an IT detail. The exact requirements depend on where an institution operates and what it does, but the table below maps the frameworks that matter most, with a focus on the Americas and the standards that apply globally.

Financial sector regulatory landscape (responsive)
Region or domain Key framework What it requires
Global, payments PCI-DSS v4.0 Protecting cardholder data, including mandatory penetration testing and retesting
Global, interbank messaging SWIFT CSP Securing SWIFT connectivity and transaction environments
Global, best practice ISO 27001 and NIST CSF A managed information security program and a common control framework
European Union DORA ICT risk management, incident reporting, third-party oversight, and threat-led penetration testing
United States GLBA, NYDFS Part 500, SEC rules Safeguarding customer data, a formal cyber program with testing, and disclosure of material incidents
Brazil CMN Resolution 4.893, BCB rules, LGPD A cybersecurity policy, incident handling and reporting to the regulator, data protection, and Open Finance and PIX security
Chile Ley 21.663 and CMF RAN 20-10 The national cybersecurity framework with incident reporting, and operational and cyber risk requirements for financial entities

A few points deserve emphasis for leaders in the region. In Brazil, the combination of the CMN cybersecurity resolution, the demands of Open Finance and PIX, and the LGPD creates a dense and specific set of obligations, including the duty to report relevant incidents to the Banco Central. In Chile, the Ley Marco de Ciberseguridad has raised the bar nationally, and the CMF framework adds sector-specific operational and cyber risk requirements. And any institution touching European clients or operations now has to consider DORA, which is notable for explicitly requiring threat-led penetration testing and rigorous oversight of technology providers.

Because these requirements change and overlap, this article is a map, not legal advice. Confirm current obligations against the primary sources and, where needed, qualified counsel.

Where regulation and risk meet: the common gaps

The frameworks above are not arbitrary. Each one codifies a lesson from real incidents, which is why the regulatory requirements and the actual risks line up so closely. Several recurring gaps sit exactly at that intersection.

The first is testing that is cosmetic rather than real. Regulations increasingly demand penetration testing, and the most advanced, such as DORA, demand threat-led testing that emulates a real adversary. An institution that treats this as a box to tick, with a shallow scan, satisfies neither the spirit of the rule nor its own risk. The second is slow detection and response. Nearly every framework now includes incident reporting deadlines, which are impossible to meet if the institution cannot detect an incident quickly in the first place. The third is unmanaged third-party risk, now a named requirement in DORA and a growing focus elsewhere, yet still a blind spot for many institutions that secure their own perimeter but not their vendors. Closing these gaps is where compliance and genuine security become the same work.

How to build a resilient security program

For a financial institution, the goal is a program where security and compliance reinforce each other rather than competing for budget and attention. In practice that rests on a few pillars.

  1. Test like a real attacker. Go beyond compliance scans to genuine penetration testing, and for mature institutions, adversary emulation and red teaming mapped to frameworks like MITRE ATT&CK. This satisfies the stricter regulations and, more importantly, reveals the exposure that matters.
  2. Detect and respond fast. Continuous monitoring with a capable security operations function is what turns an intrusion into a contained event rather than a reportable breach. It is also what makes the incident reporting deadlines in modern regulation achievable.
  3. Manage third-party risk directly. Extend the same rigor to vendors, fintech partners, and cloud providers, with assessment and ongoing oversight, as regulations increasingly require.
  4. Make compliance a byproduct. When testing, monitoring, and response operate continuously, the evidence regulators and auditors ask for is generated as a natural output, not as a separate paper exercise that paralyzes the business.

 

The institutions that handle this well do not run security and compliance as two tracks. They run one program that produces both outcomes, which is the only sustainable approach as the regulatory bar keeps rising.

How Mercurius helps financial institutions

Mercurius works with financial organizations precisely at the intersection of risk and regulation. On the offensive side, its certified engineers deliver penetration testing and adversary emulation that go well beyond a compliance scan, mapped to recognized methodologies and to MITRE ATT&CK, which is what the stricter frameworks increasingly expect. On the defensive side, its AI-native managed SOC provides the continuous detection and fast response that both limit breach impact and make regulatory reporting deadlines achievable. And on the governance side, it helps institutions turn that operational rigor into the evidence that satisfies auditors and regulators, so compliance becomes a byproduct of good security rather than a parallel burden.

The guiding principle matches what financial leaders told us they want: a partner with the technical depth to find and fix what matters, and the ability to translate it into the language the board and the regulator understand. For a sector where a technical gap becomes a financial and regulatory loss in hours, that combination is the point.

For most engagements, gray box offers the best balance, because giving the tester a normal user account avoids spending days on reconnaissance and lets the time go into finding real issues. Black box maximizes realism when the goal is specifically to measure external exposure. White box is reserved for the deepest assurance on the most critical applications.

Frequently asked questions

Why is the financial sector targeted so often by cyberattacks? Because it is where the money and the most valuable data are. Financial institutions are also deeply interconnected through payment networks and open finance, which multiplies entry points, and the impact of a breach is severe, combining direct loss, regulatory penalty, and reputational damage. These factors make finance the most targeted industry.

What regulations govern cybersecurity in the financial sector? Globally, PCI-DSS for card data and SWIFT CSP for interbank messaging, plus ISO 27001 and NIST CSF as frameworks. Regionally, DORA in the European Union, GLBA, NYDFS Part 500, and SEC rules in the United States, CMN Resolution 4.893 with BCB rules and the LGPD in Brazil, and Ley 21.663 with CMF requirements in Chile. The specific obligations depend on where an institution operates.

What is DORA and does it affect institutions outside Europe? DORA, the Digital Operational Resilience Act, is a European Union regulation covering ICT risk management, incident reporting, third-party oversight, and threat-led penetration testing for financial entities. It can affect non-European institutions that serve European clients or operate in the European market, so its reach extends beyond the region.

What are the biggest cyber risks for banks and fintechs? Ransomware and extortion, fraud and account takeover including authorized push payment fraud in instant-payment markets, application and API attacks as open finance expands, third-party and supply chain risk, insider threats, and DDoS. In finance, these convert into financial and regulatory loss faster than in most sectors.

How does a financial institution comply without slowing the business? By running security and compliance as one program rather than two. When penetration testing, continuous monitoring, response, and third-party oversight operate continuously, the evidence regulators require is produced as a natural output. Treating each regulation as a separate last-minute project is what slows the business.

Is penetration testing required in the financial sector? In many cases, yes. PCI-DSS mandates it for institutions handling card data, NYDFS Part 500 requires testing, and DORA requires threat-led penetration testing for significant entities. Beyond the mandate, testing that emulates a real attacker is the most direct way to find the exposure that leads to breaches.

Did you enjoy the content? Share it with your network!

Categories

Last contents