Emergency changes under SOX ITGC: evidence auditors test

Emergency changes under SOX: what the control has to prove

A production defect in a general ledger interface, a pricing table or a reconciliation job can stop month-end close or push wrong numbers into reported results, and it will not wait for the next scheduled change window. SOX ITGC does not prescribe an emergency change process, so the company decides how urgent fixes get made. What the auditor will test is whether that process is controlled. The risk it guards against is the one named in PCAOB AS 2110: unauthorized changes to systems or programs and inappropriate manual intervention that reach financial data. An emergency path is a legitimate route around normal approvals, which makes it the most common place for those risks to appear. Confirm first whether the control is in scope at all. It matters only where the affected application, database or interface supports a financial reporting control that depends on it, and SEC Release 33-8810 says management need not evaluate IT general controls that only affect operational efficiency.

Most emergency change findings come from retrospective approval. A typical pattern is a developer or administrator who changes production directly, then raises a ticket hours or days later, often after the fix is confirmed. Auditors will ask for the population of emergency changes for the period and trace a sample to evidence of who authorized the change before it was made, what was changed, and who reviewed it afterward. Define the emergency criteria in writing, such as a defined impact threshold or a named incident, and limit the number of people who can invoke the path. Confirm that your service desk tool records the request time, the approver, and the implementation time in a way that cannot be edited after the fact. Open-source tools such as GLPI, which provides ITIL-based change records, can hold this evidence if the emergency change type is configured and used consistently.

Two evidence sources usually close the gap between what the ticket says and what happened in production. The first is the privileged access log: for example, if database or application administrator changes are made through a vault-managed credential, the audit device log of the secrets platform, such as the JSON audit log that OpenBao writes for every API request, can show when the credential was checked out and by whom. The second is the application's own audit trail, such as the audit log that Nextcloud's admin_audit app writes to a configured file. Reconcile these logs to the emergency change tickets each period. Gaps between the two sources are the findings to resolve before year end. Confirm with your external auditor which log sources they will accept as system-generated, and how long they must be retained for the test period.

Which emergency changes fall inside SOX scope

Emergency changes only create SOX exposure when they touch systems that feed financial reporting. The cards below cover the decisions that set that boundary: which systems are in scope, who can invoke emergency access, how operational-only fixes are treated, and where third-party and cloud-hosted systems change the evidence you must collect.

Financially significant applications and databases

Start from the top-down scoping of ICFR, not from the change ticket. An emergency fix to a general ledger, subledger, consolidation tool or reporting database that supports a key control is in scope. Map each in-scope application to the controls it supports, and include the underlying databases, because a direct change to a table can alter reported balances without touching the application. Confirm the list with your external auditor before year end, since the answer depends on your own risk assessment.

Interfaces that carry financial data

Emergency changes often hit the job or interface that moves data between systems, such as a payment file transfer, a billing feed or a currency rate import. Interfaces can alter completeness and accuracy of financial data even when neither endpoint changes. Check whether each interface is covered by a key control, such as a reconciliation, and treat an emergency change to a covered interface as in scope.

Infrastructure beneath in-scope systems

Operating systems, middleware, network devices and identity services that host financial applications can all affect ICFR. An emergency patch to a server or a change to a privileged access setting can bypass application controls entirely. Define which infrastructure components support in-scope applications, record them in your scope inventory, and require the same emergency change handling for them.

Who may invoke emergency access

Decide in writing which roles can request emergency access: application developers, database administrators, operations staff and vendor support engineers. Developers and DBAs with standing access to production present the highest risk, because an emergency path can become a route around change approval. Vendor access needs its own rules, including named individuals, time limits and an approver who is not the requester.

Changes that only affect operations

SEC guidance says management need not evaluate IT general controls that only affect operational efficiency. An emergency fix that restores a monitoring dashboard or a printer queue may fall outside SOX scope, but document that conclusion with the reasoning. Be cautious with changes that look operational yet alter how a key control runs, such as a notification threshold or a job that feeds a review.

