What does SOX require for IT change control?

SOX itself does not name specific IT controls. Section 404 requires management to assess internal control over financial reporting, and auditors test IT general controls — including change management — under PCAOB AS 2201. In practice, SOX change control means every production change touching financial systems has a documented request, a risk-based approval, evidence of testing, a backout plan, and segregation between who writes the code and who deploys it.

SOX Change Control Checklist Mapped to Your ITSM Workflow

Q: What's the difference between SOX 404(a) and 404(b) for change control purposes?

404(a) requires management's own ICFR assessment; 404(b) adds an independent auditor attestation, required for accelerated and large accelerated filers. Change-control evidence expectations are effectively the same either way.

Q: Can a standard pre-approved change type skip CAB review under SOX?

Yes, if the standard change category was properly risk-assessed, documented, and approved in advance, per COBIT BAI06 practices. Auditors flag cases where the label is used to bypass review for changes that don't meet the pre-approved risk profile.

Q: How long should we retain change tickets for SOX purposes?

There is no single statutory number specific to change tickets, but most programs retain ICFR-relevant evidence for the current fiscal year plus the prior audit cycle, consistent with PCAOB AS 2201 roll-forward testing expectations.

Q: Does an ineffective change-management ITGC automatically mean a material weakness?

Not automatically. Severity depends on the reasonable possibility and magnitude of a material misstatement, and compensating controls can offset a deficiency if they operate with sufficient precision, per PCAOB AS 2201.

Q: How does SOC 2 change management differ from SOX change control?

SOC 2 is a voluntary attestation against AICPA Trust Services Criteria; SOX is a statutory requirement for SEC filers. The underlying change-management expectations overlap heavily, so many teams design one process that satisfies both.

Why this matters right now

A failed ITGC change-management control does not just generate an audit comment — it can escalate into a material weakness disclosure, and those are expensive. Academic and practitioner research tracking post-SOX filings has repeatedly found that companies disclosing material weaknesses face higher costs of capital and negative abnormal stock returns around the disclosure date, and IT-related weaknesses are a recurring category in PCAOB inspection findings on internal control over financial reporting audits (PCAOB 2023 inspection report, Ernst & Young). PCAOB’s own inspection data shows a meaningful share of Part I.A deficiencies each cycle trace back to insufficient testing of the controls auditors relied on — which for most finance-relevant applications means insufficient testing of the general controls, including change management, that make automated application controls trustworthy in the first place (PCAOB 2022 inspection report). For a CAB or platform team, that means your change ticket fields are, whether you intended it or not, part of the audit evidence trail for the company’s financial statements.

What does Sarbanes-Oxley §404 actually require?

Section 404 of the Sarbanes-Oxley Act of 2002 requires management of SEC-reporting companies to include an internal control report in the annual filing, stating management’s responsibility for internal control over financial reporting (ICFR) and its assessment of ICFR effectiveness as of fiscal year-end; accelerated filers must also obtain an independent auditor’s attestation on that assessment (SEC final rule implementing Section 404). The statute itself does not mention IT systems, tickets, or change tickets — it is a financial-reporting control statute. The bridge to IT comes through the audit standard PCAOB auditors use to test ICFR: AS 2201, “An Audit of Internal Control Over Financial Reporting,” which directs auditors to evaluate the extent of IT involvement in financial reporting processes and to test IT general controls when automated controls or IT-dependent manual controls are part of the control environment being relied upon (PCAOB AS 2201). If your ERP, billing system, or revenue-recognition tool is IT-dependent — and nearly all of them are — the change-management process around that system’s production environment becomes SOX-relevant by extension, even though no one at the SEC wrote “ServiceNow” into the statute.

What are ITGC and why do all four categories matter?

IT General Controls (ITGC) are the controls that support the reliable operation of every automated financial control layered on top of them. AICPA’s Statement on Auditing Standards No. 145 directs auditors to evaluate risks arising from an entity’s use of IT and to assess the design of controls within the control activities component, including general IT controls, when gaining an understanding of an entity’s system of internal control (AICPA SAS No. 145). In practice, auditors and frameworks summarize general controls into four buckets: access controls, change management controls, computer operations controls, and program development (SDLC) controls. ISACA’s COBIT framework maps the same territory through management objectives — most relevantly BAI06 (Managed IT Changes) and BAI07 (Managed IT Change Acceptance and Transitioning), which define change standards and procedures, impact assessment, prioritization and authorization, emergency changes, tracking and reporting, and closure and documentation as the core practices auditors expect to see evidenced (ISACA COBIT 2019, BAI06 Managed IT Changes). Auditors test all four ITGC categories together because they are interdependent: strong change control means nothing if a developer has standing production access that bypasses the change process entirely, which is why access and change are almost always tested as a pair.

