A useful change ticket records who asked, what is changing, why, how risky it is, who approved it, how it was tested, when it was deployed and how to roll it back. Seven to nine fields are enough. Pull as many as you can from the pull request automatically so people do not skip them.
What the standard asks, in plain terms
NIST's change control requirement lists what an organization should do: determine which types of changes are controlled, review proposed changes and approve or disapprove them (including consideration of security and privacy impact), document the decisions, implement approved changes, retain records for a defined period, and monitor the activity. A ticket is the place those facts sit together.
The field list
| Field | Why it exists | Can it be automatic? |
|---|---|---|
| Requester and date | Who and when | Yes, from the ticket system |
| Description and reason | What and why | Partly, from PR description |
| Change class | Standard, normal or emergency | Label on the PR |
| Risk and impact note | Security and privacy considered | Short required text |
| Approver | Someone with authority other than the author | Yes, from PR approval |
| Test evidence | Proof it was checked | Yes, CI results link |
| Deploy time and who deployed | Traceability | Yes, from pipeline |
| Rollback plan | How to undo | Required text |
| Link to commit or PR | Ties record to code | Yes |
If a field is never filled in or always says "N/A", delete it. Fewer, true fields beat many empty ones.
Design for sampling
When an auditor samples tickets, they follow the chain: request, approval, test, deploy. Make each link clickable. A ticket that says "approved in Slack" with no link breaks the chain. A ticket that links to the approving review, the passing test run and the deploy log tells the whole story in two minutes.
Steps to improve what you have
- Pull ten recent tickets and try to trace each one end to end.
- Note where you got stuck: missing approver, no test link, no deploy time.
- Make those fields required, or fill them automatically.
- Remove fields nobody uses.
- Write the approver rules: who can approve what, and that nobody approves their own work.
- Test again with ten new tickets next month.
Emergency tickets
For emergencies, require the incident link and a retro-review field filled within a set time. Add a status that shows the retro-review is still owed, and report on open ones weekly.
Retention
Ticket systems have limits and people leave the company. Export the sampled evidence periodically and keep it for the length of your retention policy. Closed tickets should be read-only, or changes to them logged.
Quick check
Do I need a ticket for every pull request?
Not necessarily. For many teams the pull request is the ticket. Define which changes need a separate ticket and say so in your policy.
Who can approve a ticket?
Someone with the authority your policy names, other than the author. Write the rule down.
Safeguard policies and gates can require checks on pull requests, and compliance and evidence automation keeps records linked. Run a free scan.
Sources
Last reviewed: 19 October 2026.
