What does SOC 2 require for change management?

The Trust Services criterion CC8.1 asks that changes to infrastructure, data and software are authorized, designed, developed, configured, documented, tested, approved and implemented. It does not prescribe tools. Your own Change Management Policy states how you meet it, and the auditor tests what that policy says. This page reads the policy and produces repository settings that match it.

Why generate the settings from the policy instead of using a standard checklist?

An auditor compares what the policy says with what happens. If the policy requires one approval and the repository requires none, every sampled change is an exception; if the repository requires two and the policy says one, nothing breaks, but the policy no longer describes the process. Reading the approval count, the emergency procedure and the review rules from the policy text keeps the two aligned, and each rule here quotes the sentence it came from.

Is the ruleset JSON ready to apply?

It is the request body for GitHub's create repository ruleset endpoint (POST /repos/{owner}/{repo}/rulesets), applied with gh api. Before applying it, replace the two status check placeholders with the exact names of your CI jobs. Applied with the placeholders, every merge is blocked because those checks never report. Rulesets need a public repository or a GitHub Pro, Team or Enterprise plan for private repositories.

What about GitLab and Bitbucket?

For GitLab the kit gives a merge request template, CODEOWNERS, the protected branch and approval settings as REST API calls with steps to check, and an export script that uses curl and jq. Required approvals and code owner approval need GitLab Premium or Ultimate. For Bitbucket and other systems the kit gives the pull request template and a settings checklist to configure by hand.

What does the evidence export script do?

It lists merged pull requests since a date with the author, who merged, the approvers and the link, and writes them to CSV. It flags any change with no approving review and any change whose only approver is its author. The repository and date arguments are validated before use, and titles that start with a spreadsheet formula character are prefixed so they open as text.

What about emergency changes?

The template has an emergency checkbox and the README creates an emergency label, so emergency changes can be listed. The policy's emergency procedure, with its retrospective review window, is quoted in the template. Auditors may look at every emergency change in the period, so keep the incident ticket, the recorded approval and the retrospective review for each.

Is anything uploaded?

No. Your generator answers stay in this browser's local storage, the policies are rendered here and the files and the ZIP are built here. Without saved answers the page shows the sample company, Northwind Cloud Inc.

SOC 2 change management: repository settings from your policy

Updated 23 October 2026

A pull request template, a GitHub ruleset for the default branch, a CODEOWNERS starter, a README that maps each rule to its setting and evidence, and a script that exports merged pull requests with their approvers. Generated from your Change Management Policy and Secure Software Development Policy, in your browser.

Generate the files

The kit reads the rendered policies for the rules they state: the number of approving reviews, review by someone other than the author, passing CI checks, stale approvals, force pushes, code owner review for security-relevant changes, the emergency procedure and its retrospective review. Each rule quotes the numbered statement it came from. Pick your source control system; it defaults to the one in your answers.

This is the sample company, Northwind Cloud Inc. The files quote its Change Management and Secure Software Development policies, not yours. Answer the generator questions (in your browser) and come back: the kit then quotes your own policies and uses your source control and CI/CD tools.

Source control

GitHubGitLabOther

Require signed commits. Off by default: the policies do not require them.

5 files for GitHub, 1 required approval

Built in your browser from the sample policies; nothing is uploaded. Replace the [Fill in: ...] and @your-org/... placeholders before you use them.

<!--
  Northwind Cloud Inc pull request template, from the Change Management Policy (P09) and the Secure Software Development Policy (P10).
  P09 section 5.1: every change is proposed with this template; incomplete templates are returned to the author.
  Fill in every section. Write "n/a" with a reason instead of deleting a section.
-->

## Summary

<!-- What changes and why. -->

## Linked ticket

<!-- Issue or ticket for this change, e.g. ENG-123 or #123 (P09 section 5.1). -->
Ticket:

## Change type

- [ ] Standard: pre-approved and listed in the standard change catalog
- [ ] Normal: the full review process
- [ ] Emergency (P09 section 5.6): active incident or imminent risk. Add the `emergency` label, link the incident ticket and record who approved it. Retrospective review due within two business days.

## Risk and impact

- Risk: Low / Medium / High
- Expected customer impact:
- [ ] Customer-visible change: internal notice sent and release notes drafted

## Testing

- [ ] Automated tests added or updated for new functionality
- [ ] Required checks pass in GitHub Actions (P09 section 4.2)
- [ ] Tested in staging (required for migrations and high-risk changes)

Test evidence:

## Rollback plan (P09 section 4.10)

- [ ] Revert the merge
- [ ] Redeploy the previous artifact
- [ ] Disable a feature flag

Plan and rollback criteria:

## Security considerations (P10 section 4.4)

