Cybersecurity for financial services: Regulations and controls

Which obligations apply depends on your firm type, your jurisdiction and whether you hold card data or serve EU customers.

Cybersecurity for financial services: What it covers

Cybersecurity for financial services protects the confidentiality, integrity, and availability of customer data, payment flows, and the systems behind them across banks, insurers, payment providers, and fintechs.

It differs from general enterprise security because regulators set minimum controls, such as multi-factor authentication and incident reporting, and examine firms against them. Firms without a dedicated security team often bring in a cybersecurity services company to design, build, and test these regulator-mandated controls.

NIST Cybersecurity Framework 2.0 supplies the structure. NYDFS Part 500, the GLBA Safeguards Rule, DORA, and PCI DSS 4.0 make parts of it mandatory, depending on firm type and jurisdiction.

We recommend starting with a gap assessment against the regimes that apply to you, because the right control order depends on your legacy systems and security staffing. Netguru builds secure fintech and banking software and offers security audit and threat modeling services for financial clients.

A qualified compliance adviser should confirm which rules cover your firm.

Why attackers target financial institutions

Attackers target financial institutions because stolen account data and payment access convert to cash quickly, and regulatory deadlines make extortion pressure effective.

In IBM's Cost of a Data Breach Report 2026, a breach in the financial sector cost $6.29 million on average, against a global average of $4.99 million.

For a security lead, the sector average is a ceiling to test against, because large incidents skew it. A budget argument holds up better when it prices three exposures separately:

• Disclosure clocks: Form 8-K Item 1.05 requires a public company to disclose a material incident within four business days of its materiality determination. The GLBA Safeguards Rule requires notice to the FTC within 30 days when a notification event involves unencrypted information of at least 500 consumers.
• Penalties: NYDFS consent orders under Part 500 have repeatedly cited missing multi-factor authentication and excessive access privileges. Price fines against the cost of those controls.
• Downtime: ransomware resilience (tested offline backups, segmentation, rehearsed recovery) shrinks the outage that gives attackers bargaining power. In IBM's X-Force Threat Intelligence Index 2023, ransomware ranked second among attacker actions on objective at 17%, behind backdoor deployment at 21%.

We recommend building the case from your own recovery time, record counts, and revenue per hour of downtime, then using the sector figures as a cross-check. The materiality determination itself is a legal judgment, so involve counsel before relying on any internal cost model for disclosure decisions.

Common cyber attacks on banks and how to prevent them

Ransomware, business email compromise, account takeover, and DDoS are the attacks that hit financial institutions most often, and each maps to a specific control and regulatory clause. Below is how each attack maps to a control and regulatory requirement:

The Snowflake case is also a third-party risk event. The breached environment belonged to a vendor platform, and the missing control was an MFA enforcement setting that the customers themselves owned.

For business email compromise, the FBI's annual figures are the benchmark: BEC caused $3.05 billion in reported losses from 24,768 complaints in 2025, second only to investment fraud (FBI IC3 2025 Internet Crime Report). Payment-verification procedure matters more than filtering here, because a fraudulent wire request often contains no malware.

Under 500.17(c), a covered entity must also notify DFS within 24 hours of making a ransom payment, and file a written explanation within 30 days. Treat clause numbers as a starting map and confirm applicability with compliance counsel, since DORA scope and Part 500 class status depend on entity type.

Which cybersecurity regulations apply to financial services?

Which cybersecurity regulations apply to a financial services firm depends on three things: where it is licensed, what type of firm it is, and whether it handles cardholder or consumer data.

Most firms answer yes to more than one row. Once you know which rules apply, the next step is designing a bank-grade finance stack that builds those obligations into the architecture from the start.

The matrix below maps each regime to who it covers and the controls it triggers:

FFIEC announced that the CAT would sunset on August 31, 2025 and pointed firms to NIST CSF 2.0 and the CISA Cybersecurity Performance Goals. Assessments that still run on the CAT should move to CSF 2.0 or the CRI Profile.

