Change request form and CAB template for SOC 2

Updated 25 October 2026

A free change request form in Word and a change log in Excel for a small SaaS team. The form covers standard, normal and emergency changes, approvals, testing, rollback and customer impact, and comes with a lightweight change advisory board (CAB) record. The fields follow the Change Management Policy, so the form and the policy say the same thing.

What an auditor samples: one change from request to deployment

For change management the usual test is to pick a change that reached production and follow it back. Unleash's guide on change management for SOC 2 describes the record as four connected data points: the ticket, the pull request, the review and test results, and the deployment record. If each links to the next, the sample takes minutes. If they do not, the sample turns into a search through chat history. The criterion behind it is CC8.1, and the evidence list is in the SOC 2 evidence checklist.

The form is the place where those four links are written down for a change that does not have a pull request to carry them, and a checklist for the author when it does. The mock audit lets you rehearse the questions an auditor asks about changes.

The form: field by field

Every field names the policy statement it comes from. The form has 8 sections:

The proposal fields are the ones section 5.1 of the policy says an incomplete request is returned for:

Proposal. 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. (P09 5.1, as rendered for the sample company)

Where a field depends on your own choice, the form says so with a [Fill in: ...] placeholder: what makes a change high risk, how often the board meets, how long the retrospective review may take. The file does not decide those for you.

Standard, normal and emergency changes, and which path needs which approval

Changes are classified as standard (low-risk, repeatable and pre-approved through the standard change catalog), normal (the full process in Section 5) or emergency (an active incident or imminent risk, handled under 5.6 with retrospective review). (P09 4.3)

The same split exists in IT service management practice. Ivanti's documentation on change requests says a standard change is approved by the CAB once, before it is added to the list of standard changes, and that an emergency change needs immediate attention from the CAB or an emergency CAB (Ivanti: about change requests). In the policy, the list is the standard change catalog:

Standard change catalog. Engineering maintains the list of pre-approved standard changes, such as automated dependency updates, content updates and scaling within approved limits, each with its conditions and automated checks. The Security Owner reviews the catalog semi-annually and removes entries whose risk has changed. (P09 5.7)

The Excel file has a Standard changes sheet with the three examples the policy names and placeholders for each entry's conditions, automated checks and owner.

A change advisory board for a team of 3 to 15

The Policyseed policy does not require a board. It requires an independent reviewer on every change, the Security Owner or a designated security reviewer on security-relevant ones, and a Security Owner who samples changes afterward. A CAB is a way to show those approvals in one place, and for a small team it can be very small:

• Who sits on it. The Security Owner and the engineering lead. When one of them wrote the change, the other decides, and a technically competent member of executive management can fill in if there is no independent reviewer, as the policy's statement 4.9 allows.
• How often it meets. Your choice. The form leaves the cadence as a placeholder, because a team that deploys daily and a team that deploys monthly need different rhythms. Pre-approved standard changes and routine pull requests do not wait for it.
• When a CAB is just two people. Often. The record still has value if it shows a date, the attendees, each change reviewed and the decision on it.

Unleash's guide notes that small teams can lean on detective controls, such as notifications and logging, when strict separation of duties is not feasible (Unleash). The Policyseed policy is stricter on one point: the author never approves the change, and the requirement is not waived. Where you adopt a looser rule, write it into the policy or record it as an exception in the policy exception register.

The emergency path: what to record afterward, and by when

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. (P09 5.6)

Section 8 of the form has a field for each element: who declared the emergency, who was notified, where the approval was recorded, the label, the retrospective review and the monthly report. The deadline for the review is the one thing you should check against your own policy. The template wording above is the Policyseed default; if you changed it, change the placeholder in the form to match.

Other write-ups use their own windows. Creately's emergency change process, which it maps to CC8.1, lists seven steps and expects post-implementation review notes dated within one business day (Creately: SOC 2 emergency change process). That is Creately's evidence list, not a SOC 2 requirement. Unleash makes the broader point that an emergency may skip the normal timeline but still has to leave a trace, with the review and retroactive approval attached to the ticket. What both agree on is the part the form captures: an emergency is allowed, an unrecorded one is not.

The change log: one row per change

The Excel file has one row per change, with the same labels as the form. Class, risk level, security-relevant, change path, outcome and status are dropdown lists. Link the ticket and the pull request instead of pasting them: the links are what you open when someone samples a row.

The log also feeds the monthly sample the policy describes: the Security Owner checks a sample of production changes for independent approval, passing checks and a deployment record, and investigates any bypass or emergency change. Keep the change record as the policy says, in statement 4.14. Related templates: the risk register for risks a change introduces, and the policy exception register for a change process you cannot yet follow in full.

Where tools replace paper, and what the form still covers

For changes made in code, the tools do most of the work. Branch protection enforces the independent review and the passing checks, the pipeline records the deployment, and a pull request template asks the author the questions. The SOC 2 change management guide for GitHub and GitLab covers the settings and the merged-pull-request report. This snippet asks the section 5.1 questions in the pull request itself; copy it into your repository's pull request template file:

## What is changing and why
<!-- The description the policy requires -->

## Linked issue or ticket
<!-- Link -->

## Change class
- [ ] Standard
- [ ] Normal
- [ ] Emergency
<!-- Emergency: add the emergency label and link the incident ticket. -->

## Risk level
- [ ] Low
- [ ] Medium
- [ ] High

## Security-relevant
- [ ] Yes
- [ ] No
<!-- If Yes, request review from the Security Owner or designated security reviewer. -->

## Test evidence
<!-- Link to the check results from your pipeline -->

## Rollback plan
<!-- Revert the merge, redeploy the previous artifact or disable a feature flag -->

## Expected customer impact
<!-- None, or what customers will notice and when -->

The form still covers what has no pull request. The policy asks for security-relevant changes in systems not managed as code to be handled this way:

Security-relevant configuration changes in systems not managed as code, such as organization settings in GitHub, Okta policies, vendor administration consoles and DNS, are requested by ticket, approved by the Security Owner and recorded with the before and after state. (P09 4.13)

Those are the changes made in a console, in DNS or in a vendor's admin screen. Section 7 of the form holds the before and after state, and the log marks the row as Not in code. The Audit Kit ($59, one time) includes a change-management folder with a pull request template and repository settings written for your source control and pipeline, next to the policies tailored to the tools you named.

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.