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

Quick answer: 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, and the tester may be internal or external provided the party is qualified. 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 risk-assessment-driven frequency and promptly after any material system change; it has been enforceable since 1 May 2025. This page is written for the firms carrying the heaviest version of that obligation: mid-market and enterprise banks, insurers, mortgage and crypto firms, their Class A affiliates, and the third-party service providers inside their supply chain.

Every regulatory statement here was read from the Department's adopted regulation text and its published assessment of public comments, and links back to that source. It explains the rule; it is not legal advice.

Who Part 500 covers in the mid-market and enterprise

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." That sweeps in state-chartered banks and trust companies, licensed lenders and mortgage servicers, money transmitters, insurers and producers, and virtual currency businesses, and federal regulation elsewhere does not displace it. The licence, not the headquarters, creates the obligation, so a regional insurer writing New York business is in scope on the same terms as a Manhattan bank.

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 its own operations and its affiliates' New York operations, and either over 2,000 employees or over US$1,000,000,000 in gross annual revenue on the same two-year basis, counting affiliates worldwide. Affiliates count only where they "share information systems, cybersecurity resources or all or any part of a cybersecurity program with the covered entity," which makes shared-services architecture a compliance decision as much as an IT one.

Class A status does not change section 500.5. What it adds is a surrounding control set, and that is why Class A firms buy more testing than the rule strictly requires:

Note what 500.1(h) requires of that audit: auditors "free to make decisions not influenced by the covered entity being audited or by its owners, managers or employees." Independence is freedom from influence, not third-party status. DFS made the same choice twice, once for auditors and once for penetration testers.

Third-party service providers inside a covered entity's supply chain

Section 500.11(a) requires written policies and procedures addressing minimum cybersecurity practices required of third-party service providers. The obligation sits on the covered entity, but the weight lands on the vendor: core banking platforms, claims processors, loan origination systems and payment orchestrators are all asked for testing evidence. Testing a vendor's environment needs the vendor's authorisation, so the mechanism is contractual: name a testing cadence and a right to review results in the agreement, then collect what the contract entitles you to. Vendors selling into New York financial services should expect the annual report, the remediation record and the retest to be diligence artefacts, not marketing collateral.

Canadian firms with New York licences, and the OSFI B-13 overlap

Canadian banks, insurers and asset managers holding a New York licence or operating a New York branch carry both regimes at once, and the two differ in specificity rather than conflict. OSFI's Guideline B-13 expects intelligence-led testing proportionate to risk but names no numeric cadence, while 500.5(a)(1) names the activity, the annual clock and the both-sides-of-the-boundary scope. A single engagement designed to the NYDFS specification therefore produces evidence a Canadian supervisor will accept for B-13, with B-13's threat-led framing raising the bar on scenario design rather than on paperwork. Our guide to OSFI B-13 and penetration testing sets out where the often-cited three-year figure actually comes from.

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 including affiliates; 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. The thresholds were raised by the second amendment from 10 employees, US$5,000,000 and US$10,000,000, so an entity that qualified under the original rule may not qualify now, or vice versa. A limited exemption is also 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.

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. Each covered entity must, in accordance with its risk assessment, maintain written vulnerability management policies and procedures 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 between "continuous monitoring or periodic penetration testing and vulnerability assessments." That structure is gone. The annual test and the scanning obligation 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. 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, and 500.1(i) defines an information system broadly. 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. An external perimeter test alone does not satisfy 500.5(a)(1). The rule requires testing from inside the boundary too, which means an internal network or assumed-breach component alongside the external work.

Vulnerability management is not the same obligation as penetration testing. Asked to rename 500.5 back to "Vulnerability assessments," DFS refused, responding that the section "contains requirements with respect to penetration testing, monitoring, and remediation, which are more accurately encompassed within the term vulnerability management" (Assessment of Public Comments). 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) defines penetration testing as "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 in the second amendment is "authorizing." DFS said it was "clarifying this definition to provide that the covered entity authorize the penetration testing," while declining to mandate database and control testing "because the scope of a covered entity's penetration testing must be determined by its risk assessment." Two consequences follow. Written authorisation is part of the definition, not a nicety: rules of engagement signed by an officer with authority to grant them are compliance evidence. And DFS itself locates scope decisions in the risk assessment, which is why the risk assessment at 500.9 has to justify what you excluded.

Manual review and timely remediation, as DFS explains them

Asked to drop the word "manual" from 500.5(a)(2), DFS said the requirement "requires human involvement to the extent automated scans cannot scan or reach systems that need scanning; it does not require a manual inspection," and that the reviewer "may use any appropriate tools available." The test is coverage, not technique: wherever the scanner does not reach, a person must review. That is an asset-inventory problem before it is a testing problem, which is why 500.13(a) requires a documented asset inventory.

