NYDFS Part 500 penetration testing and vulnerability management — the §500.5 playbook

Part 500 applies to every covered entity: any person operating under, or required to operate under, a license, registration, charter, certificate, permit, accreditation or similar authorisation under the New York Banking Law, Insurance Law or Financial Services Law, even if another regulator also supervises it (§500.1(e)). Typical examples are banks, insurers, insurance agents and brokers, mortgage companies and virtual currency businesses licensed by DFS.

Three categories change what applies:

• Limited exemption (§500.19(a)): fewer than 20 employees and independent contractors including affiliates, or less than $7,500,000 in gross annual revenue in each of the last three fiscal years from the covered entity's business and its affiliates' New York operations, or less than $15,000,000 in year-end total assets including affiliates. These entities are exempt from §500.5 and several other sections, and must file a Notice of Exemption within 30 days of determining that they qualify.
• Class A companies (§500.1(d)): at least $20,000,000 in gross annual revenue in each of the last two fiscal years from the covered entity's business and its affiliates' New York operations, plus either more than 2,000 employees averaged over those two years or more than $1,000,000,000 in gross annual revenue in each of them, both counted with affiliates wherever located. Only affiliates that share information systems, cybersecurity resources or part of the cybersecurity program count. Class A adds independent audits of the program (§500.2(c)), privileged access management and blocking of commonly used passwords (§500.7(c)), and endpoint detection and response with centralised logging and alerting (§500.14(b)).
• Every other covered entity: the full §500.5 duties apply.

§500.5 itself is the same for a Class A company and for a mid-sized covered entity. What differs is the scrutiny around it: a Class A company's independent audit will test the vulnerability management program like any other control.

§500.5 requires written vulnerability management policies and procedures, based on the risk assessment and designed to assess and maintain the effectiveness of the cybersecurity program. They must ensure four things.

1. Penetration testing (§500.5(a)(1)) of the information systems from both inside and outside the information systems' boundaries, by a qualified internal or external party, at least annually.
2. Automated scans (§500.5(a)(2)) of information systems, and a manual review of systems the scans do not cover, to discover, analyse and report vulnerabilities, at a frequency determined by the risk assessment and promptly after any material system change.
3. Monitoring (§500.5(b)): a process that keeps the entity promptly informed of new security vulnerabilities.
4. Remediation (§500.5(c)): timely remediation, giving priority to vulnerabilities based on the risk they pose to the covered entity.

Part 500 defines penetration testing as testing the security of information systems by attempting to circumvent or defeat their security features, by authorising attempted penetration of databases or controls from outside or inside the information systems (§500.1(l)). Two consequences follow. An external perimeter test on its own does not match the text: the test also has to start from inside the boundary, the position of an insider or of an attacker who already has a foothold. And a vulnerability scan is not a penetration test: the definition requires an attempt to defeat controls, not a list of missing patches.

The Second Amendment took effect on 1 November 2023 (§500.21(b)) and phased its new requirements in over two years (§500.22(c) and (d)):

• 30 days: the new notice requirements of §500.17.
• 180 days: every new requirement not listed below, including the amended penetration testing wording in §500.5(a)(1).
• One year (1 November 2024): §500.4 governance, §500.15 encryption, §500.16 incident response and business continuity, and the revised limited exemption in §500.19(a).
• 18 months (1 May 2025): §500.5(a)(2) automated scans and manual review, §500.7 access privileges, §500.14(a)(2) malicious-code controls and §500.14(b) Class A endpoint detection and logging.
• Two years (1 November 2025): §500.12 multi-factor authentication and §500.13(a) asset inventory.

All of these have passed. Calendar year 2026 is therefore the first full year in which every amended requirement applied from 1 January, and the certification or acknowledgment covering it is due by 15 April 2027 (§500.17(b)). The asset inventory matters for §500.5 more than its section number suggests: the scope of scans and penetration tests can only be shown to be complete against a complete inventory.

The regulation sets the minimum (at least annually, both perspectives, a qualified party) and leaves the design to the risk assessment. A test that holds up in an examination usually has:

• Scope drawn from the asset inventory and the risk assessment, with the systems excluded and the reason for each exclusion written down.
• Two starting positions: outside the boundary (internet-facing services, remote access, exposed applications) and inside it (a standard user workstation or a compromised account), with the paths tested from each.
• A documented choice of tester. Part 500 does not define “qualified”. Keep what supports the choice: relevant experience and certifications, independence from the teams that run the systems under test, and the methodology used.
• Rules of engagement approved before testing starts: targets, techniques that are out of bounds, testing windows, and who can stop the test.
• Findings that feed §500.5(c): each exploitable finding goes into the remediation process with a risk rating, an owner and a target date, and is re-tested after the fix.

Annually is a floor. §500.9 requires the risk assessment to be updated at least annually and whenever a change in the business or technology causes a material change to cyber risk; a major migration, an acquisition or a new internet-facing service is a good reason to test again before the next annual cycle.

