NYDFS Penetration Testing Requirements (2026): 23 NYCRR 500.5, Annual Test and Evidence

Quick answer: Yes, the New York Department of Financial Services requires penetration testing, and it says so in plain words. Section 500.5(a)(1) of 23 NYCRR Part 500, as amended by the second amendment adopted 1 November 2023, requires each covered entity to conduct "penetration testing of their information systems from both inside and outside the information systems' boundaries by a qualified internal or external party at least annually." The frequency is annual. The scope is the covered entity's information systems, tested from both sides of the boundary. The tester may be internal or external, provided the party is qualified. That requirement carried a 180-day transitional period under 500.22(c), so it has been enforceable since 29 April 2024. A separate obligation at 500.5(a)(2) requires automated scans plus a manual review of systems those scans do not cover, at a frequency set by the risk assessment and promptly after any material system change; that provision had an 18-month transitional period and has been enforceable since 1 May 2025.

Every regulatory statement on this page was read from the Department's own adopted regulation text and its published assessment of public comments on 5 September 2026, and links back to that source. Where a claim could not be traced to a DFS document, it was dropped rather than softened. This page explains the rule; it is not legal advice, and a covered entity making a compliance determination should consult counsel.

What section 500.5 actually says

The second amendment retitled section 500.5 from "Penetration testing and vulnerability assessments" to "Vulnerability management", and rewrote it as a policies-and-procedures obligation with four operative limbs. The chapeau requires each covered entity, in accordance with its risk assessment, to "develop and implement written policies and procedures for vulnerability management that are designed to assess and maintain the effectiveness of its cybersecurity program." Those policies and procedures must be designed to ensure that covered entities:

(a) conduct, at a minimum:

> > (1) penetration testing of their information systems from both inside and outside the information systems' boundaries by a qualified internal or external party at least annually; and > > (2) automated scans of information systems, and a manual review of systems not covered by such scans, for the purpose of discovering, analyzing and reporting vulnerabilities at a frequency determined by the risk assessment, and promptly after any material system changes; > > (b) are promptly informed of new security vulnerabilities by having a monitoring process in place; and > > (c) timely remediate vulnerabilities, giving priority to vulnerabilities based on the risk they pose to the covered entity.

Four observations that matter more than they look.

The old rule was an either-or. The new rule is not. Before the second amendment, section 500.5 offered a choice: "continuous monitoring or periodic penetration testing and vulnerability assessments," with the annual and bi-annual obligations applying only in the absence of effective continuous monitoring. That structure is gone. The annual penetration test in 500.5(a)(1) and the scanning obligation in 500.5(a)(2) are now cumulative minimums, expressed as "conduct, at a minimum." A covered entity running excellent continuous monitoring still owes the annual test.

"Their information systems" is broad by design. Part 500 defines an information system at 500.1(i) as "a discrete set of electronic information resources organized for the collection, processing, maintenance, use, sharing, dissemination or disposition of electronic information, as well as any specialized system such as industrial/process controls systems, telephone switching and private branch exchange systems, and environmental control systems." The prior text scoped the annual test to systems "determined each given year based on relevant identified risks in accordance with the risk assessment." That qualifier was deleted. The risk assessment still shapes how the test is designed, but the rule no longer says the annual test covers a risk-selected subset.

"From both inside and outside" ends the external-only test. This is the clause most often missed in scoping calls. An external perimeter test alone does not satisfy 500.5(a)(1). The rule requires testing from inside the boundary too, which in practice means an internal network or assumed-breach component alongside the external work.

Vulnerability management is not the same obligation as penetration testing. DFS was asked to rename 500.5 back to "Vulnerability assessments" and refused, responding that "Section 500.5 contains requirements with respect to penetration testing, monitoring, and remediation, which are more accurately encompassed within the term vulnerability management" (Assessment of Public Comments, 1 November 2023). The heading is a container. Inside it, the annual test and the scanning cadence are separate requirements with separate deadlines.

How Part 500 defines penetration testing

Section 500.1(l) carries its own definition, and the second amendment changed it:

Penetration testing means testing the security of information systems by attempting to circumvent or defeat the security features of an information system by authorizing attempted penetration of databases or controls from outside or inside the covered entity's information systems.

