EvidenceSheet
SOC 2 (2017 Trust Services Criteria) · CC - Common Criteria (Security)

CC8.1 Managing changes to procedures, software, data and infrastructure

Every change to procedures, software, data or infrastructure is authorised, designed or acquired, configured, documented, tested, approved and implemented. Points of focus: changes are managed across the system life cycle; they are authorised before development, designed and developed, documented, tracked before implementation, configured, tested, approved and deployed; the effect on objectives is evaluated through the life cycle; changes needed to remediate incidents are identified and started; a configuration baseline is maintained for IT and control systems; emergency changes follow their own authorise-test-approve path; and confidential and personal information are protected during design, development, testing and change. The 2022 revision adds: segregation of responsibilities so one person cannot develop, test and deploy a change alone; testing of internally developed and acquired changes before production (unit, integration, regression, static and dynamic code analysis, quality assurance or automated testing); a process to identify, assess, test, approve and roll out patches on time; for availability, designing for resilience and testing it during development; and, for privacy, building privacy requirements into design and collecting and processing only the personal information the purpose needs.

Source: SOC 2 (2017 Trust Services Criteria), CC8.1. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open SOC 2 (2017 Trust Services Criteria) in the compliance library.

These are criteria, not controls: you design controls that meet them, and which criteria are in scope follows the categories your report covers (Security always; Availability, Confidentiality, Processing Integrity and Privacy only if chosen). A Type 2 report tests that the controls operated across the period, so the evidence asked for is samples across that period, not one copy.

5
artefacts
1
held by a system
3
at each review
hard
to go live
Ticketing / ITSM
where the evidence lives
teal = a system already holds it · olive = produced at each review. To go live: easy when half or more of the artefacts are already held by a system, moderate from a quarter to a half, hard below a quarter.

These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.

system holds itEvidence a system already holds

  • Patch management records with timelines · Vulnerability scanner / patch tooling

periodic reviewEvidence produced at each review

  • Sample of change tickets with approval, testing evidence and deployer different from author · Ticketing / ITSM
  • Evidence production data is not used in test environments, or is masked · Ticketing / ITSM
  • Privacy-by-design or data minimisation review records for new features (privacy engagements) · Ticketing / ITSM

governing documentDocuments that govern the control

  • Change management policy covering normal, standard and emergency changes · Policy repository / GRC workspace

First move

Mostly documents and reviews. Pull the 1 system-held artefact from your Vulnerability scanner / patch tooling on a schedule; put the documents under version control with an owner and review date, and log each review as a dated record with a named reviewer.

Common gaps auditors find

Do this for your whole sheet

Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.

Build my evidence sheet

CC7.5 Recovering from security incidents · CC9.1 Mitigating risks of business disruption