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.
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.
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.
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.
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.
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.
From alert flood to a short list
KEV + EPSS + reachability turn a raw scan into the few findings that actually need action now.
Illustrative funnel. Reachability removes the bulk of unexploitable noise before triage.
The clock by finding type
Indicative fix windows. Tightest where exposure and active exploitation meet.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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- 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.