The SEC released cybersecurity disclosure rules on July 26, 2023. These rules are meant to address the demand by investors regarding registrants’ cybersecurity risk management, strategy, and governance practices. The following overview is a high-level summary of the rules.
Overview of Requirements
The new disclosure rules are split into two requirements:
- Disclosure of material cybersecurity incidents
- Cybersecurity risk management, strategy, and governance
Disclosure of Material Cybersecurity Incidents
Organizations need to disclose the following information via Form 8-K:
- Material aspects of the nature, scope, and timing of the cybersecurity incident
- Likely material impact on the financial condition and results of operations
Organizations must make this disclosure within four business days of determining that an incident materially impacts an organization, barring a few exceptions.
Cybersecurity Risk Management, Strategy, and Governance
The annual Form 10-K filing should include sufficient detail for a reasonable investor to understand the following:
- Board leadership structure and administration of risk oversight, including any committees involved and processes for being informed of cybersecurity risk
- Processes for assessing, identifying, and managing material cybersecurity risks
- Any third-party involvement with the overall risk management system, with considerations for risks associated with using third-party providers
- How any cybersecurity threats have materially impacted or are likely to impact its business strategy, results of operations, or financial condition
- Management positions or committees responsible for assessing and managing cybersecurity risks along with their relevant expertise, how they’re informed of and monitor the prevention, detection, mitigation, and remediation of incidents, and whether they report cybersecurity risks to the board of directors, committee, or subcommittee
Defining Materiality for Your Organization
Defining materiality for your organization could involve various stakeholders such as IT, accounting, and legal departments, and possibly outside counsel. While financial impacts are obvious determinants of materiality, impacts to other data sets, such as customer data, data availability, intellectual property, or source code, should also be included in this decision process.
The US Supreme Court defines materiality as a fact that, if omitted, would have a substantial likelihood of being viewed by a reasonable investor as significantly alter the total information made available.
The process and people required for determining materiality need to be defined before a cybersecurity incident occurs or the organization would risk being unable to determine materiality without unreasonable delay.
One way to define materiality for organizations is to lean on your risk management program. If you have a strong risk management program, you’ve likely already identified the areas of your business that, if impacted, would lead to materiality. The problem is that few companies have strong risk management programs, perhaps being part of why the SEC has included materiality as part of the disclosure rule.
Reporting Risk Management
In an attempt at improving sales or practices, your company may have attempted to implement a security program based on a particular security framework, such as Systems and Organizational Control (SOC) 2® or International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) 27001. While most security programs were designed to mitigate specific product risk, they weren’t designed to satisfy the SEC’s disclosure rule around reporting risk management and the board’s oversight of risk management. The SEC will require companies to report cybersecurity risks and their corresponding risk management strategies to their boards.
Remember that the scope of this reporting should represent your entire business and not just your product.
Questions for Evaluating Security Programs
The following questions should be considered when evaluating the capability of your security program to provide the board visibility into cybersecurity risk management:
- Does your security program include technical, operational, and administrative controls for your entire business or is it just focused on your product?
- Have you identified the cybersecurity risks to your organization?
- Have you tied the existing elements of your security program to these risks?
- Are there unmitigated risks? Discussing these with the board could be a good opportunity to justify desired additional resources
- Do you help managers and the board assess the effectiveness of the security program by regularly reporting on the actions required to successfully run the security program?
Actions for Security Programs
The following actions are examples of managing risk within security programs, such as account reviews, firewall reviews, and backup practices.
Using a risk framework, such as the ones created by the National Institute of Standards and Technology or Center for Internet Security, can broaden your organization’s focus on risk beyond the product.
Risk areas should be evaluated against the controls contained within your security program. Not all risk areas will necessarily apply to your environment, but be sure to think about your enterprises’ entire IT environment, not just your products or financial reporting applications.
The control areas used to manage risk are the same areas that should be reported to the board or committee on at least an annual basis. As your organization determines how to report the operational effectiveness of these control areas internally, a description of your risk management program must be included within your Form 10-K.
How These Rules Apply to Technology Companies
When technology companies think of materiality, they’ll probably first think of the impact a breach would have on their products, software as a service (SaaS) or otherwise, and the impact a breach would have on customers using the products. Companies should also consider the impact a breach would have on the other systems being used to run the business.
Technology companies have likely implemented security controls in support of compliance frameworks, such as SOC 2 or ISO 27001, to protect their products and enable sales. However, the scope of these controls may not always apply to all the systems in the business that may contain customer or financial data. Ideally, they’re prepared for an incident involving their products and their financial reporting tools.
Questions for Other Business Process Systems
- What would happen if other systems were unavailable due to a ransomware attack?
- Are controls in place to protect those systems?
- Are there sufficient backups?
- Are restrictions in place to limit access to those other systems?
- Were those other systems scoped out during the SOC 2, ISO 27001, or HITRUST assessment and potentially beyond the reach of the myriad of corresponding controls?
Determining systems or processes as out of scope for an auditor doesn’t make them out of scope for an attacker. Depending on the system’s nature and the data stored on it, the scope of other systems should be carefully considered as part of the materiality decision, because potential impact to those other systems could be of interest to investors.
Compliance as a Differentiator
There have been many reactions to the disclosure rules. Some companies need help with their risk management processes. Some IT leaders want guidance on improving their board’s visibility into cybersecurity risks and the controls used to mitigate those risks. Other companies seek to improve existing practices. Still others felt confident with their existing security program and regular reporting but wanted direction on how to relay those processes in a Form 10-K to present for investors.
As investors adapt to the cybersecurity portion of Form 10-K, the market will likely respond, and stock prices could adjust for companies with less mature cybersecurity programs. Technology companies should also consider the potential impact this will have on their customer base. Reporting on the oversight of their cybersecurity program and how it manages risk could either drive customers towards or away from your products.
Case Study Example
A SaaS company has a robust security program focused mainly on their product that includes controls covering their production SaaS environment. This program meets the American Institute of Certified Public Accountants (AICPA) SOC 2 criteria for security and confidentiality. Their internal business applications are primarily cloud hosted, but they hadn’t performed a security risk assessment against their entire corporate environment and found gaps in their controls around access management and vendor reviews.
Additionally, the documentation supporting cybersecurity governance and cybersecurity risk management that is being reported to the board is limited to the SaaS production environment. The company is leveraging the team and processes in place to expand their documentation and reporting to now include both the corporate environment and the SaaS environment.
When they performed an assessment of their incident response program and breach notification, they found that it was sufficient to meet the new requirements by the SEC as it was already scoped to the entire organization.
By taking the time to review their security program through the lens of SEC cybersecurity disclosures, the company confirmed their program was solid and capable of satisfying most SEC requirements. They were able to meet the timeliness requirements around material breach disclosures and their reporting and oversight processes were sufficient to include in the annual Form 10-K reporting. They only needed to broaden their scope to include their corporate environment in their assessment and reporting processes.
We’re Here to Help
For more information about how SEC cybersecurity rules could impact your business, please contact your Moss Adams professional.
Additional Resources