The IPO process is extremely complex. When the SEC released cybersecurity disclosure rules in July 26, 2023, cybersecurity preparation became another key component of IPO readiness.

Complying with these rules helps companies meet investors’ demand around the reporting of cybersecurity risk management, strategy, and governance practices.

Position your organization’s cybersecurity framework for IPO success with insights into the SEC’s cybersecurity disclosure rules.

Overview of SEC Requirements for Cybersecurity

The SEC’s disclosure rules are split into the following two requirements:

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 can 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 should also be included in this decision process such as the following:

• Customer data
• Data availability
• Intellectual property
• Source code,

The US Supreme Court defines materiality as a fact that would change how a reasonable investor understands the overall information if it was left out.

The process and people required for determining materiality need to be defined before a cybersecurity incident occurs or the organization risks being unable to determine materiality without delay.

Methods to Define Cybersecurity Materiality

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, which may be why the SEC has included materiality as part of the disclosure rule.

Reporting Risk Management

In an attempt to improve sales or practices, your company may have implemented a security program based on a particular 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 are designed to mitigate specific product risk, they aren’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.

The scope of this reporting should represent your entire business, 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 only 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 an opportunity to justify 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
• 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 apply to your environment. 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 an annual basis at the minimum. 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, 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 is typically top of mind. Companies should also consider the impact a breach can have on the other systems being used to run the business, especially when exploring the IPO process.

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, as the potential impact to those other systems could be of interest to investors.

Compliance as a Differentiator

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.

Demonstrating robust compliance isn’t just about checking boxes; it involves integrating security best practices into daily operations. This signals to investors that the company has disciplined processes, strong internal controls, and a well-managed infrastructure—which are crucial for a public company.

Case Study Example

A SaaS company has a robust security program focused mainly on their product that includes controls covering their production SaaS environment.

The Problem

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 risk management that’s 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 include both the corporate environment and the SaaS environment.

The Solution

When they performed an assessment of their incident response program and breach notification, they found 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 firm professional.

Additional Resources

• Technology Practice
• Cybersecurity Risk & IT Compliance Services