SOC 2 Academy: Incident Response Teams

by Joseph Kirkpatrick / March 8th, 2019

Common Criteria 7.4

When a service organization undergoes a SOC 2 audit, auditors will verify whether they comply with the common criteria listed in the 2017 SOC 2 Trust Services Criteria. Common criteria 7.4 says, “The entity responds to identified security incidents by executing a defined incident response program to understand, contain, remediate, and communicate security incidents, as appropriate.” Let’s take a look at what organizations need to do to comply with this criterion and why it’s important to establish incident response teams.

Establishing Incident Response Teams for SOC 2 Compliance

Incident response teams are critical to ensuring an organization’s business continuity. If an organization neglects to establish an incident response team, how will they effectively remediate a security incident when – not if – one occurs? Incident response teams need to have established roles and responsibilities, extensive training, and current procedures to follow in order for an incident response plan to be effective. For example, if an entity’s server goes down, who on the incident response team is responsible for identifying that? Who is responsible for understanding the impact that security incident has on the organization? Who determines how the security incident will be addressed? Who communicates that to management or other stakeholders? These are all factors that need to be considered when putting together incident response teams.

How to Comply with Common Criteria 7.4

During a SOC 2 audit, an auditor will use points of focus to determine if an organization complies with common criteria 7.4. They’ll ask questions such as:

• Does the organization assign roles and responsibilities to members on the incident response team?
• Does the organization have procedures in place to contain security incidents?
• Does the organization have procedures to mitigate ongoing security incidents?
• Does the organization have procedures in place to end threats posed by security incidents?
• Does the organization have procedures in place to restore data and business operations after a security incident?
• Has the organization developed and implemented communication protocols for security incidents?
• Does the organization have an understanding of the nature of the security incident and determines a containment strategy?
• Does the organization document and communicate remediation activities as outlined in the incident response plan?
• Does the organization evaluate the effectiveness of the design of the incident response plan on a routine basis?
• Does the organization evaluate incidents related to security, availability, confidentiality, processing integrity, and privacy on a regular basis?

More Incident Response Resources

What is an Incident Response Plan? The Collection and Evaluation of Evidence

Incident Response Planning: 6 Steps to Prepare Your Organization

Business Continuity and Disaster Recovery: How to Avoid a Crash Landing

Security incidents come in all shapes and sizes. You’ve got things that you would consider to be minor and you’ve got things that are very serious, where potential data breaches that can occur. It’s very important that your incident response team is made up of people who can understand what they’re dealing with as quickly as possible. They can make decisions, perform an analysis, and draw on their experience or other resources that they have access to in order to make a determination about what type of incident occurred, what type of effect it could potentially have, and what the most appropriate way to respond to it is. As we consider in your SOC 2 audit common criteria 7.4, we’re really going to understand how your incident response program is put together. Who are the people on the team? What are their roles and responsibilities? Have those roles and responsibilities been communicated to them? Have they been trained on it? Do they have the appropriate training and background in order to be effective when responding to those incidents? Not only does that group of people have to identify and contain the incident occurs, but they’ll also have to have some involvement in the mitigation and restoration of services after an incident. Let’s look at a real simple example. Let’s say that a server crashes and a critical application is not available to your staff in order for them to carry out their duties. The incident response program that you have would have to, first of all, in a very timely way, identify that the server was down. Someone performing incident response would have to evaluate that very quickly and determine which server it was, what services it was providing, and understand the impact to the organization. For example, for every hour that the server is down, your organization is losing $100,000, so we need to restore operations and get the server back up and running as soon as possible. While those types of efforts are happening, there might be someone on the team who has the role of containing it. Was their something that led to the server going down? Were their logs that need to be retained and secured in order to analyze that incident in order to understand if there was a possible attack going on that caused the server to go down? If this is so and you restore the server and it goes down again because it’s an ongoing attack, you’ve missed the opportunity to mitigate that risk. There are a lot of things like that could go into responding to incidents. These are issues that your auditor will ask you about in order to understand if your incident response program is mature enough to handle the very wide variety of issues that could come up during and after a security incident.