Incident Triage Techniques: Severity Classification, Materiality, and the SEC 4-Day Clock

TL;DR

• Triage is the decision everything else depends on. Wrong severity classification leads to wrong response intensity, wrong escalation, wrong disclosure decisions — and for public companies, potential SEC enforcement.
• The SEC’s 4-day reporting clock starts when materiality is determined, not when the incident is discovered. That distinction matters enormously — but it doesn’t justify delay. The SEC expects companies to make materiality determinations without unreasonable delay after discovery.
• Materiality has no bright-line dollar test. Quantitative and qualitative factors both count: reputational harm, customer relationship damage, regulatory exposure, and competitive impact can all tip a small breach into material territory.
• The first year of Form 8-K cybersecurity filings (2024–2025) revealed the same failure across companies: no documented internal decision process. If your triage process doesn’t generate a paper trail in real time, it’s not going to hold up under examination.

The alert fired at 2am. By the time the security team has initial containment at 6am, there are already three questions the CISO needs answered before the board call at 9:

What happened, exactly? How bad is it? And do we need to tell the SEC about this within four business days?

The first two questions belong to incident response. The third belongs to triage — the classification process that determines severity, drives escalation, and, for public companies, starts a regulatory clock that doesn’t pause for remediation.

Most incident response programs are reasonably competent at detection and containment. Most are bad at triage — specifically, at translating technical findings into the business severity classifications that determine whether something goes to the board, to outside counsel, and to the SEC. The first year of Form 8-K cybersecurity filings produced a steady stream of SEC comment letters, and a disproportionate number focused not on what happened but on how companies decided — or failed to decide — whether it was material.

Here’s a practitioner framework for getting triage right.

Why Classification Errors Are So Costly

An underclassified incident (calling a P1 a P3) delays executive escalation, under-resources containment, and — for public companies — runs the clock down before the materiality clock even starts. Overclassification wastes resources, desensitizes leadership, and creates organizational pressure to keep future severity assessments low to avoid the false alarms. Both failure modes are real, and both have appeared in post-incident reviews.

The broader problem: most severity frameworks are designed for IT operations, not for the hybrid IT/legal/regulatory decision that SEC disclosure requires. A framework that works well for triaging a server outage may produce completely wrong outputs when applied to a data breach affecting 8,000 customer records where the affected data is a regulated data type.

Triage for incident response isn’t just a technical process. It’s a business decision process that needs to start at detection and run in parallel with containment.

A Working Severity Classification Framework

A four-tier framework with concrete business criteria works for most financial services organizations:

The classifications need to be anchored in quantitative terms your team can apply consistently under pressure. “Significant operational disruption” means nothing if it’s not defined. Attach it to something concrete: “three or more customer-facing services offline for more than one hour,” or “more than 10,000 customer accounts affected.” Whatever the threshold is, write it down.

Critical calibration principle: Initial triage classifications should be conservative — assume higher severity, not lower, when data is incomplete. You can downgrade a P1 to a P2 as facts develop. Upgrading a P3 to a P1 three days later after delaying escalation is the pattern that produces SEC enforcement problems.

The Materiality Decision Process

For public companies, P1 and most P2 incidents require a materiality determination — a documented analysis of whether the incident rises to the threshold requiring 8-K disclosure under Item 1.05.

The SEC’s standard: information is material if there is a substantial likelihood that a reasonable investor would consider it important when making an investment decision. There is no financial bright line. In the SEC’s own guidance, materiality analysis must consider:

Quantitative Factors

• Actual or projected financial impact (remediation costs, lost revenue, regulatory fines)
• Insurance coverage and net exposure
• Impact on financial results compared to recent reporting periods

Qualitative Factors

• Harm to reputation or brand
• Damage to customer, vendor, or business partner relationships
• Likelihood of litigation or regulatory investigation
• Negative competitive impact (exposure of trade secrets, competitive intelligence)
• Number and type of individuals whose information was compromised
• Sensitivity of affected data (health data, financial data, government IDs)

The “small breach, high sensitivity” scenario matters most here. A breach involving 500 records from a healthcare product’s waitlist — where the data includes names, email addresses, and preliminary financial screening information — may be material even with no operational impact. A breach of 50,000 internal email addresses with no customer PII may not be. The data type and relationship context matter as much as the volume.

Who Makes the Call

The SEC’s first-year comment letter review repeatedly flagged companies that lacked a documented internal escalation and decision-making procedure. The materiality determination should involve:

• General Counsel or outside securities counsel
• CFO or Controller
• CISO or equivalent
• Business unit heads where relevant

Document the deliberation. “Legal, finance, and security leadership reviewed available facts on [date] and determined no material impact for the following reasons: [specific factors]” is defensible. “We decided it wasn’t material” is not.

The SEC 4-Day Clock: Mechanics and Common Mistakes

Under Item 1.05 of Form 8-K (effective December 18, 2023 for large accelerated filers), the four-business-day clock runs from the date of materiality determination — not the date of discovery, detection, or containment.

This distinction creates genuine operational tension. A company that discovers a breach on Monday, completes its investigation by the following Wednesday, and determines materiality that day has four business days from Wednesday to file — not from Monday. But the SEC has been equally clear that the investigation itself cannot be stretched to avoid the clock. “Without unreasonable delay” means your investigation timeline needs to be defensible in proportion to incident complexity.

Lessons from the first year of Form 8-K filings (2024–2025):

