SOC 2 Change Management with Tickets Instead of CI/CD

TL;DR

• Change management maps to CC8.1, which has 14 Points of Focus covering authorization, design, testing, approval, deployment, segregation of duties, baseline configuration, emergency changes, and patch changes
• Ticket-driven workflows (JIRA, ServiceNow, Azure DevOps Boards, Linear) satisfy CC8.1 when each ticket captures request, risk rating, approver, test plan, maintenance window, rollback plan, and post-implementation verification
• A six-state workflow (Draft, Assessment, Approved, Scheduled, Implemented, Closed) maps cleanly to the CC8.1 outcomes and produces consistent evidence the auditor can sample
• For small teams, segregation of duties holds when approver, implementer, and verifier are three different people, even if the implementer is the only one technically deep enough to make the change
• Emergency change procedures, CAB structures, and the quarterly review pattern complete the program

A SOC 2 auditor sampling change management evidence wants to see the same thing every time: who asked, who approved, what got tested, when it landed, what happened if verification failed. They want it consistently across ten or fifteen sampled changes spanning the observation period. The shape of the evidence package is what matters. The workflow that produces it is the team's choice.

Cloud-native shops produce that package as a byproduct of the pull request workflow. Pull request, automated tests, reviewer approval, merge to a protected branch, pipeline-driven deployment with rollback. The evidence is a GitHub link the auditor clicks through. Teams running on bare metal, hybrid stacks, healthcare legacy, manufacturing, MSP fleets, or anywhere a CI/CD pipeline cannot safely automate the change produce the same evidence package through a different path: tickets. Ticket-driven change management is fully SOC 2-compliant for bare metal and hybrid environments. It just takes deliberate workflow design, and most auditor-facing content does not describe what that design looks like.

What SOC 2 Actually Requires

SOC 2 doesn't mandate pull requests. The Trust Services Criterion that governs change management is CC8.1, and it describes outcomes, not implementation patterns. A change management program that satisfies CC8.1 covers the following territory:

• Change request and authorization. Every production change starts as a documented request with a justification, a named requester, and a named approver who is not the person making the change.
• Risk and impact assessment. Each change is evaluated for risk before approval. Risk drives the level of review, testing required, and whether a change advisory board weighs in.
• Testing and validation. Changes are tested before reaching production. Scope of testing is proportionate to risk. Test results are recorded.
• Approval and segregation of duties. Production changes require documented approval. The approver, implementer, and deployer are not all the same person. Small teams require documented compensating controls.
• Scheduled implementation. Changes land in defined maintenance windows or through documented emergency procedures. Unscheduled changes are the exception, and each exception is itself a tracked record.
• Post-implementation verification and rollback. Changes are verified after deployment. If verification fails, a documented rollback plan is executed. The verification and the rollback (if any) are recorded.
• Change record retention and review. Records are retained through the observation period and sampled during the audit. A quarterly review confirms the process is running as described.

None of these outcomes say pull request. A ticket workflow satisfies every one of them when designed to.

Tickets vs CI/CD: The Framing That Matters

The common mistake is framing this as cloud vs on-prem. That's not the distinction. Cloud environments use ticket-driven change control all the time for database migrations, IAM changes, and DNS cutovers. On-prem environments can and do run CI/CD pipelines for the parts of their stack that support it.

The real distinction is ticket-driven vs pull-request-driven change control. Two evidence models, both valid under SOC 2. The pull-request model produces evidence as a byproduct of the tool: the approval is the PR review, the testing is the CI run, the deployment is the merge, the rollback is git revert. Every step is captured automatically. The ticket model produces evidence as a byproduct of the workflow: the approval is a state transition, the testing is a recorded result attached to the ticket, the deployment is a logged action tied back to the ticket ID, the rollback is a documented procedure that was either executed or wasn't. The auditor reads the ticket end-to-end instead of clicking through a commit history. Both work. Only one of them gets written about.

The Structure of a SOC 2-Ready JIRA Ticket

JIRA is the canonical example because most compliance-relevant teams already have it. The same structure applies to ServiceNow (the default for larger ITIL-aligned enterprise environments), Azure DevOps Boards, or Linear. What matters is that every ticket captures the same fields in the same places so the auditor doesn't have to hunt. This is the same evidence-continuity pattern used for ticket-driven vulnerability remediation and incident response.

Required fields

Beyond title and description, a SOC 2 change ticket should carry:

