Have an incident response plan – or try putting out a fire without an extinguisher. For SOC 2, incident response is an absolute must. If you don’t have a well-practiced plan, you’re not compliant, period. Why? To prevent scenarios like this:
You get a panicked call from one of your employees at 4 pm on a Friday.
“One of our data processing vendors has been hit by a ransomware attack! We rely on that service for our product, and it’s completely shut down.”
You ask them when they expect to get it back online.
“I don’t know, I haven’t talked to anyone at the vendor. I just heard about this issue from a friend of mine at a company that’s also been affected. It doesn’t seem like they were prepared for this.”
This sort of situation is exactly why B2B clients want to see SOC 2 compliance – and why Incident Response and Business Continuity/Disaster Recovery are key parts of the compliance standard.
SOC 2 Heavily Emphasizes Incident Response
The importance of Incident Response and Business Continuity/Disaster Recovery in SOC 2 are emphasized by their appearance throughout the COSO Principles and the Common Criteria (CC) – also known as the Security Criteria . Their appearance in the Common Criteria is especially notable because all companies pursuing SOC 2 must meet the Common Criteria, regardless of the other Trust Services Criteria they have selected.
(CC2) Communication and Information – These controls address how teams communicate IT and security requirements, responsibilities and overall objectives across the organization.(CC5) Control Activities – These controls address how organizations establish security controls, connect controls to policies and procedures and assign duties.(CC7) System Operations – These controls address how organizations handle system vulnerabilities, detect system operational issues and respond to security incidents.(CC9) Risk Mitigation – These controls define how organizations manage business risks, third parties, and external vendors as related to data security.
Business Continuity/Disaster Response is less emphasized in the Common Criteria and more focused on in the optional Availability criteria, but there are still related considerations all SOC 2 compliant companies must make.
SOC 2 Incident Response Requirements
SOC 2’s requirement of incident response planning can be broken down into four categories.
1. SOC 2 Incident Response Planning
SOC 2 calls out the following as key areas for incident Response planning
Logging and Monitoring
Requirement to monitor systems and their operations for anomalies that would indicate malicious activity and errors affecting the organization’s ability to meet promised objectives. It is necessary to identify and evaluate unusual or malicious activities.
Training Responding teams should be aware of their roles and the responsibilities that come along with it.
3rd Parties
All 3rd parties’ role in responding to an incident should be taken into account. E.g. – SOC 2 requires that Cybersecurity insurance (or other relevant insurance) is in place to mitigate the financial impact of a breach or other incident.
2. Reporting
As part of the Communication and Information and System Operations criteria, SOC 2 prescribes that all users (including customers and employees) of the system be provided with information on how and where to report suspected security issues including incidents, failures, concerns or complaints.
SOC 2 also requires organizations to have a process to maintain a list of security incidents that have occurred or will occur. Note that this includes a list of instances of noncompliance with security policies as well.
3. Testing
SOC 2 requires that a security incident response test is performed at least annually to test the effectiveness of the procedures and plan in place.
4. Improvement to the Incident Response Plan
SOC 2 focuses on how the incident response plan can be continuously improved. They push to achieve this by requiring that organizations evaluate security events to determine whether they could or have resulted in an incident or a failure to meet the company’s objectives. In such scenarios, actions should be taken to prevent or address such failures.
The compliance standard also requires that reported security incidents are documented in a tracking system and post – incident analysis be done to understand the incident, remediate the issues, evaluate and communicate the effectiveness of the response.
There is certainly a degree of overlap among Incident Response, Business Continuity and Disaster Recovery strategies, but each has its place in an organization’s planning and preparing regimen, and each addresses its own collection of unique considerations.
While incident response planning addresses particular, discrete, time-based incidents that may occur, business continuity and disaster recovery planning encompasses the relatively broad scopes of general operational continuity and major catastrophic events respectively.
SOC 2 Business Continuity/Disaster Recovery Requirements
SOC 2’s Business Continuity/Disaster Recovery requirements vary depending on if you have selected to pursue the Availability Criteria as part of your audit.
If you don’t pick the Availability criteria, auditors will still focus on some business continuity elements. You will need to have a contingency plan, implement monitoring practices (explained below), and document your considerations for potential business disruptions.
If you do pick availability, the requirements are larger. The full considerations are as follows:
1. Redundancy
SOC 2 requires that failover environments be readily available in the event that the primary environment is not available.
2. Monitoring (Same as Incident Response)
Systems and their operations should be monitored for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity’s ability to meet its objectives. The anomalies should be further analyzed to determine whether they represent a security event.
Are you alerted when services and supporting infrastructure meet certain thresholds?
3. Documentation
A set of processes, plans and policies that will ensure effective operational continuity and help recover from a disaster. This is where the Business Continuity/Disaster Recovery Plan comes in.
4. Testing and Improving
Disaster recovery and business continuity plans need to be tested on an annual basis. The results of the test should be evaluated to determine if current processes require updating.
The test should include a backup restoration to help ensure the recoverability of application data.
How to meet SOC 2 Incident Response requirements.
While you might have started your SOC 2 exercise with the sole purpose of becoming compliant, you should approach the creation of your Incident Response and Business Continuity/Disaster Recovery plans with the intention of making them good, usable documents for your security program.
This is the best way to ensure you have a useful product that is SOC 2 compliant.
Write a policy and a plan.
When writing out your Incident Response plan, it’s easy to overlook these two items:
A communication strategy, owned by an appointed communication’s employee. SOC 2 does not explicitly require this, but it is part of a good plan.
Think about other third parties like an external forensics team or law enforcement that may be involved during an incident – include circumstances under which different third parties should be contacted (i.e. contact the FBI if hit by ransomware).
Test
Practice makes performance. If you never test or practice your plan, it will be much less effective.
Testing can include tabletop exercises where members of the Incident Response Team or Business Continuity Management Team get together acting in their role’s capacity and walkthrough/respond to a few incident or disaster scenarios. It is an interesting activity already but can be made more fun with gamification .
Looking for something a little different? Try these three advanced incident response scenarios.
Improve
Extremely important, often overlooked!
The whole point of the getting a SOC 2 is to ensure smooth functioning of services and operations. As you put your organization’s current practices and procedures to test, it will become clear how effective and efficient they are. Pay attention to that and incorporate the findings and improvements into the processes going forward. You can never have a perfect plan.
Conclusion
You wouldn’t want one of your mission critical vendors to be unprepared for an emergency – so why shouldn’t you be prepared for the same?
There are countless reasons that incident response planning is considered to be an essential element of every cybersecurity program by every good security compliance standard.
Another compelling one is that a strong incident response plan has the potential to identify and contain an attack before it becomes severe, saving your organization thousands of dollars in employee hours, downtime, and/or reputational damage!
Don’t just treat SOC 2’s Incident Response requirements as a checkbox. Create a great plan, and it will serve you well.
Want to get great cybersecurity content delivered to your inbox? Click here