Asked to strike "timely" from 500.5(c) as too subjective, DFS declined and said 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, only an expectation that you have defined a cadence, applied severity to it, and can show the record.

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 which have now expired. There is no remaining runway argument available in 2026.

Three triggers should pull a test forward of the annual floor. Material system change: 500.9(a) requires the risk assessment to be updated "whenever a change in the business or technology causes a material change to the covered entity's cyber risk," which changes what the annual test should cover. A new business line or acquisition expands the estate 500.5(a)(1) covers and can move Class A thresholds. The certification calendar: the notice of compliance under 500.17(b) is due by 15 April for the prior calendar year, so a March test with fixes still open in April produces a harder conversation than a Q3 test 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 exposed management interfaces. This is the "outside the boundaries" half, and 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, where an 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 integrations behind them. Authorisation is the class that matters, 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 nonpublic information. Our ranking of cloud penetration testing companies for AWS and SOC 2 covers who delivers that scope.

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.

Multi-entity groups add a sixth decision. Where a holding company runs several licensed subsidiaries on shared infrastructure, decide up front whether the annual test is one engagement covering the shared estate with entity-specific application scopes attached, or separate engagements per licence. Either is defensible. A group test whose report cannot be mapped back to each covered entity's own certification is not.

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

Section 500.5(a)(1) says the test must be conducted "by a qualified internal or external party." 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 went further in the same cycle, listing among its revisions "including audits conducted by internal auditors in the definition of 'independent audit'," and "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 triennial requirement appeared in a draft and was removed before adoption, so citations to it in 2026 are citations to a document that never took effect.

What the rule requires instead is that the party be qualified, which section 500.10 frames as "qualified cybersecurity personnel of the covered entity, an affiliate or a third-party service provider sufficient to manage the covered entity's cybersecurity risks." An internal team can satisfy 500.5(a)(1) if you can evidence its qualification and its ability to test systems it does not own. Most mid-market and enterprise covered entities still buy externally for reasons unconnected to any mandate: independence is easier to demonstrate than to argue, qualification evidence is portable in a way an internal training record is not, and internal teams that comfortably ran an external assessment often lack the Active Directory or cloud depth for the inside half. A common middle path is that the internal team owns 500.5(a)(2), an external firm owns the annual test, and both feed the same remediation record.

The evidence a DFS examiner asks for

Section 500.17(b)(3) requires each covered entity to maintain for five years "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." The evidence package 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 what was excluded and why. This shows an examiner that "their information systems" was addressed rather than sampled.

2. The written authorisation, which the 500.1(l) definition expressly contemplates, signed by someone with authority to grant it, with the rules of engagement, testing windows and escalation contacts.

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

4. The full technical report, with reproduction steps, affected assets, severity ratings and a stated rating methodology, since severity without a methodology is not auditable. Our worked example is the penetration testing report sample, and how to evaluate a penetration test report covers what separates a usable report from a scanner export.

5. Evidence of both halves of the boundary, kept identifiable in the report structure. An examiner reading a single "network test" section cannot tell which side it was run from.

6. The remediation record, with owners, dates, decisions and accepted risks with written rationale. That is the "all remedial efforts undertaken" language, verbatim, and the remediation plan and timeline for anything still open, the clause most often missing.

7. The retest report confirming closure. An unretested fix is the difference between "remedial efforts undertaken" and "remedial efforts planned."

8. The link into the risk assessment at 500.9 and into the CISO written report under 500.4(b), which must cover "overall effectiveness of the covered entity's cybersecurity program" and "plans for remediating material inadequacies." At enterprise scale that report is the artefact the board actually reads.

Keep all of it for five years, not one. Note also the enforcement framing in 500.20(b), under which "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." Among the mitigation factors under 500.20(c) is consistency with "nationally recognized cybersecurity frameworks, such as NIST." Documentation quality is a penalty factor, not just an audit convenience.

What a mid-market or enterprise NYDFS buyer needs from a vendor

A startup buying its first pentest is buying a report. A mid-market or enterprise covered entity is buying an input to the annual certification under 500.17, to a Class A independent audit under 500.2(c), to a board paper, and to a vendor file its own customers will diligence.

500.5 evidence built for 500.17, not retrofitted. Ask the vendor to show the artefacts listed above as standard deliverables rather than upgrades: scope statement, signed authorisation, tester qualifications, severity methodology, remediation record, remediation plan and an included retest. A firm that treats the retest as a change order is selling you half the 500.17(b)(3) record, and that is the most common gap between a quote that looks cheap and an evidence package that is complete.

