Under Description Criteria (DC) 4 of the description criteria for SOC 2, the AICPA requires disclosure of security incidents that affected the system, commitments, system requirements, or objectives. But we are often asked, “where is the line”? How do you know what needs to be disclosed versus what does not? This blog post will help to clarify that a bit when you are developing your system description for your SOC 2 report.
How does the AICPA define security incidents?
The AICPA defines security incidents as those that: (a) were the result of controls that were not suitably designed or operating effectively to achieve one or more of the commitments and system requirements; or (b) otherwise resulted in a significant failure in the achievement of one or more of those commitments and system requirements.
That’s a lot of dry language, but think about it this way, if the incident was the result of a control (or controls) not being designed or implemented properly, or if it didn’t operate properly, then it should be a security incident to be disclosed. For example, if a change wasn’t reviewed or approved prior to being pushed to production, and in turn left open a security vulnerability that was breached, that means you may have failed your security commitments for your system.
To disclose or not disclose?
If you have an incident that meets the terms above, you likely will need to disclose it. The AICPA does, however, provide additional guidance on determining whether to disclose an incident. In addition, to control failures, failure to meet commitments and system requirements (as above), the following should be considered when determining whether or not to disclose an incident:
- Whether public disclosure of the incident was required (or is likely to be required) by cybersecurity laws or regulations
- Whether the incident had a material effect on your company’s financial position or results of operations and required disclosure in a financial statement filing
- Whether the incident resulted in sanctions by any legal or regulatory agency
- Whether the incident resulted in your company’s withdrawal from material markets or cancellation of material contracts
Another rule of thumb that some companies use is if the incident warranted a press release, notice to your customers, or something similar, they will likely disclose it in their system description.
The AICPA also states that any incidents noted from your sub-service organization(s) should be considered for disclosure in your report as well.
How to disclose (what’s required)
OK, so you determined that you have a security incident that warrants disclosure. What now? Here is what you should include in your system description under DC 4:
- What the incident was
- When and how it happened
- The extent of the incident (what got affected)
- How did you stop it and remediate it?
- Any changes in the control environment as a result
The AICPA also provides some leniency regarding disclosure. They state that disclosures about security incidents should not be made at a detailed level which might increase the likelihood that a hostile party could exploit a security vulnerability. Rather, the disclosures are intended to enable report users to understand the nature of the risks faced by your company and the impact of the realization of those risks.
Security incidents are a scary thing – we get it. Your job is to minimize the impact of those incidents. Always worry about that first.
When it comes to whether or not to disclose it in your SOC 2, we can help. Use this blog, the AICPA’s description criteria, the SOC 2 guide, as well as have a conversation with us to help you understand what needs to be disclosed around your incident.