Category: Trust Services Criteria

Change Management Criteria (CC8)

Also known as: CC8, CC8.1, Change Management Common Criteria, SOC 2 Change Management Controls

Simply put

Change Management (CC8) is the part of SOC 2's Security (Common Criteria) category that deals with how an organization makes changes to its systems, software, and processes in a controlled way. It typically calls for changes to be requested, reviewed, tested, and approved before they go live, so that unauthorized or risky modifications are prevented. Because CC8 sits within the required Security category, it is generally assessed in any SOC 2 examination.

Formal definition

CC8 is a category within the SOC 2 Common Criteria (the Security Trust Services Category, which is always in scope) that addresses how an entity manages changes to infrastructure, data, software, and procedures. Its criterion, CC8.1, typically requires that an entity recognize the need for changes, then authorize, design, test, approve, and deploy those changes through a controlled process while preventing or detecting unauthorized changes. The specific evidence and control activities used to satisfy CC8.1 are guided by the associated Points of Focus and depend on the engagement's scope and the auditor's judgment; in a SOC 2 Type II examination, operating effectiveness is evaluated over a defined review period, whereas a Type I addresses suitability of design at a point in time. As part of a SOC 2 examination, CC8 attests only to the controls and period covered and does not constitute a certification, nor does it guarantee freedom from unauthorized changes or breaches.

Why it matters

Changes to systems, software, and procedures are among the most common ways that security controls are unintentionally weakened. An unreviewed configuration change, an untested software deployment, or an unauthorized modification can introduce vulnerabilities, disrupt availability, or expose data, often without anyone noticing until an incident occurs. CC8 exists because a controlled change process is one of the primary defenses against this class of risk, requiring that modifications be recognized, authorized, designed, tested, approved, and deployed in a disciplined way rather than made ad hoc.

For organizations undergoing a SOC 2 examination, CC8 carries particular weight because it sits within the Security category (the Common Criteria), which is always in scope. This means change management is generally assessed in any SOC 2 engagement, regardless of which optional Trust Services Categories an organization selects. Weaknesses in how changes are governed can surface as findings that affect the overall report, making CC8 a criterion that service organizations typically cannot deprioritize.

It is important to keep the boundaries of CC8 in perspective. A SOC 2 report attests only to the controls and the period covered by the examination; it does not certify the organization, nor does it guarantee that no unauthorized change or breach will ever occur. CC8 provides assurance that a controlled change process was suitably designed, and, in a Type II examination, operating effectively over the defined review period, but it is not a warranty against future failures.

Who it's relevant to

Compliance and GRC Managers

CC8 is one of the Common Criteria that is generally in scope for every SOC 2 examination, so compliance and GRC teams typically need to ensure a documented, controlled change process exists and that it can be evidenced. They are often responsible for coordinating the change requests, impact analyses, and approval records that auditors review against CC8.1.

Security and Platform Engineers

Engineers who modify infrastructure, software, and configurations are the practitioners whose day-to-day work CC8 governs. They typically operate the controlled process that authorizes, designs, tests, approves, and deploys changes, and are usually the ones who generate the technical evidence auditors examine.

SOC 2 Auditors

Auditors evaluate CC8 as part of the Security category, exercising professional judgment guided by the Points of Focus. In a Type II examination they assess operating effectiveness over the defined review period, while in a Type I they assess suitability of design at a point in time. Their conclusions are expressed in the resulting report.

Service Organization Leadership

Leaders at organizations pursuing a SOC 2 report should understand that CC8 findings can affect the overall examination outcome and how the report is perceived by customers. They should also recognize that the report attests only to the controls and period covered and does not guarantee freedom from unauthorized changes or breaches.

Inside CC8

Placement within the Common Criteria

CC8 is part of the Security category (the Common Criteria) of the Trust Services Criteria, which is the only required category in a SOC 2 examination. It addresses how an organization manages changes to infrastructure, data, software, and procedures.

Change authorization

CC8 typically addresses whether changes are requested, reviewed, and authorized before being implemented, so that unapproved modifications are not introduced into the production environment.

Design, development, and testing

The criterion generally covers whether changes are designed, developed, and tested prior to deployment, depending on the scope and the nature of the systems in question.

Segregation of environments and duties

In many engagements CC8 considerations include separating development, testing, and production environments and separating the responsibilities of those requesting, approving, and deploying changes, though the specific expectations depend on scope and auditor judgment.