The inserted word is "authorizing." DFS explained why in its comment assessment: a commenter asked the Department to broaden the definition "by specifying that the covered entity authorize the testing and explicitly adding a requirement that a covered entity conduct testing on databases and controls," and the Department responded that it was "clarifying this definition to provide that the covered entity authorize the penetration testing," while declining the second change "because the scope of a covered entity's penetration testing must be determined by its risk assessment."

Two practical consequences. First, written authorisation is part of the definition, not a nicety: your rules of engagement, signed by an officer with authority to grant it, are compliance evidence. Second, DFS itself locates scope decisions in the risk assessment, which is why the risk assessment at 500.9 is the document that has to justify what you excluded.

What 500.5(a)(2) means by "manual review"

Commenters asked DFS to drop the word "manual" from 500.5(a)(2), arguing that automation beyond scanners might be more appropriate. The Department's response is the clearest statement available on how to read the clause:

The requirement for a manual review requires human involvement to the extent automated scans cannot scan or reach systems that need scanning; it does not require a manual inspection. When automated scans cannot reach or do not cover particular systems, those systems must be manually reviewed with human involvement, and the individual performing such review may use any appropriate tools available to facilitate the manual review.

So the test is coverage, not technique. Wherever the scanner does not reach, a person must review, using whatever tooling helps. That is an asset-inventory problem before it is a testing problem, which is exactly why 500.13(a) requires a complete, accurate and documented asset inventory.

What "timely" remediation means

Commenters also asked DFS to strike "timely" from 500.5(c) as too subjective. The Department declined, and explained the standard:

Based on the Department's experience and the broader reporting and discussion relating to publicly reported cyberattacks, there is no doubt that vulnerabilities must be remediated in a "timely" manner. Nonetheless the amendment provides covered entities with flexibility by not defining a specific time frame within which vulnerabilities must be remediated. Accordingly, "timely" remediation should be assessed within the context of a number of factors, including the seriousness of the vulnerability, the work required to remediate the vulnerability, and the remediation cadence.

There is no NYDFS patch clock. What there is instead is an expectation that you have defined a cadence, applied severity to it, and can show the record.

Who is covered, and who is exempt from 500.5

Covered entity is defined at 500.1(e) as "any person operating under or required to operate under a license, registration, charter, certificate, permit, accreditation or similar authorization under the Banking Law, the Insurance Law or the Financial Services Law, regardless of whether the covered entity is also regulated by other government agencies." That sweeps in state-chartered banks and trust companies, licensed lenders and mortgage servicers, money transmitters, insurers and insurance producers, and virtual currency businesses licensed under the Financial Services Law. Federal regulation elsewhere does not displace it.

Class A company is defined at 500.1(d) as a covered entity with at least US$20,000,000 in gross annual revenue in each of the last two fiscal years from all business operations of the covered entity and the business operations in New York of its affiliates, and either "over 2,000 employees averaged over the last two fiscal years, including employees of both the covered entity and all of its affiliates no matter where located" or "over $1,000,000,000 in gross annual revenue in each of the last two fiscal years from all business operations of the covered entity and all of its affiliates no matter where located." When counting employees and revenue, affiliates count only where they "share information systems, cybersecurity resources or all or any part of a cybersecurity program with the covered entity."

Class A status does not change the penetration testing clause. Section 500.5 applies identically. What Class A status adds is a surrounding control set, and one of those additions is the reason Class A firms buy more testing than the rule strictly requires:

Note what 500.1(h) does and does not require of that Class A audit. "Independent audit means an audit conducted by internal or external auditors free to make decisions not influenced by the covered entity being audited or by its owners, managers or employees." Independence is about freedom from influence, not about being a third party. DFS made the same choice twice, once for auditors and once for penetration testers.

The limited exemption at 500.19(a)

Small covered entities are exempt from section 500.5 entirely. Section 500.19(a) exempts a covered entity with any one of: fewer than 20 employees and independent contractors of the covered entity and its affiliates; less than US$7,500,000 in gross annual revenue in each of the last three fiscal years from all business operations of the covered entity and the New York business operations of its affiliates; or less than US$15,000,000 in year-end total assets including affiliates, calculated under GAAP. An entity meeting one of those tests is exempt "from the requirements of sections 500.4, 500.5, 500.6, 500.8, 500.10, 500.14(a)(1), (a)(2), and (b), 500.15 and 500.16."

