SOC 2 Academy: Change Management Best Practices
by Joseph Kirkpatrick / March 15th, 2019
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
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.