• Change type. Standard, normal, or emergency. Drives the workflow path.
• Risk rating. Low, medium, or high. Drives whether a CAB review is required and how much testing evidence must be attached.
• Requester and implementer. Named people.
• Approver. Named person or CAB reference. Must not equal the implementer for medium and high risk changes.
• Target systems. Production systems or components affected. Critical for scoping.
• Maintenance window. Scheduled start and end time, or a reference to a recurring window.
• Rollback plan. A short, specific description of how the change will be reversed if verification fails.
• Post-implementation verification. The test or check that confirms the change landed correctly.
• CAB reference. If applicable, the meeting date and a link to the minutes.

Workflow states

A clean SOC 2 workflow has six states, each tied to a required field or attachment:

1. Draft. Requester fills in the change details, risk rating, and target systems.
2. Assessment. Risk rating is confirmed, CAB requirement is determined, test plan is attached.
3. Approved. Approver signs off in the ticket. State transition records the approver identity and timestamp.
4. Scheduled. Maintenance window assigned. Ticket is now waiting for the window to open.
5. Implemented. Implementer logs the steps executed, attaches deployment output, and runs the verification check.
6. Closed. Post-implementation verification result is recorded. If rollback was triggered, the rollback outcome is documented before closing.

This six-state workflow satisfies every outcome CC8.1 expects when field requirements are enforced at each transition. JIRA supports this through workflow validators, worth configuring once so the auditor sees consistency across samples. ServiceNow's change management module enforces the same pattern with different terminology and is the go-to in larger enterprise environments where ITIL alignment matters.

The worked example

Consider a generic scenario: a production database needs a schema migration to add two columns and an index on a reporting table. Medium risk because the migration briefly locks the table and rollback means dropping the new columns if anything downstream breaks. A change this size also needs a verified backup and restoration plan attached to the ticket before it runs.

In Draft, the requester describes the change and flags the affected columns. In Assessment, the DBA on call rates it medium risk, triggering a CAB requirement. The CAB reviews the ticket, discusses the lock behaviour, and approves on the condition that it run in the Sunday-night maintenance window. The CAB chair is set as the approver and the minutes are attached. On Sunday night the implementer (not the approver, not the DBA who did the risk rating) runs the migration script, attaches the script output and row-count verification, and transitions to Implemented. On Monday morning a different team member runs the post-implementation verification and attaches the result. The ticket closes.

Every outcome CC8.1 expects has a fingerprint in that one ticket. Authorization lives in the request and approver field. Risk assessment lives in the risk rating and CAB decision. Testing lives in the test plan and post-implementation verification. Segregation of duties lives in the separation between approver, implementer, and verifier. Scheduled implementation lives in the maintenance window reference. Verification and rollback live in the post-change check and the documented fallback. Retention lives in the ticket itself, preserved for sample review. The auditor doesn't need to understand the schema change. They need to see that fingerprint consistently across ten or fifteen sampled tickets.

CAB, Maintenance Windows, and Emergency Changes

For medium and high risk changes, a change advisory board is the standard compensating control that replaces the automated risk gates a CI/CD pipeline would enforce. The CAB doesn't need to be formal or large. A weekly thirty-minute meeting with an engineering lead, an operations lead, and someone from security or compliance works. What matters is the documented record: date and attendees, ticket references reviewed, decision per ticket, conditions, and action items. The auditor will match the minutes against the approved-state transitions on sampled tickets.

Maintenance windows. The evidence is a calendar, not a narrative. A shared calendar with recurring window entries, the same reference name used in the JIRA maintenance window field, and a twelve-month retention policy is enough. For environments without a scheduling tool, a wiki page listing each window by date range and ticket IDs covered works just as well.

Emergency changes. SOC 2 expects them. A framework that pretends every change can wait for the next CAB gets overridden the first time a critical system goes down. Define an emergency change type that skips the pre-approval CAB step but requires post-hoc approval within 48 to 72 hours and a review at the next CAB. The ticket still captures requester, implementer, risk, target, rollback, and verification. A team that handles zero emergencies in a quarter is suspicious; a team that handles and documents them is credible.

Segregation of Duties When the Team Is Small

CC8.1 expects that approver and implementer not be the same person. For small teams this is the control that breaks most often and the place auditors push hardest. It's closely coupled to access control enforcement, since the same identity model that gates who can approve a ticket gates who can actually land the change.

Segregation can be split differently than most guidance assumes. The approver and the verifier are the two roles that must differ from the implementer. The approver signs off that the change should happen; the verifier confirms it landed correctly. Both can be done by people who aren't technical owners of the system as long as they can read the risk assessment, the test plan, and the verification output. For a team where one engineer owns the entire platform: the engineer requests and implements, a technical lead approves based on the risk assessment and test plan, and a third person (operations, QA, or a rotating team member) runs the post-implementation verification.

