31 October 2026 · 10 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
NYDFS Penetration Testing: What 23 NYCRR Part 500 Requires from Banks, Insurers, Money Transmitters and Crypto Licensees
The Second Amendment to New York's Cybersecurity Regulation turned penetration testing from a risk-based option into an annual requirement from both inside and outside the boundary, phased in between December 2023 and November 2025. This guide explains Section 500.5 and the sections around it, what Class A companies owe on top, and what the CISO and senior officer are certifying every April.
What 23 NYCRR Part 500 is and who it covers
Part 500 of Title 23 of the New York Codes, Rules and Regulations is the Cybersecurity Regulation of the New York State Department of Financial Services (NYDFS). It took effect in March 2017 and was the first US financial regulation to prescribe specific cybersecurity controls rather than principles. The Second Amendment, adopted on 1 November 2023, rewrote large parts of it with phased effective dates: the new incident and extortion payment notices from 1 December 2023, most new control requirements from 29 April 2024, a further set from 1 November 2024, and the final items (universal multi-factor authentication under 500.12, the asset inventory under 500.13 and the Class A endpoint detection and logging requirements under 500.14(b)) from 1 November 2025. As of 2026 the regulation is fully in force.
A covered entity is any person operating under, or required to operate under, a licence, registration, charter, certificate, permit, accreditation or similar authorisation under New York's Banking Law, Insurance Law or Financial Services Law. In practice that means New York-chartered and licensed banks and the New York branches of foreign banks, insurers and insurance producers, mortgage lenders and servicers, money transmitters, licensed lenders, check cashers and the virtual currency businesses that hold a BitLicense or a limited purpose trust charter. Limited exemptions exist for the smallest entities (fewer than 20 employees, under USD 7.5 million in New York gross revenue, or under USD 15 million in total assets, including affiliates), but even exempt entities retain a core set of obligations.
The reach is international. A European bank with a New York branch, a European insurer with a New York-licensed subsidiary, or a payments or crypto firm that holds a New York licence is a covered entity for the systems that support that licensed business, and the regulation applies alongside, not instead of, DORA, NIS2 and home-country supervision.
Section 500.5: vulnerability management, clause by clause
Before the Second Amendment, 500.5 asked for annual penetration testing or continuous monitoring, at the entity's discretion. The amended section removes the choice.
500.5(a)(1): annual penetration testing from inside and outside
The cybersecurity program must include penetration testing of information systems from both inside and outside the information systems' boundaries, by a qualified internal or external party, at least annually. The words 'inside and outside' are deliberate: an external test of the perimeter alone no longer satisfies the section. Examiners expect an internal, assumed-breach component that measures what an attacker can do once a workstation or a vendor connection is compromised.
500.5(a)(2): automated scans plus manual review
Automated scans of information systems, and a manual review of systems not covered by such scans, to discover, analyse and report vulnerabilities, at a frequency set by the risk assessment and promptly after any material system change. The manual-review clause matters for legacy core systems, mainframes, OT and appliances that scanners cannot authenticate to; the regulation expects someone to look at them anyway.
500.5(b): a monitoring process for new vulnerabilities
The entity must have a process to be promptly informed of new security vulnerabilities, which in practice means subscribing to vendor advisories and vulnerability intelligence for the technology stack in the asset inventory, and a documented route from advisory to triage.
500.5(c): timely remediation prioritised by risk
Vulnerabilities must be remediated in a timely manner, with priority based on the risk they pose. Examiners test this by sampling: pick a critical finding from the last penetration test, follow it to the ticket, the fix and the retest. If the trail breaks, the finding is a governance finding as well as a technical one.
The sections a testing programme touches
Section 500.5 is where the penetration test is required. Several other sections are where its results are consumed.
| Section | Requirement, in short | How penetration testing supports it |
|---|---|---|
| 500.9 Risk assessment | Periodic risk assessment, reviewed at least annually and updated after material changes, that informs the design of the program | Test findings are the most concrete input to the risk assessment; conversely, the risk assessment sets the scope and depth of the next test |
| 500.12 Multi-factor authentication | MFA for any individual accessing any information system of the covered entity, with narrow CISO-approved compensating controls (fully in force 1 November 2025) | Testers verify coverage and resistance: legacy protocols that bypass MFA, phishable factors, and service accounts excluded from the policy |
| 500.13 Asset inventory | A complete, maintained inventory of information systems with owner, location, classification, support expiration and recovery objectives | Discovery during the test finds assets missing from the inventory; the inventory in turn defines what the test must cover |
| 500.14 Monitoring and training | Risk-based monitoring of user activity, protection against malicious code, annual training including social engineering; Class A: EDR and centralised logging with alerting | The internal test is a live validation of detection: what the SOC saw, when, and what it missed |
| 500.16 Incident response and BCDR | Written incident response and business continuity plans, tested at least annually with senior officers, including the ability to restore from backups | An assumed-breach test with ransomware objectives exercises the plan against a realistic scenario rather than a tabletop |
| 500.17 Notices and certification | 72-hour notice of cybersecurity incidents, 24-hour notice of extortion payments, annual certification or acknowledgment of non-compliance by 15 April | The test report and retest evidence are part of the file the CISO and senior officer rely on when they sign |
| 500.2(c) Independent audit (Class A) | Class A companies must have an independent audit of the cybersecurity program at least annually | Auditors sample the testing programme; a current, well-scoped report with closed findings shortens the audit |
Class A companies and the annual certification
The Second Amendment created the Class A category for the largest covered entities: at least USD 20 million in gross annual revenue in each of the last two fiscal years from the entity's operations and its affiliates' New York operations, combined with either more than 2,000 employees (including affiliates, wherever located) or more than USD 1 billion in gross annual revenue across the entity and all affiliates. Class A companies carry additional duties: an annual independent audit of the cybersecurity program (500.2(c)), a privileged access management solution and automated blocking of commonly used passwords (500.7(c)), and endpoint detection and response plus centralised logging with alerting (500.14(b)). For a Class A company the internal penetration test doubles as the proof point for 500.14(b): an attacker moving laterally through the estate should light up the EDR and the SIEM, and if it does not, the examiner will want to know why.
Every covered entity, Class A or not, files an annual submission by 15 April under 500.17(b). It is either a certification of material compliance for the prior calendar year or a written acknowledgment of non-compliance identifying the sections not met and a remediation timeline. The submission must be signed by the covered entity's highest-ranking executive and its CISO, and the entity must retain the records that support it for five years. That signature is what makes Part 500 different from most frameworks: a named executive is attesting personally that the penetration test under 500.5 happened, covered inside and outside, and that findings were remediated. The quality of the test report determines how comfortable that signature is.
What examiners and the certifying officers expect to see
NYDFS examines through document requests and interviews. These are the items a well-run programme can produce on the first request.
- A penetration test report dated within the last 12 months with a scope statement that explicitly covers both external (internet-facing) and internal (assumed-breach) testing of the systems supporting the licensed business
- The qualifications of the testing party: named testers, certifications, independence from the teams that operate the systems tested
- A methodology reference (NIST SP 800-115, PTES, OWASP) and evidence that manual testing was performed, not only automated scanning
- Scan schedules and results at the frequency the risk assessment commits to, plus the manual review of systems scanners cannot cover
- A remediation log tying each finding to an owner, a deadline derived from its risk rating, the fix and the retest evidence
- The current risk assessment (500.9) showing how test results fed into it and how it set the scope of the next test
- The detection record from the internal test: alerts generated, time to detect, time to respond, and gaps identified (critical for Class A companies under 500.14(b))
- Evidence that the incident response and BCDR plans were tested in the past year (500.16), ideally against the scenario the internal test produced
- The signed 500.17(b) submission for the prior year and the file of records that supports it
Part 500 alongside DORA, NIS2, GLBA and SOC 2
International financial groups rarely answer to one regulator. A European bank's New York branch sits under Part 500 and under DORA at group level; a US insurer with EU operations may face NIS2 through a subsidiary; a fintech may hold a New York licence, fall under the FTC Safeguards Rule for other business lines and carry a SOC 2 report for its enterprise customers. The testing obligations overlap more than they conflict. DORA Articles 24 and 25 require an annual, risk-based testing programme covering systems behind critical functions; Part 500 requires annual inside-and-outside penetration testing of the information systems supporting the licensed business; the Safeguards Rule requires annual penetration testing and semi-annual vulnerability assessments for FTC-regulated institutions; SOC 2 expects testing as evidence for the monitoring criteria.
One programme can serve all of them if the scope statement is written for it. The practical approach is a single annual engagement whose scope document maps each in-scope system to the regulations that cover it, whose report cites the relevant section per finding, and whose retest evidence is filed in each regulatory record. What does not transfer is the New York certification: however many frameworks the test serves, a named executive and the CISO sign for Part 500 specifically, so the file for that signature should be assembled with that in mind.
How HackersHub supports Part 500 compliance
We scope the annual engagement to the information systems that support the New York-licensed business, test them from outside (the internet-facing perimeter, remote access, customer and partner portals) and from inside (an assumed-breach position on the corporate network or through a vendor connection), and we treat the detection record as a deliverable, so the test also evidences 500.14. For insurers and lenders that run core systems scanners cannot reach, we perform the manual review 500.5(a)(2) asks for. The report maps every finding to the Part 500 section it bears on, carries a risk rating that your remediation deadlines can key off, and includes a retest so the remediation log closes with proof.
Testers are OSCP-certified and named in the report, which answers the 'qualified party' language of 500.5 directly. HackersHub is based in Amsterdam, Netherlands and works for financial institutions on both sides of the Atlantic; for New York-regulated entities we test remotely within agreed windows and US business hours, and for European groups we align the Part 500 engagement with the DORA programme so one test serves both files.
Frequently asked questions
Preparing the file for your 15 April certification?
We test inside and outside the boundary, record what your defences detected, and report every finding against the Part 500 section it bears on. Talk to an expert about scoping before your next cycle.