CC8.1: Change management
CC8.1 tests whether code reaches production through review. Deixic sets the branch rules, waits for an approver where a rule can block a merge, and never approves a pull request itself.
What CC8.1 asks
CC8.1 asks that the company authorize, test, and approve each change before it reaches production, and keep a record of who did what.
For a startup on GitHub, the auditor samples merged pull requests and checks for a review, passing checks, and an approver other than the author.
Source: AICPA Trust Services Criteria (2017, with revised points of focus 2022). This page paraphrases the criterion.
Tests that fail, and what Deixic does
Each row is a test from your compliance platform and the change Deixic makes in the connected system.
| Failing test | What Deixic does | Authority |
|---|---|---|
| Code changes require reviewGitHub | Requires a pull request with 1 approval on the default branch and blocks force pushes. The first run covered 12 repositories. | Runs under written policy |
| Status checks must pass before mergeGitHub | Requires the checks your pipeline already reports. A required check that does not exist blocks every merge, so an approver confirms the list. | Waits for a named approver |
| Administrators follow the same rulesGitHub | Turns off the administrator bypass on branch protection. | Waits for a named approver |
| Production deploys need approvalGitHub | Adds required reviewers to the production environment. | Waits for a named approver |
| Every production change links to an approved pull requestGitHub | Lists commits that reached the default branch without a pull request in the audit period. | Goes to you as a decision |
What waits, and what Deixic refuses
Approvals name a person and record a reason. Decisions are actions outside the authority your policy grants.
Waits for a named approver
- Requiring status checks, because a wrong list blocks every merge.
- Removing the administrator bypass.
- Naming the reviewers on the production environment.
Never run without your decision
- Explaining a commit that skipped review. Deixic lists it and does not rewrite history.
- Approving or merging a pull request. Deixic never reviews its own change or anyone else's.
- Force-pushing or disabling a rule to land a change.
What Deixic reads back
After each change Deixic reads the setting from the system itself.
| System | Read back |
|---|---|
| GitHub | Branch protection as stored for each repository: approvals, force pushes, checks, administrator bypass. |
| GitHub | Environment protection rules and their reviewers. |
Evidence your auditor receives
One signed, hash-linked receipt per change, exported as PDF, HTML, or JSON.
- Branch protection settings before and after for each repository
- The repository list the change covered
- The sampled pull requests with reviewer and checks
- Commits that skipped review and your explanation
- Approver and reason for each rule that waited
- The re-run result of the test in your compliance platform