What is SOC 2 Change Management (CC8)?
Organizations are responsible for making necessary changes to protect, enforce, and improve its systems. Although being able to make changes and adapt to new situations is essential, it is important to have a plan in place for how to best go about implementing these critical actions. Managing changes in a manner that is controlled, regulated, and protects against unauthorized access is a key to upholding the standards outlined in the SOC 2 Common Criteria related to Change Management (CC8) (pp. 45-47).
The change management Points of Focus lay out a series of requirements related to managing changes to infrastructure, data software and procedures. Generally speaking, it focuses on making sure that changes to each are authorized, tested, approved and documented in an auditable manner.
Knowing where your organization stands with change management, and following the criteria outlined in Common Criteria 8 will help keep your organization’s data safe and secure. Not to mention, following the guidance outlined in the CC8 will help you receive a clean SOC 2 report.
What are the Requirements for SOC 2’s CC8?
The SOC 2 CC8 Points of Focus feature several points related to change management, as well as additional information regarding change management as related to Privacy and Confidentiality. We have outlined the main points in the common criteria below to help you make changes within your operation using systemized, controlled methods.
Policies and Documentation Requirements
Much like all of the other Common Criteria, the most difficult part of CC8 is related to creating and maintaining documentation related to your execution of the controls. You will want to have an overall policy that details how your organization handles changes as well as supporting procedures that shows how each specific class of changes is addressed. Please take a look at our CC2: Communication and Information post to see more about the overall policy requirements, the bullet points that need to be included, and the frequency of review.
CC8.1 Requirements
The entity authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to its infrastructure, data, software, and procedures to meet its objectives.
On the surface, CC8.1 looks like the easiest Common Criteria that we have looked at thus far and it is the only Criteria within CC8. However, looks can be deceiving as there is a lot that goes into it. We will take a spin through each of the Points of Focus and then add some overall best practices discussion to help put some context to this. Please keep in mind that this is the Common Criteria with the least number of “obvious” answers for your organization – your change management process will likely look vastly different from your neighbor’s test that you are trying to copy from.
CC8.1 Points of Focus for All Reports
Manages Changes Throughout the System Life Cycle – This one is fairly straight forward – have a Software Development Life Cycle that has been documented that you follow.
Authorizes Changes – Authorizing changes is about showing that the business drives the requirements for the system (and not the development/engineering shop). They should define the requirements (i.e. through the creation of stories in the agile world). The key here is that the authorization is happening prior to development. In most cases, this is fairly easy to demonstrate through the use of tickets that drive the development process in your organization.
Designs and Develops Changes – This is essentially the development part of of the change – creating lower level technical documentation and writing the code to implement the requested changes. This is typically inherent to software development – we will usually see some form of source code repository that handles pull requests/merges to provide a method to the madness here.
Documents Changes – This one pairs up with the CC2 requirements that we talked about – there should be a process to keep your employees and contractors up to date as well as a process to keep your customers up to date on the changes that you make to your systems.
Tracks System Changes – If it was not documented then it did not happen. Have a way to track changes through their lifecycle.
Configures Software – All software has configurations that need to be adjusted to work well. This Point of Focus asks you to keep track of these configurations/parameters as it is usually a bad thing if you do this wrong. Note this applies to both purchased software (i.e. Commercial Off The Shelf) and your own developed software.
Tests System Changes – Performing and documenting testing prior to implementation into the production environment is one of the more difficult tasks for our clients to do. We will typically start with having clients assemble a set of scenarios and document what they consider to be an appropriate level of testing for each. For example, a major release may require unit, automated, integration, static and manual testing while a single issue bug fix may only require a lower degree of testing. Once that is decided, it is a simple as documenting how each of the steps was performed.
Approves System Changes – Once the change has been authorized, designed, developed and tested and is ready to make the jump to production, there should be a process for approving the change. This approval should confirm that all of the requisite tasks have been performed and that the business is ready for this change to be promoted. The approval should be documented and should be from the business side of the house. We will talk more about segregation of duties related to change management below.
Deploys System Changes – While this one looks like a relatively simple ask of how to deploy changes, it goes a bit deeper than that. Specifically, it looks at segregation of duties/responsibilities related to the deployment process. The key objective here is to prevent or detect the ability for a single person to unilaterally develop and implement a change without going through the change management process.
Identifies and Evaluates System Changes – This one pairs well with the Authorizes Changes Point of Focus as the intent of changes to the system should be to support the achievement of the objectives of the organization. This one is difficult to explicitly document, but should be inherent to your documentation.
Identifies Changes in the Infrastructure, Data, Software, and Procedures Required to Remediate Incidents – One of the requirements for CC7.5 is to have procedures in place to restore and recover your environment after an incident. This particular Point of Focus is here to remind you that the changes you make to restore and recover from the incident should also follow your change management process.
Creates Baseline Configuration of IT Technology – Much like Configures Software, this Point of Focus is looking for you to maintain baseline configurations that you use in your organization. This could be in a written hardening guide document or perhaps in an Infrastructure as Code repository that goes through the change management process.
Provides Changes Necessary in Emergency Situations – Unfortunately, not all changes are done in the regular order of business. When things do go sideways and a change is required to fix it, you will still have to follow your change control procedures, however, those procedures can have specific call outs for emergency changes. For example, in an emergency situation, you may say that not all documentation needs to be finished prior to the change (but, needs to be finished timely) versus a regular change that needs all documentation completed prior to implementation.
Manages Patch Changes – While it may be obvious that patch changes made to your environment should follow your change control process, the add on bonus that is introduced here is that they are implemented in a timely manner. Some might say that this is mostly covered if you perform regular vulnerability scans as CC7.1 asks you to do, however, this can also extend to feature/bug fix patching that may not be picked up by vulnerability scanners. Having a regularly scheduled review of available patches may end up being appropriate.
CC8.1 Bonus Points for Availability
This Point of Focus is only applicable if you have selected the Availability Criteria to go along with your examination.
Considers System Resilience – Within your SDLC, you should include design requirements and test cases to support your system availability to meet availability commitments that you have made to your customers. This includes both availability (i.e. having a high availability architectures) and ability to successfully execute your disaster recovery plan.
CC8.1 Bonus Points for Confidentiality
This Point of Focus is only applicable if you have selected the Confidentiality Criteria to go along with your examination.
Protects Confidential Information – This one seems fairly straight forward – an organization should always protect confidential information. This specific call out will often focus on the use of confidential information in non-production environments for testing, debugging or development work. The best practice here is to sanitize your data prior to loading into lower environments, but when this is not possible, make sure that those environments have controls that are as good as production controls in place to protect the information.
CC8.1 Bonus Points for Privacy
These two Points of Focus is only applicable if you have selected the Privacy Criteria to go along with your examination.
Protects Personal Information – This is much like Protects Confidential Information, but instead of Confidential information it focuses on Personal Information. The same approach for keeping data out of and/or protecting it when in non-production environments applies here.
Privacy by Design – This means that you think about privacy issues and data use before you create or make changes to your system. It is one of the major themes of GDPR requirements (and good privacy practices overall) and is rather analogous to phrases like “a stitch in time saves nine.”
CC8 Hot Topics
Testing of Changes
The difficult thing with testing (and really, most things from a SOC 2 perspective) is that you will likely already be doing 80% of what you should be doing, but only have documented 20% of that documented. It is very common for us to start looking at GitHub Issues and JIRA tickets to see that each of them will have some form of requirements already documented but that is exactly where the documentation ends. We usually find that it was included in a release and marked as done without a single peep about whether it was tested.
When talking with our clients, we usually find that most will do some form of testing – perhaps they enforce peer review at code check in (which may satisfy requirements for unit testing) and when it is a big enough change, the product manager pops out from the woodwork to see that all of the features are working as expected. The main issue here is the consistency of the documentation and segregation of duties between those involved in the process.
Generally speaking, the person(s) that are developing the change should not be the person(s) that are testing the change. The documentation for testing needs to reflect that there was more than one person reviewing the change before it being pushed for approval and implementation.
Segregation of Duties
To expand on the theme of having multiple people involved in the change process, segregation of duties makes it difficult (or preferably, impossible) for a single person to develop and implement a change without any other involvement. Office Space references aside, having more than one set of eyes on a change tends to drastically increase software quality and prevent bugs from creeping into your system.
The common problem that our clients have is that they have a very small team that is involved in the development and implementation of their product. They cite the inability to budget for an independent quality assurance function or the fact that they literally have two developers that are also the co-product owners. Historically, auditors have gotten very upset at developers with access to the production environment as they expect a prevent type control to achieve segregation of duties. In a small team like we have described, it is often more appropriate to have a detect type control that draws attention to releases when they occur.
An example detect control could be as simple as a deployment pipeline being configured to drop a message into your preferred chat application where everyone can see it. This would alert personnel to changes that are being made and if they are out of line with expectation, could raise an incident to investigate. Good hygiene with source code and deployment pipeline management can also provide some level of prevent and detect style of controls to assist here.
At the end of the day, we very rarely have to force a client to change how they manage their segregation of duties within their change management processes. It usually comes down to improving documentation and having formalized procedures for it that can be audited instead.
Conclusion
Implementing changes is an inevitable part of operating any organization—the key is doing so with care and caution. You can keep your organization running smoothly by learning to conduct changes wisely, efficiently, and in accordance with proper standards.
The main thing to remember here is that “if it was not documented, it did not happen” – especially for testing and approval of changes.
You and your organization are not alone in managing change management. This article covers the main points in meeting Common Criteria guidelines, but it is a complex topic for which it is often helpful to seek professional guidance. We are here to help keep your organization running like a well-oiled machine (and, of course, pass your SOC 2 audit), so reach out!