Several baseline regimes sit under these. GDPR Article 33 sets a 72-hour breach notice to the supervisory authority. PSD2 requires strong customer authentication for electronic payments. NIS2 applies to financial entities in the EU, but DORA (Regulation (EU) 2022/2554) is the sector-specific rule for firms in both scopes. DORA also replaces PSD2's incident reporting for payment providers.

We recommend building one control set against the strictest overlapping requirement. MFA, an incident response plan with the shortest notification clock, and third-party risk management are required by several of these regimes at once, so one control satisfies multiple rows.

Firm size and licensing decide applicability, and thresholds like Class A are tested on consolidated figures. Confirm scope with counsel before you rely on this table.

What is the new cybersecurity regulation for financial services?

Two regimes are new: amended NYDFS 23 NYCRR 500, phased in through November 1, 2025, and the EU's Digital Operational Resilience Act (DORA), which has applied since January 17, 2025.

The milestones below show what a covered entity should have ready at each date:

DORA's incident clock is separate from Part 500's. Per the DORA and its technical standards, a major ICT-related incident needs an initial report within 4 hours of classification, and no later than 24 hours after detection.

The second amendment to 23 NYCRR 500 became effective November 1, 2023, with requirements phased in through November 1, 2025. Every row in the table is now in force.

These dates cover only the Part 500 and DORA changes. Whether your entity is a covered entity, a Class A company, or in DORA scope is a legal determination for counsel.

How fast must you report a cyber incident?

The shortest reporting clock is DORA's: an initial notification of a major ICT-related incident within 4 hours of classification and no later than 24 hours after awareness. For US-only firms, the shortest is 36 hours.

The clocks side by side:

The triggers differ, so the clocks start at different moments. DORA's outer limit runs from awareness. NYDFS, the banking agencies and the SEC run from a determination, and the SEC final rule requires the materiality determination "without unreasonable delay". The Safeguards Rule clock runs from discovery. See also the DORA.

We recommend writing into the incident response plan who makes each determination and how quickly. The regulator clocks run in parallel, so one incident can start several at once. Have counsel confirm which regimes apply to your entity.

Which security controls should financial firms prioritize first?

A security team of two engineers should sequence the work as multi-factor authentication first, then encryption and patch SLAs, then privileged access management and logging. That order follows how much exposure each control removes per engineer-week. Alongside MFA, use a password manager to create and store unique passwords for each work account, reducing password reuse across financial systems.

Each step maps to a requirement an examiner will ask about. The 90-day plan, with the failure mode to expect at each step:

MFA fallbacks. Call-center agents on shared workstations cannot carry personal authenticator apps. Issue FIDO2 hardware keys per desk or per shift, and keep break-glass admin accounts with a sealed hardware token. Do not let the help desk reset a factor over the phone on knowledge questions, because that path becomes the bypass attackers use.

Gateway TLS. None of the named regimes mandates TLS 1.3 by name. Terminate TLS 1.3 at an API gateway or reverse proxy and use AES-256 for data at rest.

Where a legacy core cannot terminate it, keep the internal hop on TLS 1.2 with mutual authentication inside a segmented network. Under 500.15, the CISO must approve any such compensating control in writing and review it annually.

Patch SLA against freezes. PCI DSS 4.0 requirement 6.3.3 gives one month to install patches for vulnerabilities in the two top CVSS severity bands. Set a tighter internal SLA for internet-facing systems (14 days is an illustrative target, not a benchmark). Write an emergency exception into the change-freeze policy, and use WAF virtual patching when a freeze blocks a deploy.

PAM and key custody. Define RBAC roles before vaulting credentials, or the vault will mirror existing over-permissioning. We recommend a cloud KMS with customer-managed keys first, and dedicated HSMs only when a card scheme, PCI PIN requirement, or auditor demands them.

Run a one-page incident response plan in parallel (500.16; DORA Article 17), naming who makes the materiality determination. The reporting clocks above start at that decision.

Class A thresholds and the 500.19 exemptions change which items are mandatory for your firm, so confirm scope with counsel.

How to secure sensitive customer financial data on AWS and cloud

Securing cloud workloads that hold customer financial data starts with the shared responsibility line: the provider secures the infrastructure, and you secure the configuration, keys, identities and data on top of it.

