An examiner sits across from your CISO and asks one question your stack cannot answer. Your portfolio manager logged in on Tuesday. What did that login go on to touch, where did the data go, and how does that compare to what the manager does on a normal Tuesday? Your IAM logs prove the login. They say nothing about the move that followed.
Three regimes now route to that question. NYDFS Part 500 covers any firm handling New York resident data, which for a hedge fund is effectively all of them. SEC Regulation S-P, updated in 2024, attaches incident response and notification duties to most funds. DORA covers any fund with European investors, fund administrators, or prime brokers. They overlap on incident response plans, annual testing, and vendor risk. They diverge from the old checklist on one axis: they ask what your tools actually see while data is moving.
Part 500 stopped accepting the access log
Part 500 mandates a CISO, annual penetration testing, multi-factor authentication, and encryption of nonpublic information. The 2024 amendments tightened privileged access management and incident reporting. None of that is new to a fund that runs a security program.
Section 500.05 is where the questions got sharper. It requires monitoring of authorized user activity. Most funds read that as reviewing IAM access logs, and for years examiners accepted it. They do not anymore. The follow-up is specific. After the user authenticated, what did the session do? What did it read? What network connection did it open, and to where?
The access log answers none of this. It records that someone logged into the trading platform and opened a position report. It does not record that the same session then enumerated a directory it had never touched, staged a copy, and pushed it to an approved storage bucket at an unusual hour. Every step uses access you granted on purpose. No single log line flags the run. That is the gap Part 500 now probes, and an access log review walks the examiner straight into it.
Reg S-P puts a 30-day clock on your detection speed
The SEC rewrote Reg S-P in May 2024. Funds must notify affected individuals within 30 days of discovering a covered incident: unauthorized access to customer information that creates a reasonably foreseeable risk of substantial harm.
The clock starts at discovery, not at breach. An attacker who reached your investor data in January but stayed invisible until March gives you 30 days from March. The notification is the easy part. The hard part is the examiner asking why discovery took two months, and a slow answer is its own finding.
Most funds run CrowdStrike or SentinelOne on endpoints, Zscaler or Palo Alto on the network, Proofpoint on email. That stack handles known payloads, bad reputation, and phishing. It does not handle the move that rides access you already approved.
Here is the path it misses. A supply chain package compromises a portfolio manager's laptop. The code never drops a known payload. It uses ordinary system utilities to walk the file tree, compress investor records, and ship them through an approved cloud storage API over a TLS connection to a whitelisted domain. No signature fires. No network rule trips. Each event is permitted. The fund learns of the breach weeks later, when an investor gets a phishing email quoting their own position data. Now your CISO is explaining to the SEC why the enumeration, the staging, and the upload all passed unremarked, and the 30-day clock has been running since a discovery that came far too late.
DORA names the thing directly
DORA took effect in January 2025 and reaches any fund with EU investors, administrators, or prime brokers. Article 17 requires risk management frameworks with mechanisms for prompt detection of anomalous activities. Article 9 requires monitoring that catches unusual data flows.
Read the verbs. Not security monitoring. Not threat detection. Anomalous activities. Unusual data flows. Those words assume you have a baseline of normal and can name the deviation from it. A tool that only matches signatures and reputation feeds cannot. It catches known techniques against known targets. It is blind to behavior that is wrong for your environment but unremarkable in general.
A quant researcher who reads market data files all day opens an HR directory. A risk analyst's service account that lives in the database starts opening SSH connections to production trading systems. A reporting job that has only ever written reports spawns a shell. Pull any one of these out and it is permitted, even mundane. The breach is the pattern, not the event. You can only read the pattern at runtime, on the move itself: which identity acted, what job it was doing, what it touched, where the data went, and how far that sits from this identity's history in this role on this infrastructure.
Where the three regimes converge
All three regulators made the same move. They stopped grading you on the controls you set in advance and started grading you on what you detect while it happens. The premise is blunt: any guardrail you configured will eventually be walked through by a move it was told to allow. So the exam is now about how fast you see the move and how completely you can scope it.
SEC examiners probe detection mechanisms. NYDFS auditors ask how you baseline normal. DORA assessors test whether you can identify anomalous activity. Three frameworks, one underlying demand.
Your stack does not meet it, and the reason is structural, not a tuning problem. EDR watches processes and files. Network security watches packets and flows. The SIEM correlates logs after the fact. Not one of them watches data movement as it happens, ties each move to the identity and the job behind it, and surfaces the pattern that forms across moves instead of waiting for a single rule to break. That is the layer the regulators are converging on, and it is the layer the stack leaves dark.
The richest vantage on data movement is the kernel. From there you observe a move as the system performs it, in time to act, rather than rebuilding it later from whatever logs the application chose to emit. Data movement governance watches there, metadata only by default, off the path. It resolves each move to a probabilistic, source-dependent identity and the job behind it, then writes the anomalous pattern up as a case. You do not have to read the data to see it is moving in a way it should not. Content-aware inspection is there when an investigation needs it; the pattern does not require it.
The old objection to watching at this layer was cost to the machine. It does not hold. A single off-the-path collector runs at roughly 0.1% of one core and a 4-8 MB footprint, with nothing inline. It does not block, drop, or alter traffic. When a pattern crosses into anomaly, the response is host-level network isolation, quarantine from the control plane, not a filter that has to be right packet by packet.
What the 2026 exam actually wants
The examiner's questions have lost their slack. Saying you have EDR deployed and a SIEM configured no longer closes the topic. How do you catch a technique that matches no signature? How do you flag behavior that is anomalous for one specific role? Once you detect, how fast can you scope it? Those are answerable only by a tool that watches the movement, resolves it to an identity and a job, baselines it across users and roles and infrastructure, and surfaces the deviations worth a case while dropping the noise.
The frameworks are not converging on simpler requirements. They are converging on more technical ones, and a checkbox program reads as a checkbox program under questioning. A fund that can show detection at the layer the regulators now care about turns a long, defensive exam into a short one.
If your last exam ended on the access log and you want the next one to go further, that is a 30-minute technical call. We will walk your CISO's likely questions and show what watching the movement actually answers.