Practitioner resource

The NYDFS 23 NYCRR Part 500 Technical Evidence Playbook

November 1, 2026

Before you read

Would you share your contact details with GDF? It helps us understand who finds these resources useful. It is optional, and every guide is yours to read either way.

Skip and read

We will remember your choice on this browser so you can browse the whole library without another request. You can read without sharing information.

Discuss Engaging an Expert All guides

(212) 561-5860 24/7: (800) 868-8189

An examination response is easier to defend when the entity can connect a regulatory requirement to a named owner, the systems within scope, the control that operates there and evidence showing what happened during the relevant period. A policy binder alone cannot establish that an account was removed, a backup restored or an incident evaluated on time. Equally, a dashboard warning does not establish a legal violation without understanding its scope and context.

This playbook helps a covered entity assemble and explain technical evidence for counsel, compliance leaders, internal audit and authorized examiners. It is not a certification of compliance or a substitute for the regulation. Determine the entity's obligations, exemptions and reporting requirements with the appropriate legal and compliance owners. Keep factual exceptions visible and distinguish current remediation from the state of controls during the period under review.

Establish the covered entity, examination period and applicable requirements

Begin with the legal entity and its relevant license, registration or other DFS authorization. Identify affiliates, shared services and providers that operate systems on its behalf. Record the examination period, the request or notice received and the person coordinating the response. Confirm whether a claimed exemption is current, documented and relevant to each requirement rather than treating the word exempt as a complete answer.

Use the official regulation and current DFS guidance to build the requirements register. Mark the basis for each applicability decision and preserve the approving person's record. Do not treat every organization that does business in New York as a Part 500 covered entity. Conversely, another regulator's oversight does not by itself settle the entity's DFS obligations. The applicable rule and entity circumstances control. [DFS_FAQ]

Create one evidence index with a clear chain to each assertion

Give each requirement or examination request a stable reference. For each response, identify the control owner, relevant systems, period, evidence source, collection date and location. Use a short explanation of what the evidence demonstrates and what it does not. For example, a configuration export shows a setting at a point in time, while activity records may help demonstrate operation over a period.

Keep original exports separate from annotated presentation copies. Preserve the query, filters, source time zone, export options and errors. If the source is a provider portal, record the tenant and administrative scope used. A result generated today may not demonstrate the historical state requested by an examiner. Identify historical gaps early and seek other authorized records without changing timestamps or rewriting the earlier account.

Make the risk assessment traceable to actual business risk

Use the risk assessment to explain why particular assets, access routes and business processes matter. Connect identified risks to their control owners and supporting evidence. A repeated list of generic threats does not show how the entity evaluated its own environment. Keep the assessment's scope, assumptions, methodology, risk criteria and material exclusions with its findings.

DFS's September 2026 guidance emphasizes an assessment tailored to the entity, documented risks, traceability to controls and updates when circumstances change. Use that guidance alongside the regulation, not as a replacement for it. Record management's remediation or risk-acceptance decisions and the facts on which they relied. A later reassessment should explain what changed rather than overwrite the earlier result. [DFS_RISK]

Reconcile inventories with systems and data that actually exist

Compare the asset inventory with representative identity, endpoint, cloud, network and business-application records. Identify owners, locations and significant dependencies. Include systems supplied through shared services and the information the entity needs from providers to understand them. Keep unmatched assets and undocumented owners as open items with an accountable next step.

An inventory can support an examination only within its demonstrated coverage. A spreadsheet of purchased laptops may omit virtual machines, tenant applications or infrastructure operated by a provider. A discovery tool may miss offline or isolated systems. Document the collection methods and reconciliation process. The objective is an explainable inventory whose limitations are understood, rather than an unsupported statement that a single export contains everything.

Show how access is approved, reviewed and removed

Assemble evidence of account creation, privilege approval, periodic review and termination. Include ordinary users, privileged administrators, service identities, remote access and relevant provider access. Review a sample of actual personnel changes against the corresponding access records. Explain discrepancies with facts: a delayed disablement, an account used by a service or an approval that could not be located.

For MFA, distinguish the written policy, configured scope and effective enforcement. Preserve policy exports, exclusions, alternative-control decisions where applicable and representative operating records. Identify the systems and people that the evidence actually covers. A successful MFA event for one administrator is not proof that every user and application is protected. The staged requirements through November 2025 are already in the past as of this edition; do not present them as a future implementation window. [DFS_TIMELINE]

Connect vulnerability findings to remediation and retesting

Keep the approved scope, asset coverage, assessment dates and material exclusions with penetration-test and vulnerability-assessment reports. Reconcile findings to responsible owners, remediation decisions, target dates and evidence of closure. Where a weakness was accepted or a fix deferred, retain the rationale and applicable compensating measures rather than quietly deleting the finding from a dashboard.