Two cautions before anyone files a notice of exemption. The thresholds were raised by the second amendment, from 10 employees, US$5,000,000 and US$10,000,000 respectively, so an entity that qualified under the original rule may not qualify now, or vice versa. And a limited exemption is not a full exemption: multi-factor authentication under 500.12, the risk assessment under 500.9, incident notice under 500.17(a) and third-party service provider policies under 500.11 all still apply.

Sections 500.19(c) and 500.19(d) provide narrower full exemptions from a longer list including 500.5, for a covered entity that operates no information systems and holds no nonpublic information, and for certain Insurance Law article 70 entities.

Cadence: what is due, and when it became due

The second amendment became effective 1 November 2023 under 500.21(b). Section 500.22 then set staged transitional periods. All of them have now expired, which means there is no remaining runway argument available to a covered entity in 2026.

Beyond the annual floor, three triggers should pull a test forward.

Material system change. The rule attaches "promptly after any material system changes" to the scanning obligation at 500.5(a)(2), not to the annual test. But the risk assessment at 500.9(a) must be "reviewed and updated as reasonably necessary, but at a minimum annually, and whenever a change in the business or technology causes a material change to the covered entity's cyber risk." A material change that moves your cyber risk changes what the annual test should cover, and re-testing after a major release is the cheapest way to show that link.

A new business line or acquisition. Affiliates that share information systems, cybersecurity resources or any part of the cybersecurity programme count toward Class A thresholds and expand the estate that 500.5(a)(1) covers.

The certification calendar. The notice of compliance under 500.17(b) is due electronically by 15 April each year and covers the prior calendar year. A test performed in March, with fixes still open in April, produces a harder certification conversation than a test performed in Q3 with a closed retest.

Scope: what "inside and outside the boundaries" means in a scoping call

Part 500 does not enumerate assets, so the scope statement is where compliance is either earned or lost. A defensible NYDFS scope normally has five components.

External perimeter. Internet-facing infrastructure, VPN and remote access endpoints, mail and DNS, and any exposed management interfaces. This is the "outside the boundaries" half, and it is the half most firms already buy.

Internal network. An assumed-breach or authenticated-position engagement inside the corporate estate: Active Directory or Entra ID, privileged access paths, lateral movement, and the segmentation between corporate and production. This is the "inside the boundaries" half that 500.5(a)(1) added, and it is where a Active Directory penetration test maps directly onto the 500.7(c) privileged access controls.

Customer-facing applications and their APIs. Online banking portals, policyholder and broker portals, payment initiation flows, and the machine-to-machine integrations behind them. Authorisation is the class that matters here, because a well-formed request returning another customer's record is a nonpublic information disclosure under 500.1(k) rather than a technical curiosity.

Cloud accounts. Identity and access configuration, storage exposure, and workload isolation in whichever platforms hold or process nonpublic information. Our guide to cloud penetration testing services covers how that scope is bounded against provider rules of engagement.

Documented exclusions. Anything carved out, with the reason and the compensating control, recorded in the scope statement and reflected in the risk assessment. Silent exclusions look like gaps in an examination. Reasoned exclusions look like a programme.

Third-party service providers sit slightly outside this. Section 500.11(a) requires written policies and procedures addressing minimum cybersecurity practices required of third-party service providers, based on the risk assessment. Testing a vendor's environment usually needs the vendor's authorisation, so the practical mechanism is contractual: name a testing cadence and a right to review results in the agreement, then collect what the contract entitles you to.

Who may perform the test: independence without a third-party mandate

This is the question that generates the most incorrect advice, so it is worth being precise. Section 500.5(a)(1) says the test must be conducted "by a qualified internal or external party." DFS wrote both options into the rule text. There is no requirement in Part 500 that a penetration test be performed by an external firm, and any statement that NYDFS mandates third-party testing is wrong on the text.

