Common Criteria 8.1

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 8.1 says, “The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.” How can organizations be sure that they’re complying with this criterion? Let’s discuss some change management best practices that organizations should be following.

Why is Change Management Important for SOC 2 Compliance?

During a SOC 2 audit, it’s especially important that organizations can demonstrate to their auditors that they have an effective change management system in place. Why? Change management systems provide organizations with policies and procedures for making updates to their IT infrastructure, which in turn helps mitigate the potential for overlooking any new vulnerabilities or risks created while changes are taking place. In the past, we’ve seen organizations use a variety of different change management systems, from simple forms to elaborate ticketing systems. Whichever way an organization chooses to implement their change management system, though, they should end up with a database that allows them to review all of the changes that have been made at their organization, who authorized them, and who implemented them.

How to Comply with Common Criteria 8.1

When an organization pursues SOC 2 compliance, an auditor will use the following points of focus to determine if they comply with common criteria 8.1. These points of focus include the following:

• Does the entity manage changes throughout the lifecycle of the system and its components?
• Does the entity have a process in place to authorize changes before they’re made?
• Does the entity have a process in place to design and develop changes?
• Does the entity have a process in place to document the changes to the system?
• Does the entity have a process in place to track changes to the system?
• Does the entity have a process in place to select and implement configurations for the software?
• Does the entity have a process in place to test changes to the system before they’re deployed?
• Does the entity have a process in place to approve changes to the system before they’re implemented?
• Does the entity have a process in place to deploy changes to the system?
• Does the entity identify how system changes might impact business objectives?
• Does the entity evaluate how system changes are impacting business objectives?
• Does the entity identify and evaluate changes to the system’s infrastructure, data, software, and procedures required to remediate incidents?
• Does the entity create and maintain a baseline configuration of IT technology?
• Does the entity have a process in place to provide changes necessary in emergency situations?

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

Change management is a very big topic in the SOC 2 compliance framework. Common criteria 8.1 talks about change management, and I’ve seen everything from changes being communicated via email to very sophisticated change management ticketing systems and paper forms. There are many ways to do it, but ultimately, every organization needs a way to do change management. I’m going to read the requirements from common criteria 8.1 because it’s a lengthy list, and it’s not one that I’ve memorized, but the list includes the following. The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. It’s a big requirement, and there’s a lot to discuss out of what I just read for that criterion. When you have a change to anything – whether it’s infrastructure, data, software, or procedures – you have to be able to show that you authorized it, you designed the change, you configured and tested it, you approved it, and you implemented it. You could end up with a very massive database of all the changes that you have executed over the years. You should be able to show which changes were approved and which were not. You should be able to provide proof that you tested the change or the initial authorization that you received to make the change. There’s a lot of information there. You just want some way that’s appropriate to the size and complexity of your organization to be able to show your auditor your documentation about each change. A lot of organizations can cover those requirements in a very easy way, whether it’s through a ticketing system or a form, that really represents each one of those pieces of data in some way. For example, who authorized it? Who ultimately approved the change after it was tested? You would want to have those components and whatever documentation that you’ve put together for your change management program. However, what’s so hard for most people is that we operate in such an ad hoc way, or we have an emergency, and have to make changes on the fly or risk making clients unhappy or worse. This results in changes being made that don’t get documented or identified as a change that occurred, so change management is really about slowing down and applying procedures to make sure that changes are known and approved, and there’s an audit trail so that auditors can understand the changes that occurred in your environment if any issues arise later. Think about your change management program, what it looks like, where it came from, and if it needs to be improved or modified in some way. You’ll need to demonstrate to your auditor that those things are being documented and tracked.

Common Criteria 7.5

Because security incidents are a matter of when, not if, they occur, it’s a best practice to always analyze what happened and how an organization could have prevented it. That’s why during a SOC 2 audit, an auditor will assess an organization’s compliance with the 2017 Trust Services Criteria, which includes common criteria 7.5. Common criteria 7.5 says, “The entity identifies, develops, and implements activities to recover from identified security incidents.” Let’s discuss what an auditor will look for when assessing an organization’s compliance with this criterion.

Incident Response Recovery

Recovering from a security incident can be a tedious task, but it’s an opportunity for organizations to learn from their mistakes and strengthen their security posture. For service organizations pursuing SOC 2 compliance, they’ll want to demonstrate that they do the following throughout their incident response recovery to comply with common criteria 7.5:

• The organization’s incident response plan restores the affected environment to a level of functionality that allows them to meet their business objectives.
• The organization effectively communicates about the security incident, what actions were taken to recover from it, and how it can be prevented in the future.
• The organization determines the root cause of the event.
• The organization implements changes to prevent and detect recurrences.
• The organization improves response and recovery procedures.
• The organization implements periodic incident response testing.

It’s important that organizations keep in mind that security incidents and disasters can’t be 100% prevented. However, by creating, practicing, and implementing effective incident response programs, including the incident response recovery process, they’ll be more prepared for when disaster hits.

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

