As we reported in our March 2022 client alert, the Securities and Exchange Commission released proposed cybersecurity reporting rules and solicited feedback through a 60-day comment period. The comment period ended on May 9, 2022, and the SEC received 100+ comments from business, legal, nonprofit and government sectors.
While the comments ranged from broadly supportive to particularly critical, many shared common apprehensions about specific provisions of the rule. Below, we discuss eight key issues raised and solutions proposed by multiple commentors concerning:
1. Timing of Incident Notice
The four business-day deadline for reporting a material cybersecurity incident is too short for companies to evaluate the incident, prepare a report and determine whether the incident in question is material – and premature reporting could increase security risks.
- A 30-day reporting deadline tolled during a reasonable investigation to determine whether the disclosure would impede the registrant’s ability to contain and remediate the incident.
- Permit governmental agencies to vet and authorize reporting delays.
- Adjust disclosure framework to reflect state notification statutes.
- Allow smaller reporting companies additional time to fully investigate and disclose the situation.
Some existing US state, federal (e.g., the Health Insurance Portability and Accountability Act, or HIPAA) and non-US breach notification laws allow for a reasonable investigation before the clock starts ticking for breach notification deadlines. While the four business-day reporting requirement has existed for Form 8-K Current Reports for some time, the uncertainty associated with discovering and confirming a security incident warrants a different – and more flexible – approach. In this context, as in many of the US state breach notification laws, a more appropriate standard would require reporting material cybersecurity events “without unreasonable delay.” This standard would allow for both a reasonable investigation to confirm whether a security incident occurred, and further analysis as to its “materiality” for financial reporting purposes. As most seasoned breach response lawyers know, many times neither of these findings are readily apparent when an organization gets its first indications of a potential security incident. The failure to calibrate this time frame likely will lead to the same knee-jerk over-reporting that has plagued data protection regulators in Europe since the General Data Protection Regulation (GDPR) took effect, which undermines the SEC’s desire to provide shareholders with meaningful, accurate and actionable information to make buy/sell decisions.
2. Law enforcement and national security delayed-reporting exceptions
Reporting delays should be permitted for incidents subject to law enforcement and/or national security investigations.
- Permit delayed reporting of a cybersecurity incident that is the subject of a bona fide investigation by law enforcement or other public authorities. This delay would allow companies to remain in compliance while maintaining the security and confidentiality measures needed to run a complete investigation and comply with law enforcement and national security needs. For example, law enforcement may recommend a course of action that could extend beyond four days. These exceptions would avoid frustrating law enforcement efforts when appropriate.
The need here, which also is recognized by most US state breach notification laws, is driven by two concerns. First, a Form 8-K report could inform threat actors that their successful breach efforts have been discovered. When this occurs, threat actors have been known to take steps to cover their tracks, delete evidence, dismantle infrastructure and avoid detection. This can undermine a new or ongoing criminal law enforcement investigation. Second, where a breach affects the supply chain or critical infrastructure, reporting a cybersecurity incident can have national security implications. For example, a cyber incident report could effectively reveal a zero-day exploit common across an industry segment to the public, which increases the likelihood of wider exploitation. This is a serious concern with respect to security researchers and the reporting of critical vulnerabilities, and a common practice is to withhold reporting of serious vulnerabilities until after a patch or other remedy is available for widely-used software or services. In fact, for incidents that could have a national security impact, the better rule would first require reporting to law enforcement (with confidentiality guarantees) to avoid creating much more significant risks and impacts.
3. Definitions of key terms
The definitions of “cybersecurity incident,” “cybersecurity threat” and “information systems” are too imprecise, overly burdensome, or create disjointed compliance requirements with other reporting regimes.
- Employ definitions used by NIST. For example, NIST defines a “cybersecurity incident” as “an occurrence that (1) actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or (2) constitutes a violation or imminent threat of violation of law, security policies, security procedures or acceptable use policies.”
- Employ definitions used in the Cybersecurity Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA). For example, an “incident” is defined as “an occurrence that actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information on an information system, or actually or imminently jeopardizes, without lawful authority, an information system.”
- Employ definitions used in the SEC’s Release No. 33-11028. For example, it defines a “cybersecurity incident” as “an unauthorized occurrence on or conducted through a [company]’s information systems that jeopardizes the confidentiality, integrity, or availability of a [company]’s information systems or any [company] information residing therein.”
- Employ definitions used in the 2016 Presidential Policy Directive on United States Cyber Incident Coordination. For example, it defines a “cyber incident” as “an event occurring on or conducted through a computer network that actually or imminently jeopardizes the integrity, confidentiality, or availability of computers, information or communications systems or networks, physical or virtual infrastructure controlled by computers or information systems, or information resident thereon. For purposes of this directive, a cyber incident may include a vulnerability in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source.”
- Establish tiers of important information and describe the impact on the issuer’s evaluation for each tier level. These tiers provide companies with a framework to consider the severity and materiality of cybersecurity incidents as they occur.
Defining a security incident has been a challenge since the drafting of the Computer Fraud and Abuse Act of 1986 (and probably earlier). That challenge is present in the SEC’s proposed rule as well. However, it is not clear that any of the suggested definitions or standards are any less ambiguous. Again, as experienced security and legal practitioners know, modern companies face a multitude of events that could result in a security incident, which could include everything from a critical (but potentially unexploited) vulnerability to “pings” or attempted security breaches to minor breaches that have little impact to an organization (e.g., “cryptojacking” software used to mine bitcoin). When it comes to reporting financially significant security incidents, it is better to have a brighter line definition, which would include the following elements:
- An opportunity for a reasonable investigation of a potential incident.
- A confirmation by the company of an actual security breach.
- A determination that the breach could reasonably have a material impact to the confidentiality, availability or integrity of sensitive company information or critical systems.
The fourth element in this context is already built into the Form 8-K: whether the confirmed incident is material from a financial reporting/shareholder point-of-view.
4. Board of directors’ cybersecurity expertise disclosure requirement
The board of directors’ cybersecurity expertise disclosure requirement is overly burdensome and/or unnecessary.
- Remove this requirement, because it could likely transform into a de facto requirement for registrants to find board members with cybersecurity expertise. In turn, the absence of such board expertise may be misconstrued by the public as a signal that the company does not take cybersecurity seriously. This could increase securities litigation, including for companies that do, in fact, have robust cybersecurity controls in place.
- Define the criteria for “cybersecurity expertise” more broadly so that smaller companies can more easily comply. As written, it may be difficult for differently sized registrants to meet the requirement, given the lack of availability of recognized experts and the difficulties and costs of finding such experts.
- Alternatively, allow this requirement to be satisfied at the management and/or enterprise level.
While a strict requirement for board expertise is onerous, having such expertise on the board can be helpful. Having some element of fluency on cybersecurity matters on the board can facilitate the board’s ability to appropriately oversee management’s preparations for, and responses to, cybersecurity incidents. However, the rule’s focus on cybersecurity expertise is arguably too narrow. Cybersecurity expertise should be married with financial, legal, and business-oriented expertise so companies can understand and measure potential adverse impacts that may arise out of a security incident. The necessary stakeholders to enable measurement of those adverse impacts reside at the management/enterprise level (and less so at the board level).
5. Aggregation of immaterial events
The requirement to disclose previously undisclosed individually immaterial cybersecurity incidents when they have become material in the aggregate requirement is impractical, unnecessary, and/or overly vague.
- Remove this requirement because it is highly subjective and practically unworkable.
- Alternatively, provide significantly more definitive guidance regarding how, under what circumstances, and over what period incidents are subject to the requirement, including a list of non-exhaustive examples for reference.
- Set a one-year limitation to the analysis, as the current requirement provides no temporal limits.
This concept is novel to the cybersecurity world. It is unclear how such immaterial events will manifest into something that has a material impact for Form 8-K purposes. It would be helpful for the SEC to provide concrete examples that illustrate the concerns it hopes to address with this requirement.
6. Risk management, strategy and governance disclosure requirements
The risk management, strategy, and disclosure requirements will heighten exposure to future cyberattacks – i.e., the disclosure will provide attackers with a “road map.” The disclosures may also reveal protected intellectual property.
- Remove this requirement, as it could tip off malicious actors to thematic vulnerabilities within an affected company.
- Include less detailed and prescriptive requirements, and/or make clear that broad summary descriptions of policies and programs should suffice. The level of specificity contemplated by the proposal will not increase the flow of material information to investors, given that companies already are required to disclose cyber risks in quarterly filings.
- Incorporate some form of confidentiality framework that would allow companies to demonstrate their preparedness for a potential cyber incident while not creating additional risk exposure to cyberattacks.
We have three points to make here. First, too much detail concerning a company’s cybersecurity risk assessment and security measures could create security risks by informing potential threat actors of a company’s defenses and security weaknesses. Most companies are very careful to avoid publicizing their internal security procedures and protocols. Second, it is unclear how these required disclosures will be helpful or useful for average shareholders and enable them to make trading decisions. While the proposed rule does require a fair amount of detail, it is likely not enough information for an average shareholder to identify companies with materially weak security. Third, having to make broad statements about complex security issues, as is currently required, exposes companies to unnecessary liability should those statements prove inadvertently incomplete or not adequately qualified. This also creates yet another potential hook for the plaintiffs’ bar and regulators in actions against public companies.
7. Safe harbor provisions
As provided by Rules 13a-11 and 15d-11 under the Securities Exchange Act of 1934 (i.e., that a Form 8-K is not required if the “substantially the same information” required by Form 8-K has been previously reported by the registrant), include safe harbors from public and private claims for failing to timely file a Form 8-K disclosure, particularly in instances where the breach information is obtained from third parties – and may not be reliable or able to be confirmed – and when public companies are not reasonably able to verify accuracy and completeness of the information provided.
- In its solicitation for comment, the SEC explicitly requested input on whether it should incorporate the above two safe harbors in its final rule. Many commenters supported incorporating both, and argued that the safe harbors would further the SEC’s goal of facilitating “more timely and consistent disclosure about material cybersecurity incidents.”
- Others argued that not including the safe harbors would be unduly harsh.
We tend to agree that if a material cybersecurity risk has been previously reported, an additional and redundant Form 8-K report should not be required. The comments correctly highlight the uncertainty in determining whether a cybersecurity incident has actually occurred and its materiality from a financial reporting perspective. This concern dovetails with the need to carefully and precisely define what constitutes a notifiable cybersecurity incident (as discussed above). It also highlights the challenges of reporting a material cybersecurity incident in such a short time frame, which requires a careful balance between providing accurate and useful information and timeliness.
8. Fear of regulatory disharmony
The SEC’s proposed rule could lead to disjointed cybersecurity compliance requirements, given that state laws contain different requirements for determining whether a breach has occurred, and because CIRCIA has not yet conducted rulemaking to define key terms, including a “covered entity.”
- Standardize defined terms in the proposed rule with existing cybersecurity reporting requirements, such as the definitions provided by NIST, state data breach notification laws and/or CIRCIA.
- More clearly stipulate how it intends to harmonize this myriad of cybersecurity reporting regulations. For instance, the SEC could directly acknowledge the requirements and definitions of other reporting regimes, and provide an analysis of how its proposed rules do and do not align with them.
Yes, more reporting laws with different triggers, definitions, timing elements, and reporting requirements create uncertainty and confusion. This has been the case for some time with 50 different state breach notification laws, a federal overlay (e.g., HIPAA and the Gramm-Leach-Bliley Act, or GLBA), and reporting requirements under foreign laws. That said, the audience in this case is different from the audience under traditional breach notification laws. The concern here ties to shareholder decision-making, not protecting oneself from the personal impacts of a data breach. However, the 8-K Form current report already serves as a general mechanism for reporting material events to shareholders. Arguably, some of the obligations in the SEC’s proposed rule already exist. So, it is a fair question to ask why the proposed rule is needed at all – especially given the multitude of reporting obligations in other contexts.