DFS made a parallel choice elsewhere and then went further. In the same amendment cycle the Department listed among its revisions "including audits conducted by internal auditors in the definition of 'independent audit'," and separately "removing the requirement for class A companies to use external experts to conduct a risk assessment at least once every three years in § 500.9." That external-expert triennial requirement appeared in a draft and was removed before adoption. It is not in the rule. Citations to it in 2026 are citations to a document that never took effect.

What the rule does require is that the party be qualified, and the Department gives supporting texture in section 500.10, which requires covered entities to "utilize qualified cybersecurity personnel of the covered entity, an affiliate or a third-party service provider sufficient to manage the covered entity's cybersecurity risks and to perform or oversee the performance of the core cybersecurity functions," to provide them with updates and training, and to "verify that key cybersecurity personnel take steps to maintain current knowledge of changing cybersecurity threats and countermeasures." Section 500.10(b) then confirms that a covered entity "may choose to utilize an affiliate or qualified third-party service provider to assist in complying with the requirements set forth in this Part."

So the honest position is this. An internal team can satisfy 500.5(a)(1) if you can evidence its qualification and its ability to test the systems it does not own. Most covered entities still buy externally for three reasons that have nothing to do with a mandate:

1. Independence is easier to demonstrate than to argue. Where the same team builds, runs and tests a system, an examiner or a Class A independent audit will probe the separation. An external report closes that question in a sentence.

2. Qualification evidence is portable. Named testers, certifications, firm-level accreditation and a stated methodology are simpler to file than an internal training record.

3. Capacity. The annual test now has to cover both sides of the boundary. Internal teams that comfortably ran an external assessment often do not have the Active Directory or cloud depth to run the inside half at the same quality.

A defensible middle path exists and is common: internal team owns the continuous scanning and manual review obligations in 500.5(a)(2), an external firm owns the annual 500.5(a)(1) test, and both feed the same remediation record.

The evidence a DFS examiner asks for

The regulation is unusually explicit about records. Section 500.17(b)(3) requires each covered entity to "maintain for examination and inspection by the department upon request all records, schedules and other documentation and data supporting the certification or acknowledgment for a period of five years," and it names what must be inside that set: "the identification of all areas, systems and processes that require or required material improvement, updating or redesign, all remedial efforts undertaken to address such areas, systems and processes, and remediation plans and timelines for their implementation."

Read that clause carefully and the shape of the evidence package falls out. It is not a report. It is a report plus the story of what you did about it.

1. The scope statement, naming systems, applications, URLs, IP ranges, cloud accounts and roles in scope, and naming what was excluded and why. This is what shows an examiner that "their information systems" was addressed rather than sampled.

2. The written authorisation, which the 500.1(l) definition now expressly contemplates, signed by someone with authority to grant it.

3. The rules of engagement, including testing windows, escalation contacts and any production constraints.

4. The tester's qualifications, whether internal or external: names, certifications, methodology, and the split between automated and manual effort.

5. The full technical report, with reproduction steps, affected assets, severity ratings and a stated rating methodology. Severity without a methodology is not auditable. Our worked example of what that looks like is the penetration testing report sample, and the companion piece on how to evaluate a penetration test report covers what separates a usable report from a scanner export.

6. Evidence of both halves of the boundary. Keep the internal and external components identifiable in the report structure. An examiner reading a single "network test" section cannot tell which side it was run from.

7. The remediation record, with owners, dates, decisions and accepted risks with written rationale. This is the "all remedial efforts undertaken" language, verbatim.

8. The remediation plan and timeline for anything still open, which is the clause most often missing.

9. The retest report confirming closure. An unretested fix is an assertion, and it is the difference between "remedial efforts undertaken" and "remedial efforts planned."

10. The link into the risk assessment at 500.9, showing how findings changed the assessment and therefore the controls. DFS put scope determination inside the risk assessment; this is the document that closes the loop.

11. The CISO written report under 500.4(b), which must cover, among other things, "overall effectiveness of the covered entity's cybersecurity program" and "plans for remediating material inadequacies." Test results are the natural input.