What specific change-control expectations do SOX auditors test?

Boiled down from AS 2201 and the COBIT BAI06 practices, auditors testing change management for a SOX-in-scope application look for five things, every time:

Segregation of duties between development and deployment. The person who wrote or configured the code change cannot be the same person who moves it into production. PCAOB’s AS 2201 explicitly notes that IT can enhance an entity’s ability to achieve effective segregation of duties by enforcing security controls in applications, databases, and operating systems — meaning auditors expect the tool, not just a policy document, to prevent the conflict (PCAOB AU 319 / AS 2201 discussion of IT and internal control).
Documented, risk-based approval before production deployment. Every change needs an identifiable approver — normally someone independent of the change author — captured before the change ships, not after.
Evidence of testing prior to deployment. Test results, UAT sign-off, or a QA log attached to the change record, proportional to the change’s risk to financial reporting.
A documented backout or rollback plan. Auditors want to see that the organization planned for failure, not just success — this is a specific, repeatedly cited expectation in change-management control descriptions built against COBIT AI6/BAI06 (“Illustrative Controls,” TIBCO SOX compliance guide referencing COBIT change standards](https://docs.tibco.com/pub/logcssox/4.0.0/doc/html/SOX-guide/AI6-Change-Standards-and-Procedures.htm)).
Retention of the full change record for the audit period. Auditors sample historical changes and trace them back to the change log and supporting documentation — if the record does not exist or was purged, that sample fails (TIBCO SOX compliance guide, COBIT AI6).

How do COBIT and COSO fit together with SOX?

Most SOX programs use COSO’s Internal Control — Integrated Framework as the top-level control framework management uses for its 404 assessment, since AS 2201 requires the auditor to use the same suitable, recognized framework as management (PCAOB AS 2201). COSO sets the “why” — control environment, risk assessment, control activities, information and communication, monitoring — at the entity level. COBIT sits underneath as the IT-specific control catalog that operationalizes COSO’s “control activities” component for technology: BAI06 and BAI07 are COBIT’s answer to “what does a change-management control activity actually look like inside an IT department.” You do not need to run a full COBIT implementation to satisfy SOX — most mid-market programs cite COBIT informally as the control-objective language behind their internal change-management policy, then map their actual ServiceNow or Jira Service Management workflow to it.

How do SOX change controls map to ServiceNow or Jira Service Management fields?

This is the part most SOX narratives skip, and it’s the part your CAB actually has to operate. Each control expectation above corresponds to a specific, testable ticket field:

SOX / ITGC control expectation	ServiceNow field/mechanism	Jira Service Management field/mechanism
Segregation of duties (dev ≠ deployer)	`Assignment group` + workflow state restrictions preventing the `Requested by`/implementer from self-approving	Restricted transition permissions on the “Deploy” transition; requester excluded from approver group
Documented approval	`Approvals` related list (CAB approval records, timestamped, named approver)	Approval field/workflow with named approvers logged per transition
Testing evidence	Attachment on `Test plan` / `Test results` field	Attachment on the issue, linked “Test” issue type, or a required custom field for QA sign-off
Implementation plan	`Implementation plan` field (rich text, required before CAB approval)	“Implementation plan” custom field or linked Confluence runbook
Backout plan	`Backout plan` field (required field on `normal` and `standard` change types)	“Backout plan” custom field, often required by workflow validator before transition to “Approved”
Change closure / outcome	`Close code` (successful, successful with issues, unsuccessful) + `Close notes`	Resolution field + mandatory closure comment
Retention	Ticket history retained per platform data-retention policy; export to GRC/SOX evidence repository	Ticket history retained per Atlassian data-retention policy; export to GRC/SOX evidence repository

The audit-relevant point: if any of these fields are optional, unvalidated, or editable after the fact without an audit trail, the control is weaker than it looks on a process diagram. Auditors test the field, not the policy PDF that describes the field.

What change-management deficiencies do PCAOB inspections actually cite?

PCAOB inspection reports don’t always name “change management” line by line, but the deficiency patterns they publish map directly onto weak change-control evidence. Across recent inspection cycles, PCAOB has repeatedly flagged: insufficient testing of the design or operating effectiveness of controls selected for testing, and insufficient testing of the accuracy and completeness of data or reports used in the operation of controls — both cited as the most common Part I.A deficiency categories in the 2022 and 2023 inspection cycles reviewed for a major firm (PCAOB 2023 inspection report; PCAOB 2022 inspection report). Translated to change management, that pattern usually means the auditor could not get evidence that the change ticket’s approval or testing actually happened as designed — a missing attachment, an approval logged after deployment, or a “standard change” category used to route around CAB review entirely. PCAOB’s reports also cite overreliance on controls without sufficient testing as a driver of financial-statement-audit deficiencies, which is the direct auditor-side consequence of a change-management ITGC that looks fine on paper but has gaps in its evidence trail (PCAOB 2022 inspection report).

What to do about it

Lock the backout-plan and test-evidence fields as required, not optional, on any change record tagged to a SOX-in-scope application, in both ServiceNow and Jira Service Management.
Remove standing production deploy access from anyone who also has code-commit or configuration rights in the same system — this is the single most commonly tested access/change control pairing.
Force CAB or delegated approver sign-off before the deployment state, not after — a workflow validator that blocks the transition until an approval record exists beats a policy that just asks nicely.
Tag changes by financial-reporting relevance at intake, so your SOX population sample can be pulled cleanly instead of hand-picked by IT after the fact.
Retain full ticket history, including edit history, for at least the audit period plus one year — auditors sample prior-period changes, and gaps read as scope limitations.
Run a quarterly self-test: pull 25 random change tickets from SOX-in-scope systems and confirm each has an approval, implementation plan, test evidence, and backout plan attached before you find out from your external auditor that they don’t.
Route emergency changes through a distinct, still-auditable path — COBIT’s BAI06 explicitly separates standard changes from emergency changes, but both need documentation and retrospective approval, not a blank exception.
Give your CAB a standing audit-readiness checklist (below) and review it monthly, not just before fieldwork.

Frequently asked questions

Does SOX require a specific ITSM tool like ServiceNow or Jira Service Management?

No. SOX and PCAOB standards are tool-agnostic — they require the control outcome (segregation of duties, documented approval, tested and reversible changes), not a specific product. See the ServiceNow vs. Jira Service Management change management comparison for how the two platforms differ in how easily they support these controls out of the box.

Who is actually in scope for SOX IT general controls?

Any system that materially affects financial reporting — ERP, billing, revenue recognition, general ledger, and any application feeding numbers into the financial statements — is in scope, along with the infrastructure and access layers underneath it, per the IT-involvement evaluation required under PCAOB AS 2201.

What’s the difference between SOX 404(a) and 404(b) for change control purposes?

404(a) requires management’s own assessment of ICFR; 404(b) adds an independent auditor attestation, required for accelerated and large accelerated filers. Change-control evidence expectations are effectively the same either way — 404(b) just means an external auditor is testing your tickets directly rather than relying solely on management’s self-assessment (SEC Section 404 study).

Can a “standard” pre-approved change type skip CAB review under SOX?

Yes, if the standard change category itself was properly risk-assessed, documented, and approved in advance — COBIT’s BAI06 practices explicitly recognize standard and emergency change paths as legitimate, provided they are still tracked, reported, and closed with documentation (ISACA COBIT BAI06 practices). What auditors flag is a “standard change” label used to bypass review for changes that don’t actually meet the pre-approved risk profile.

How long should we retain change tickets for SOX purposes?

There’s no single statutory number tied to change tickets specifically, but most programs retain ICFR-relevant evidence, including change records, for the audit period plus enough prior periods to support trend and roll-forward testing described in PCAOB AS 2201 — commonly at least the current fiscal year plus the prior year’s audit cycle.

Does an ineffective change-management ITGC automatically mean a material weakness?

Not automatically. Auditors evaluate severity based on the reasonable possibility of a material misstatement and its magnitude; a deficiency can be compensated by other controls if those controls operate at a level of precision that would catch the error (PCAOB AS 2201, compensating controls). But weak change control removes one of the primary compensating controls other automated checks depend on, which is why auditors scrutinize it closely.

How does SOC 2 change management differ from SOX change control?

SOC 2 is a voluntary attestation against the AICPA Trust Services Criteria, chosen by the company; SOX is a statutory requirement for SEC filers. The underlying change-management control expectations — approval, testing, segregation of duties — overlap heavily, which is why many teams design one change-control process that satisfies both. See the SOC 2 change management controls and audit questions article for the SOC 2-specific control language.

Where does the Change Advisory Board fit into SOX evidence?

The CAB is usually the human control point that produces the approval evidence auditors sample. See how to run a CAB meeting in 2026 for the operational side, and use the CAB agenda generator to standardize the agenda fields that later become audit evidence.

Audit-ready CAB checklist

Before your next SOX walkthrough or interim testing cycle, confirm the CAB record for every in-scope change includes:

Run this against a sample before your auditor does. Use the change risk score tool to flag which upcoming changes carry the highest financial-reporting risk and deserve the closest documentation scrutiny, and see 12 external risk sources every CAB should monitor for signals worth folding into that risk classification.

Sources

#sox #compliance #itgc #change-control #audit

Published July 21, 2026.