NYDFS 23 NYCRR 500
NYDFS 23 NYCRR Part 500 Penetration Testing
Human-led penetration testing scoped to Part 500 for covered entities in New York. Testing is annual per 500.5, with vulnerability assessments on a shorter cycle, and the report is written for the CISO, the board committee and the DFS examiner.
The engagement
What the NYDFS Penetration Testing engagement covers
NYDFS 23 NYCRR Part 500 obligates covered entities (state-chartered banks, licensed lenders, licensed insurers, money transmitters, virtual currency licensees and other DFS-regulated institutions) to run a cybersecurity program built around a written risk assessment. Part 500.5 specifically requires penetration testing at least annually and vulnerability assessments on a documented cadence. The program is expected to be led by a qualified CISO (500.4) and reviewed periodically at the board or senior-governing-body level.
The penetration testing engagement is scoped against the covered entity's information systems as defined in 500.1. In practice that means internet-facing services, internal networks, identity systems (Active Directory, Entra ID, Okta), cloud control planes (AWS, Azure, GCP tenancies), core business applications and APIs, and any third-party service provider integration whose compromise would affect nonpublic information.
The testing is human-led. Automated scanning is used for coverage on known-vulnerability signatures and for large-surface enumeration, but every material finding in the report is reproduced by a practitioner before it is written up. That discipline matters because 500.5 and 500.9 both expect the CISO and, ultimately, the board or governing body to make decisions on real attack paths, not on scanner severity ratings that may not reflect exploitable risk.
Scope
External network and internet-facing services
Enumeration of exposed hosts, services, TLS configurations and known-CVE surface. Reproduction of credible attack paths through misconfigured or vulnerable services. Documented before/after evidence for anything exploited in the engagement.
Internal network and identity
Testing from an assumed-foothold posture against Active Directory or Entra ID, common lateral-movement paths (Kerberoasting, ADCS, delegation abuse, DPAPI, SMB relay), and credential exposure. Testing follows the standard MITRE ATT&CK path where the environment supports it and stops at documented markers rather than at business impact where doing so would be disruptive.
Cloud control planes
AWS IAM (roles, policies, trust relationships, cross-account paths, S3 exposure), Azure and Entra ID (conditional access, app registrations, managed identities, privileged roles), and GCP IAM. Findings are ranked against the credible blast radius rather than against scanner severity.
Web applications and APIs
OWASP Top 10 and OWASP API Top 10 coverage, authentication and authorization boundaries, tenant isolation for multi-tenant SaaS, business-logic issues, and access-control edge cases. Testing is authenticated at multiple privilege levels where the application supports it.
Third-party service providers in scope
Where a third-party service provider's environment carries covered nonpublic information, the engagement either extends to the provider under a testing authorization or documents the reliance on the provider's independent test as an inherited control.
Vulnerability assessment cadence
Vulnerability assessments are run against the covered environment on a documented cadence (commonly biannual or quarterly), with results delivered in a form the CISO can hand to the board committee that receives the 500.4 CISO report.
Evidence commonly reviewed
Evidence reviewed
- Screenshots and command output for every reproduced finding
- Exploitation timeline with timestamps for each material step
- Cleaned test-account artifacts and IOC list for defender review
- Cloud audit-log evidence (CloudTrail, Azure Activity, GCP Cloud Audit) of the testing footprint
- Retest evidence for any finding remediated during the engagement
What you receive
Deliverables
- Executive summary written for the CISO and the board committee
- Technical report with reproduction steps for every material finding
- 500.5-aligned attestation of the testing scope, dates and methodology
- Remediation guidance with control owner, exploit precondition, recommended fix and retest plan
- Structured findings export for import into GRC or ticketing systems
Engagement workflow
How the engagement runs
Scoping and rules of engagement
Scoping is set against the covered entity's 500.1 classification of nonpublic information and the systems that store, process or transmit it. The rules of engagement are written explicitly: which systems are in scope, which are out of scope, which testing techniques are authorized (network, application, social-engineering, physical), which are excluded, the testing window, the escalation contacts on both sides and the criteria that would pause testing. The scope statement and the rules of engagement are the two documents the DFS examiner will look for first when validating that the testing was fit for 500.5.
Reconnaissance and threat modeling
Reconnaissance is performed with active and passive techniques appropriate to the scope, and the results feed a written threat model that ties the covered entity's crown-jewel systems (systems holding nonpublic information, systems supporting critical business functions, systems supporting recovery) to the attacker paths that could reach them. The threat model determines where testing effort is spent; time is not evenly distributed across the scope.
Testing execution
Testing execution runs the authorized techniques against the in-scope systems with careful contemporaneous logging: source IP, target, tooling, timestamps, request and response artifacts, and any exception where the test paused for coordination with the covered entity's blue team. Where a control fires (EDR alert, WAF block, IDS detection, SOC ticket), the fact and the timestamp are recorded so the covered entity has objective evidence of what its detection stack actually did.
Reporting and 500.5 alignment
The report is written to what 500.5 actually requires and to what covered-entity risk committees actually consume: an executive summary calibrated to business impact, a technical section with reproduction steps for every material finding, an attestation of the testing scope, methodology and dates, and a remediation guide with control owner, exploit precondition, recommended fix and retest plan. The 500.5 attestation is written so it can travel to the DFS examiner as its own document.
Remediation validation and retest
Retest of remediated findings is performed against the same reproduction steps used for the original finding, and retest evidence is captured with before and after artifacts. Where the DFS examiner or the covered entity's audit committee requests a separate retest attestation, the retest attestation is prepared as its own document and cross-references the original finding identifier so the record is easy to follow.
Frequently asked
Common questions on NYDFS Penetration Testing
Is your report accepted for 500.5 examiner reviews?
The report is written to what 500.5 actually requires: identification of the tested information systems, the testing methodology, the dates of the testing, the material findings and the remediation status. Whether any specific report satisfies the DFS examiner is a matter for the covered entity and its counsel, not for GDF.
Do you also run the 500.9 risk assessment?
GDF provides the technical inputs (asset inventory, control effectiveness observations, test findings) that feed into the risk assessment. The 500.9 risk assessment itself is a covered-entity governance artifact and typically stays with the CISO and legal or compliance.
Do you retest after remediation?
Yes. Retest of remediated findings is included in the engagement scope. Retest evidence (before and after reproduction) is included in the final report and can be broken out as a separate attestation letter where the DFS examiner requests one.
Can testing be scheduled around a DFS examination?
Yes. Testing windows are commonly aligned to the covered entity's examination schedule so the report is current when the examiner asks for it.
How is testing scoped for a New York branch of a foreign bank?
For New York branches of foreign banking organizations, the scope is set against the systems that carry nonpublic information under 500.1, not the parent's global footprint. The engagement letter is explicit about that boundary.
Talk with an examiner
Discuss the matter and the next step.
Call to discuss timing, scope and the safest way to share information. Do not send evidence or credentials by email.
24/7 hotline: 1-800-868-8189