How do I prove change management from GitHub for SOC 2 or ISO 27001?
the heygrc team
Largely, yes, if the settings are right. A pull-request workflow already records what changed (the diff), who reviewed and approved it, what ran before merge (the checks), and when it merged (the merge commit). SOC 2 CC8.1 and ISO 27001 A.8.32 both want changes authorized, tested, approved, and traceable, and a well-run repository evidences most of that with no extra tooling. What it does not give you for free is the enforcement story (proof the approvals could not be skipped) and the mapping from each change to the control it touches. Those you add.
Let branch protection carry the authorization half
Change management is two questions: was each change authorized, and can you show it. The pull request shows the instance; branch protection shows the rule. Require pull requests with at least one approval (two where segregation of duties matters), require the checks you trust, and require review from code owners on the paths that matter. An auditor sampling CC8.1 or A.8.32 asks how you know an unreviewed change cannot reach main: the protection settings show the rule as it stands today, each approval is an instance of it holding, and if the rule changed inside the audit window, the repository audit log (ruleset and protection changes) is where you show when.
Make each pull request read as a change record
The PR body says why, the diff says what, the check runs say it was tested, the approval says a second person accepted it, and the merge commit says when the change merged. When it actually shipped is a deployment record (a release, an environment, a deploy run), which change management treats as its own step, not something the merge proves. Keep pull requests small enough that a review is a real review, link the ticket or issue for the business reason, and do not push straight to the protected branch even where you can, which is the route around the review you require of everyone else. A tidy history is not vanity: it is the population an auditor samples.
Know what GitHub does not prove
Three gaps. Force-push can rewrite history on refs that are not protected and admins can bypass some protections, so the enforcement story has edges; state them honestly rather than overclaim. Retention has edges too: delete the repository and the pull-request records go with it, and GitHub's own logs (the org audit log, Actions logs) expire on a limited, plan-dependent window, so export what your audit window needs before they do. And nothing in the pull-request record itself maps a change to the framework: CC8.1 does not label a diff and A.8.32 does not comment on a pull request. That mapping is what a per-PR compliance review adds (heygrc posts findings that name the clause), building the control-to-change trail in the same place the change already lives.
# Default reviewers for the whole repo* @acme/devs+ /security/ @acme/securityWith branch protection requiring review from code owners, changes under security/ route to the security team for approval. Guard the CODEOWNERS file itself the same way, or the rule can be weakened in an ordinary pull request. Authorization for the risky paths, written in a file an auditor can read.
Related