Introduction
Many engineering teams use Jira tickets as the front door for production changes. For a SOC 2 audit, that ticket often becomes the anchor of the evidence: it shows why the change was made, who approved it, and how it links to code and deployment. This guide explains what auditors usually look for in a change ticket and how to keep tickets useful as evidence.
This is general guidance, not a requirement of any specific auditor. Your control description and your auditor's test attributes decide what must be present.
Related reading: What Is Change Management?, What Is Peer Review (Code Review)?, and Change Management Evidence for SOC 2.
Why the Ticket Matters
In a SOC 2 Type 2 examination, auditors usually obtain a population of production changes for the audit period, select an audit sample, and trace each item to its records. A ticket that connects the request, approval, review, and release makes that trace short. A missing or vague ticket makes it long, and gaps can become a control deviation.
What a Strong Change Ticket Contains
| Ticket element | Why auditors care |
|---|---|
| Clear summary and description | Shows what changed and why |
| Requester and assignee | Identifies who asked for and who built the change |
| Approval record | Shows authorization before release, per your policy |
| Link to the pull request | Connects the ticket to pull request approval evidence |
| Test or verification notes | Shows the change was checked before release |
| Release or deploy reference | Ties the ticket to the production event and date |
| Status history with timestamps | Shows the order of events, such as approval before deploy |
Keep Tickets Consistent
Consistency matters more than detail. A few habits help:
- Use one issue type or label for production changes so the population is easy to pull
- Require a linked pull request or commit before a ticket can move to done
- Record approvals in the ticket workflow instead of in chat messages
- Use a distinct path for urgent work, and document it as an emergency change with a follow-up review
- Avoid editing closed tickets after the fact, because history changes can raise questions
Building the Population from Jira
Auditors need a complete list, not a hand-picked one. Practical steps:
- Agree with your auditor on what counts as an in-scope production change
- Export tickets for the full audit period using a saved filter
- Reconcile the export against deploy records so no release is missing a ticket
- Note any production changes without tickets and explain them
- Keep the export and the filter definition with the date it was run
See also What Is an Audit Population?.
Linking Tickets to Code and Deploys
A ticket alone shows intent. Auditors also want proof that the change was reviewed and released as described. Link each ticket to its pull request, and keep the review and branch protection records that show required approvals. Related guides: Pull Request Review Evidence for SOC 2 and GitHub Branch Protection Evidence for SOC 2.
Common Mistakes
- Closing tickets without a linked pull request
- Approvals given verbally or in chat and never recorded
- Bulk-editing tickets after the period ends
- Using free-text fields so changes cannot be filtered reliably
- Letting the requester approve their own change when the control calls for independence
- Treating urgent fixes as exempt from tickets
Pre-Fieldwork Checklist
- Saved filter returns every in-scope production change for the period
- Each ticket links to a pull request and a deploy reference
- Approval and review dates fall before the release date
- Urgent changes have a post-implementation review
- Exceptions are explained and tracked for remediation
How AuditFlo.co Helps
AuditFlo.co helps teams retain continuous evidence collection and audit-period history for change records when tickets and pull requests live in connected systems your team already uses, such as Jira and GitHub. That history can make it easier to assemble a population and trace samples. AuditFlo.co does not approve changes, does not issue SOC 2 reports, does not certify compliance, and does not replace your auditor.
To see the workflow for your stack, request a demo.
Key Takeaway
A good Jira change ticket links the request, approval, review, and release in one place. Keep tickets consistent, build the population from a saved filter, and tie each ticket to code and deploy records so sampling is quick and clean.