- [ ] This change is security-relevant (authentication, authorization, data access, cryptography, cloud IAM, network exposure or logging) and needs the Security Owner's approval (P09 section 4.5)
- [ ] Reviewed: authorization
- [ ] Reviewed: input handling
- [ ] Reviewed: secrets
- [ ] Reviewed: logging of sensitive data
- [ ] Reviewed: error handling
- [ ] Reviewed: dependency changes
- [ ] No secrets, keys or production data in the code, tests or this description (P10 section 4.8)

## Infrastructure and data

- [ ] Infrastructure plan or diff attached (infrastructure changes)
- [ ] Migration is backward compatible, tested in staging, and a backup or snapshot is taken first (destructive migrations)

## Reviewer

- [ ] I am not the author of this change and I read the full diff (P09 section 4.9)

What the sample policies require, and the setting for each

Each rule quotes the policy sentence it comes from. “Template wording” means the sentence was not in the policy text and the Policyseed template was quoted instead.

Rule	Policy says	Setting
Production runs only what was merged to the protected default branchP09 section 4.1	“All production code and infrastructure-as-code lives in GitHub, and production reflects only what has been merged to the protected default or release branch.”	Repository ruleset targeting ~DEFAULT_BRANCH (add release branch patterns if you release from them).
Every change goes through a pull or merge requestP09 section 4.2	“Every change is made through a pull or merge request in GitHub.”	Ruleset rule pull_request (direct pushes to the default branch are rejected).
Required number of approving reviewsP09 section 4.2	“Branch protection on default and release branches requires at least one approving review from someone other than the author …”	pull_request.required_approving_review_count = 1.
The author never approves their own changeP09 section 4.9	“The author of a change never approves it, and self-approval is disabled in GitHub.”	GitHub does not let a pull request author approve their own pull request; pull_request.require_last_push_approval = true also stops whoever pushed last from being the approver.
New commits dismiss earlier approvalsP09 section 4.2	“… dismisses stale approvals on new commits …”	pull_request.dismiss_stale_reviews_on_push = true.
CI checks must pass before mergeP09 section 4.2	“… requires all status checks from GitHub Actions to pass …”	Ruleset rule required_status_checks with your GitHub Actions job names (replace the [Fill in] placeholders).
Force pushes and branch deletion are blockedP09 section 4.2	“… blocks force pushes and branch deletion …”	Ruleset rules non_fast_forward and deletion.
Administrators cannot bypass the rulesP09 section 4.2	“… applies to administrators without bypass.”	Ruleset bypass_actors is empty, so repository and organization admins follow the same rules.
Security-relevant changes need the Security Owner's reviewP09 section 4.5	“Changes affecting authentication, authorization, data access, cryptography, cloud IAM, network exposure or logging are security-relevant and additionally require approval from the Security Owner or a designated security reviewer, routed automatically through code ownership rules in GitHub.”	CODEOWNERS file plus pull_request.require_code_owner_review = true.
Security scans block merges on Critical and High findingsP10 section 4.5	“Every pull request and the default branch are scanned in GitHub Actions with static application security testing, software composition analysis, secret detection, container image scanning and infrastructure-as-code scanning. Critical and High findings block the merge until fixed or formally suppressed under 5.3.”	A required status check for the GitHub Actions security scan job (second placeholder in the ruleset).
Secret scanning and push protectionP10 section 4.8	“Secrets follow the Encryption and Key Management Policy: never hard-coded or committed to GitHub, always injected from the secrets manager at runtime, and protected by secret scanning and push protection.”	Repository settings: secret scanning and push protection enabled (the gh api command in the README). Check availability for private repositories on your plan.
Every pull request uses the templateP09 section 5.1	“The author opens a pull request in GitHub using the template, which requires a description, linked issue, risk classification, test evidence, rollback plan, expected customer impact and whether the change is security-relevant. Incomplete templates are returned to the author.”	.github/pull_request_template.md in the default branch.
Reviewers apply a security checklistP10 section 4.4	“All code is peer reviewed through a pull request in GitHub under the Change Management Policy, and reviewers apply a security checklist covering authorization, input handling, secrets, logging of sensitive data, error handling and dependency changes.”	Security section of the pull request template.
Emergency changes get a retrospective reviewP09 section 5.6	“Emergency changes. The Engineering lead or Security Owner declares an emergency when an active incident or imminent risk cannot wait for the normal process. A second engineer is notified before the change, approval given verbally or in chat is recorded in the incident ticket, and the change is labeled as an emergency in GitHub. Within two business days it receives a full retrospective review and any follow-up fixes, and it appears in the monthly change report.”	An emergency label and the emergency checkbox in the template; the export script lists labeled pull requests.
Every change has a rollback pathP09 section 4.10	“Every change has a documented rollback path: revert the merge, redeploy the previous artifact or disable a feature flag.”	Rollback plan section of the pull request template.
Only the pipeline deploys to productionP09 section 4.6	“Production deployments are performed only by GitHub Actions using dedicated service identities scoped to the target environment. Personal credentials never deploy to production, and the deployment record captures who triggered it, the commit deployed and the outcome.”	A production environment in GitHub Actions with deployment branch rules limited to the default branch; deploy credentials held by the pipeline only.
Change records are retainedP09 section 4.14	“The pull request, its review, the check results from GitHub Actions and the deployment record together form the change record and are retained for at least 12 months as audit evidence.”	Keep merged pull requests and Actions logs; export the CSV each month because log retention in Actions is limited.
Monthly sample of production changesP09 section 5.8	“The Security Owner samples at least ten percent of production changes and no fewer than five, verifies independent approval, passing checks and a deployment record for each, confirms branch protection settings in GitHub remain as required, investigates any bypass or emergency change, and summarizes the results to Executive Management.”	Run export-merged-prs.sh each month and review the flagged rows.

