Incident Response Decision Log: Document Why a Notification Clock Did—or Did Not—Start

TL;DR

• The SEC 4-day clock, OCC 36-hour rule, and NYDFS 72-hour requirement all share one trigger: a documented determination that the threshold was met—not detection.
• “We decided the clock didn’t start” is as legally significant as “we started the clock”—and requires the same documented reasoning.
• The decision log is the artifact that proves good-faith determination without unreasonable delay. Without it, you’re explaining the decision under enforcement pressure instead of preserving it in real time.
• Every incident log needs a clock-assessment step with a named decision-maker, timestamp, reasoning, and reassessment schedule.

A security alert fires at 11:47 PM. By morning, the team confirms unauthorized access to customer data. The CISO asks legal: do we have to file? Legal says it depends on materiality. Who decides? By when? And what happens if the answer is no?

That conversation is the notification clock decision. If it happens in a Slack thread that gets deleted, in a verbal call with no notes, or in a War Room with no log, the company has made a consequential legal decision with no evidence it was made at all. Regulators examining the incident—six months later, under subpoena—will find the detection timestamp, the containment record, and a gap where the materiality determination should be.

The decision log closes that gap.

The notification clock landscape

Every institution managing a cyber event is potentially facing multiple clocks simultaneously. The most common for financial services:

Two things are true about all of these clocks: they start at a determination, not at detection. And the determination is a documented decision made by a named person or group at a specific time.

The SEC cybersecurity disclosure framework and the OCC 36-hour rule overlap in ways that require coordination. A banking organization that is also a public company may need to make separate determinations under separate standards for the same event—one for the OCC notification and a different one for SEC materiality. The decision log must address each.

What the decision log must contain

The decision log is not the incident timeline, the forensic report, or the executive summary. It is a specific artifact documenting the legal determination: given what we know right now, has a notification threshold been met?

Required fields for each decision log entry:

1. Event reference and timestamp of log entry Link to the incident ticket or IR log. Record the exact time the log entry was created, not the time the incident was detected.

2. Known facts at time of decision Not a full technical writeup—that’s the incident log. This is the summary of what decision-makers actually knew when they made the call: which systems were accessed, whether data was exfiltrated, estimated scope of affected records or accounts, whether the attack is ongoing or contained. Be precise about what is known vs. what is still under investigation.

3. Threshold(s) assessed Name every notification obligation that was assessed. If four clocks were considered and three were determined not to have started, list all four with the reasoning for each. A determination that the NYDFS clock did not start should be documented with the same rigor as a determination that it did.

4. Reasoning This is the core legal analysis. For SEC materiality: apply the reasonable investor standard—would a reasonable investor consider this important? Include quantitative factors (financial loss, revenue impact, number of records) and qualitative factors (nature of data, customer harm, regulatory exposure, likelihood of litigation). For OCC 36-hour: does this meet the definition of a “notification incident” (an incident resulting in actual harm to the confidentiality, integrity, or availability of an information system, or a business disruption to normal operations)?

5. Decision and clock status

6. Decision-maker(s) and their roles Name the individuals who participated in the determination. Typical composition: CISO or Head of Security (facts); General Counsel or outside counsel (legal threshold analysis); CFO (financial materiality inputs for SEC); CEO (SEC materiality final sign-off for public companies). Record who was present and who made the final call.

7. Reassessment schedule If the incident is ongoing or material facts are still unknown, set the next reassessment time. For major incidents, reassessment every 24 hours is appropriate. Log each reassessment as a new entry referencing the original.

8. Actions triggered If the clock started: who is responsible for drafting the notification, what is the deadline, who approves before it goes out? If the clock did not start: what would change that determination, what is the monitoring plan?

The “clock did not start” determination

The decision that a notification threshold was not met is a legal decision with consequences equal to the decision that it was. The same documentation standard applies.