Third-party and cloud-hosted systems

Financial systems hosted by a SaaS provider or a cloud platform raise a separate question: who executes the emergency change, and what evidence reaches you. You may inherit some controls from the provider, but you still own your configuration changes, access grants and approvals. Ask each provider for its emergency change procedure and for reports that show changes made to your tenant or environment, and confirm how your auditor will receive that evidence.

How to set up an emergency change process auditors can test

This sequence gives management an emergency change path that stays narrow, leaves a trail from access to production, and gets reviewed after the fact, so an auditor can trace each urgent change to a reason, an approver and a logged event.

Define what qualifies as an emergency
Management and IT write a short, approved definition of an emergency change, such as a production outage, a financial calculation error that affects reporting, or a security fix that cannot wait for the standard cycle. The definition names who may declare an emergency and excludes routine enhancements and convenience requests. The output is a signed policy or procedure that the change manager and the business owners of in-scope applications have approved, which an auditor can read and compare against sampled changes.
Restrict and log emergency access
Limit emergency access to a small named group of administrators, and keep that access in a separate, approved path rather than standing rights on production. Access is granted only when an emergency is declared, and each grant is recorded with the user, the system and the time. The output is an access list that IT can produce on request, plus a log showing when emergency credentials or elevated roles were used.
Open a ticket or incident reference
Before access is used, or as soon as practical after an urgent situation begins, the responder opens a change or incident record in the ticketing system. The record states the problem, the affected financially significant system, the planned fix and the declared emergency category. Auditors look for the link between the logged access event and this record, so the reference number should appear in the access log or be easy to match to it. The output is a ticket with a unique ID that all later steps refer to.
Obtain business and IT approval
The business owner and an IT approver confirm the fix before or immediately after it goes live, depending on what the situation allows. Approval should be recorded on the ticket with names, dates and a short statement of what was authorized. Where the approver cannot be reached in time, the record should show who was contacted and who gave the verbal go-ahead, with formal approval obtained afterward. The output is a ticket showing the approval trail that an auditor can inspect.
Document the change and what was done
The responder records the exact changes made, including scripts, configuration edits, database updates or code releases, and attaches the artifacts or references to them. This record should match what the logs show. Manual interventions in production are a specific IT risk that auditors examine, so every manual step should be written down. The output is a completed ticket that describes the change in enough detail for a reviewer to reproduce or reverse it.
Complete post-implementation review
After the emergency is resolved, someone independent of the responder reviews the change against the ticket and the approved definition. The reviewer checks whether the change was justified, whether approval was obtained in time, and whether a standard change should follow to address the root cause. The review window should be set in the written procedure, and the policy should define what happens when it is missed. The output is a signed review on the ticket, with any follow-up changes linked.
Reconcile emergency changes to production logs
On a regular schedule, IT compares the list of emergency tickets with production change records, access logs and audit logs from the affected systems. Any production event that has no ticket is investigated as a potential unauthorized change. The reconciliation is documented with its date, scope, preparer and reviewer, and each exception is resolved or escalated. The output is a signed reconciliation that shows the population of emergency changes is complete, which is the evidence auditors most often request to test whether the process works.

How an assessor tests emergency changes

Before selecting anything, the assessor asks for a complete population of emergency changes in the period under test, usually from the ticketing system and from the change log of each in-scope application, database and infrastructure component. The assessor checks that the population is complete by comparing it with other sources, such as privileged access logs or deployment records, because an incomplete population makes every later test meaningless. The sample is then drawn from that population using a method the auditor documents, and each selected change is traced through its full lifecycle.

