A routine configuration change can expose customer records even when the application code remains untouched. An urgent data correction can also create problems if nobody checks which records it will affect. Companies need a reliable way to evaluate changes before those changes reach the services customers depend on.
CC8, the Change Management group within the SOC 2 common criteria, addresses controlled changes to systems. Its scope includes infrastructure, data, software, and procedures. That breadth matters: a strong software release process can leave important gaps if administrators, support teams, or external providers can make other production changes outside it.
Changes are necessary to fix vulnerabilities, improve services, and meet new business needs. The difficulty is understanding what a change could disrupt and giving the right people enough information to make a sound decision.
Consider an engineer changing the permissions on a production database. The change record can explain why the new access is needed, identify the affected service, document a test using suitable data, and name the person who approved deployment. Afterward, someone checks that the intended account can perform the required task and that unrelated accounts did not gain access. A retained history makes that decision understandable later.
The same reasoning applies to a purchased application or a revised operating procedure. A workflow that only records code commits will not capture every change capable of affecting security.
CC8 contains one criterion, CC8.1. The descriptive label below is an editorial summary, not an official AICPA title.
CC8.1 Controlled System Changes. Changes receive appropriate scrutiny throughout their life cycle.
In practice, a team can connect the business reason for a change to its risk assessment, review, testing, deployment decision, and verification. A small, repeatable adjustment may follow a preapproved route with automated checks. A change to authentication or sensitive data may need additional review. The route should reflect the consequences of an error and the company’s commitments.
Emergency changes still follow a defined process for authorization, testing, approval, and implementation. The process may use expedited checks suited to the urgency and risk, with records of the decision and appropriate follow-up. See the AICPA Trust Services Criteria for the complete criterion and related points of focus.
A customer reviewing change-related controls will want to understand whether the company can make necessary updates without leaving production changes uncontrolled. Useful questions include:
Supporting evidence may include change requests, reviewer decisions, test results, deployment histories, configuration records, and emergency-change follow-up. These records are more useful when they identify the actual change and environment. An approval for one version does not explain why a different version reached production.
A Type 1 report addresses the system description and suitability of control design as of a specified date. A Type 2 report also addresses operating effectiveness over a specified period and includes the auditor’s tests and results. Read the scope, opinion, and any testing exceptions before drawing conclusions about change practices. Neither report predicts the outcome of a future release.
Pay attention to the system boundary. A report covering one product may say little about another platform acquired later. Provider-managed changes also deserve attention: the company may rely on a supplier’s release process while remaining responsible for its own configurations, integrations, and acceptance decisions.
The following examples illustrate ways to organize change management. They are starting points to assess against actual risks and discuss with the service auditor.
Headcount does not determine the appropriate level of review. A five-person company processing sensitive records may need stronger deployment safeguards than a larger company operating a low-risk internal service. SOC 2 does not prescribe a change advisory board for every release or require a particular development platform.
The individual article will examine this criterion in greater detail, with practical controls and supporting evidence. Its link will be added when the article is published.
Discuss your SOC 2 objectives with Genius GRC and identify controls and supporting evidence that fit your systems, release practices, and operational risks.
