Skip to main content
Governance Authority
Category: Privacy and Cybersecurity

Cybersecurity Incident Disclosure

Also known as: Cyber Incident Disclosure, Material Cybersecurity Incident Disclosure
Simply put

Cybersecurity incident disclosure refers to the practice of publicly reporting significant cyber events that affect a company. Under rules adopted by the U.S. Securities and Exchange Commission (SEC) in 2023, publicly traded companies in the United States are generally required to disclose cybersecurity incidents they determine to be material. This disclosure is typically made through a designated regulatory filing within a set number of business days after the materiality determination.

Formal definition

Cybersecurity incident disclosure, as operationalized under the SEC's 2023 amendments, requires registrants to file current disclosure about a cybersecurity incident once it is determined to be material. Under the final rule, the underlying definition of a cybersecurity incident is described as not self-executing but rather operationalized through Item 1.05; the disclosure is generally required via Form 8-K within four business days of determining that the incident is material, rather than within four days of the incident's occurrence. The rule does not prescribe a fixed timeframe for making the materiality determination itself, and the obligation applies to U.S. public companies subject to SEC reporting; scope, applicability, and related requirements vary and this entry does not address disclosure regimes in other jurisdictions or the substantive analysis of what constitutes materiality. This entry is educational and not legal, audit, or compliance advice.

Why it matters

Cybersecurity incident disclosure sits at the intersection of compliance, risk, and investor protection. For U.S. public companies subject to SEC reporting, the SEC's 2023 amendments elevate certain cyber events from an operational security concern to a securities-law disclosure obligation. Once an incident is determined to be material, the company generally must file current disclosure via Form 8-K within four business days of that determination. This reframes cyber incidents as potentially price-sensitive information that the market is entitled to receive on a defined timeline.

The rule's structure places significant weight on the materiality determination, which triggers the disclosure clock. The four-business-day window runs from the materiality determination rather than from the incident's occurrence or discovery, and the rule does not prescribe a fixed timeframe within which that determination must be made. This makes the determination process itself a focal point for governance and controls: companies need a defensible, documented process for assessing materiality promptly, because delay in reaching a determination is an area of regulatory and reputational sensitivity.

Because the underlying definition of a cybersecurity incident is described in the final rule as not self-executing but rather operationalized through Item 1.05, companies cannot rely on the definition alone to know what and when to disclose; they must apply the operative disclosure requirement to their specific facts. The scope of the rule is limited to U.S. public companies subject to SEC reporting, and it does not address disclosure regimes in other jurisdictions. Organizations operating across borders may face additional or overlapping obligations that this entry does not cover.

Who it's relevant to

Boards and Audit or Risk Committees
Boards and their designated committees typically hold oversight responsibility for the company's disclosure processes and cyber risk governance. They generally do not perform the operational materiality assessment themselves, but they oversee whether management has an adequate, well-documented process for identifying incidents, reaching timely materiality determinations, and meeting the current disclosure obligation. Directors should understand that the disclosure clock runs from the materiality determination and that the rule does not set a fixed timeframe for making that determination.
General Counsel and Securities/Disclosure Functions
Legal and disclosure teams typically own the interpretation of Item 1.05 and the preparation of the Form 8-K. Because the definition of a cybersecurity incident is operationalized through the disclosure requirement rather than being self-executing, these functions apply the rule to specific facts, coordinate the materiality determination, and manage the four-business-day filing timeline once a determination is reached.
Chief Information Security Officers and Cyber Risk Teams
CISOs and security teams are generally the first to detect and characterize an incident and provide the technical facts that feed the materiality assessment. They typically do not make the securities-law materiality determination in isolation, but their timely escalation and factual input are essential to a defensible determination process that supports the disclosure obligation.
Chief Compliance and Risk Officers
Compliance and risk functions typically help design and monitor the cross-functional process that connects incident detection, materiality assessment, and disclosure. Their focus is generally on ensuring the process operates as designed and is documented, so that the company can demonstrate a reasoned basis for both its determinations and the timing of any resulting Form 8-K filing.
Internal Audit
As an assurance function, internal audit may evaluate the design and operating effectiveness of the controls supporting incident escalation, materiality determination, and disclosure. Internal audit generally provides independent assurance rather than owning the operational process itself.

Inside Cybersecurity Incident Disclosure

Materiality Assessment
The process by which a company evaluates whether a cybersecurity incident is significant enough to warrant public disclosure. In many jurisdictions, disclosure obligations are triggered by a materiality threshold, though the specific standard and timing vary by regime, sector, and entity type. This assessment is typically a management responsibility, subject to board or committee oversight.
Timing and Deadlines
The window within which disclosure must occur after an incident is identified or determined to be material. Requirements differ across regimes; some prescribe a fixed number of days from a materiality determination, while others frame disclosure around periodic reporting. Practitioners should confirm the applicable deadline for their jurisdiction and entity, as this is generally a legal requirement rather than voluntary guidance where a statute or regulation applies.
Content of Disclosure
The substantive information communicated, which may address the nature, scope, and timing of an incident and its reasonably likely impact. Many regimes do not require disclosure of specific technical details that could impede remediation or aid threat actors, but this depends on the applicable rule.
Governance and Oversight Disclosures
Separate from incident-specific reporting, some regimes require description of the processes for managing cybersecurity risk and the board's or a committee's role in oversight. This distinction separates ongoing program disclosure from event-driven incident disclosure.
Ownership and Accountability
The allocation of responsibility across the three lines: operational management typically detects, assesses, and remediates incidents; a compliance or legal function generally advises on disclosure obligations; and the board or a designated committee provides oversight rather than executing operational response. Internal audit or another assurance function may evaluate the effectiveness of these processes.
Applicable Regime and Jurisdiction
The specific legal, regulatory, or listing framework governing disclosure, which varies by where the entity is domiciled, listed, and operates, as well as by sector. Some obligations arise from binding law or listing rules, while frameworks and codes may offer non-binding guidance.

