Introduction
An SEC 8-K cybersecurity incident filing under Item 1.05 gives a public company four business days to disclose an incident once the company determines it is material. That clock is tied to the determination itself, a distinction that matters enormously once a legacy system is involved.
Item 1.05 applies to any US public company subject to SEC reporting obligations. A materiality determination is the internal process, typically run by a disclosure committee, that decides whether an incident is significant enough to trigger the filing requirement.
Companies running modern, monitored infrastructure can usually complete that process, even though it stays difficult. Companies running legacy systems face a different problem: the process breaks down at the evidence layer before the committee ever gets to apply the standard.
The determination requires a disclosure committee to apply a securities law test to a set of facts about scope, data exposure, and business impact. When the breached system is running on an unsupported stack with no monitoring or audit trail, those facts are often the one thing the company cannot produce on any defensible timeline.
This article covers what the materiality determination actually requires, why legacy systems break that requirement at the evidence level rather than just the clock level, and why a “not material” call made on incomplete facts tends to reopen later on worse terms than if it had never been made.
The Materiality Standard Behind Every SEC 8-K Cybersecurity Incident Filing
The SEC adopted its cybersecurity disclosure rules in July 2023. Item 1.05 requires a company to file a Form 8-K within four business days of determining that a cybersecurity incident is material [1]. The determination itself must happen without unreasonable delay after discovery, though the rule sets no fixed number of days for that step.
The standard governing the determination is the same one that has applied to securities disclosure for decades: information is material if there is a substantial likelihood a reasonable investor would consider it important, or if it would alter the total mix of information available to investors. That test is holistic. It weighs quantitative and qualitative factors together, and it treats a reasonably likely future impact the same as a confirmed one.
For a cybersecurity incident, that holistic test breaks down into a recurring set of factor groups.
| Factor Group | What It Requires Knowing | Example Inputs |
| Financial exposure | Direct loss, remediation cost, revenue impact | Incident response spend, downtime cost, insurance coverage |
| Operational disruption | Duration and breadth of affected business functions | Which systems went down, for how long, and what depended on them |
| Data exposure | Categories and volume of data implicated | Personal data, payment data, source code, confidential business data |
| Reputational and customer trust | Scope of customer notification, brand exposure | Number of affected customers, prior incident history |
| Regulatory and legal | Likelihood of litigation or regulatory action | State breach law triggers, sector-specific reporting duties |
| Strategic significance | Whether affected systems touch core business functions | M&A pipeline, regulated product lines, key counterparty relationships |
Every one of these factor groups depends on a company being able to state, with reasonable confidence, what happened and how far it reached. That dependency is where the next section picks up.
Why Legacy Systems Can’t Produce the Evidence a Materiality Determination Needs
A disclosure committee applying the test above needs a starting point. Security has to hand the committee a working picture: which systems were touched, what categories of data were potentially exposed, and a scope estimate the committee can weigh against the factor groups.
That handoff assumes the breached environment can produce it. An unsupported application with no structured logging, no dependency map, and no monitoring pipeline generally cannot. When a legacy system is compromised, the organization frequently cannot say with confidence what was accessed, when, or how far the exposure extends, because the system was never built to answer that question.
This condition persists regardless of staffing levels, because the system itself was never built to answer the scope question. The Cybersecurity and Infrastructure Security Agency has stated plainly that it does not assume legacy products still running in production are fully patched, and does not assume end-of-life products have been decommissioned [2].
Unsupported software accumulates vulnerabilities that no vendor will ever patch, and that condition compounds every month a system stays in production.
Research tracking the Known Exploited Vulnerabilities catalog found that nearly half of the entries trace back to end-of-service software, and that vulnerabilities in end-of-life systems are roughly four times more likely to be weaponized than vulnerabilities in supported ones [3].
This is not hypothetical. Applications running on VB6, Ab Initio-based data pipelines, or Java monoliths still deployed on end-of-life WebLogic or JBoss frequently have no native telemetry, no structured logging, and no dependency map that a forensic team can pull on day one of an incident response.
The SEC has already brought an enforcement action against a company specifically for this kind of structural gap, charging the absence of a process that could have supplied the facts in time as its own violation, apart from the disclosure language itself. That case is covered in detail below.
The table below lines up what a defensible determination needs against what an unsupported stack typically has available.
| What the Determination Needs | What a Monitored, Supported System Provides | What an Unsupported Legacy System Typically Provides |
| Scope of affected systems | Structured logging, dependency mapping | Fragmented or absent logs, undocumented integrations |
| Categories of data implicated | Data classification tied to system inventory | Unclear data flows, no current inventory |
| Timeline of the incident | Timestamped audit trail | Little or no audit trail |
| Confidence in the scope estimate | Forensic tooling compatible with the platform | Forensic tooling built for supported platforms, often incompatible |
The gap extends the clock and changes what the committee is adjudicating. A committee weighing the six factor groups above on a confirmed scope estimate is making a defensible judgment call. A committee weighing the same factors on a scope estimate it knows is incomplete, because the system cannot confirm it, is making a provisional call that has not been named as provisional. That distinction becomes the problem in the next section.
See what your legacy estate would actually tell a disclosure committee before an incident forces the question. Start with a $0 Modernization Assessment.
The Item 1.05(c) Amendment Trap When Legacy System Scope Surfaces Late
Item 1.05(a) does not require a company to have every fact confirmed before filing. A company can disclose the material or reasonably likely material impact of an incident and state that specific information is not yet determined. Item 1.05(c) then requires an amended filing within four business days of the point that missing information becomes known [4].
That structure works cleanly when the gap between the initial filing and the missing fact is short. It becomes a liability when the missing fact is scope itself, and scope only becomes knowable weeks or months later because the affected system could not produce it faster.
A few conditions tend to trigger the reopening of a prior determination:
- The affected systems list grows as forensic work uncovers previously unmapped integrations
- Additional categories of data are confirmed implicated once a fuller investigation completes
- A regulator opens an inquiry or a state attorney general issues a civil investigative demand
- A litigation threat or class action complaint surfaces new facts about the scope of exposure
The without-unreasonable-delay standard does not reset when one of these triggers fires. It anchors to the moment the fuller scope became knowable, not to the moment the company chose to revisit the determination.
A company that made a reasonable “not material” call on the facts it had, using a system that could not produce better facts faster, is now evaluated against a standard that assumes it should have known sooner. That is a materially worse position than the one the company was trying to avoid by filing carefully the first time.
Prudential Financial’s February 2024 incident shows how far scope can move after an initial filing. The company’s original disclosure described a threat actor accessing administrative and user data affecting a small percentage of accounts, and an early breach notification cited roughly 36,500 affected individuals.
Later breach-notification updates months afterward put the confirmed number above 2.5 million people, once fuller forensic work was complete [5].
The scope that mattered to the eventual materiality picture was not available at the time of the earliest filing, which is exactly the condition this section describes.
What to File When You Can’t Make a Determination Yet: Item 8.01
Item 1.05 is not the only option while a materiality determination is still in progress. The SEC’s May 2024 guidance directed companies not to use Item 1.05 for incidents that have not yet been determined material, or that have been determined immaterial, and pointed instead to Item 8.01 as the appropriate vehicle for that kind of voluntary disclosure [1].
A legacy system breach where scope cannot yet be confirmed is exactly the scenario this guidance anticipates.
Filing under Item 8.01 lets a company communicate that an incident occurred without triggering the four-day Item 1.05 clock, since that clock only starts once a materiality determination has actually been made. It does not pause the separate obligation to make that determination without unreasonable delay.
If the incident is later determined material, the company must then file a full Item 1.05 Form 8-K within four business days of that determination.
The risk sits on the far side of that sequence. If the scope eventually confirmed turns out to be large, both the original Item 8.01 filing and the gap between it and the later Item 1.05 filing come under scrutiny, and a longer gap reads worse when the reason for it was a system that could not produce answers any faster.
The Unisys Enforcement Action and the Cost of Missing Escalation Controls
In October 2024, the SEC settled charges against four companies, all downstream of the 2020 SolarWinds intrusion, for filing risk factor language that described realized cybersecurity exposure as a hypothetical possibility [6]. Unisys drew the largest penalty at four million dollars and a second charge the other three companies did not face.
The second charge was for deficient disclosure controls. The SEC alleged that Unisys had no defined process requiring cybersecurity personnel to escalate incident information to the executives responsible for SEC filings. That is a different finding from the misleading-language charge. It is a finding about the organization’s architecture rather than its wording, and about whether that architecture could support an accurate and timely determination.
The distinction matters directly for a company running material legacy exposure. The people responsible for the filing do not have the facts they need when they need them, whether the cause is a missing process or a missing audit trail.
One is an organizational gap and the other is a technical one, but both produce the same downstream symptom and land on the same enforcement theory.
For a closer look at how this same enforcement record reshapes the annual Item 1C risk-factor language public companies file about legacy exposure, see our breakdown of SEC cybersecurity disclosure rules for legacy systems.
Legacyleap’s Gen AI Agents Build the Evidence Base Before a Legacy System Forces the Question
The evidence gap described above is a modernization problem before it is a legal drafting problem, because disclosure policy cannot change what the underlying system is able to tell a committee.
Legacyleap is a Texas-based, Gen AI-powered legacy application modernization platform built on multi-agent orchestration, and that architecture is what closes this specific gap rather than a documentation exercise on its own.
Legacyleap has worked with multiple clients across healthcare, BFSI, manufacturing, and other regulated and legacy-heavy industries, each carrying the same underlying evidence problem this article describes.
How the agent lifecycle closes the gap
- Assessment Agent: builds the dependency map, data flow inventory, and system-level documentation a disclosure committee needs as a starting point, before an incident forces the question
- Modernization Agent: applies Gen AI within a governed, diff-based transformation process that engineering teams review and approve before any change is accepted, carrying the application onto a supported platform with an active patch channel
- QA Agent: validates behavior parity between the legacy and modernized versions through auto-generated regression and functional test suites, confirming the modernized system behaves as the original did before it goes into production
The result is a system that can produce the audit trail, structured logging, and monitoring integration a determination depends on, because those capabilities exist on the modern platform the system now runs on.
That shift covers the full lifecycle the argument above depends on: the Assessment Agent builds the evidence base a determination needs today, and the Modernization and QA Agents remove the structural cause of the evidence gap going forward.
For public companies carrying legacy exposure into a disclosure obligation, Legacyleap operates as the modernization partner built specifically to close this evidence gap, working across assessment, transformation, and validation so the underlying system can finally produce what a determination requires.
Reducing the Legacy Footprint That Creates This Exposure
An accurate materiality determination requires evidence that a legacy system was never built to produce. That gap does not go away with a better-documented process. It goes away when the system that would generate the incident is no longer the one with no audit trail.
The most durable way to reduce this exposure is to have fewer systems in production that cannot answer the scope question when it matters.
Legacyleap’s Free Security Assessment maps a legacy estate’s vulnerabilities and unresolved CVEs, separates compliance risk from security risk, and delivers findings in three to five days, entirely inside the client’s own infrastructure, with no source code leaving the environment. Request a Free Security Posture Assessment to see this mapped against your own environment.
To see how the Assessment, Modernization, and QA Agents work against a real codebase before sharing your own, book a technical demo.
FAQs
Item 1.05 applies only once an incident is determined material, starting the four-day clock. Item 8.01 is the voluntary path for incidents still undetermined or found immaterial.
No. A company can disclose a reasonably likely material impact and flag that specific details are still unknown, then amend within four days once that information becomes available.
It gets reopened. Triggers like scope expansion or a regulatory inquiry restart the clock from when the fuller picture became knowable, not from when the company revisited it.
A determination needs bounded facts about scope and data exposure. Unsupported legacy stacks often lack the logging and monitoring needed to produce those facts in time.
A separate charge for having no defined process to escalate incident information to the executives responsible for SEC filings, treated as its own violation.
References
[1] SEC, Erik Gerding, “Disclosure of Cybersecurity Incidents Determined To Be Material and Other Cybersecurity Incidents,” May 21, 2024, https://www.sec.gov/newsroom/speeches-statements/gerding-cybersecurity-incidents-05212024
[2] CISA, “BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities,” https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities-revoked
[3] HeroDevs, “How Outdated Systems and Legacy Software Are Fueling Modern Cyber Attacks,” https://www.herodevs.com/blog-posts/how-outdated-systems-and-legacy-software-are-fueling-modern-cyber-attacks
[4] SEC, “Compliance and Disclosure Interpretations: Exchange Act Form 8-K,” https://www.sec.gov/rules-regulations/staff-guidance/compliance-disclosure-interpretations/exchange-act-form-8-k
[5] McGuireWoods, “SEC Settles Charges for Alleged Misleading Disclosures, Shedding Light on Materiality in Cyber Context,” October 2024, https://www.mcguirewoods.com/client-resources/alerts/2024/10/sec-settles-charges-for-alleged-misleading-cyber-disclosures/
