Why Banking Has Its Own Cybersecurity Ecosystem
Financial institutions do not operate under general-purpose security frameworks alone. The combination of systemic risk - a single large bank’s failure can cascade across entire economies - and the sensitivity of the data they hold means that regulators have developed sector-specific requirements that go significantly further than ISO 27001 or NIST CSF on their own.
The landscape is not monolithic. A bank operating internationally is likely subject to the EU’s Digital Operational Resilience Act, the guidance published by the US Federal Financial Institutions Examination Council, and the SWIFT Customer Security Programme simultaneously. Understanding what each framework demands, and where they overlap, is essential for any security professional working in or advising the financial sector.
DORA: The EU’s Binding Digital Resilience Law
The Digital Operational Resilience Act entered into force across the European Union on the 17th of January 2025, applying to banks, insurance companies, investment firms, payment institutions, crypto-asset service providers, and - notably - the critical ICT third-party providers that serve them. It is not a guideline or a framework. It is directly applicable legislation, and non-compliance carries significant supervisory consequences.
DORA is built around five pillars: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. The ICT risk management pillar requires firms to implement a comprehensive framework that covers protection, detection, containment, recovery, and repair capabilities. Crucially, it demands that the management body - the board - takes direct ownership of that framework, reviews it at least annually, and receives dedicated training on ICT risk.
The Third-Party Dimension
DORA’s most novel and operationally challenging aspect is its treatment of third-party risk. Financial entities must maintain a register of all contractual arrangements with ICT third-party service providers. Contracts with providers that support critical or important functions must contain specific clauses: full audit rights for the institution and its competent authority, service level agreements with measurable performance indicators, data localisation requirements where applicable, and exit strategy provisions.
The most significant third-party providers - those designated as “critical” by the European Supervisory Authorities - will be subject to direct oversight by the ESAs themselves, not just by the institutions that use them. This creates a regulatory relationship directly between supervisors and cloud providers or core banking platform vendors, which is a structural shift in how third-party risk is governed in the EU.
Threat-Led Penetration Testing
DORA mandates threat-led penetration testing (TLPT) for significant financial entities on a triennial basis. TLPT is not a standard penetration test. It follows methodologies such as TIBER-EU - the ECB’s framework for red team testing of financial institutions - in which external red team providers conduct targeted attacks against live production systems based on a threat intelligence report developed specifically for the entity under test.
The scope covers people, processes, and technology. Social engineering, physical access attempts, and technical exploitation are all within bounds. The results are reported to the firm’s competent authority, and remediation must be formally tracked.
FFIEC: The US Regulatory Baseline
In the United States, cybersecurity guidance for financial institutions is issued by the Federal Financial Institutions Examination Council, a coordinating body whose member agencies include the Federal Reserve, the OCC, the FDIC, the NCUA, and the CFPB. FFIEC guidance does not have the direct legislative force of DORA, but it is treated by examiners as the baseline expectation, and deviations require documented justification.
The FFIEC Cybersecurity Assessment Tool (CAT), introduced in 2015, maps an institution’s inherent risk profile against its cybersecurity maturity across five domains: cyber risk management and oversight, threat intelligence and collaboration, cybersecurity controls, external dependency management, and cyber incident management and resilience. The CAT was retired as a mandatory tool in 2023, with the FFIEC explicitly endorsing the NIST Cybersecurity Framework 2.0 and the CISA Cybersecurity Performance Goals as its preferred reference frameworks going forward.
What Examiners Actually Focus On
Regardless of which framework an institution uses to organise its programme, examination findings cluster around consistent themes. Authentication hygiene is examined closely: examiners expect multi-factor authentication on all administrative access, on remote access, and increasingly on customer-facing access for higher-risk transactions. Patch management timelines are scrutinised - the expectation is that critical vulnerabilities are remediated within 30 days of disclosure, with documented exceptions for systems where patching requires extended change windows.
Third-party oversight is as important in the US context as it is under DORA. The FFIEC’s guidance on third-party relationships requires institutions to conduct due diligence before entering a relationship, negotiate contractual protections around audit rights and incident notification, and monitor performance throughout the life of the contract. Examiners will ask to see the third-party inventory, the risk tiering methodology, and evidence of ongoing monitoring for critical vendors.
Business Continuity and Cyber Resilience
The FFIEC Business Continuity Management booklet distinguishes between traditional business continuity - recovering from disruptions like natural disasters or infrastructure failures - and cyber resilience, which addresses scenarios where systems are simultaneously available but producing corrupted or fraudulent data. Ransomware is the canonical example: systems are running, but their integrity is compromised.
This distinction matters for recovery time and recovery point objectives. An institution that has set RTO and RPO targets based on infrastructure failure scenarios may find them inadequate for a ransomware event where the backup data itself is encrypted or corrupted. FFIEC guidance expects institutions to model cyber-specific scenarios in their business impact analysis and to test recovery from those scenarios in tabletop and, where feasible, technical exercises.
SWIFT Customer Security Programme
SWIFT operates the global messaging network over which the majority of international financial transactions are instructed. Its Customer Security Programme (CSP) is a mandatory framework for all institutions connected to the SWIFT network, covering both direct participants and those connected through service bureaux.
The CSP controls are organised into mandatory and advisory categories across three objectives: secure your environment, know and limit access, and detect and respond. The mandatory controls include network segmentation of the SWIFT local infrastructure, protection of Internet-browsing activities on systems that can reach SWIFT, hardening of the SWIFT operator workstations and application servers, and multi-factor authentication for operator access.
Annual Attestation and Independent Assessment
Every year, all SWIFT-connected entities must attest their compliance with the mandatory controls through SWIFT’s KYC Security Attestation portal. For entities in scope for independent assessment - which as of the 2023 framework revision includes a larger population based on transaction volume and connectivity type - a qualified external assessor must validate the attestation rather than the institution self-certifying.
SWIFT publishes aggregated attestation data to the broader community, meaning that your counterparties can see your compliance status. This creates a market-driven incentive for compliance alongside the regulatory one: correspondent banking relationships can be affected if a counterparty’s CSP attestation reveals significant gaps.
The Lessons of Bangladesh Bank
The 2016 compromise of the Bangladesh Bank’s SWIFT infrastructure, in which attackers fraudulently instructed transfers totalling $81 million via the SWIFT network, was the direct catalyst for the CSP’s creation. The technical path of that attack followed a now-familiar playbook: initial compromise of an endpoint, lateral movement to the SWIFT operator workstations, and then the use of legitimate SWIFT messaging capabilities to submit fraudulent payment instructions. Malware modified the locally installed SWIFT Alliance Access software to suppress confirmation messages and manipulate printed records.
The CSP controls are explicitly designed to close the attack surface demonstrated in that incident and subsequent similar campaigns attributed to the Lazarus Group. Understanding this context makes the specific control requirements more legible: they are not bureaucratic inventions but direct responses to observed adversary tradecraft.
Where the Frameworks Converge
Despite their different origins and jurisdictions, DORA, FFIEC guidance, and the SWIFT CSP converge on several consistent themes that define the current baseline expectation for financial sector cybersecurity.
| Theme | DORA | FFIEC | SWIFT CSP |
|---|---|---|---|
| Board-level accountability | Explicit legislative requirement | Examiner expectation | Governance control requirement |
| MFA for privileged access | Required | Required | Mandatory control |
| Third-party risk management | Prescriptive contract requirements | Due diligence and monitoring | Service bureau controls |
| Incident reporting | Strict timelines to supervisors | SAR and notification obligations | Mandatory incident reporting to SWIFT |
| Resilience testing | TLPT mandate | Scenario-based exercises | Not mandated, but advised |
The convergence is not coincidental. Regulators coordinate internationally through bodies like the Financial Stability Board and the Basel Committee on Banking Supervision, which have published their own cyber resilience guidance influencing national and regional rule-making.
Practical Implications for a Security Programme
An institution operating in multiple jurisdictions cannot maintain separate programmes for each framework without creating significant operational overhead and governance confusion. The practical approach is to build a unified control framework - typically anchored to NIST CSF or ISO 27001 - and then map each regulatory requirement to the relevant controls, documenting where each framework’s requirements exceed the baseline and implementing the more stringent of the competing requirements as the operational standard.
Gap analysis against DORA’s specific requirements around third-party contract terms is often the most time-consuming piece for institutions with large vendor ecosystems. Many legacy contracts predate DORA and lack the mandatory clauses around audit rights and exit provisions. Renegotiating those contracts at renewal, and prioritising critical ICT providers for early remediation, is the operationally realistic approach rather than attempting to renegotiate all contracts simultaneously.
The direction of travel is clear: regulators expect financial institutions to treat cyber resilience with the same rigour they apply to credit risk or liquidity risk - quantified, governed at board level, regularly tested, and embedded in the institution’s operating model rather than delegated entirely to a separate technology function.