How auditors sample changes

A common approach is to request a complete list of production changes for the period, pick a sample and, for each sampled change, ask for:

the ticket or issue that requested it
the peer review, by someone other than the author
the test and check results before merge
the approval, recorded before the merge time
the deployment record linking the merged commit to production

Auditors may also look at the branch protection or ruleset configuration and how it changed during the period, at any bypass, and at emergency changes and their retrospective review. The export script produces the list; the ruleset JSON and gh api /repos/OWNER/REPO/rulesets show the configuration. Sample sizes and formats depend on the CPA firm, so agree them before the period starts.

The Trust Services criteria involved:

CC8.1 Change management: changes are authorized, designed, tested, approved and implemented; this is the criterion change samples are tested against.
CC5.2 Technology controls: general controls over technology, which branch protection and pipeline settings are part of.
CC6.8 Malicious software: controls to prevent or detect unauthorized or malicious software, which required reviews and scans support.

The settings make the process enforceable; they are not evidence that it ran. The pull request history, the reviews and the deployment records are.

Collect the evidence from the command line

The open-source Policyseed CLI has a policyseed evidence command that collects repository evidence for the audit period. See collecting audit evidence in the README, and the integrations page for the CLI, the CI check and the MCP server.

Change Management Policy template: the policy the rules come from.
Policy generator: answer the questions once and this page quotes your own policies and uses your source control and CI/CD tools.
Audit Kit: the paid kit includes this change management folder, built from your tailored policies, alongside the Word policies and evidence trackers.

Frequently asked questions

What does SOC 2 require for change management?: The Trust Services criterion CC8.1 asks that changes to infrastructure, data and software are authorized, designed, developed, configured, documented, tested, approved and implemented. It does not prescribe tools. Your own Change Management Policy states how you meet it, and the auditor tests what that policy says. This page reads the policy and produces repository settings that match it.
Why generate the settings from the policy instead of using a standard checklist?: An auditor compares what the policy says with what happens. If the policy requires one approval and the repository requires none, every sampled change is an exception; if the repository requires two and the policy says one, nothing breaks, but the policy no longer describes the process. Reading the approval count, the emergency procedure and the review rules from the policy text keeps the two aligned, and each rule here quotes the sentence it came from.
Is the ruleset JSON ready to apply?: It is the request body for GitHub's create repository ruleset endpoint (POST /repos/{owner}/{repo}/rulesets), applied with gh api. Before applying it, replace the two status check placeholders with the exact names of your CI jobs. Applied with the placeholders, every merge is blocked because those checks never report. Rulesets need a public repository or a GitHub Pro, Team or Enterprise plan for private repositories.
What about GitLab and Bitbucket?: For GitLab the kit gives a merge request template, CODEOWNERS, the protected branch and approval settings as REST API calls with steps to check, and an export script that uses curl and jq. Required approvals and code owner approval need GitLab Premium or Ultimate. For Bitbucket and other systems the kit gives the pull request template and a settings checklist to configure by hand.
What does the evidence export script do?: It lists merged pull requests since a date with the author, who merged, the approvers and the link, and writes them to CSV. It flags any change with no approving review and any change whose only approver is its author. The repository and date arguments are validated before use, and titles that start with a spreadsheet formula character are prefixed so they open as text.
What about emergency changes?: The template has an emergency checkbox and the README creates an emergency label, so emergency changes can be listed. The policy's emergency procedure, with its retrospective review window, is quoted in the template. Auditors may look at every emergency change in the period, so keep the incident ticket, the recorded approval and the retrospective review for each.
Is anything uploaded?: No. Your generator answers stay in this browser's local storage, the policies are rendered here and the files and the ZIP are built here. Without saved answers the page shows the sample company, Northwind Cloud Inc.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.