Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Compliance›NYDFS Part 500
United States · 23 NYCRR Part 500

NYDFS 23 NYCRR Part 500

the New York cybersecurity rule for financial covered entities, and how to meet it

23 NYCRR Part 500 is the New York Department of Financial Services (NYDFS) cybersecurity regulation. Every NYDFS-regulated bank, insurer, and money transmitter operating in New York is a "Covered Entity" and must run a written cybersecurity program with named accountability, tested controls, and reportable incidents.

The Second Amendment, finalized November 1, 2023, phased in new obligations through November 1, 2025. The most consequential for engineering and security teams: §500.5(b) requires automated vulnerability scanning effective May 1, 2025, §500.3 mandates application-security and secure-SDLC policies, and §500.17 keeps the 72-hour cybersecurity-event notification window. This page explains how to satisfy each requirement.

Talk to our advisory team Read it on dfs.ny.gov
At a glance
Nov 1, 2023Second Amendment finalized
May 1, 2025§500.5(b) automated scanning effective
72 hours§500.17 incident notification window
Nov 1, 2025Final staggered effective date
23 NYCRR Part 500 — NYDFS Cybersecurity Regulation (Second Amendment)
Why it matters

A financial-sector rule with teeth, deadlines, and personal accountability

Part 500 is enforceable law, not a voluntary framework. NYDFS has brought multiple enforcement actions and levied multi-million dollar penalties for inadequate controls and late or missing notifications. Covered Entities must file an annual certification of material compliance, and the regulation now requires senior-officer or board sign-off on the program and on key policies (§500.4, §500.17).

The Second Amendment sharpened the technical bar. §500.5(b) moved vulnerability management from a vague expectation to a concrete requirement: automated scans, plus manual review of anything automation cannot cover, at a cadence driven by your risk assessment, backed by documented and annually approved vulnerability- and patch-management policies. §500.3 forces application security and secure SDLC into the written program rather than leaving them to engineering discretion.

The reporting clock is unforgiving. A reportable cybersecurity event must reach NYDFS within 72 hours (§500.17(a)), and the amendment added notice for ransomware deployment and extortion payments. Meeting Part 500 is as much about provable process and evidence as it is about tooling.

How O3 helps

Find it before attackers do. Catch it if they try. Fix it fast.

Across these requirements, O3 runs one continuous loop on your own software so issues surface, get caught, and get fixed before they become an incident.

1 · Find it first

Test like an AI-assisted attacker

An agentic pentest probes your app across 50+ vulnerability classes the way a real attacker chains them, so exploitable flaws surface in your build before someone outside finds them.

2 · Catch it live

Detect and block exploitation at runtime

A kernel-level eBPF agent watches process trees and syscalls, recognises an attack sequence as it unfolds, and restricts the offending process on the spot rather than taking down the host.

3 · Fix it fast

Auto-patch what is reachable

Reachability ranks what genuinely matters, then autofix opens a pull request with the change, so remediation starts inside tight fix windows instead of sitting in a queue.

Risk-based prioritisation

From alert flood to a short list

KEV + EPSS + reachability turn a raw scan into the few findings that actually need action now.

Raw findings in dependency tree~12,400
Vulnerable & version-matched~4,700
Reachable in your code~1,360
KEV / high-EPSS · act now~370

Illustrative funnel. Reachability removes the bulk of unexploitable noise before triage.

Remediation expectations

The clock by finding type

Indicative fix windows. Tightest where exposure and active exploitation meet.

Cybersecurity event notice to NYDFS (§500.17(a))72 hours
Extortion / ransom payment notice (§500.17(c))24h pay + 30d explain
Vulnerability scan cadence (§500.5(b))Risk-based / periodic
Annual certification of material compliance (§500.17(b))By April 15 yearly
§500.5(b)

How to meet the automated vulnerability scanning requirement

Effective May 1, 2025, §500.5(b) requires automated scans of information systems to detect known vulnerabilities, plus a manual review of systems that automated tools cannot cover, on a cadence set by your risk assessment. Detection alone is not enough: §500.5(c) requires timely remediation based on risk.

23 NYCRR §500.5(b)23 NYCRR §500.5(c)
Inventory every in-scope information system and map which can be covered by automated scanning versus which need manual review (§500.5(b)).
Run automated scans on a documented, risk-based cadence and after material system changes; record dates, scope, and coverage gaps.
Prioritize findings by exploitability and exposure, not raw CVSS, and define remediation SLAs tied to risk severity (§500.5(c)).
Adopt and have the senior governing body approve written vulnerability- and patch-management policies at least annually (§500.5(b)).
Where O3 helps