Documentation and tracking

CC8 typically involves maintaining evidence that changes were tracked, reviewed, and approved through a defined process, which becomes the basis for the auditor's testing in a Type II examination.

Relationship to evidence in Type I vs Type II

For a SOC 2 Type I, the auditor assesses the suitability of the design of change management controls at a point in time; for a Type II, the auditor assesses both design and operating effectiveness over a defined review period, the length of which is set by scoping decisions.

Common questions

Answers to the questions practitioners most commonly ask about CC8.

Is CC8 an ISO 27001 Annex A control?

No. CC8 is part of the Common Criteria within the SOC 2 Trust Services Criteria, which are distinct from ISO 27001 Annex A reference controls. While change management concepts appear in both frameworks and can be partially mapped, CC8 is not an Annex A control, and satisfying CC8 does not automatically satisfy the corresponding ISO 27001 requirements. The two frameworks assess change management through their own structures and criteria.

Does meeting CC8 in a SOC 2 report guarantee that no unauthorized changes occurred?

No. A SOC 2 report attests only to the controls described and the period covered by the engagement. In a Type II examination, it addresses whether change management controls were suitably designed and operated effectively over the defined review period, but it does not guarantee freedom from unauthorized changes or breaches. The report reflects the auditor's evaluation within the defined scope rather than an absolute assurance.

What kinds of changes does CC8 typically apply to?

CC8 typically addresses changes to infrastructure, data, software, and procedures relevant to the systems in scope. The specific changes covered depend on scoping decisions and the system boundaries defined for the engagement, so the precise scope varies across examinations rather than following a single universal list.

How is CC8 usually evidenced during a SOC 2 Type II examination?

In most engagements, evidence for CC8 includes documentation showing that changes were authorized, tested, reviewed, and approved before deployment. Auditors typically sample changes over the review period to assess operating effectiveness. The exact evidence requested depends on the auditor, the scope, and the nature of the system, so approaches vary between engagements.

How does CC8 relate to segregation of duties in the change process?

Change management under CC8 is often supported by separating the roles involved in requesting, approving, and deploying changes, which helps reduce the risk of unauthorized or unreviewed changes. Whether and how segregation is applied depends on the organization's environment and the scope defined for the examination rather than a fixed prescribed structure.

How should emergency changes be handled to align with CC8?

Organizations commonly define a separate process for emergency changes that allows expedited deployment while still requiring after-the-fact review, documentation, and approval. Auditors typically look for evidence that emergency changes were tracked and retroactively evaluated. The specific handling depends on the organization's policies and the auditor's expectations within the defined scope.

Common misconceptions

CC8 mandates one specific change management tool or a single required workflow that every organization must follow.

CC8 describes control objectives rather than prescribing a particular tool or workflow. In most engagements, organizations demonstrate how their own process meets the criterion, and the specific approach depends on scope, systems, and auditor judgment rather than a universal mandate.

Passing CC8 in a SOC 2 report means the change management controls are equivalent to ISO 27001's requirements for the same area.

CC8 is one of the Trust Services Criteria within a SOC 2 attestation and is not the same as ISO 27001's clauses 4-10 requirements or its Annex A reference controls. Mapping between the frameworks is possible but partial, and satisfying CC8 in a SOC 2 examination does not automatically satisfy ISO 27001.

A clean SOC 2 report covering CC8 guarantees that no unauthorized or harmful change will ever reach production.

A SOC 2 report attests only to the controls and the period covered. It reflects the auditor's evaluation of change management controls within the defined scope and does not guarantee freedom from control failures, incidents, or breaches.

Best practices

Define a documented change management process that specifies how changes are requested, reviewed, authorized, tested, and deployed, so evidence exists for the auditor's testing.

Retain records that demonstrate authorization occurred before implementation, since operating effectiveness over the review period is what a Type II examination evaluates.

Where scope warrants, separate development, testing, and production environments and separate the duties of those requesting, approving, and deploying changes.

Confirm with your service auditor which systems and change types fall within the examination scope, since expectations for CC8 depend on scoping decisions rather than a fixed rule.

Align change management evidence to the review period agreed for a Type II engagement, recognizing that the period length is set by scoping rather than a fixed duration.

If you also pursue ISO 27001, treat any mapping between CC8 and the relevant ISMS requirements or Annex A controls as partial, and validate each framework's requirements independently.