Keep all of it for five years, not one. And note the enforcement framing in 500.20(b): "the commission of a single act prohibited by this Part or the failure to act to satisfy an obligation required by this Part shall constitute a violation," including "the material failure to comply for any 24-hour period with any section of this Part." Among the mitigation factors the superintendent must consider under 500.20(c) is "the extent to which the relevant policies and procedures of the company are consistent with nationally recognized cybersecurity frameworks, such as NIST." Documentation quality is a penalty factor, not just an audit convenience.

How NYDFS 500.5 maps to SOC 2, ISO 27001 and PCI DSS

Most covered entities are running Part 500 alongside at least one customer-facing framework. The obligations overlap enough that one well-scoped engagement can feed several evidence sets, provided the report is structured for it.

The practical takeaway is that NYDFS and PCI DSS are the two regimes that name the test and set the clock, and NYDFS is stricter on one axis: PCI DSS bounds scope to the cardholder data environment, while 500.5(a)(1) says "their information systems." Build the engagement to the NYDFS scope and the narrower frameworks are covered inside it. Our guide to the pentest evidence auditors accept across SOC 2, ISO 27001, PCI DSS and CMMC sets out the shared package.

What the tests actually find

A cadence argument is easier to have with data. Stingrai's State of Penetration Testing 2026 analysed 1,206 verified findings from 55 penetration tests, and four of its numbers speak directly to the Part 500 obligations.

92.7% of tests surfaced at least one High or Critical finding. That is the figure to put next to a risk assessment that concluded the estate was low risk without anyone attacking it. A written assessment that has never been tested is an opinion about vulnerability, not a measurement of it, and 500.9(a) asks for an assessment "sufficient to inform the design of the cybersecurity program."

The false positive rate across the dataset was 0.74%. Evidence quality is what an examiner or a Class A independent audit is judging. A report padded with unvalidated scanner output degrades the credibility of the findings that matter, and it is exactly what 500.5(a)(2) already covers separately.

The median Critical took 10.5 days to fix. Section 500.5(c) requires timely, risk-prioritised remediation without naming a clock. A documented median gives you something to defend, and a defined cadence is precisely what DFS said "timely" would be assessed against.

Authorisation and authentication failures concentrate in web application testing. Those are the findings that turn into nonpublic information exposure under 500.1(k), and they are the class automated scanning is worst at, because the request is well formed and the response is a valid 200. Only a tester who knows which record belongs to which customer can tell that it should not have been returned. Our analysis of why API scanners miss BOLA and IDOR goes into the mechanics.

What a NYDFS-driven penetration test costs

There is no NYDFS rate card, and any figure presented as one is invented. What can be said honestly is which variables move the number.

Boundary count. The single biggest driver, because 500.5(a)(1) requires both sides. A covered entity buying only an external test is buying roughly half the engagement the rule describes, and the internal half is usually the larger one for a firm with an Active Directory estate.

Role and tenancy complexity on applications. Authorisation testing scales with role pairs, not page count. A broker portal with customer, broker, agency administrator, operations and support roles has an authorisation matrix several times larger than a single-role product.

Cloud account count. Each platform and each production account adds configuration review time.

Retesting. The line most often left out of a comparison. Section 500.17(b)(3) asks for the remedial efforts undertaken, and a quote that excludes retesting is not comparable to one that includes it.

Testing windows. Financial services production constraints push work to nights and weekends and add days.

Our penetration testing cost guide for 2026 breaks the pricing structures down by engagement type, and the pentest cost calculator gives a scoped estimate from asset counts rather than a guess. For published day-rate benchmarks, the Penetration Testing Price Index 2026 collects rate cards rather than quotes.

Stingrai publishes fixed package prices rather than a metered rate. The pricing page lists an Autonomous Pentest from US$3,000 one-time driven by Snipe, and a Hybrid Pentest at US$6,800 one-time where certified penetration testers work alongside Snipe throughout the engagement, both covering one web application and its APIs. The same two tiers run continuously at US$450 and US$1,275 per month on a 12-month engagement. A full Part 500 scope covering internal network, external perimeter, applications and cloud is quoted rather than listed, through Get a Quote.

What Stingrai delivers against a Part 500 scope