Common criteria 7.5 for SOC 2 compliance has to do with recovering from an incident. After the incident is over and the dust is settled, what should you do with it? You’ll want to learn from it. You should sit down and analyze the root cause of the incident, what you could’ve done differently, and what you learned from the situation that can help you in the future. You want to make sure that any incident that does get documented during the year of your audit period that you have a way to show the auditor that you have considered the results of the incident, learned from it, documented the lessons learned, had a debriefing, put new procedures into place, and modified the incident response program because of the lessons you learned. So, think about recovery when you consider common criteria 7.5 and how proper recovery would include learning from the incident and applying those changes to your incident response approach, so that you are stronger when or if another incident occurs.

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.” While we’ve already discussed why it’s important to establish incident response teams and how organizations can comply with common criteria 7.4, there’s one component of this criterion that we’d like to emphasize: the importance of testing the incident response plan.

Why Do You Need to Test Your Incident Response Plan?

No plan works the way it’s supposed to without a little practice. An organization’s incident response plan might look perfect on paper, but what happens when a security incident actually occurs and it’s time to put that plan into action? The incident response team members might get confused or miss a critical step in the recovery process. To ensure that the incident response plan resolves the security incident as smoothly as possible, organizations should practice it at least annually.

Let’s look at the following scenario as an example of how organizations can comply with common criteria 7.4. An organization wants to make sure that their incident response plan has all of the kinks worked out because they know that security incidents are unavoidable and want to be best prepared. They decide to hold an annual incident response training with their incident response team members where they review three possible scenarios: malware has attacked their network, an employee fell victim to a phishing attack, and a former employee stole sensitive data before resigning. While there is no telling if any of these scenarios will actually occur at that organization, having the incident response team members practice responding to different scenarios allows them to learn how to adapt the incident response plan to different situations.

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

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

I know sometimes people roll their eyes when auditors come along because we make you go through all these methods, like annual risk assessments, annual disaster recovery tests, and a business continuity and incident response test. Clients often ask, “Can we consolidate these things? Can we just check a box somewhere?” We hope you understand that the reason why we push for these things is because each one of these things is important. I specifically want to address common criteria 7.4 and why an incident response test is so critical. If people on your team are not used to responding to incidents on a daily basis – and that’s most of our customers because they don’t have a group of people in an environment where there’s an incident every day, and they’re just getting more knowledgeable, stronger, and better every day – these incidents that rise to the level of critical only happen a couple of times a year, so you’ve got people on the team who aren’t very well practiced or versed in that. What’s the value of an incident response test once a year? It’s an opportunity to go into the conference room, sit down, take three scenarios, and walk through them with your incident response team. For example, you might give a scenario where X data was stolen or one of your former employees left and their using information that they took with them to try and attack your systems. You’d want to walk through these scenarios and ask questions like: what would we do here? How do we respond? What type of resources do we need? What kind of tools would we employ? The reason this is so valuable is because even if that specific example doesn’t happen in real life, some element of what you’ve practice will come up during a real-life situation. When this happens, you’ll be very thankful that you’ve figured out some resources that you can call during the heat of the moment, and you’ve identified some tools that you could have at your disposal to help out with incident response. Ultimately, doing an incident response test every year shouldn’t just be a motion that you go through to satisfy an auditor. It really should be real practice to prepare your people for the real thing. Think about your next incident response test and how you can make it better, so that you can learn from it and be better prepared for the real situation.

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.

Common Criteria 7.3

When an organization undergoes a SOC 2 audit, auditors will be looking to validate that they comply with the common criteria listed in the 2017 SOC 2 Trust Services Criteria. Common criteria 7.3 says, “The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures.” What will an auditor look for when assessing this criterion? What do organizations need to do to comply with common criteria 7.3? Let’s take a look.

Incident Response Best Practices for SOC 2 Compliance

The first step in following incident response best practices is learning how to accurately identify an incident, so that an organization knows when it’s necessary to implement an incident response plan. According to Verizon’s 2018 DBIR, a security incident is a security event that compromises the integrity, confidentiality, or availability of an information asset. So, for example, if you have personnel performing daily log reviews and they notice that an unauthorized user or source has gained access to your systems or data, activating your incident response plan would be necessary.

During a SOC 2 audit, an auditor will want to verify that an organization follows incident response best practices. They’ll typically do this by asking questions, such as:

• Does the entity have procedures in place for responding to security incidents?
• Does the entity have procedures in place for evaluating the effectiveness of the incident response plan?
• Does the entity communicate effectively when an incident is discovered and throughout the incident response plan?
• Does the entity have procedures in place to analyze security incidents and their impact?

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

Common criteria 7.3 for SOC 2 compliance is really getting into incident response, because the requirement is about taking action after you’ve analyzed a particular security event. Is this a real security event? Is this something that could impact your organization negatively and prevent you from achieving your objectives? If so, it is an incident, it should rise to the level of an incident, and you need to activate your incident response plan in order to take the proper action to respond to it. Being able to define what an incident is is important, first of all. You want to clearly know what rises to the level of an incident and when it is that the incident response team activates. That team needs to go through practices, scenarios, and training in order to know how to respond appropriately to not only contain the incident, but resolve it, learn from it, and develop further procedures so that you’re even better prepared for the next time you face one of those incidents.