Work in four steps: encrypt, scope IAM, mask, then monitor with cloud security posture management (CSPM).

The worked example assumes a lender's analytics platform on AWS. Nightly core banking and card transaction extracts land in Amazon S3, AWS Glue transforms them, Amazon Athena queries them, and a BI tool serves dashboards. The design is illustrative and has three zones:

• Landing: raw extracts containing account numbers and PANs, short retention, its own KMS key.
• Curated: tokenized data only, written by Glue jobs that call a tokenization service in a separate vault account.
• Consumption: Athena workgroups with Lake Formation column grants, plus masked views for the BI service role.

To see how the steps interact, follow one field, the account number, through the platform. It arrives in the landing bucket encrypted under the landing key. The Glue role can decrypt only that key, and it tokenizes the value deterministically before writing to the curated zone.

From there, analysts and the BI role see tokens only. Detokenization sits behind the vault account, and only a fraud-investigation role can reach it, through time-bound elevation. Each hop is a separate permission, so one compromised role exposes one stage, not the whole chain.

The order follows dependencies. Encryption comes first because it is a configuration change with no consumer impact. IAM scoping comes second because key policies and Lake Formation grants decide who can ever see plaintext.

Masking and tokenization come third, since they change the data analysts query. Use deterministic tokens for join keys, or customer-level analytics will break. Keep the token vault in a separate account with its own administrators.

CSPM comes last because its rules encode the baseline the first three steps created. Alert on unencrypted buckets, public access, roles with wildcard actions and disabled key rotation. Each finding then measures drift from a known-good state. For a related Netguru engagement, see Digital Wealth Solutions, the AdviceTech Platform for Financial Advisors.

Tokenization can shrink PCI DSS scope, but whether a given design qualifies is a judgment for your Qualified Security Assessor. The same goes for how your regulator reads 500.15 compensating controls.

How do you manage third-party and vendor cyber risk?

Manage third-party and vendor cyber risk by tiering vendors by what they touch, writing audit and exit rights into contracts, and testing concentration before an outage does. Third-party risk management is an explicit requirement in NYDFS 23 NYCRR 500.11, the GLBA Safeguards Rule (16 CFR 314.4(f)) and DORA Articles 28-30.

We suggest three tiers, so diligence effort follows exposure:

A SOC 2 report describes only what the vendor chose to scope. Read the audit period, the exceptions noted, which subservice organizations are carved out, and the complementary user entity controls you must operate yourself. A report that carves out the hosting provider says nothing about hosting.

NYDFS 500.11 requires policies covering due diligence and contractual protections such as access controls, encryption and notice of cybersecurity events. Amended Part 500 also extends the 72-hour notice to incidents at a third-party service provider that affect the covered entity. Contracts should therefore carry:

• A breach-notice window shorter than your own regulatory clock
• Audit and inspection rights that cover subcontractors
• Data return and deletion terms
• Exit assistance with a defined transition period, which DORA Article 30(3) requires for vendors supporting the most important functions

The DORA register of information is a structured dataset, not a spreadsheet of vendor names. Fields include the legal entity identifiers of your firm and the ICT third-party service provider, the function supported, service type, criticality assessment, subcontracting chain, data storage and processing locations, and contract dates. Much of this data comes from procurement and contract files, but the criticality assessment and subcontracting fields usually depend on a vendor security risk assessment that records where services run and who else touches them.

For concentration risk, we use this test for each important function. List the provider and its subcontractors down to the cloud region. If one failure takes down more than one function, or you cannot restore within your recovery time objective through an alternative, either document a risk acceptance or qualify a second provider. DORA Article 29 requires a concentration assessment before you sign.

This breaks down with hyperscalers, which rarely negotiate audit terms for mid-size customers. Rely on their regulatory addenda and pooled audit programs, and have counsel confirm the contract meets each regime you fall under.

What does a cybersecurity audit for financial institutions involve?

A cybersecurity audit for financial institutions tests whether each control maps to a named requirement, and whether you can produce dated evidence that the control ran. Examiners work from the regulation or framework, then ask for artifacts.