Stingrai is a CREST-accredited penetration testing service provider at the firm level, holds 18 published CVEs across the team, and is rated 5.0 out of 5.0 across 19 Clutch reviews. Team certifications include OSCE3, OSCP, OSWE, OSED, OSEP, CREST CRT, CISSP, CRTO, GCPN, CRTE and eWPTX, which is the qualification evidence 500.5(a)(1) asks you to be able to produce for the party performing the test. Stingrai's penetration testing supports Part 500 programmes, along with SOC 2, ISO 27001, PCI DSS 4.0, NIST SP 800-53 and 800-171, DORA and NIS2, by producing the technical evidence those programmes consume.

The engagement model fits the two halves of 500.5 directly.

Annual or continuous, both available. A covered entity can buy a one-time annual test against the 500.5(a)(1) floor, or run continuous testing across the year so that the annual evidence and the material-change trigger are covered by the same programme. Both are published offerings; neither is the only option. Our explainer on continuous PTaaS sets out where each model fits.

Certified penetration testers and Snipe work concurrently. Snipe is Stingrai's autonomous AI agent for web application penetration testing, custom-trained on more than 6,000 HackerOne Hacktivity disclosure reports and on methodology distilled from Stingrai's own penetration testers. It hunts the complex classes that generic scanners miss, including IDOR, business logic flaws and broken authorisation, performs both black-box dynamic testing and white-box source review, generates AutoFix pull requests, and can run as a pull-request gating check. Stingrai's penetration testers test at the same time throughout the engagement, direct Snipe's focus, extend its attack paths and pursue what it surfaces. Both contribute findings across all severities.

Retest included. The retest is what converts "remedial efforts planned" into "remedial efforts undertaken" in the 500.17(b)(3) record.

Guarantee. On the Autonomous tier, "No High or Critical Finding = Don't Pay." That guarantee applies to the Autonomous tier only; other tiers and scopes are quoted through Get a Quote.

What this means for covered entities

• Buy both sides of the boundary. An external-only test does not satisfy 500.5(a)(1) as written. If your current engagement has no internal component, that is the gap to close before April.

• Stop treating the scanning obligation as the test. 500.5(a)(2) and 500.5(a)(1) are separate limbs with separate deadlines. Continuous scanning does not discharge the annual test, and the annual test does not discharge the scanning cadence.

• Write down why anything was excluded. DFS puts scope determination inside the risk assessment. An exclusion with a documented reason is a programme decision; an exclusion with no record is an examination finding.

• Keep the whole evidence package for five years. Scope, authorisation, report, remediation record, remediation plan and timeline, retest. Section 500.17(b)(3) names most of those explicitly.

• Do not pay for a third-party mandate that does not exist. Buy externally because independence and depth are worth it, not because someone told you the rule requires it. And do not cite the Class A triennial external risk assessment; DFS removed it before adoption.

Frequently Asked Questions

Does NYDFS require penetration testing?

Yes. Section 500.5(a)(1) of 23 NYCRR Part 500 requires each covered entity to conduct "penetration testing of their information systems from both inside and outside the information systems' boundaries by a qualified internal or external party at least annually." Unlike most financial-services rules, NYDFS names the activity, sets the frequency and sets the scope in the same sentence. The requirement has been enforceable since 29 April 2024, which is 180 days after the second amendment took effect on 1 November 2023.

How often does 23 NYCRR 500.5 require a penetration test?

At least annually, as a minimum floor. The rule text reads "conduct, at a minimum: (1) penetration testing ... at least annually." Separately, 500.5(a)(2) requires automated scans plus a manual review of systems those scans do not cover "at a frequency determined by the risk assessment, and promptly after any material system changes," so the scanning cadence is risk-driven and change-driven while the penetration test has a fixed annual floor.

Does NYDFS require a third-party penetration test?

No. The rule permits "a qualified internal or external party." There is no third-party mandate in Part 500, and the same amendment that added the annual test also expanded the definition of "independent audit" at 500.1(h) to include audits "conducted by internal or external auditors free to make decisions not influenced by the covered entity being audited." What the rule requires is qualification and, in the Class A audit context, freedom from influence. Most covered entities still buy externally because independence and depth are simpler to evidence, not because the regulation compels it.