From the NYU Compliance and Enforcement blog’s analysis of the first year of filings: of approximately 80 total filings in the first year, only about 14% were made under Item 1.05 as material. The rest were voluntary disclosures under Item 8.01 for non-material incidents. Following the SEC’s May 2024 guidance clarification — specifically, SEC Corp Fin Director Erik Gerding’s statement that Item 1.05 should only be used for confirmed material incidents — companies stopped over-disclosing under Item 1.05 and started using Item 8.01 as the appropriate vehicle for significant-but-not-material disclosures.

The practical implication: filing under Item 8.01 isn’t a red flag. It’s appropriate for incidents that are real and significant enough to warrant voluntary disclosure without meeting the materiality threshold. What creates problems is filing under Item 1.05 for incidents that aren’t material, or waiting until the SEC issues a comment letter to figure out which item applied.

The AT&T exception: AT&T filed its July 2024 Form 8-K 84 days after detection — the most prominent example of a delayed filing. The delay was authorized by the Department of Justice, which determined that immediate disclosure posed a substantial risk to national security or public safety. That exception exists but is extremely narrow. Don’t plan around it.

Escalation Protocols During Triage

Triage isn’t a solo activity. The escalation structure needs to be pre-built so it activates without deliberation when an incident hits.

A functional escalation protocol specifies, for each severity tier:

• Who gets notified (by name and backup)
• Within what timeframe (hours, not “promptly”)
• Through what channel (phone call, not just email for P1/P2)
• What information must be in the initial notification
• What decisions or approvals are required before certain actions

For P1/P2 incidents, external parties often need notification too: outside IR counsel (to protect privilege over the investigation), cyber liability insurance carrier (most policies require timely notification), and in some cases regulators (banking regulators for material operational events, HIPAA covered entities for suspected health data breaches).

One underappreciated escalation requirement: your board or audit committee. Banking regulators under the November 2021 Computer-Security Incident Notification rules require notification within 36 hours of a material cybersecurity incident. The materiality standard there is different from (and generally lower than) the SEC standard — it covers incidents that disrupt business operations, impair the bank’s ability to deliver services, or affect financial stability. Dual-reporting obligations apply to many financial institutions that are both SEC registrants and bank subsidiaries.

Documentation in Real Time

The most consistent failure mode in the first wave of SEC comment letters wasn’t bad judgment — it was the absence of contemporaneous documentation. Reconstructed timelines, after-action summaries written two weeks after the incident, and gap-filled narratives don’t establish that you made a thoughtful, timely decision.

During triage, the incident record should be capturing in real time:

• Detection timestamp and source (SIEM alert, external report, employee notification)
• Affected systems, data types, and initial scope estimate
• Analyst initial classification with stated rationale
• Escalation notifications with timestamps and responses
• Containment actions taken, by whom, and when
• Materiality assessment trigger (when the determination process began)
• Key facts considered in the materiality analysis
• Final determination with names, dates, and rationale

This documentation isn’t just for the SEC. It’s your forensic chain of custody, your regulatory exam artifact, and your litigation evidence. Teams that treat the incident ticket as a technical log and handle escalation through Slack are creating a documentation gap that becomes costly when the regulators come asking.

Common Triage Failures (and Where They Show Up)

1. The “wait for more data” delay spiral. The investigation needs more time before escalating. Then a bit more. Before long, four business days have passed from the materiality determination and the filing is late. Set hard deadlines for escalation triggers regardless of investigation completeness.

2. Severity inflation pressure from business units. “If we call this a P1, we have to notify the board and the CEO will panic.” Severity ratings must be insulated from organizational pressure. Pre-define tiers in policy so the analyst isn’t making a judgment call about executive reactions.

3. Treating “not yet confirmed” as “not material.” The SEC standard doesn’t require certainty — it requires reasonable assessment. An incident that will likely be material once investigation confirms scope cannot be held in limbo indefinitely while investigation continues.

4. No backup for the person who knows the escalation path. The analyst who knows which escalation contacts to call is on PTO. The incident response plan lives in a shared drive the on-call engineer doesn’t have access to at 2am. Run tabletop exercises specifically focused on triage — not just containment — to find these gaps.

So What?

The triage decision is where incident response and regulatory compliance intersect. Getting severity wrong delays the right response. Getting the materiality determination wrong — in either direction — creates SEC enforcement exposure. And failing to document either decision in real time turns a manageable incident into an examiner finding.

The SEC’s clarifying guidance from May 2024 and the first-year filing analysis from Greenberg Traurig both point to the same underlying problem: companies that haven’t built the decision infrastructure before an incident happens. Severity tiers without dollar thresholds. Escalation paths with no backup contacts. Materiality processes with no cross-functional ownership.

Build the framework before the alert fires. When it does, you’ll be making one decision, not inventing a process.

The RiskTemplates Incident Response & Breach Notification Kit includes incident response playbooks with built-in severity classification tiers, a materiality decision worksheet for SEC purposes, escalation protocol templates, and breach notification timelines for all 50 states — plus tabletop exercise scenarios to test your triage process before an incident occurs.

Further Reading

• Incident Response Plan Template: The 6 Phases (and What Most Templates Miss)
• Cyber Incident Response Playbook: From Detection to Lessons Learned
• SEC Cybersecurity Disclosure Rule: What’s Material, How to File, and Lessons from Early Enforcement

Sources:

• SEC Corp Fin Director Gerding: Disclosure of Cybersecurity Incidents Determined To Be Material (May 2024)
• SEC Cybersecurity Disclosure Trends: 2025 Update — Greenberg Traurig
• Lessons Learned: One Year of Form 8-K Material Cybersecurity Incident Reporting — NYU Compliance and Enforcement Blog (March 2025)
• Lessons Learned: One Year of Form 8-K — Debevoise & Plimpton (February 2025)
• CISA National Cyber Incident Scoring System (NCISS)