Both sides of the boundary in one engagement. Vendors who deliver only external work leave the harder half to somebody else, and the seams show in the certification file.

Class A control verification. If you are Class A, design the test to exercise what 500.7(c) and 500.14(b) require: privileged access paths, commonly-used-password blocking, endpoint detection of lateral movement, and whether the centralised logging stack captured the engagement. Ask for a detection timeline alongside the findings. That single artefact turns a compliance test into audit-grade control validation.

Board-ready reporting. Section 500.4(b) puts a written CISO report in front of the governing body, so the vendor should produce an executive summary a risk committee can read without translation, with severity distribution, business impact and a remediation timeline, on top of the technical detail engineers need.

Named, certified penetration testers. "Qualified" is the operative word in the rule, and the cheapest way to evidence it is a named team with firm-level accreditation and individual certifications attached to the engagement.

A portal, not an email thread. Findings belong in a system that integrates with Jira or GitHub, tracks status and owner, exposes an auditable history, and lets each entity or business unit see its own slice. Emailed PDFs do not survive a five-year retention requirement in usable form.

Procurement and TPRM fit. Expect to exchange security questionnaire responses, insurance and subcontracting positions, data handling and residency terms for findings, and background-check confirmations, and to find out whether the vendor can sign your standard financial-services terms without a three-month legal cycle. A vendor who has never been through a bank's third-party risk process will cost you a quarter.

Multi-entity scoping. Groups with several licensed subsidiaries need one master agreement covering multiple entities and scopes, with reporting that maps to each entity's certification. Ask before the first engagement, not at renewal.

Annual and continuous, both on the table. Some programmes are best served by a one-time annual engagement against 500.5(a)(1); firms shipping continuously are often better served by continuous testing that covers the annual evidence and the material-change trigger in one programme. A vendor selling only one model is fitting the rule to its business. Our explainer on continuous PTaaS sets out where each fits, and our ranking of penetration testing companies for SOC 2 covers vendors judged on evidence quality rather than tooling.

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

Most covered entities run Part 500 alongside at least one customer-facing framework, and one well-scoped engagement can feed several evidence sets if the report is structured for it.

ISO/IEC 27001:2022 does not name penetration testing as a clause requirement; Annex A 8.8 and 8.29 are where it lands, with results traced into the risk treatment plan and the Statement of Applicability. The HIPAA Security Rule in force names no testing requirement, though a 2025 proposal would add a 12-month cycle, as our HIPAA guide explains.

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 to the NYDFS scope and the narrower frameworks sit inside it. Our guide to the pentest evidence auditors accept across SOC 2, ISO 27001, PCI DSS and CMMC sets out the shared package, and our ranking of US penetration testing companies covers the firms that deliver against it.

Stingrai's State of Penetration Testing 2026, covering 1,206 verified findings from 55 penetration tests, gives three numbers worth carrying into a Part 500 conversation: 92.7% of tests surfaced at least one High or Critical finding, the false positive rate was 0.74%, and the median Critical took 10.5 days to fix, which is a defensible number against the "timely" standard in 500.5(c). Authorisation failures concentrate in web application testing, the class automated scanning is worst at, because the request is well formed and the response is a valid 200. Our analysis of why API scanners miss BOLA and IDOR covers the mechanics.

What a NYDFS-driven penetration test costs

There is no NYDFS rate card. What can be published is the market band for each scope component a Part 500 engagement contains, drawn from Stingrai's penetration testing cost guide, the Canadian figures in our ranking of Canadian penetration testing companies, and the Penetration Testing Price Index 2026, which reports a median of US$1,364 per consultant day across 30 published rate cards.

Five variables move a Part 500 quote. Boundary count is the biggest, because a covered entity buying only an external test is buying roughly half the engagement the rule describes. Role complexity scales authorisation testing with role pairs rather than page count. Cloud account count adds configuration review time per platform. Retesting is the line most often left out, and a quote that excludes it is not comparable to one that includes it. Testing windows push financial services production work to nights and weekends. Our guide on how to compare penetration testing quotes converts any proposal back into tester-days, and the pentest cost calculator gives a scoped estimate from asset counts.

Stingrai publishes fixed package prices rather than a metered rate. The pricing page lists an Autonomous Pentest at 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, both covering one web application and associated APIs, with the same two tiers running continuously at US$650 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 through Get a Quote.

What Stingrai delivers against a Part 500 scope