What does "from both inside and outside the information systems' boundaries" mean?

It means an external-only engagement does not satisfy the clause. The annual test must include work from outside the boundary, which is the internet-facing perimeter, and work from inside it, which in practice is an internal network or assumed-breach component covering directory services, privileged access paths, lateral movement and segmentation. Keep the two components identifiable in the report so an examiner can see both were performed.

Which entities are exempt from section 500.5?

Section 500.19(a) grants a limited exemption from 500.5 (among other sections) to a covered entity with fewer than 20 employees and independent contractors including affiliates, or less than US$7,500,000 in gross annual revenue in each of the last three fiscal years, or less than US$15,000,000 in year-end total assets under GAAP. Sections 500.19(c) and 500.19(d) provide broader exemptions for entities that operate no information systems and hold no nonpublic information, and for certain Insurance Law article 70 entities. A limited exemption still leaves multi-factor authentication, the risk assessment, incident notice and third-party service provider policies in force.

What is a Class A company under Part 500, and does it need more testing?

Section 500.1(d) defines a Class A company as a covered entity with at least US$20,000,000 in gross annual revenue in each of the last two fiscal years from its own operations and its affiliates' New York operations, and either over 2,000 employees averaged over the last two fiscal years including affiliates worldwide, or over US$1,000,000,000 in gross annual revenue in each of the last two fiscal years including affiliates worldwide. Class A status does not change section 500.5. It adds independent audits under 500.2(c), privileged access management and commonly-used-password blocking under 500.7(c), and endpoint detection and response plus centralised logging under 500.14(b). Those additions make penetration testing evidence more consequential, because the independent audit consumes it.

Do Class A companies have to use external experts for the risk assessment every three years?

No. That requirement appeared in a draft of the second amendment and DFS removed it before adoption. In its published assessment of public comments the Department lists among the changes made "removing the requirement for class A companies to use external experts to conduct a risk assessment at least once every three years in § 500.9." The adopted 500.9(a) requires a periodic risk assessment reviewed and updated "at a minimum annually, and whenever a change in the business or technology causes a material change to the covered entity's cyber risk," with no external-expert clause and no triennial clock.

What penetration testing evidence does a DFS examiner ask for?

Section 500.17(b)(3) requires five years of "all records, schedules and other documentation and data supporting the certification or acknowledgment," expressly including "the identification of all areas, systems and processes that require or required material improvement, updating or redesign, all remedial efforts undertaken to address such areas, systems and processes, and remediation plans and timelines for their implementation." In practice that means the scope statement, the written authorisation, the rules of engagement, tester qualifications, the full technical report with severities and a stated rating methodology, the remediation record with owners and dates, the remediation plan for anything open, and the retest report. A report on its own is not the evidence package.

Does a vulnerability scan satisfy the NYDFS penetration testing requirement?

No, and the rule separates them deliberately. Automated scanning sits in 500.5(a)(2), penetration testing sits in 500.5(a)(1), and the second amendment removed the old either-or structure so that both are minimums. DFS also clarified that the manual review in 500.5(a)(2) "requires human involvement to the extent automated scans cannot scan or reach systems that need scanning," which is a coverage requirement rather than a substitute for testing. A scan enumerates known-signature weaknesses; it does not test whether one authenticated customer can retrieve another customer's records.

How does NYDFS Part 500 compare to PCI DSS on penetration testing?

Both name the test and set an annual clock, and both require internal and external coverage. The difference is scope boundary. PCI DSS Requirement 11.4 bounds testing to the cardholder data environment and its segmentation, while 500.5(a)(1) says "their information systems" with no equivalent narrowing. A covered entity that also takes card payments will usually find the PCI scope sits inside the NYDFS scope rather than beside it. Our PCI DSS penetration testing guide sets out Requirement 11.4 in detail.

Where can I read the actual rule?

Read the adopted text of the second amendment on the DFS site: 23 NYCRR Part 500, second amendment adopted 1 November 2023. Read alongside it the Assessment of Public Comments on the Revised Proposed Second Amendment, which is where DFS explains what it changed and why. The Department's Cybersecurity Resource Center carries filing portals and current guidance.

