For a SOC 2 Type 1, you can satisfy change management (CC8.1) with Git alone: protected main branch, pull requests with required review, automated tests as required checks, linked tickets, and a written emergency path. The auditor looks at whether the control is designed properly and in place at a point in time.
A Type 1 report, per the AICPA text, covers the design of controls and does not give an opinion on operating effectiveness. That makes your setup easy to show, but design still has to be real: configured tools, a written policy, and a few sample changes that follow it.
What does the design look like?
Think of five rules enforced by the repository host, not by memory:
- Nothing reaches the main branch except through a pull request. Turn on branch protection and apply it to administrators too.
- At least one approving review from someone other than the author. This maps to the criteria's points of focus on approval and on segregating responsibilities so one person cannot develop and deploy alone.
- Required status checks. Tests, linting, dependency and secret scanning must pass. The points of focus list unit, integration, regression, static and dynamic testing as examples.
- Every pull request links a ticket. The ticket records who asked and who authorized the work.
- Deploys come from the pipeline. Only the pipeline, or a short list of named people, can push to production, and every deploy is logged.
What about the emergency path?
CC8.1 points of focus include a process for emergency changes. Write three lines: who can declare an emergency, that the change still uses a pull request (it may merge after a quicker review), and that a post-change review happens within a stated time. Label such pull requests so they are easy to sample.
What about infrastructure and configuration?
Keep infrastructure as code in the same repositories, with the same rules. If somebody changes a cloud console by hand, open a ticket and note it. A baseline configuration, another point of focus, can be the infrastructure code itself plus a written hardening list.
Which evidence goes in the Type 1 folder?
- The change management policy, signed and dated.
- Screenshots or exports of branch protection and required check settings for each in-scope repository.
- The list of people who can deploy and merge, with roles.
- Three to five example pull requests showing ticket, review, passing checks and deploy.
- The emergency change procedure and, if one happened, its record.
- Your pipeline configuration file.
What mistakes delay a Type 1?
- Branch protection on some repositories, not all.
- Admin bypass left on.
- A policy that describes a review nobody has enforced yet.
- No named owner for the process.
- Pipeline credentials shared by several people.
What to do
- List in-scope repositories and the production deploy path.
- Turn on protection, required reviews, required checks and admin enforcement.
- Add the ticket link rule, using a pull request template.
- Write the one-page policy with the emergency path.
- Capture settings evidence and sample pull requests.
- Ask an engineer outside the project to try pushing straight to main. It should fail.
Quick check
Do I need a separate change management tool?
No. The criteria ask for authorized, tested and approved changes with records. Git, a ticket tracker and a pipeline can supply all of those.
Is a solo founder able to pass change management?
Reviews by a second person are hard to show with one engineer. Discuss compensating controls with your auditor, such as automated checks and delayed review by an advisor.
How Safeguard helps automate this
Git gives you the process, and Safeguard helps with the evidence and the code risk inside each change. Its compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits, saving the team time for other work. Technical evidence comes from your real code and dependencies through scans, SBOMs and reachability. Autonomous remediation can open tested fix pull requests for vulnerable dependencies, which then follow your review rules. It is off by default, every category starts on Manual, and you choose which categories run automatically. The auditor issues the report. Book a call to see it.
Sources
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022): CC8.1 and the Type 1 report description, read from a local copy on 18 October 2026
Last reviewed: 18 October 2026.
