The NYDFS 72-hour cyber-event notice: building the incident timeline with a query

Twenty-three NYCRR Part 500 — the New York Department of Financial Services cybersecurity regulation — applies to every NY-licensed financial institution. Section 500.17(a) is the clock you fear: a confirmed cybersecurity event triggers a seventy-two-hour notification window to the Superintendent. You file a real incident report, not a placeholder. The report names the affected systems, the customer impact, the containment status, and the timeline from detection to escalation to containment.

The fine for failing this isn't always the penalty number. It's the supervisory scrutiny that follows. NYDFS-supervised firms that miss the window get treated as having broader operational deficiencies. The annual cybersecurity certification — a CISO signature you cannot walk back — becomes much harder to defend.

Section 500.20 enforcement penalties start at $100,000 and scale sharply based on intent and impact. The reputational hit lasts years.

What the Superintendent actually wants in 72 hours

The notification template has four parts:

1. The event. What happened, when it was detected, by whom.
2. The impact. What systems, what customer records, what business functions.
3. The timeline. Detection → escalation → containment, every step timestamped.
4. The customer-notification status. Whether and when affected customers were notified.

If your SIEM is one tool, your IAM is another, and your customer notification system is a third, you can't produce a coherent timeline in seventy-two hours. You can produce three timelines that don't quite agree, which is worse.

The reconstruction query

MATCH (s:Session) AT RECORDED '2026-06-06T04:11:00Z'
  WHERE s.actor_origin = 'vendor:CompromisedAcct'
OPTIONAL MATCH (s)-[:ACCESSED]->(r:Record) AT RECORDED '2026-06-06T04:11:00Z'
OPTIONAL MATCH (s)-[:ATTEMPTED]->(esc:Escalation) AT RECORDED '2026-06-06T04:11:00Z'
OPTIONAL MATCH (esc)-[:RESULT]->(outcome) AT RECORDED '2026-06-06T04:11:00Z'
RETURN s, collect(r), collect(esc), outcome

Each MATCH clause reads the graph as it was recorded at the moment of detection: the attacker's session, the records it accessed, and the escalations it attempted, as your security tooling wrote them to the graph. In the illustrative walkthrough, that is twenty-three customer records accessed, two privileged tools attempted (both denied), and eleven lateral-move attempts (all blocked at segmentation).

The decision-timeline record

This is the part the Superintendent cares about most. If each step is written to the graph when it happens, the recorded times give the timeline: detection at 04:11, CISO notification at 04:13, containment at 04:31, customer notification scheduled for T+24. The timeline is read from the recorded times rather than reconstructed afterwards, and the history check reports whether the hash chain that includes those records is intact.

Access before the incident

The Superintendent's follow-up is "who accessed these records before the incident?" The engine does not log allowed reads, so this answer has to come from the access events your systems recorded. db.aclEvents returns the Cypher reads that field ACLs or purpose rules denied, and the searches and node creates they refused, with the principal, label, property, action and reason. Allowed reads are not logged, so the log shows enforcement, not a full access history.

The notification-order record

Section 500.17 implicitly requires that the regulator be notified before customers. If both notifications are written to the graph when they are sent, their recorded times show the order.

The numbers

The figures in this post and in the walkthrough are illustrative.

Illustrative walkthrough on the NYDFS tab.