Related Reading

• PCI DSS Penetration Testing: Requirement 11.4 Explained (2026)

• SOC 2 Penetration Testing: What Auditors Expect and How to Scope It (2026)

• HIPAA Penetration Testing Requirements (2026)

• Pentest Evidence Auditors Accept: SOC 2, ISO 27001, PCI DSS and CMMC (2026)

• Penetration Testing Report Sample (2026)

• DORA Threat-Led Penetration Testing (2026)

• Best Fintech Penetration Testing Companies (2026)

• The State of Penetration Testing 2026

References

1. New York State Department of Financial Services. Second Amendment to 23 NYCRR Part 500, Cybersecurity Requirements for Financial Services Companies, adopted text. Effective 1 November 2023. https://www.dfs.ny.gov/system/files/documents/2023/10/rf_fs_2amend23NYCRR500_text_20231101.pdf. The adopted amendment text in redline form. Source of every quotation on this page from sections 500.1, 500.2, 500.4, 500.5, 500.7, 500.9, 500.10, 500.13, 500.14, 500.17, 500.19, 500.20, 500.21 and 500.22.

2. New York State Department of Financial Services. Assessment of Public Comments on the Revised Proposed Second Amendment to 23 NYCRR Part 500. 1 November 2023. https://www.dfs.ny.gov/system/files/documents/2023/10/rf_fs_2amend23NYCRR500_apc_20231101.pdf. The Department's own responses to industry comments, including its explanation of the manual review requirement in 500.5(a)(2), the meaning of timely remediation in 500.5(c), the addition of "authorizing" to the 500.1 definition of penetration testing, the change to the Class A audit frequency in 500.2(c), and the removal of the proposed external-expert triennial risk assessment requirement.

3. New York State Department of Financial Services. Cybersecurity Resource Center. https://www.dfs.ny.gov/industry_guidance/cybersecurity. The Department's landing page for Part 500, filing portals and current guidance, which records that "On March 1, 2017, DFS promulgated its first-in-the-nation cybersecurity regulation, 23 NYCRR Part 500."

4. Stingrai. The State of Penetration Testing 2026. https://www.stingrai.io/blog/state-of-penetration-testing-2026. 1,206 verified findings across 55 penetration tests, severity mix, false positive rate and remediation timing.

5. Stingrai. Penetration Testing Cost 2026. https://www.stingrai.io/blog/penetration-testing-cost-2026. Pricing structures by engagement type and the variables that move a quote.

6. Stingrai. Penetration Testing Price Index 2026. https://www.stingrai.io/blog/penetration-testing-price-index-2026. Published day rates collected from public rate cards.

7. Stingrai. Penetration Testing Report Sample 2026. https://www.stingrai.io/blog/penetration-testing-report-sample-2026. A worked example of the report structure an examiner or auditor can consume.

8. Stingrai. Pentest Evidence Auditors Accept: SOC 2, ISO 27001, PCI DSS and CMMC. https://www.stingrai.io/blog/pentest-evidence-auditors-accept-soc2-iso27001-pci-cmmc. The shared evidence package across frameworks.

9. Stingrai. PCI DSS Penetration Testing 2026. https://www.stingrai.io/blog/pci-dss-penetration-testing-2026. Requirement 11.4 scope, methodology and segmentation testing.

10. Stingrai. Pricing. https://www.stingrai.io/pricing. Published one-time and continuous package prices for one web application and its APIs.

Ready to scope a Part 500 penetration test?

Section 500.5(a)(1) is specific in a way most regulations are not: annual, both sides of the boundary, qualified tester, and five years of supporting records under 500.17(b)(3). Stingrai is a CREST-accredited penetration testing service provider whose penetration testing supports Part 500 programmes by producing the scope statement, technical report, remediation record and retest evidence those programmes consume, as a one-time annual engagement or as continuous coverage across the year. Certified penetration testers work alongside Snipe, our autonomous AI agent for web application penetration testing, throughout the engagement, hunting the broken authorization and business logic flaws that put one customer's nonpublic information on another customer's screen. Book a free scoping call, get a quote for a full internal, external, application and cloud scope, or read the published package prices on the pricing page.