For teams too small for even this, a related pattern works for code changes. A small development team that couldn't sustain per-commit peer review adopted a tagging system to flag material security-relevant changes, then did quarterly retrospective reviews of only those tagged changes. Documented, focused on changes that actually mattered, and produced a written record the auditor accepted. When segregation can't be enforced on every individual change, it can often be enforced through a structured periodic review that covers the same ground more defensibly.

One related baseline: if source code lives on a single developer's laptop under local git, that's version control but not a compliance-ready repository. The auditor cannot independently verify who changed what or when. A centralized repository, whether self-hosted GitLab or a SaaS option, adds access control, change authorization, and independent auditability. That's the foundation CC8.1 expects before any ticket workflow sits on top of it.

What Evidence the Auditor Actually Looks For

Experienced SOC 2 auditors ask for a predictable set of artifacts during the change management walkthrough. Staging them before the audit is the difference between a one-hour walkthrough and a week-long evidence chase.

• Change management policy. The written policy describing workflow, roles, maintenance windows, and emergency procedures. Must match what the ticket system actually enforces.
• JIRA ticket exports for the sample population. Ten to fifteen tickets selected by the auditor, each exported as a PDF or structured report showing custom fields, state transitions, and attachments.
• CAB meeting minutes. Four quarters for a Type 2 audit, matched against the approved-state transitions on sampled tickets.
• Maintenance window calendar or log covering the observation period.
• Approval chain history for each sampled ticket. JIRA's history tab serves this directly.
• Deployment logs tied to tickets. For technology changes, the deployment output attached to the ticket. For network changes, syslog or centralized logging evidence showing the change landed as described.
• Post-implementation verification evidence attached before the ticket closed.
• Emergency change records with post-hoc approval documented in the ticket.
• Quarterly change review evidence demonstrating the program runs continuously across the observation period.

Staging this is not a one-time task. It's the kind of work a fractional security team keeps on cadence, the same way they keep access reviews and backup tests on cadence. When evidence is continuous, the audit is a review instead of a rebuild.

Where This Fits in an Effective Security Program

Teams that stay continuously compliant with change management don't treat the ticket as paperwork that sits next to the real work. They treat the ticket as the real work. It's where the risk conversation happens, where the approval lives, where test results attach, where the rollback plan gets written before the change lands, and where verification gets recorded. The SOC 2 evidence is a byproduct of running the process well, not a separate artifact produced for the auditor.

Build the program once with a ticket workflow that matches how the team actually operates, and frameworks map onto it without restart. The program is the source of truth; SOC 2 is a lens that tests whether the program is running as described. The same ticket workflow satisfies ISO 27001 A.8.32, CPCSC change control, and ITSP.10.171 change management requirements. Extend, don't restart.

We help teams build SOC 2-ready change management workflows that match how their infrastructure actually runs, not a template designed for a cloud-native pipeline. See how we approach SOC 2 on-prem consulting engagements, or book a strategy call.

Further Reading

• SOC 2 Readiness for Bare Metal SaaS: cluster overview and what an on-prem engagement actually looks like
• SOC 2 Ticketing, SLA, Vulnerability, and Incident Response: the sibling ticketing post covering vuln and incident evidence
• SOC 2 Configuration Baselines for Bare Metal: how configuration baselines sit alongside change control
• SOC 2 Access Control for On-Prem: the access model that gates who can approve and implement changes
• How to Choose a SOC 2 Consultant: what to look for if you need outside help structuring the program

How CC8.1 Points of Focus Show Up in the Ticket Workflow

CC8.1 in the 2017 Trust Services Criteria (with revised Points of Focus, 2022) is the change management criterion. The AICPA lists fourteen Points of Focus underneath it, which describe the characteristics auditors evaluate when assessing whether change management is suitably designed and operating effectively. Every one of those characteristics has a place in the ticket workflow described above. Here's how they map.

Lifecycle coverage. Change management has to cover the full lifecycle of system components, including infrastructure, data, software, and manual or automated procedures. The practical implication for ticket-driven shops is that one workflow needs to handle code changes, network changes, database changes, and configuration changes uniformly. Splitting them across separate ad hoc processes creates evidence gaps.

Authorization before design. Changes need an authorization step before design or implementation begins. In the workflow above, this is the Approved state, with an approver who is not the implementer. Authorization is documented as a state transition, not a verbal sign-off.