O3 covers the automated-scan obligation across code and dependencies with SAST, SCA, agentic DAST, and secret scanning, then ranks findings by function-level reachability plus EPSS and KEV so remediation effort maps to real exploitability rather than CVSS noise.

§500.3

How to build the secure SDLC and application-security policy

§500.3 requires written cybersecurity policies approved by a senior officer or the governing body, explicitly covering systems and application security, the software development lifecycle, and quality assurance. This pushes appsec from informal practice into documented, auditable policy.

23 NYCRR §500.3
Write application-security and secure-SDLC policies covering design, code review, testing, and QA, and get senior-officer or board approval (§500.3).
Embed security gates into the development pipeline: dependency vetting, static analysis, and pre-release testing.
Maintain a component inventory for produced and consumed software so third-party and open-source risk is visible.
Review and re-approve the policies at least annually and whenever the technology or threat picture changes (§500.3).
Where O3 helps

O3 operationalizes the SDLC policy: SAST taint analysis (source to sink, interprocedural), SCA against OSV, malicious-dependency detection for typosquats and compromised maintainers, and CycloneDX SBOM generation give engineering provable application-security evidence inside the pipeline.

§500.17

How to meet the 72-hour incident reporting obligation

§500.17(a) requires notice to the Superintendent within 72 hours of determining a reportable cybersecurity event has occurred. The Second Amendment added separate notice for ransomware deployment in a material part of systems and for extortion payments, plus an annual certification or acknowledgment of compliance.

23 NYCRR §500.17(a)23 NYCRR §500.17(b)23 NYCRR §500.17(c)
Define internally what constitutes a reportable cybersecurity event and the decision point that starts the 72-hour clock (§500.17(a)).
Build a runbook that routes detection to determination to NYDFS notice within 72 hours, with named owners.
For extortion payments, notify within 24 hours and provide a written explanation within 30 days (§500.17(c)).
File the annual certification of material compliance, or a written acknowledgment of non-compliance with a remediation plan, by April 15 (§500.17(b)).
Where O3 helps

O3's eBPF runtime agent builds kernel process trees and detects attack chains, and its L7 deep packet inspection flags exfiltration and DNS tunneling. These shorten time-to-determination, which is what actually starts the 72-hour clock.

§500.4 / §500.9

How to establish CISO oversight and risk assessment

§500.4 requires a qualified CISO who reports in writing at least annually to the senior governing body on the program and material risks. §500.9 requires a periodic written risk assessment that drives the design of controls, including scanning cadence and access rules.

23 NYCRR §500.423 NYCRR §500.9
Designate a qualified CISO and ensure adequate authority and resources to manage the program (§500.4).
Deliver the CISO's written report to the board or equivalent at least annually, covering material cybersecurity risks (§500.4).
Conduct and document a risk assessment that is updated as the business, technology, and threats change (§500.9).
Use the risk assessment to set scanning frequency, access tiers, and control priorities so decisions are defensible.
§500.12 / §500.7

How to satisfy MFA and access-privilege controls

§500.12 requires multi-factor authentication for any individual accessing the Covered Entity's information systems, with limited risk-based exceptions approved in writing by the CISO. §500.7 requires least-privilege access, periodic access reviews, and privileged-account controls.

23 NYCRR §500.1223 NYCRR §500.7
Deploy MFA for remote access, privileged accounts, and access to nonpublic information; document any CISO-approved compensating controls (§500.12).
Apply least-privilege by default and review user and privileged access entitlements periodically (§500.7).
Disable or remove access promptly when roles change or personnel leave.
Monitor and log privileged-account use for anomalous behavior.
§500.13 / §500.14

How to handle asset inventory, monitoring, and training

§500.13 requires written asset-management and data-retention policies, including a documented inventory of information systems. §500.14 requires monitoring and detection controls, including endpoint detection and response capabilities, plus regular cybersecurity awareness training.

23 NYCRR §500.1323 NYCRR §500.14
Maintain a current asset inventory tracking ownership, location, classification, and end-of-life for in-scope systems (§500.13).
Implement monitoring and EDR-class detection on systems handling nonpublic information (§500.14).
Provide periodic security awareness training, including social-engineering and phishing, to all personnel (§500.14).
Tie monitoring telemetry into the incident-response process so events reach a determination quickly.
Where O3 helps

O3's eBPF runtime agent (no sidecars) provides kernel-level process and syscall visibility and dynamic per-PID blocking, supporting the continuous-monitoring and detection expectations of §500.14.

The whole framework

Every core Part 500 requirement and how a Covered Entity meets it

All 22 requirement areas, each with the reference and a vendor-neutral note on how teams meet it.