The evidence pack below follows NYDFS 23 NYCRR 500. The same artifacts serve FFIEC guidance, which now points institutions to NIST Cybersecurity Framework 2.0 after the FFIEC retired its Cybersecurity Assessment Tool.

Before the audit, check three things for every row:

• A named internal owner exists.
• The artifact is dated inside the policy cycle.
• Every exception has an expiry date.

A part-time or outsourced CISO is where these checks tend to fail. 500.4 allows a third-party CISO, but the covered entity keeps responsibility and must name a senior employee to oversee that provider. We suggest testing this early: if you cannot produce the board report, the incident log, or the annual certification support without emailing the provider, the evidence is not yours yet.

For reference material, use the CISA Financial Services Sector page, FFIEC IT Examination Handbook, Treasury sector guidance, and FS-ISAC threat reports. An independent pre-audit assessment can run this checklist against your artifacts before an examiner does. Teams that struggle to keep this evidence organised may also want to evaluate financial compliance software that centralises audit trails and regulatory monitoring.

Where does AI help and hurt in financial cybersecurity?

AI helps most in account takeover detection and fraud scoring, and hurts through false positives, model drift, and cloned voices that defeat call-center verification.

Price false positives before you set a threshold. Multiply the share of good customers blocked by their average account value and your churn rate after a blocked event, then add analyst hours per manual review. Use your own figures: a model that catches more fraud can still lose money.

Drift is a governance task. Fraud patterns shift faster than retraining cycles, so track score distributions against a baseline, set retraining triggers, and name an owner. A product security lead (CPSO) can hold that role. Include the models in the risk assessment that 23 NYCRR 500 requires.

Deepfake voice fraud attacks the call center, where agents verify identity during KYC and account recovery. Never let a voice match authorize a payment-detail or credential change alone. Require an out-of-band callback and multi-factor authentication for those requests.

The same out-of-band check covers business email compromise, the costliest attack in the threat table above.

AI anomaly detection can shorten ransomware dwell time, but it does not replace ransomware resilience: immutable backups and restore tests you have timed.

How do you build a security-aware workforce?

A security-aware workforce comes from training each role on the attack it is most likely to face, at a cadence set by its exposure. Finance operations see business email compromise, call centers see voice-based social engineering, engineers see secrets and supply-chain mistakes, and admins see credential theft.

An annual all-staff course is the regulatory floor: 23 NYCRR 500.14 (social engineering included), DORA Article 13(6), PCI DSS 4.0 requirement 12.6.3 and the GLBA Safeguards Rule all require it. The cadences below are our suggestion above that floor, not a mandate.

Pair training with controls for insider threat: session logging on privileged access management, quarterly entitlement reviews, and same-day offboarding.

Run a ransomware tabletop at least annually; Part 500.16 and PCI DSS 12.10.2 both expect the incident response plan to be tested. Settle these decision rights before the exercise:

1. Who declares an incident and who makes the materiality determination.
2. Who may isolate production systems.
3. Who approves any extortion-payment discussion, with counsel involved.
4. Who notifies regulators on the Part 500 and DORA major ICT-related incident clocks.

Our view is that a firm shipping its own customer-facing apps and APIs across several product teams should hire a Chief Product Security Officer (CPSO). The role covers threat modeling, secure coding and product security risk management, and it sits beside the CISO.

Firms that only buy vendor platforms can usually cover this with an application security lead. Confirm role requirements with counsel, since Part 500 and the Safeguards Rule name specific officers.

FAQ: Cybersecurity for financial services

Start with a gap assessment

A gap assessment maps your current controls against the frameworks that bind you, so remediation is ranked by exposure. Score each control against NIST Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond, Recover), then against NYDFS 23 NYCRR 500 or whichever regime applies.

Have counsel confirm applicability. Include third-party risk management: check vendor contracts, access reviews, and due-diligence records against obligations such as the third-party service provider policy in Section 500.11. Add threat modeling of payment and customer-data flows to turn the gap list into a priority order.

Netguru's cybersecurity audit and penetration testing team runs both exercises, and our managed services team can cover the monitoring that follows. To scope a gap assessment for your firm, talk to our team.