Population completeness: The assessor confirms the emergency change list is complete before sampling, often by reconciling it to deployment or privileged session records.
Sample selection: Items are chosen across the period and across systems, so one busy weekend does not dominate the results.
Lifecycle tracing: Each sampled change is followed from the trigger, through the emergency request, the fix, and the review.
Scope of each item: The assessor confirms the change touched a financially significant system or its data, since out-of-scope items are not tested.
Evidence request: The auditor asks for the ticket, the code or configuration diff, the access grant, and the post-change review for each sampled item.

Check that the population was generated from more than one source and that you can explain how you know it is complete.

Evidence that passes an emergency change audit

An emergency change is only defensible if the paper trail around it is complete. The artifacts below connect the policy that allows emergency access to the activity that happened and the review that followed. Auditors typically trace from the population of emergency changes outward, so the population itself must be complete before any single change can be tested.

Emergency change policy and criteria

The written policy defines what counts as an emergency, who may declare one, which systems are covered and how long a temporary access grant may last. Auditors compare actual emergency changes against these criteria, so vague wording such as urgent business need invites exceptions. Check that the policy names the approvers, the ticket required before or immediately after access, and the review deadline. Confirm the policy version in force during the audit period and its approval date.

Population report of emergency changes

This is the complete list of emergency changes to in-scope systems for the audit period, usually exported from the ticketing system with ticket IDs, dates, requesters and affected systems. Auditors use it to select samples, so any gap makes the whole population unreliable. Ask whether the report is generated from the system of record or assembled by hand, and whether a second source such as access logs was used to confirm it is complete.

Access request and approval records

For each emergency change, auditors look for evidence that privileged access was requested, approved by someone other than the requester where possible, and granted for a defined window. The approval should show who approved it and when, and the grant should match the approved scope. Check for approvals given after access was used, and for standing elevated accounts that bypass the request step entirely.

Timestamped activity logs

Activity logs show what actually changed during the emergency window and when. They should capture the administrator identity, commands or API calls, and the start and end of the session, with logs stored outside the administrator's control. Compare log timestamps with the approval and ticket times to detect work performed before authorization. Confirm that log retention covers the full audit period.

Retrospective review sign-offs

After the fix, a reviewer who did not perform the change should confirm the change was necessary, matched the approved scope and was reversed or formally adopted as a standard change. Each sign-off needs a name, a date and a link to the change record. Auditors check that reviews happened within the deadline in the policy and that open reviews are escalated rather than left pending.

Reconciliation output

Reconciliation compares changes found in production, from logs, configuration baselines or file integrity records, against the emergency change population. Any production change without a matching ticket is an exception that must be investigated. Ask for the reconciliation frequency, the owner of the exceptions list and evidence that exceptions were resolved before the audit closed.

What emergency change control costs to run

This table compares each cost component of running emergency change control for financially significant systems, who is paid for it, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request, since no price is given here and costs depend on your environment and scope. The main takeaway is that most of the recurring cost comes from after-the-fact review and evidence upkeep, not from the emergency fix itself.

Cost component	Who is paid	One-time or recurring	What drives it
Ticketing tooling or licenses	Software vendor or hosting provider; internal team if self-hosted	Setup one-time, licenses or hosting recurring	Number of users, whether emergency requests get their own workflow, and hosting model
Engineering time for access and logging	Implementation partner or internal platform engineers	One-time build, recurring tuning	How many systems use break-glass access, and whether privileged sessions are already logged centrally
Reviewer time for retrospective approvals	Internal managers, change board members or application owners	Recurring	Emergency change volume, time allowed to approve after the fact, and how many reviewers hold approval rights
Evidence upkeep	Internal compliance or operations staff	Recurring	Frequency of emergency changes, how consistently tickets link to logs, and how much manual reconciliation is needed
External review or consultant support	Consultant, co-sourced internal audit or implementation partner	Often one-time readiness, sometimes recurring	Gaps found in design review, how many systems are in scope, and whether the work is fixed scope
Auditor sampling effort	Your external auditor, paid under the audit engagement	Recurring each audit cycle	Number of emergency changes in the period, quality of population completeness, and clarity of records