Show the distinction between an automated result, a validated weakness and a retest observation. A rescan can help determine whether a particular issue remains detectable under the retest conditions. It does not establish the absence of every attack path or prove the entire environment secure. If material systems were excluded, explain who authorized that boundary and what other evidence addresses the risk. Testing should support the entity's risk decisions and examination response, not substitute for them.

Explain logging, monitoring and the limits of historical coverage

For important sources, record the enabled events, collection path, retention, time synchronization and responsible monitoring team. Identify whether records are provider generated, forwarded to another platform or stored locally. Preserve evidence that alerts were received and handled where the examination concerns monitoring operation, not merely the existence of a product license.

Build a coverage table for the review period. Mark earliest and latest available records, known interruptions and relevant changes to settings or licenses. Treat missing logs as a limit on the account, not proof that nothing happened. Where the entity relies on a provider, request the specific evidence needed and retain the provider's stated coverage and exceptions. Avoid inserting personal information into a broad response package when a suitably scoped or redacted record will address the request.

Demonstrate recovery through actual exercise records

Collect the incident-response and business-continuity or disaster-recovery plans applicable to the reviewed systems. Identify the people responsible for using them, the exercises performed and the resulting corrective actions. For restoration evidence, distinguish a backup job's reported completion from an observed recovery of the required data or system.

Preserve the exercise scenario, participants, start and finish times, dependencies, exceptions and decisions. If the exercise was limited to a sample or an isolated environment, say so. Record how unresolved findings were assigned and followed through. A polished report that omits a failed restoration step is less useful than a complete account that shows the failure, its consequence and the remediation. [DFS]

Address third parties and shared responsibility directly

List the providers relevant to each request and identify the business owner responsible for the relationship. Match the entity's claimed control to the contract, available assurance material and any direct operating evidence. Read the scope, period and exceptions in provider reports rather than treating the report's existence as confirmation of every service the entity uses.

Where responsibilities are divided, document who approves access, enables logging, preserves evidence and responds to an incident. A provider may operate infrastructure while the entity remains responsible for tenant settings or user access. Keep unanswered requests visible. If a provider cannot supply historical evidence, describe the gap and identify possible alternative records. Do not represent an assurance letter as a substitute for facts the letter does not address.

Preserve the incident and notification decision record

Maintain a chronology separating initial detection, escalation, determination, containment, evidence collection and notifications. The regulation's incident-notice provisions and its defined terms require careful application. Record who made the relevant determination, the facts known at that point and the time of each submission or update. Do not use a general internal severity label as a substitute for the applicable regulatory analysis.

Part 500 also contains distinct provisions for extortion-payment notices and explanations. Keep payment-related decisions under the direction of authorized leadership and counsel. This guide does not authorize payment or determine notification duties. Technical personnel should preserve the factual account and identify changing information promptly, without promising that an early triage review can establish the full scope of access. [DFS]

Support the annual submission with the record it actually requires

Identify the data and documentation supporting the entity's annual submission and the responsible signatories. Distinguish a current improvement project from evidence about the prior calendar year. The regulation provides different submission paths, including certification of material compliance and acknowledgment of noncompliance. Counsel and responsible officers determine the appropriate submission, not the presence of a completed checklist.

Keep the supporting records and known areas requiring improvement together with remediation plans and their status. Preserve versions and approvals so the entity can explain the account later. Do not label a missing record compliant merely because its owner expects to find it. A technical specialist can help reconcile evidence and articulate limitations; that work does not replace the signatories' responsibilities. [DFS]

Deliver a response package that a reviewer can follow

Prepare a concise response narrative and link it to the indexed supporting records. Use consistent entity names, system identifiers, dates and evidence references. Separate facts, interpretations and open questions. Identify documents supplied by a provider and statements based only on an interview. Make the source and limits visible without flooding the reviewer with unrelated exports.

Before delivery, have the control owner confirm factual accuracy and have counsel or compliance review the response within their responsibilities. Test whether a person unfamiliar with the project can follow a material assertion to its support. Resolve broken references, conflicting dates and unexplained gaps. Preserve the delivered version and the record of later corrections. That produces an examination response whose reasoning can be checked, even when the underlying environment still contains work to do.

Evidence handling record linking a source, collection, transfer and analysis — Planning illustration. Apply it to the authorized scope and actual systems described in this guide.

Information Gathering Q&A Checklist

Use this Q&A with the people who own the systems and the relevant legal or business decisions. Mark unknown or not applicable answers explicitly. Record an owner, a confirming source and the date. The public guide-request form asks for your email, not the answers below.

Do not write passwords, recovery keys, unlock codes or authentication secrets here. Record whether authorized access is available, who controls it and how a secure handoff can be arranged. Keep completed copies in the location counsel or the company approves. Do not send a completed record containing sensitive account or employee details through a public contact form.

Who is directing the matter and who can authorize technical access?

Identify directing counsel, the business decision maker, the IT security owner and any outside administrator. Record the immediate deadline, relevant period and known preservation risk. An employee's possession of a device or an administrator's ability to access an account does not by itself settle the authorized examination scope.

Answer: