Guide

NYDFS Part 500: Turning Data Movement Into Provable Evidence

April 25, 2026 Hilt 8 min

Your most valuable data leaves on access you granted on purpose. Part 500 asks for monitoring and provable controls over nonpublic information. How runtime data movement evidence answers the obligation the checklist does not name.

NYDFS Part 500: Turning Data Movement Into Provable Evidence cover image

An examiner asks one question your clean Part 500 attestation cannot answer: a customer's nonpublic information left your environment last quarter, so show me what it did. Not which roles could reach it. What moved, whose, through which job, to where. Most firms reach for logs and start reconstructing. The clock under Section 500.17 has already started.

Part 500 names concrete obligations. A written program, access controls, encryption, multi-factor authentication, a CISO who certifies annually, continuous monitoring or periodic testing of the systems that hold NPI. Map each section to a control, collect the artifact, certify. The checklist passes. The obligation underneath it can still go unmet, because the regulation is built around a noun it tells you to protect but never tells you how to account for: nonpublic information. Customer financial data, account numbers, the records whose departure trips the 72-hour notification under Section 500.17.

The obligation the checklist does not name

Read Section 500.06 and Section 500.14 together. Audit trails. Monitoring designed to detect unauthorized access to or tampering with NPI. The language assumes a clean line between authorized and unauthorized, and assumes that watching the authorization boundary is enough.

The expensive cases do not respect that line. Your most valuable data leaves on access you granted on purpose. A reconciliation job holds standing access to customer account records. A departing analyst keeps legitimate credentials until the last hour. A vendor integration pulls NPI through an approved channel every day. Every move is authorized. Not one trips an access-control rule, because the access was correct. The single move is not the danger. The pattern across moves is, and a control that only checks whether each step was permitted cannot see a pattern.

So a firm holds a clean Part 500 attestation and still cannot answer the question that matters after an incident: what did this customer data actually do, and can we prove it.

Why permission-based controls cannot produce the evidence

Most of the Part 500 stack evaluates permission. Access controls enforce who may reach NPI. Encryption protects it at rest and in transit. DLP guesses in advance whether an action looks risky, then either buries the team in false alarms or waves the permitted move through. Forensics reconstructs the move after the data is gone and the disclosure letter is in draft.

None of these produces a continuous, identity-resolved record of movement. That is structural, not a vendor failure. These tools were built to answer "was this allowed," and they answer it well. Part 500's deeper obligation, prove your controls over NPI are working, asks a different question: what happened to the data, resolved to the job behind it, scored against what normal looks like. You can guess before the move and stay blind to the permitted exfiltration. You can reconstruct after it and arrive too late. Or you can watch the move while it happens. Only the third writes evidence at the moment the move creates it.

Watching the movement, not the permission

Runtime data movement governance watches data movement at the kernel, metadata only by default, off the path. It does not read your customers' data to see that a pattern is wrong. Each move resolves to a probabilistic, source-dependent identity: which user, which job, which destination, and whether this fits what that identity normally does with NPI.

That last clause is what Part 500 is reaching for. The regulation wants assurance that your controls over nonpublic information are real and observable. A system that resolves a customer-data move to the job behind it and scores it against months of how that data normally moves produces exactly the assurance the audit-trail and monitoring sections describe, without reading the data to get it.

Take the reconciliation job with standing access to account records. One night it reads a wider set of customer tables than it has ever touched, inside a tighter window, bound for a destination it has never used. No access rule is violated. The job is authorized. The access pattern is unusual for that identity. The volume is unusual despite the approved channel. The destination is new. Any one signal is noise. Together they are a pattern, and a pattern is a case, not an alert.

Hilt writes that case with the identity, the job, the data classes touched, the timeline, and the deviation that triggered it. If the move warrants it, the response is host-level network isolation (quarantine) from the control plane. The collector never sits inline, never blocks, drops, or alters traffic, and never stands between the data and where it is going. It observes the move and isolates the host at the network.

The evidence Part 500 actually rewards

Certification rewards artifacts. The 72-hour clock rewards a different thing. When NPI leaves, Section 500.17 requires notice to the Superintendent within 72 hours of determining a reportable event occurred, and the hard part is the determination. Did NPI move. Whose. How much. Through what job. To where. A firm answering those questions from a written case, resolved to identity and scored against baseline, makes the notification decision on evidence. A firm without one reconstructs from fragmented logs while the clock runs, then over-reports out of caution or under-reports out of blindness.

That is what runtime movement evidence gives the CISO who signs the annual certification under Section 500.17(b). Not a promise that nothing bad can happen. A continuous, identity-resolved record of what the firm's nonpublic information actually did.

Where this fits, and where it does not

Runtime data movement governance does not replace your Part 500 stack. Access controls still enforce who may reach NPI, and Hilt assumes they do their job. Encryption still protects data at rest and in transit. Your SIEM still aggregates the logs the regulation expects. Real controls, covering real sections, good at what they cover.

What they were never designed to cover is the pattern of movement across permitted actions, the behavioral evidence that NPI moved in a way that does not fit. That is the layer Hilt adds. It runs single-tenant inside your own cloud, AWS, GCP, Azure, or Ali Cloud, with negligible overhead, on the order of 0.1% of one core and 4 to 8 MB of memory per host. Events never leave your account, which matters most when the data in question is the regulated data itself.

The certification you sign and the determination you make under the clock then rest on the same record: provable, continuous evidence of what your nonpublic information did, produced at the moment it moved.

If your current controls confirm that every access to NPI was permitted but cannot show what that data did across those permitted accesses, resolved to the job behind it and scored against how it normally moves, that is the gap Part 500 is quietly pointing at. We are happy to walk an engineer on your team through how the collector produces that evidence in a 30-minute technical call, kernel to written case.