NYDFS 23 NYCRR 500

NYDFS 23 NYCRR Part 500 Penetration Testing

Penetration testing and vulnerability monitoring scoped to the covered entity, applicable Part 500 duties and exemptions. The written scope identifies qualified testers, targets, permitted actions and the evidence required for the organization's review.

Bagged hard drive beside a forensic write blocker.

The engagement

What the NYDFS Penetration Testing engagement covers

For an entity subject to the applicable requirements, amended section 500.5 distinguishes at least annual penetration testing from vulnerability monitoring. Scans and manual review are risk based and address material system changes; current applicability and exemptions should be established before the engagement. The technical scope supports the organization's program and does not replace its compliance decisions.

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 report distinguishes demonstrated findings, configuration evidence, observations and conditions deliberately left untested. Automated results need appropriate validation and context; reproduction may be unsafe or outside the authorization. Record those limits rather than presenting every scanner item as a proven attack path.

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. The test plan maps selected techniques to MITRE ATT&CK where they fit the environment and stops at documented markers to avoid disruptive business impact.

  • 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 potential access and business impact 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

    Agree vulnerability monitoring around the actual risk assessment, system changes and applicable amended requirements. Record asset coverage, successful authentication, scan or manual-review method, exceptions and the person responsible for follow-up. A fixed calendar label alone does not establish compliance.

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 activity
  • 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

  1. Scoping and rules of engagement

    Scope the tested information systems and nonpublic information with the responsible entity. Record targets, exclusions, starting access, permitted techniques, testing window, contacts and stop conditions. The covered entity and counsel determine which evidence is needed for its regulatory obligations; no order of regulator review is promised.

  2. 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 most important 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.

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

  4. Reporting and 500.5 alignment

    The report records tested systems, method, dates, material findings, evidence, exclusions and agreed remediation or retest status. A separate testing-scope statement can summarize the work performed. It is not a regulator-issued approval or a substitute for the entity's required certification or acknowledgment.

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

Our report identifies tested systems, methods, dates, material findings and remediation status. These are engagement deliverables, not a report template prescribed by section 500.5. The entity and counsel assess whether the work and supporting records meet the applicable requirement.

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 a New York branch of a foreign banking organization, scope begins with the covered entity's information systems and relevant shared parent or vendor dependencies. The engagement letter records those boundaries and exclusions. Neither every global system nor only systems holding nonpublic information is assumed to define the applicable scope.

Check applicability and the evidence needed

Identify the regulated entity, claimed exemption, covered environment, latest risk assessment, changes since the last test and any existing findings. The accountable entity and counsel confirm which Part 500 provisions apply.

  • Agree the qualified tester, external/internal/application scope, starting credentials and prohibited actions.
  • Retain evidence of targets actually tested, unreachable or excluded systems, method and dates.
  • An illustrative remediation row records a finding, control owner, due date and retest result; an untested correction stays open.
  • Confirm any retest and follow-up separately. A favorable result on the tested scope does not establish that all systems are secure or that DFS will accept a submission.

Current NYDFS cybersecurity regulation and guidance

Talk with an examiner

Talk with the local team

Tell us where the people, devices or retaining team are located and the matter you need help with.

Since 1992 · 24/7 dispatch · Court-tested experts

Or call 1-800-868-8189

Email or phone is required. A submission does not create an engagement. For an active incident, please call. Read what we send with the request.

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

Privacy center

Choose your site settings

Optional technology stays off until you choose otherwise. You can change these browser settings at any time. Access to the core site does not depend on optional technologies.

Technology preferences
Sale or cross-context sharing: not used GDF does not sell or share website personal information for cross-context behavioral advertising.