Hedge funds now operate under three overlapping compliance regimes. NYDFS Part 500 applies to firms handling New York resident data. SEC Regulation S-P was updated in 2024 with incident response requirements that hit most funds. DORA, the EU's Digital Operational Resilience Act, covers any fund with European investors or counterparties.
The requirements share a pattern. All three demand incident response plans, regular testing, and vendor risk management. All three require annual assessments. None of them care much about your checkbox security stack.
What changed in 2024 is what regulators ask about during examinations. They're now probing the detection gap: the space between what your EDR catches and what's actually happening in your infrastructure.
What NYDFS Part 500 Actually Requires
Part 500 applies to any financial services entity operating in New York or serving New York residents. For hedge funds, that's nearly universal coverage.
The regulation mandates a Chief Information Security Officer, annual penetration testing, multi-factor authentication, and encryption of nonpublic information. The 2024 amendments added requirements around privileged access management and extended incident reporting timelines.
Section 500.05 requires monitoring of "authorized user activity." Most funds interpret this as reviewing user access logs in their IAM system. Examiners are starting to ask more specific questions. What did the user actually do after they authenticated? What processes did they spawn? What files did they access? What network connections did they establish?
Traditional monitoring tools capture application-layer events. A user logs into the trading platform, opens a position report, downloads it. That's what your SIEM shows. The question examiners ask is what happened at the system level. Did that download spawn an unexpected process? Did it make an unusual network connection? Did it access credential files?
The gap exists because most security tools run in user space. They see what the application reports. They don't see the syscalls underneath.
SEC Regulation S-P and the Incident Response Timeline
The SEC updated Reg S-P in May 2024. The changes created specific incident response and notification requirements that hadn't existed in the original 2000 regulation.
Funds must now notify affected individuals within 30 days of discovering a "covered incident." That's defined as unauthorized access to customer information that creates a reasonably foreseeable risk of substantial harm. The notification must include the date of the incident, types of information involved, and contact information for credit agencies.
The 30-day clock starts at discovery, not at breach. That distinction matters. If an attacker accessed fund investor data in January but you didn't detect it until March, you have 30 days from March. Except the SEC will ask why detection took two months.
Most hedge funds run CrowdStrike or SentinelOne on endpoints, Zscaler or Palo Alto for network traffic, and Proofpoint for email. That's 95% coverage for common attack vectors. The 5% that's missing is system-level behavior that doesn't trigger endpoint signatures or network rules.
A concrete example: an attacker compromises a portfolio manager's laptop through a supply chain package. The malicious code doesn't execute a known payload. It uses legitimate system utilities to enumerate files, compress investor data, and exfiltrate it through an approved cloud storage API. No signatures fire. No network rules trigger. The TLS connection looks normal because it's going to a whitelisted domain.
The fund discovers the breach when an investor receives a suspicious email referencing their position data. That's 47 days after initial access. Now you're explaining to the SEC why your detection capabilities missed syscall-level enumeration and why your network monitoring didn't catch bulk data movement to an authorized but unusual destination.
DORA's Operational Resilience Focus
DORA took effect in January 2025. It applies to financial entities operating in the EU, which includes most hedge funds with European investors, European fund administrators, or European prime brokers.
The regulation focuses on digital operational resilience. That means your ability to absorb, adapt to, and recover from ICT-related disruptions. DORA requires testing every three years at minimum, with advanced testing for systemically important entities.
Article 17 mandates ICT risk management frameworks that include mechanisms for "prompt detection of anomalous activities." Article 9 requires monitoring of network and information systems, including "unusual data flows."
The language is specific. Not "security monitoring" or "threat detection," but anomalous activities and unusual data flows. That implies baseline understanding of normal behavior.
Most hedge fund cybersecurity programs monitor for known threats. Signature matches, IP reputation, behavioral analytics against threat intelligence feeds. That catches attacks using known techniques against known targets through known vectors.
What it doesn't catch is novel behavior that's anomalous for your environment but not necessarily malicious by general standards. A quantitative researcher who normally reads market data files suddenly accessing HR directories. A risk analyst's service account that typically queries databases now making SSH connections to production trading systems. A compliance system that usually generates reports now spawning PowerShell sessions.
These patterns aren't malicious in isolation. They become suspicious in context. The context exists at the kernel layer, where you can see the full chain: which user initiated the session, what binary actually executed, what files it touched, what network sockets it opened, and how that compares to historical behavior for that user in that role on that infrastructure.
The Detection Gap Regulators Actually Care About
The pattern across all three frameworks is the shift from preventive controls to detective controls. The assumption is that prevention will eventually fail. The question is how quickly you notice and how completely you understand the scope.
When SEC examiners review your incident response plan, they ask about detection mechanisms. When NYDFS auditors test your monitoring, they want to see how you baseline normal behavior. When DORA assessments evaluate your resilience, they probe your ability to identify anomalous activities.
The gap most firms have is between their security stack and their kernel. EDR agents see processes and files. Network security sees packets and flows. SIEMs correlate logs. None of them see the syscall boundary where user space transitions to kernel space, where you can observe behavior before encryption, before obfuscation, before the application layer has a chance to normalize or hide it.
A kernel-level agent captures process execution with full context: parent process, command line arguments, environment variables, user and session IDs. It captures file operations with inode data, timestamps, and access patterns. It captures network events with socket information, connection state, and protocol details. Most importantly, it captures all of this before TLS encryption, before application-layer protocols, at the point where the system actually performs the operation.
The performance argument against kernel instrumentation used to be valid. Not anymore. eBPF-based monitoring using CO-RE and BTF runs with 0.1% CPU overhead at scale. Detection latency averages 98 milliseconds. False positive rates drop to 0.18% after 180 days of baseline learning.
What Compliance Actually Looks Like in 2026
Hedge funds need to demonstrate three capabilities to satisfy current regulatory frameworks. First, comprehensive monitoring that captures system-level behavior, not just application-level events. Second, behavioral baselining that identifies anomalies across users, roles, and infrastructure simultaneously. Third, evidence that detection gaps have been identified and addressed.
The conversation with examiners has changed. It's no longer sufficient to say you have EDR deployed and your SIEM is configured. The questions are more specific. How do you detect novel techniques that don't match known signatures? How do you identify anomalous behavior for specific user roles? How quickly can you determine the scope of a breach after initial detection?
The technical answer involves instrumenting at the kernel layer where you can observe actual system behavior, correlating that behavior across multiple dimensions to build accurate baselines, and detecting deviations that matter while filtering out noise that doesn't. Most firms are discovering that their existing security stack, while valuable for known threats and common vectors, doesn't provide the visibility regulators are now asking about.
The compliance landscape isn't getting simpler. The frameworks are converging on similar requirements, but those requirements are more technically specific than they were two years ago. Funds that treat compliance as a checkbox exercise will struggle in examinations. Funds that build genuine detection capabilities at the layer regulators care about will find the compliance conversation much shorter.