Over the last year, the world saw a number of major security breaches in the news. Some notable ones include the Equifax data breach, Uber data breach, WannaCry cyber attack, and the list goes on. While each of these had its own unique security vulnerability that was exploited they all shared in at least one commonality, they experienced a security incident (i.e. information security or cybersecurity) that would have required reporting under the new SOC 2 Guidance. In this post, we will talk about information and cyber security incidents, the change in incident reporting expectations, implementing the new guidance, and disclosure requirements.
What are Security Incidents?
The definition of an incident can vary depending on your company and the multiple factors at play. With that said, NIST defines an incident as, “an occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.”
Using the definition defined above we will dissect a few of the incidents identified above.
- Equifax Data Breach: During the Equifax data breach about 145 million U.S. consumers and businesses had their information hacked as a result of a known vulnerability that existed on their web portal that was not patched in a timely manner. Because of this breach, the confidentiality of consumer data was jeopardized, making this an incident.
- Uber Data Breach: During the Uber data breach, hackers accessed a server which stored personally identified information (PII) by gaining access to their code repository which contained login information needed to gain access to Uber’s production environment. Like the Equifax data breach, the confidentiality of Uber’s client information was jeopardized, making this an incident.
- WannaCry Cyber Attack: The WannaCry attack was a particular notable attack as it used a logic known as worm tactics which allowed it to hop to other users through LAN and WAN connections. This allowed the attack to disrupt entire networks for some that were infected. It spread through a known exploit within an old file sharing protocol found in Windows systems released for over 15 years. During this attack, the integrity and availability of the system were affected, making this an incident.
Old vs. New SOC 2 Incident Reporting Expectations
Up until the latest version of the SOC 2 guidance, which officially goes into effect December 15, 2018, service organizations receiving SOC 2 reports were not required to disclose major information security or cyber security incidents that occurred either as of the date of the system description or during the audit period the report covers. The only time it would have been mentioned is if the incident was the result of a control failure due to poor design or if the control did not operate effectively.
According to the new guidance, management is now going to be required to include specific information about incidents that (1) occurred as a result of a failure in the design or operating effectiveness of one or multiple controls or (2) upon occurrence resulted in the company not being able to meet service commitments and system requirements.
According the AICPA, reportable security incidents should include the following information:
- Nature or description of the incident
- Timing around when the incident occurred
- The consequence the incident will have on the service organization, service organization’s users and any disruption to service commitments and system requirements.
How to Implement the New Guidance?
The AICPA has an Assurance Services Executive Committee which works on different tasks that are designed to offer guidance, criteria, and tools to support members of the AICPA in implementing requirements published by the AICPA. This includes the Description Criteria for a Description of a Service Organization’s System in a SOC 2 Report. Within this publicly available document is guidance around implementing the new requirement of adding incidents to the system description.
Something important to note is that the AICPA understand that not all incidents are major and require reporting to their users. The new Description Criteria provides considerations that management can use when determining whether an information security or cyber security incident response is warranted, and therefore meet the reporting requirements noted in the section above. The considerations are as follows:
Incident Response Considerations:
- Was the incident a result from controls that were either not designed properly or did not operate as intended?
- As a result of the incident, was the service organization not able to meet the service commitment and system requirements guaranteed to their users?
- Are there any laws or regulations which will force the incident to be publicly disclosed, if it has not been already?
- Has or will the incident impact the financial stability or long-term operations of the service organization and will this require a financial statement disclosure?
- Did the incident require any type of legal or regulatory sanction?
- Has or will the incident cause the service organization to cancel any major contracts?
If the answer to any of these considerations is yes, then it is likely that the incident needs to be reported within the upcoming SOC 2 report.
I Have a Reportable Security Incident, What Now?
If by going through the considerations in the previous section and through conversations with the appropriate personnel it is decided that an incident does need to be reported, it is important to understand what that should look like.
When a company reports an incident, the information reported should be presented in a high-level for a number of reasons. The first reason is that certain details could provide parties with bad intentions enough information needed to further exploit the system. Secondly, the reporting of incidents is only intended to provide readers with the description of the incident, timing, and any consequences the incident has caused.
Service organizations that determine they have a reportable incident should work with appropriate personnel such as their auditor and legal team to ensure that the information provided will not result in further damage to their system.
Preventing & Handling Cyber/Information Security Incidents
While my hope is that hacking and cyber security incidents do not continue to occur, the reality is that the threat is out there and only seems to be growing. The best way to ensure that your service organization lowers the risk of having to report on a security incident is by having a security management team with a policy and plan that continues to identify, analyze, and remediate risks that can negatively impact users and the system. But in the case that a security incident does occur, it is also important to understand the requirements of disclosure as a means to avoid unnecessary exposure.
For more information, check out some other Linford & Company posts about cyber security incidents and securing your environment.
- Insider Threats: The #1 Cyber Security Risk to an Organization
- Mobile Workforce Security: Nine Strategies to Secure Mobile Devices
- Containerization Security: What Are Containers & How to Secure Them?
Jaclyn Finney started her career as an auditor in 2009. She started with Linford & Co., LLP. in 2016 and is a partner with the firm. She is a CISA with a special focus on SOC, HITRUST, FedRAMP and royalty examinations. Jaclyn works with her clients to provide a process that meets the needs of each customer and generates a tailored report that is useful to the client and the users of the report.