4§500.2–500.4
Program, policy & governance
7§500.5–500.9
Vulnerability, access & risk controls
7§500.10–500.16
Personnel, vendors, data & resilience
4§500.17–500.19
Reporting, certification & exemptions
Requirement area
Cybersecurity program§500.2Maintain a documented, risk-based program
Cybersecurity policy§500.3Written, board-approved appsec & SDLC policies
Chief Information Security Officer§500.4Qualified CISO; annual written board report
Vulnerability management§500.5(b)Automated scans + manual review, risk cadence
Remediation of vulnerabilities§500.5(c)Timely risk-based remediation, documented
Penetration testing§500.5(a)Annual pen test of information systems
Audit trail§500.6Maintain logs to detect and respond to events
Access privileges & management§500.7Least privilege; periodic access reviews
Application security§500.8Secure dev procedures; review external code
Risk assessment§500.9Periodic written risk assessment, updated
Cybersecurity personnel§500.10Qualified staff or trained service providers
Third-party service provider policy§500.11Due diligence and contractual safeguards
Multi-factor authentication§500.12MFA for system access; CISO-approved exceptions
Asset management & data retention§500.13System inventory; secure disposal of data
Monitoring & training§500.14Detection/EDR controls; awareness training
Encryption of nonpublic information§500.15Encrypt data in transit and at rest
Incident response plan§500.16Written, tested IR and BC/DR plans
Event notification (72 hours)§500.17(a)Notify NYDFS within 72 hours of determination
Annual certification§500.17(b)Certify material compliance by April 15
Extortion payment notice§500.17(c)Notify within 24h; explain within 30 days
Confidentiality§500.18Protect information submitted to NYDFS
Exemptions§500.19File limited-exemption notice if eligible

Turn Part 500 vulnerability management into provable evidence

§500.5(b) wants automated scanning and §500.3 wants a real secure-SDLC policy. O3 runs SAST, SCA, agentic DAST, and secret scanning, ranks findings by reachability plus EPSS and KEV, and produces CycloneDX SBOMs so your NYDFS evidence is concrete, not aspirational. See how O3 maps to your Covered Entity program.

Read it on dfs.ny.gov
FAQ

Common
questions.

Everything teams ask before rolling this out. Still stuck? Reach our team.

  • Any entity operating under a license, registration, charter, or similar authorization under New York's Banking, Insurance, or Financial Services Law is a Covered Entity. That includes banks, insurers, mortgage lenders, and money transmitters operating in New York. Limited exemptions exist for small entities under §500.19, but most still owe core obligations.
  • Effective May 1, 2025, §500.5(b) requires automated scans of information systems to detect known vulnerabilities, plus manual review of systems automation cannot cover, at a cadence driven by the risk assessment. It also requires written vulnerability- and patch-management policies approved at least annually by the senior governing body.
  • Under §500.17(a), a Covered Entity must notify the Superintendent within 72 hours of determining that a reportable cybersecurity event has occurred. The clock starts at determination, not detection, so a fast path from alert to determination is essential. Extortion payments carry a separate 24-hour notice under §500.17(c).
  • §500.3 requires written cybersecurity policies, approved by a senior officer or the governing body, that explicitly address systems and application security, the software development lifecycle, and quality assurance. §500.8 adds that the program include secure development procedures and a process to evaluate externally developed applications.
  • NYDFS finalized the Second Amendment on November 1, 2023, with staggered effective dates running through November 1, 2025. Notable milestones include the §500.5(b) automated-scanning requirement effective May 1, 2025, and expanded reporting and governance obligations phased in across 2024 and 2025.
  • Yes. §500.12 requires multi-factor authentication for any individual accessing the Covered Entity's information systems. The CISO may approve reasonably equivalent or more secure compensating controls in writing, but exceptions must be documented and reviewed. The Second Amendment broadened MFA expectations beyond just remote access.
  • NYDFS treats each Part 500 requirement as a separate obligation and has imposed multi-million dollar penalties in enforcement actions for inadequate controls and late or missing notifications. The annual certification of material compliance under §500.17(b) carries personal accountability for the certifying senior officer.
  • Yes. §500.5(a) requires annual penetration testing of information systems based on the risk assessment, in addition to the automated and manual vulnerability assessment in §500.5(b). Continuous monitoring or periodic testing, including pen testing, must be designed to detect changes that could create or indicate vulnerabilities.
  • O3 maps to the technical core: SAST, SCA, agentic DAST, and secret scanning satisfy §500.5(b) automated scanning, with reachability plus EPSS and KEV ranking remediation by real exploitability. SBOM generation and malicious-dependency detection support the §500.3 application-security policy, and the eBPF runtime agent aids §500.14 monitoring and faster §500.17 determination.

See O3 Security in Action

See why security and engineering leaders trust O3
to secure their entire software supply chain.