Secure design and development. When changes are designed and built, security objectives can't be compromised in the process. For ticket-driven environments this shows up as code review for application changes, peer review for infrastructure changes, and a description field that surfaces security-relevant details before approval.

Documentation that outlasts the implementer. Each change is documented in enough detail that someone other than the original implementer can understand what happened later. The description, target systems, risk rating, and rollback plan fields on the ticket carry this load.

Tracking from request through implementation. The whole lifecycle of a change is tracked, not just the implementation event. The JIRA ticket itself is the tracking artifact, and the history tab shows the auditor every state transition with timestamps and actors.

Software configuration control. A process for selecting, implementing, maintaining, and monitoring configuration parameters that control software behavior. In practice, configuration changes flow through the same ticket workflow as code changes, with the configuration values attached to the ticket.

Testing proportional to risk. Changes are tested before they reach production, and the depth of testing scales with the risk rating. Automated test results, manual test plans, and post-implementation verification all attach to the ticket so the auditor sees the test trail in one place.

Approval before deployment. A documented approval before implementation, separate from the request. The state transition from Assessment to Approved records the approver identity and the timestamp, and that record is the evidence the auditor samples.

Segregation of duties at deployment. Deployment happens with separation of responsibilities, so a single person cannot unilaterally develop, test, and push a change. The structural separation between approver, implementer, and verifier described earlier is the segregation control. For small teams where one person owns the platform, the verifier role is the safety valve.

Impact identification and evaluation. Objectives affected by a change are identified up front, and the modified system's ability to meet those objectives is evaluated throughout the development cycle. This is the impact assessment field on the ticket plus the post-implementation verification step.

Incident-driven changes. When an incident requires changes to remediate, those changes go through the change process. The incident ticket triggers a change ticket through a workflow link, so the audit trail spans both incident response and change management.

Baseline configurations for IT. A baseline configuration of IT and control systems is created and maintained. Documented baselines per system tier sit alongside the ticket workflow and inform what counts as a change versus a return-to-baseline.

Emergency change handling. Urgent changes need a process too. The emergency change type with a 48-72 hour post-hoc approval window described above is the standard pattern.

Manages Patch Changes. Patches are explicitly named as a category of change that needs the same identification, evaluation, testing, approval, and implementation discipline as any other change. Patches flow through the same ticket workflow with shorter SLA tiers driven by severity. (See the SOC 2 patch management for on-prem post for the full patching treatment.)

Explore further in Framework Explorer: CC8.1, see the full requirement, all 14 Points of Focus, evidence types, and cross-framework mappings.

Source: AICPA TSP Section 100, 2017 Trust Services Criteria with Revised Points of Focus (2022). Point of Focus characteristics described in Truvo's words and mapped to a ticket-driven implementation pattern. Consult the source document for the official AICPA text.

Frequently Asked Questions

Does SOC 2 require CI/CD for change management?

No. SOC 2's change management criteria describe outcomes (authorization, risk assessment, testing, approval, segregation of duties, scheduled implementation, verification, rollback, and record retention). They don't prescribe pull requests or automated pipelines. A ticket-driven workflow in JIRA, ServiceNow, Azure DevOps Boards, or Linear satisfies the same outcomes when designed to capture those fields and state transitions.

What fields should a SOC 2 change ticket in JIRA contain?

At minimum: change type, risk rating, requester, implementer, approver, target systems, maintenance window, rollback plan, post-implementation verification, and a CAB reference where applicable. Enforcing those fields through workflow validators produces consistent evidence across every sampled ticket.

How does segregation of duties work for small teams?

The approver and the verifier are the two roles that must differ from the implementer. The approver signs off on the risk and test plan; the verifier confirms the change landed correctly. For teams too small for even this, structured quarterly retrospective reviews of tagged material changes can serve as a compensating control when documented properly.

How are emergency changes handled under SOC 2?

Define an emergency change type that moves to implemented without pre-approval but requires post-hoc approval within 48 to 72 hours and a review at the next CAB. The ticket still captures requester, implementer, risk, target, rollback, and verification. Auditors expect emergency changes to exist and expect every one to have a retroactive approval documented.

What evidence should be staged before a SOC 2 change management walkthrough?

The change management policy, JIRA ticket exports for the auditor-selected sample, CAB minutes for the observation period, the maintenance window calendar, approval chain history, deployment logs tied to tickets, post-implementation verification attachments, emergency change records, and the quarterly change review records that demonstrate the process is active.