Common questions

Answers to the questions practitioners most commonly ask about Cybersecurity Incident Disclosure.

Does every cybersecurity incident have to be disclosed publicly?
No. Public disclosure obligations are generally triggered only when an incident meets a defined threshold, which under certain regimes is framed around materiality or a similar significance test, rather than by the mere occurrence of any incident. Many incidents are handled through internal escalation and remediation without any external reporting. Whether a specific event requires disclosure depends on the applicable statute, regulation, or listing rule, the jurisdiction, the entity type and sector, and the facts. Some sector-specific or data-protection regimes may separately require notification to a regulator or affected individuals on different criteria and timelines than securities-law public disclosure. These distinctions should be assessed with qualified legal counsel; this entry is educational and not legal advice.
Isn't cybersecurity incident disclosure just an IT or information security responsibility?
Not by itself. Detecting, containing, and remediating an incident are operational activities typically owned by management and the information security function, but the decision about whether and how to disclose is a distinct governance and legal judgment. In many organizations that determination involves legal, compliance, disclosure controls, senior management, and, depending on significance, the board or a designated committee. Boards generally exercise oversight of the disclosure process rather than performing the operational response. Separating the operational duty (management and security) from the oversight duty (board) and the disclosure determination (legal, disclosure controls, and management) is important; conflating them can obscure where accountability sits.
How does an organization determine whether a cyber incident meets the threshold for disclosure?
Organizations generally establish a documented process that applies the threshold defined by the relevant regime, which under certain securities frameworks centers on materiality assessed from the standpoint of a reasonable investor, and under other regimes may use different criteria. In practice this typically involves a cross-functional assessment considering factors such as the nature, scope, and potential impact of the incident. Because materiality and comparable tests depend on facts and judgment, many organizations pre-define escalation criteria, decision-makers, and consultation with legal counsel rather than relying on ad hoc evaluation. The applicable standard and any prescribed timeline vary by jurisdiction, sector, and entity type, so the specific threshold should be confirmed against the governing rules.
Who should be involved in the disclosure decision, and what is the board's role?
Roles typically include the information security and IT functions for operational facts, legal and compliance for the disclosure determination and regulatory analysis, disclosure controls or a disclosure committee where one exists, and senior management for approval. The board or a designated committee, such as audit or a risk or technology committee where established, generally provides oversight of the process and may be involved in decisions for incidents of sufficient significance. The board's role is generally one of oversight rather than day-to-day management of the response. How responsibilities are allocated depends on the entity's governance structure, its policies, and applicable requirements.
How can an organization prepare in advance to disclose within short regulatory timelines?
Where a regime imposes a defined reporting window, organizations commonly prepare through documented incident response and escalation procedures, pre-agreed criteria and decision authority for assessing significance, clear cross-functional roles, and template materials that can be tailored quickly. Tabletop exercises and integration between the incident response process and the disclosure controls process are frequently used to test readiness. Preparation supports timely, accurate disclosure, but it does not substitute for a facts-and-jurisdiction-specific determination at the time of an incident. The existence and length of any timeline vary by regime and should be confirmed against the governing rules.
How does incident disclosure relate to broader cyber risk management and internal controls?
Disclosure is generally one component of a wider system that includes cyber risk management and the controls supporting reliable, timely reporting. Under certain frameworks, controls relevant to disclosure are treated as part of disclosure controls and procedures, distinct from but connected to internal control over financial reporting. It is useful to distinguish control design, whether a process is capable of producing timely and accurate disclosure, from operating effectiveness, whether it functions as intended in practice. Assurance functions such as internal audit may evaluate these controls, while management owns their design and operation. How these elements are structured and tested depends on the applicable framework, requirements, and the organization's own judgment.

Common misconceptions

Every cybersecurity incident must be publicly disclosed.
In many regimes, disclosure obligations are triggered only when an incident meets a defined threshold, often materiality. Whether disclosure is required depends on the facts, the applicable jurisdiction, and the governing rule; minor or immaterial incidents generally may not trigger a public reporting obligation.
The board is responsible for detecting incidents and preparing the disclosure.
Detection, assessment, and remediation are typically operational responsibilities owned by management, with legal or compliance functions advising on disclosure. The board or a designated committee generally provides oversight of the process rather than performing it. Conflating oversight with execution misstates where accountability sits.
One disclosure standard applies uniformly across all companies.
Disclosure requirements vary by jurisdiction, sector, listing status, and entity type. Some obligations are binding law or listing rules while others reflect non-binding guidance, and thresholds, timing, and content differ across regimes. There is no single universally mandatory standard.

Best practices

Establish a documented process, owned by management, to escalate suspected incidents and determine materiality on a timely basis, with clearly defined criteria and decision-makers.
Confirm the specific disclosure obligations applicable to your entity's jurisdictions, sectors, and listing status, distinguishing binding legal or listing requirements from non-binding guidance, and involve legal or compliance counsel in that determination.
Define the respective roles of management, legal and compliance, and the board or a designated committee before an incident occurs, so oversight and operational responsibilities are not conflated under pressure.
Prepare disclosure content that addresses the nature, scope, and reasonably likely impact of an incident while avoiding technical details that could impede remediation, subject to what the applicable rule requires.
Coordinate incident-specific disclosure with ongoing governance and risk-oversight disclosures so that event-driven and program-level reporting remain consistent and are not treated as interchangeable.
Have an assurance function periodically evaluate whether the disclosure controls are appropriately designed and operating effectively, and treat this glossary content as educational rather than as legal, audit, or compliance advice.