Who owns emergency change control and what can be outsourced

Management owns ICFR, so it owns the emergency change process from start to finish. Management defines what qualifies as an emergency, who may declare one, who approves the break-glass path, and who reviews each change once the fix is in production. Those decisions are management's to make and document, and they cannot be handed to a vendor or to the auditor. Management also decides whether a control gap caused by an emergency change is a deficiency that needs remediation.

Policy and criteria: Define what counts as an emergency, such as a production outage or a defect that misstates financial output, and what does not.
Named approvers and reviewers: Assign who authorizes an emergency change and a separate reviewer who examines it after the fact.
Access decisions: Decide which people may hold emergency or privileged access and how it is granted and removed.
Post-implementation review: Confirm each emergency change is documented, tested afterward where needed, and closed within a defined window.
Deficiency evaluation: Judge whether unreviewed or unapproved emergency changes affect IT-dependent controls.

Check that your policy names owners by role, that the reviewer is independent of the person who made the change, and that someone can show the last quarter's emergency changes with approvals attached.

Where emergency change controls usually fail

Emergency changes bypass the normal change process, so they are where auditors look hardest for gaps. The failures below tend to share a root cause: the emergency path was never defined, bounded and reviewed with the same rigor as the standard path. Each card pairs a gap with the fix that closes it.

Undefined emergency criteria

When nobody has written down what counts as an emergency, teams classify routine fixes as urgent to skip approvals. Define the trigger in writing, for example a production outage or a confirmed security exposure affecting a financially significant system, and name who may declare it. Ask for the criteria document and check whether recent emergency tickets actually meet it.

Shared privileged accounts

Emergency work often runs through a shared administrator or break-glass login, so the system cannot show who made a change. Issue named, time-limited elevated access for each emergency, and record the requester and approver against the session. Confirm that the shared account is locked, its password is vaulted, and each use is logged.

Approvals dated after the fact

A change may be implemented first and approved days later, with no defined window for retrospective review. Set a fixed deadline for the post-implementation approval and flag any ticket that closes after it. Auditors will compare the implementation timestamp with the approval timestamp, so the gap needs to be visible in the ticket history.

Changes made without any ticket

Direct edits to production, such as database fixes or configuration tweaks made in a console, may never reach the ticketing system. Reconcile production changes from system logs and file integrity records against emergency tickets each period. Any change with no matching ticket should be investigated and documented as an exception.

Incomplete emergency populations

Auditors can only test emergency changes if the population is complete. When the ticket queue is the only source, changes made outside it are invisible to the sample. Ask for a population drawn from several sources, such as the ticket system, privileged session logs and deployment records, and confirm the totals agree before sampling.

Reviewers approving their own work

When the engineer who made an emergency fix also signs off on the review, the second line of control disappears. Require that the post-implementation reviewer is independent of the implementer and holds the authority to reject the change. Check the ticket for distinct requester, implementer and reviewer identities.

Emergency change questions buyers ask before hiring help

How much effort does an emergency change process take to run in-house?

Running an emergency change process in-house is mostly a documentation and discipline effort, and the cost is staff time rather than a single purchase. Your team must define what qualifies as an emergency, pre-approve who can authorize one, keep a break-glass access path with logging, and reconcile every emergency change to a ticket after the fact. The recurring effort depends on how often emergencies occur. A stable platform with few urgent fixes needs little ongoing work, while a system that changes often under pressure needs regular review of the emergency log. Ask your team to estimate hours from the last twelve months of out-of-cycle changes, since that history is the most reliable input you have.

Do we need an outside partner to set up emergency change controls?

You do not need a partner to design emergency change controls, but many organizations bring in help to build the supporting evidence and test it. The controls themselves are owned by your organization, including the approval rules and the people accountable for reviewing each emergency change. An implementation partner can configure the ticketing workflow, restrict privileged access, and set up logging so the evidence is easy to pull. Only an independent auditor issues an opinion on whether the controls operate effectively. Ask any partner to state in writing which parts they configure and which parts remain your responsibility.