Stingrai is a global CREST-accredited penetration testing services company founded in Toronto, Canada in 2021, trusted by companies from startups to enterprises to meet audit requirements for SOC 2, ISO 27001, CMMC, PCI DSS and HIPAA. OSCE³, OSWE, OSEP, CREST CRT certified pentesters, who are also world-class security researchers and bug bounty hunters. Choose from fully human-led or hybrid (AI agents plus human penetration testers) engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements, delivered through its PTaaS platform. Team certifications include OSCE3, OSCP, OSWE, OSED, OSEP, CREST CRT, CISSP, CRTO, CRTE and eWPTX, which is the qualification evidence 500.5(a)(1) asks you to produce. 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.

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 so the annual evidence and the material-change trigger sit in one programme. Both are published offerings.

Certified penetration testers and Snipe work concurrently. Snipe is Stingrai's AI agent for web application penetration testing, including the application's APIs, available for autonomous web testing or alongside penetration testers in a Hybrid web engagement. It hunts the complex classes generic scanners miss, including IDOR, business logic flaws and broken authorisation, performs 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 and pursue what it surfaces, and both contribute findings across all severities. Internal network, external perimeter and cloud scopes are delivered by the penetration testing team.

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

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 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, and neither discharges the other.

• Buy the evidence package, not the report. Scope, authorisation, tester qualifications, report, remediation record, remediation plan and retest, kept five years under 500.17(b)(3).

• Write down why anything was excluded. An exclusion with a documented reason is a programme decision; an exclusion with no record is an examination finding.

• Design the test to prove Class A controls. If 500.7(c) and 500.14(b) apply, ask for a detection timeline alongside the findings.

• Do not pay for a third-party mandate that does not exist. Buy externally because independence and depth are worth it, not because the rule compels it.

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, the frequency and the scope in one sentence. The requirement has been enforceable since 29 April 2024, 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 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.

How much does a NYDFS penetration test cost?

There is no NYDFS rate card. Market bands for the scope components a Part 500 engagement contains run US$5,000 to US$30,000 for a single customer-facing web application and its APIs, US$5,000 to US$40,000 for external perimeter and internal network work, and US$10,000 to US$50,000 for cloud accounts. Canadian equivalents run C$5,000 to C$12,000 for a small web application, C$15,000 to C$35,000 for network, and C$40,000 to C$120,000 for an annual continuous programme. Stingrai publishes fixed package prices on its pricing page, at US$3,000 one-time for an Autonomous Pentest of one web application and associated APIs, with a full Part 500 scope quoted.

What should a mid-market or enterprise covered entity look for in a penetration testing vendor?

Evidence fit first. The vendor should deliver the 500.17(b)(3) artefacts as standard: scope statement, written authorisation, named tester qualifications, a severity methodology, the remediation record, a remediation plan for anything open, and an included retest. Then look for both sides of the boundary in one engagement, a detection timeline that validates Class A controls under 500.7(c) and 500.14(b), board-ready reporting for the 500.4(b) CISO report, a findings portal that integrates with Jira or GitHub, a third-party risk posture that survives procurement, one agreement covering multiple licensed entities, and both annual and continuous cadences on the table.

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 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.

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," "all remedial efforts undertaken," 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.

Related reading

• Best Penetration Testing Companies for SOC 2 (2026)

• Best Cloud Penetration Testing Companies for AWS and SOC 2 (2026)

• Best Fintech Penetration Testing Companies (2026)

• Best Penetration Testing Companies in the USA (2026)

• OSFI B-13 and Penetration Testing (2026)

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

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

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

• Penetration Testing Report Sample (2026)

• Insurance Penetration Testing Requirements (2026)

• 10 NYCRR 405.46 Penetration Testing Requirements (2026)

References

1. New York State Department of Financial Services. Second Amendment to 23 NYCRR Part 500, adopted text. Effective 1 November 2023. https://www.dfs.ny.gov/system/files/documents/2023/10/rf_fs_2amend23NYCRR500_text_20231101.pdf. Source of every rule quotation on this page.

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. Source of the Department's explanations of manual review, timely remediation, the "authorizing" clarification, and the removal of the proposed external-expert triennial risk assessment.

3. New York State Department of Financial Services. Cybersecurity Resource Center. https://www.dfs.ny.gov/industry_guidance/cybersecurity. Filing portals and current guidance.

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.

5. Stingrai. Penetration Testing Cost 2026. https://www.stingrai.io/blog/penetration-testing-cost-2026. US dollar bands by engagement type.

6. Stingrai. Top Penetration Testing Companies in Canada 2026. https://www.stingrai.io/blog/top-penetration-testing-companies-in-canada-2026-ranked. Canadian dollar bands by engagement type.

7. Stingrai. Penetration Testing Price Index 2026. https://www.stingrai.io/blog/penetration-testing-price-index-2026. Median US$1,364 per consultant day across 30 published rate cards.

8. Stingrai. Pricing. https://www.stingrai.io/pricing. Published one-time and continuous package prices for one web application and associated 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. 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.