SEC enforcement against companies that did not file 8-K Item 1.05 has specifically examined the gap between detection and determination. When an examiner can establish that an incident was detected on date X and that executives knew about it by date X+2—but no materiality determination is documented until day X+20—the inference of deliberate delay is difficult to rebut without contemporaneous records.

A decision log entry that says “assessed OCC 36-hour threshold as of [time] — not triggered — event does not meet ‘notification incident’ standard because access was limited to a test environment with no customer data; containment confirmed [time]” is defensible. The absence of that log entry is not.

The “not triggered” entry must include:

• The standard applied (OCC, SEC, NYDFS, state law)
• The facts that led to the non-trigger determination
• What facts, if discovered, would change the determination
• The next scheduled reassessment

The multi-clock problem

The Flagstar Bank 2021 breach illustrates what multi-clock management looks like when things go wrong. Flagstar initially concluded that the breach affecting 1.5 million customers did not require prompt notification—a determination that later became the subject of class action litigation and regulatory scrutiny. The facts that drove the notification decision, and the process by which it was made, were examined extensively. What documentation existed for that decision? When was it made? Who made it?

The SEC cybersecurity 8-K filing process for financial institutions covers the Flagstar case in more detail. The pattern—detection, delayed determination, regulatory scrutiny of the gap—is the same pattern that has driven enforcement in multiple 2024-2025 SEC cases.

The FFIEC 36-hour computer-security incident notification rule requires a separate analysis from SEC materiality. Institutions subject to both should address them in separate log entries, since the standards are different and the audiences are different.

Practical implementation: the 24-hour materiality meeting

The most operationally reliable implementation of the decision log is a structured meeting at the 24-hour mark for any P1 or P2 incident, with a defined agenda and mandatory log output.

24-hour materiality meeting structure:

• Who is required: CISO (or incident commander), General Counsel (or outside privacy/cyber counsel), CFO (or Controller for financial inputs), CEO notification (for public companies)
• Agenda item 1: Current known facts (15 minutes)
• Agenda item 2: Threshold review for each potentially applicable clock (20 minutes)
• Agenda item 3: Determination and documentation (10 minutes)
• Agenda item 4: Action items and next reassessment (5 minutes)

The meeting produces one log entry with all required fields. If the incident is ongoing, the next meeting is scheduled before this one ends.

Pre-plan who holds the meeting if the CISO is unavailable. If outside counsel is on retainer for cyber response, have them dialed in by default for any P1.

What happens when the meeting gets skipped

The documented case pattern from 2024-2025 SEC enforcement: a security team detects an incident, classifies it as significant, escalates to leadership—and then the materiality determination happens informally, in email chains that are ambiguous, or not at all. The company files the 8-K days or weeks after a date that, in retrospect, is when the facts available were sufficient to support a materiality determination.

The SEC does not need to prove the company knew it was material on day one. They need to show the facts available on day X were sufficient that a good-faith determination process should have concluded materiality—and that no documented determination exists for those days.

The decision log is the evidence that the determination was made, by whom, on what facts, at what time. Without it, every day between detection and filing is a potential “without unreasonable delay” problem.

So what?

Every incident response plan has playbooks for detection, containment, and remediation. Most do not have a prescribed, structured process for the notification clock determination—the single most legally consequential step in incident response.

The decision log template should be in your IRP before an incident occurs: pre-populated with the notification thresholds you’re subject to, the decision-maker roles by function, and the reassessment schedule. When a P1 fires at midnight, your team should be filling in a form they’ve seen before, not designing a process under pressure.

The Incident Response & Breach Notification Kit includes a notification clock decision log template structured around SEC Item 1.05, OCC 36-hour, NYDFS 72-hour, and state breach notification thresholds—pre-populated with the legal standard for each clock, the required fields, and a decision-maker checklist. It also includes an all-50-states breach notification matrix so the state law column of the log doesn’t require a separate research sprint at 2 AM.