§500.5(a)(2) ties scan frequency to the risk assessment, so the frequency has to be written down and justified, not inherited from a tool default. Three details are often missed. Scans must also run promptly after any material system change, not only on the calendar. Systems the scanners cannot cover, such as appliances, operational technology or SaaS configurations, need a documented manual review. And results must be analysed and reported, not just collected.

For §500.5(b), name the sources you monitor (vendor advisories, the CISA Known Exploited Vulnerabilities catalogue, sector sharing groups) and who triages them. For §500.5(c), timely and risk-based means remediation targets that depend on exploitability and exposure, not only on CVSS scores; the KEV emergency patch window playbook describes one way to set them.

DFS guidance in 2026 points the same way. In May 2026 it asked regulated entities to identify and remediate known exploited vulnerabilities expeditiously, especially on internet-facing systems, and told CISOs that frontier AI models amplify the potency, scale and speed of vulnerability discovery and exploitation. Both letters state that they create no new requirements; they are meant to inform how entities manage risk and comply with Part 500.

By 15 April each year, a covered entity files either a certification that it materially complied with Part 500 during the prior calendar year, or an acknowledgment of noncompliance that identifies the sections not complied with, describes the nature and extent of the gap, and gives a remediation timeline or confirms remediation (§500.17(b)). Both are signed by the highest-ranking executive and the CISO. The certification must rest on data and documentation sufficient to determine and demonstrate material compliance, and the records must be kept for five years. DFS's FAQs add that an entity may not certify unless it was in material compliance with all applicable requirements for the prior year.

For §500.5, the file an examiner would expect to see:

• The written vulnerability management policy and procedures, with evidence of the annual approval required by §500.3.
• The current risk assessment and the rationale linking it to scan frequency and test scope. DFS's September 2026 guidance on risk assessments asks for documentation that shows how risks were identified, assessed and addressed, including the methodology, the data considered and the rationale.
• Each penetration test report, showing the inside and outside perspectives, the scope and exclusions, and the tester's qualifications.
• Scan schedules and results, the list of systems under manual review, and the scans run after material changes.
• The monitoring sources and the triage record for new vulnerabilities.
• Remediation records: finding, risk rating, owner, target and actual dates, re-test result, and approved exceptions.
• The CISO's annual written report to the senior governing body (§500.4(b)), which covers material cybersecurity risks and plans for remediating material inadequacies.

1. External-only testing. A perimeter test with no inside perspective does not match the text of §500.5(a)(1).

2. An undocumented tester. If the file does not show why the tester was qualified, the certification rests on an assumption.

3. Scan frequency with no link to the risk assessment. A monthly schedule may be right, but the risk assessment has to say why, and material changes need their own scans.

4. Silent coverage gaps. Systems the scanner cannot reach, with no manual review on record.

5. Remediation by CVSS alone. §500.5(c) asks for priority based on the risk to the covered entity, which depends on exposure and exploitability in its own environment.

6. Certifying through a known gap. DFS's FAQs treat materiality as a judgement about the nature, duration, scope and potential impact of the noncompliance. Under §500.20(b) a single act or failure to act can be a violation, including a material failure to comply with any section for any 24-hour period. An acknowledgment with a remediation timeline is the route the regulation provides.

An autonomous AI red team does not replace the qualified party that §500.5(a)(1) requires, and it does not decide whether an entity materially complied; the CISO and the highest-ranking executive do. What it changes is the evidence available between annual tests.

• Both perspectives, continuously. Black-box campaigns from outside the boundary and gray-box campaigns from inside it, with the credentials of a standard user, run on a schedule and after material changes rather than once a year. See black-box vs gray-box testing.
• Priority from proof. Findings arrive with evidence that they are exploitable in your environment, which is the input §500.5(c) prioritisation needs. See fix what was proven exploitable first.
• Re-test on demand. Each fix can be checked with the same proof that found the flaw, which closes the remediation record.
• Human approval gates. Five autonomy levels define what the agents may do alone and what waits for a person, from approval of any active scan at the lowest level to no approval gates at the highest, which is chosen deliberately. See human in the loop.
• Records that hold up. Every attack attempt is recorded in a SHA-256 hash chain per campaign, each entry signed with Ed25519, so the testing records behind the 15 April filing can be shown to be unaltered.
• No new third party. Findings about exploitable systems, and any customer data or credentials a test touches, can fall within Part 500's definition of nonpublic information (§500.1(k)). Zero Hunt runs its own models on the appliance, with no external AI service, so that data does not reach an outside AI provider that would itself become a third-party service provider to assess under §500.11. See on-premise AI red team.

• 23 NYCRR Part 500 as amended by the Second Amendment (NYDFS, PDF)
• Cybersecurity submissions: annual compliance notification, exemptions and incident notices (NYDFS)
• What is required: standard and Class A requirements (NYDFS)
• Cybersecurity FAQs (NYDFS)
• Industry letter of 21 May 2026: Heightened Cybersecurity Risks Associated with Frontier AI Models (NYDFS)
• Industry letter of 21 May 2026: Measures Regulated Entities Should Consider in a Heightened Cybersecurity Threat Environment (NYDFS)
• Industry letter of 10 September 2026: How to Conduct and Use Risk Assessments Required by the Cybersecurity Regulation (NYDFS)