What the SEC Cybersecurity Disclosure Rules Require from Public Software Companies
The SEC cybersecurity disclosure rules require every public software company to (1) report material cybersecurity incidents on Form 8-K Item 1.05 within four business days of determining materiality, and (2) describe — in their annual Form 10-K Item 106 — the processes used to assess, identify, and manage material cybersecurity risks, along with board and management oversight of those risks. Adopted in July 2023 and in force across the 2024 and 2025 reporting cycles, the rules apply to domestic registrants on the standard four-business-day clock, with foreign private issuers reporting comparable disclosures on Form 6-K and 20-F. For software companies specifically, the practical bite of the rule lands on open-source vulnerabilities — the CVEs (Common Vulnerabilities and Exposures) buried in transitive dependencies, end-of-life (EOL) libraries no longer patched upstream, and legacy systems your scanners flag as "no fix available." Heading into 2026, with AI-assisted exploitation compressing the window between disclosure and weaponization, the question is no longer whether you must disclose, but whether your remediation capacity can keep pace with a four-day clock on code you cannot safely upgrade.
What exactly do the SEC cybersecurity disclosure rules require from public software companies?
What exactly the SEC requires from public software companies under its cybersecurity disclosure rules breaks down into two distinct obligations: rapid incident disclosure and annual program disclosure. Both took effect for most registrants in late 2023, and by 2026 they are a settled part of the 10-K and 8-K rhythm for any U.S.-listed software business.
The rules live in two specific filings, each with its own scope, trigger, and content requirement.
What are the two filing obligations?
| Attribute | Form 8-K, Item 1.05 | Regulation S-K, Item 106 (in Form 10-K) |
|---|---|---|
| Trigger | A cybersecurity incident determined to be material | Annual reporting cycle |
| Deadline | Four business days after the materiality determination | With the annual report |
| Scope | The specific incident | The company's overall cybersecurity program |
| Required content | Nature, scope, and timing of the incident; material impact or reasonably likely material impact on the registrant | Processes for assessing, identifying, and managing material risks from cybersecurity threats; board oversight; management's role and expertise |
| Delay permitted? | Yes, only if the U.S. Attorney General notifies the SEC that disclosure poses a substantial risk to national security or public safety | No |
Which attributes of your program must you describe?
Item 106 is explicitly about processes, not controls inventories. Public software companies must disclose:
- Risk-management processes — how cybersecurity risk is identified, assessed, and integrated into the broader enterprise risk program.
- Third-party engagement — use of assessors, consultants, auditors, or other parties, and oversight of risks from third-party software providers (relevant to open-source and vendor dependencies).
- Prior incidents — whether previous incidents have materially affected, or are reasonably likely to materially affect, the registrant.
- Board oversight — which committee owns cybersecurity and how it is briefed.
- Management role and expertise — who runs the program (typically the CISO), their relevant background, and how they report up.
In short, the SEC does not prescribe controls or tooling. It requires that you describe, in plain English, how you govern cybersecurity risk and that you disclose material incidents on a strict four-business-day clock.
Which Form 8-K Item 1.05 incident disclosures must software companies file within four business days?
Form 8-K Item 1.05 requires public software companies to file a disclosure within four business days of determining that a cybersecurity incident is material. The clock does not start at detection — it starts at the materiality determination, which the SEC says must be made "without unreasonable delay." That distinction is where most AppSec and legal teams get into trouble.
What must the Item 1.05 filing actually contain?
The filing must describe the material aspects of the incident's nature, scope, and timing, plus the material impact (or reasonably likely material impact) on the registrant, including its financial condition and results of operations. You are not required to disclose specific technical details, the affected system names, vulnerabilities exploited, or the incident response status if doing so would impede the response — but you cannot use that as a blanket excuse to omit material facts.
A narrow national-security or public-safety delay is available only with written Attorney General notification to the Commission.
Which actions trigger the four-business-day clock, and what are the tradeoffs?
| Do this | But watch out for |
|---|---|
| Convene a materiality committee the moment an incident is confirmed | Stalling the determination to buy time is itself a disclosure risk — the SEC reads "unreasonable delay" strictly |
| File on Item 1.05 even when facts are incomplete, then amend via 8-K/A within four business days of learning new material information | Under-disclosing the scope to protect the investigation can trigger enforcement for misleading omissions |
| Coordinate Legal, IR, SecOps, and the CISO on a single approved narrative before filing | Parallel statements to customers, regulators, or press that diverge from the 8-K create securities-law exposure |
| Treat an exploited open-source CVE — including transitive dependencies in End-of-Life (EOL) components — as potentially in-scope | Assuming a vulnerability in an un-upgradeable legacy library is "not material" because no fix exists; remediation pathways like back-porting (applying the security fix to the version you already run) exist and regulators expect you to know that |
Mitigation tip for the highest-impact risk: pre-wire the materiality committee with documented criteria before an incident — ambiguity at hour zero is what blows the four-business-day window.
How should public software companies determine whether a cyber incident is 'material'?
Public software companies determining materiality face a question that depends on what you mean by "material" — the term carries at least two distinct meanings under SEC rules, and conflating them is the most common compliance mistake.
What are the two competing definitions of materiality?
Financial-statement materiality is the older, accounting-driven concept: would a misstatement of this magnitude influence a reasonable investor's view of the financials? This is quantitative and typically tied to revenue or earnings thresholds.
Securities-law materiality — the standard that governs Item 1.05 of Form 8-K — is broader. Under the TSC Industries v. Northway test, information is material if there is a substantial likelihood a reasonable investor would consider it important in making an investment decision. For a cyber incident, that turns on qualitative impact, not just dollars: reputational harm, customer trust, regulatory exposure, the nature of compromised data, and operational disruption all count.
The SEC has been explicit that public software companies cannot default to a quantitative-only threshold. A breach that leaks source code or signing keys may be material even if direct financial loss is modest.
How should the determination process actually run?
A defensible process for software issuers typically includes:
- A standing disclosure committee that includes security, legal, finance, and investor relations — not security alone.
- Pre-agreed qualitative factors: data sensitivity, system criticality, customer contractual exposure, third-party (open-source and supply-chain) involvement, and regulatory triggers under regimes such as PCI DSS 4.0, DORA, or NYDFS.
- A "without unreasonable delay" clock: once enough facts are known to assess materiality, the determination must be made promptly — you cannot stall the clock by prolonging investigation.
- Contemporaneous documentation of the reasoning, even when the conclusion is "not material."
One underappreciated angle: incidents rooted in unpatched open-source components — particularly transitive dependencies or end-of-life libraries flagged by software composition analysis tools as "no fix available" — invite sharper scrutiny in 2026, because regulators increasingly view known-but-unremediated CVEs as a foreseeable, and therefore disclosable, risk posture.
What annual Regulation S-K Item 106 disclosures are required in the 10-K?
The annual disclosures under Regulation S-K Item 106 require public companies to describe, in their Form 10-K, how they identify, assess and manage material risks from cybersecurity threats — including open-source and supply-chain risk — and the governance structures that oversee that work. Unlike the four-business-day Item 1.05 8-K trigger for material incidents, Item 106 is a yearly narrative obligation organized into two halves: risk management & strategy (Item 106(b)) and governance (Item 106(c)).
What attributes must the risk management & strategy disclosure cover?
Item 106(b) asks registrants to describe specific, enumerable attributes of their cyber risk program. Each attribute below has a defined scope and a reason it matters to investors:
| Required attribute | Allowed scope / values | Why it matters |
|---|---|---|
| Processes for assessing, identifying and managing cyber risk | Narrative description; must say whether processes are integrated into the broader enterprise risk management (ERM) program | Signals maturity and consistency with COSO/ISO 31000-style ERM |
| Use of third parties | Assessors, consultants, auditors, MSSPs | Investors weigh independence and assurance quality |
| Oversight of third-party / supply-chain risk | Processes covering vendors and open-source dependencies, often informed by an SBOM in SPDX or CycloneDX format | Captures transitive and software-composition exposure |
| Material incidents to date | Whether prior incidents have materially affected, or are reasonably likely to affect, strategy, operations or financial condition | Connects program description to actual outcomes |
What attributes must the governance disclosure cover?
Item 106(c) zooms in on who is accountable. The required attributes are:
- Board oversight: which committee (audit, risk, or a dedicated cyber committee) owns cyber risk, and the cadence of reporting to it.
- Management role: the positions or committees responsible — typically the CISO, CIO or a cross-functional steering group — and their relevant expertise (prior roles, certifications, years in the field).
- Information flow: how management is informed about, monitors, and reports incidents and program status up to the board.
One underappreciated angle: Item 106(b) explicitly covers risks from third-party software, which means an un-remediated CVE in an end-of-life (software no longer patched by its maintainer) library is no longer just an engineering problem — it is a disclosable program weakness if material.
How do the SEC rules apply differently to SaaS and software vendors versus other industries?
When the SEC rules apply to public software and SaaS vendors, they hit a fundamentally different attack surface than they do for a bank or a manufacturer: your product is code, and most of that code is open source you did not write. That changes how Item 1.05 (material incident disclosure within four business days) and Regulation S-K Item 106 (annual cybersecurity risk-management and governance disclosure) translate into practice. If you ship software, your "cybersecurity risk" is inseparable from your software supply chain — the libraries, transitive dependencies, and base-OS packages that compose every release.
Which disclosure attributes matter most for software vendors?
The contextual reality is that SaaS and on-prem software companies must describe a risk program covering both their corporate environment and the code they distribute. The following attributes are the ones examiners and investors scrutinize most closely:
| Attribute | Allowed values / scope | Why it matters for software vendors |
|---|---|---|
| Incident materiality threshold | Qualitative + quantitative; product-impacting CVEs included | A critical CVE in your distributed library can be material even without a breach of your own systems |
| Software Bill of Materials (SBOM) practice | SPDX, CycloneDX, or none | Demonstrates you can identify exposure when the next Log4j hits |
| Remediation SLA | Hours-to-days for criticals | Investors read this as operational maturity; vague language invites scrutiny |
| Third-party / supply-chain governance | Documented intake, vetting, patch cadence | Item 106 explicitly asks about third-party risk |
| Board oversight cadence | Quarterly, named committee, named expertise | Required narrative under Item 106(c) |
| Legacy and EOL exposure | Inventoried, with a remediation path | EOL components are the hardest to disclose honestly without a fix strategy |
When does this context change your disclosure posture?
If you are a regulated-industry SaaS vendor (fintech, health, infrastructure), your customers' regulators — NYDFS, DORA, PCI DSS 4.0, FedRAMP — already demand evidence of timely remediation. Consistency across both audiences is the new bar.
Frequently Asked Questions
What exactly do the SEC cybersecurity disclosure rules require?
The SEC's rules, in force since late 2023, require public companies to disclose material cybersecurity incidents on Form 8-K within four business days of determining materiality, and to describe their cybersecurity risk management, strategy, and governance annually on Form 10-K. The 8-K must cover the incident's nature, scope, timing, and material impact (or reasonably likely impact) on the registrant.
When does a vulnerability — not an incident — trigger disclosure?
An unexploited vulnerability generally does not trigger an 8-K on its own; the rules center on incidents. However, a known critical vulnerability in a public software company's product that the company cannot remediate, and that creates material risk to customers or revenue, can become disclosable in the 10-K risk factors and governance sections. This is one reason regulated issuers increasingly track mean-time-to-remediate for critical CVEs (publicly catalogued software flaws).
How does back-porting help meet SEC disclosure obligations?
Back-porting — applying a security fix to the exact older library version already in production rather than forcing an upgrade — lets security teams close critical CVEs quickly without waiting on engineering refactors. Faster remediation shrinks the window in which an exploitable flaw could escalate into a materially disclosable incident, and it gives the 10-K governance narrative concrete evidence of an effective remediation program.
Do the rules apply to private software vendors selling to public companies?
Not directly, but indirectly yes. Public-company customers must describe oversight of third-party cybersecurity risk, so private vendors increasingly receive contractual flow-down requirements for SBOM (Software Bill of Materials) delivery, CVE remediation SLAs, and incident notification timelines tighter than the SEC's four business days.
How do SCA scanners fit into SEC compliance?
Software Composition Analysis tools — scanners such as Snyk, Checkmarx, and Black Duck that catalogue open-source dependencies and known vulnerabilities — give issuers the inventory and detection evidence regulators expect. They identify exposure but do not close it; pairing scanning with a remediation capability is what converts a finding into the fix that supports a defensible governance disclosure.
What should the 10-K cybersecurity governance section actually describe?
It should describe the board's oversight of cyber risk, management's role and expertise, the processes used to identify and manage material risks from cybersecurity threats, and how third-party providers fit into that program. Specifics like CVE intake processes, remediation SLAs for critical and high-severity findings, and handling of end-of-life or un-upgradeable components are increasingly expected as supporting detail.
Last updated: 2026-06-22