How long does it take to put emergency change controls in place?

The duration depends mainly on how many financially significant systems fall in scope, how mature your current change tooling is, and how quickly approvers can agree on the criteria. A narrow scope with one ticketing system and a small set of applications is far quicker to implement than a multi-system estate with interfaces and databases. Plan for time to write the emergency criteria, configure the workflow, test the break-glass access, and run at least one walkthrough with the approvers. Ask any provider for a timeline built from a written scope, and confirm how much of it depends on your own change advisory board schedule.

What do the finance and IT teams need to contribute?

Finance and IT each own part of the control, and the work fails when either side is absent. Finance should identify which applications and reports affect financial statements, confirm which emergency changes could alter balances or reported results, and agree on the approvers for those systems. IT should own the access model, the ticket workflow, the log retention, and the reconciliation of changes found in production to tickets. Both teams should attend a walkthrough so the approvers can explain what they check and what evidence they keep. Request a named owner from each side before work begins.

Can open-source tools replace a commercial ITSM platform for emergency changes?

Open-source tools can cover the core needs for emergency changes if your process is simple and your team can operate the platform. GLPI's Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, which supports the change record, approval and closure steps. Zammad can bring requests from email and other channels into one ticket system, which helps capture urgent requests when they arrive outside the normal portal. Nextcloud's admin_audit app writes additional event information to audit.log, which can support logging of administrative actions. Confirm each platform meets your approval, retention and reporting requirements before you commit, because feature sets differ between editions and versions.

What will auditors sample when they test emergency changes?

Auditors typically select a sample of emergency changes from the population of changes in the period and trace each one to its evidence. For each sampled change they look for a ticket or record that describes the urgency, shows who authorized it, shows access was granted for the fix, and shows the change was reviewed after the fact by someone independent of the person who made it. They also compare production change activity against the approved tickets to find changes that were never recorded. Under the PCAOB framework, testing combines inquiry, observation, inspection of documentation and re-performance, so keep the documentation complete and accessible. Ask your auditor which sample size and population they will use before the period starts.

How do emergency changes differ from standard changes?

Emergency changes skip the normal lead time and some pre-deployment testing, but they still need authorization and review. A standard change is planned, goes through documented request, approval and testing steps, and then moves to production through the normal path. An emergency change is restricted to a defined urgent need, uses a pre-approved fast path, limits who can make the change, and is reviewed after deployment. Auditors focus on whether the emergency path is narrow enough that it does not become a way around the normal process. Under AS 2110, unauthorized changes to systems or programs are a recognized IT risk, so the boundary between the two paths matters.

How DeployOpen scopes and prepares emergency change evidence

DeployOpen works on emergency change handling as an implementation and evidence engagement inside your own infrastructure. We set up the emergency access path, approval records and after-the-fact review so that urgent fixes to financially significant systems leave a traceable record, while your organization keeps ownership of the control itself.

How we scope

Agree in writing which financially significant applications, interfaces and infrastructure the emergency change path covers.
Document who may invoke an emergency change, the approvers on call and the criteria that justify bypassing the normal process.
Confirm the review window and the owner responsible for after-the-fact review before any build work starts.

How we build

Configure the ticketing workflow so emergency changes carry a distinct type, mandatory justification and linked approval fields.
Restrict emergency access to named, pre-approved roles and enable audit logging on privileged actions in the target systems.
Test the workflow end to end with sample emergency changes so the records show each step auditors would trace.

How we hand over

Deliver a written procedure describing invocation, approval, retrospective review and closure for emergency changes.
Provide an evidence map that shows which ticket fields, log sources and review sign-offs satisfy each test step.
Train the named reviewers and document the handover so your team can run the process without DeployOpen present.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Confirm with your external auditor which evidence formats and sample periods they expect before finalizing the design.