What SOX auditors expect from IT incident and problem management
No SEC rule or PCAOB standard lists incident and problem management as an IT general control. Auditors reach it through risk. PCAOB AS 2110 asks the auditor to understand IT risks to internal control over financial reporting, and its Appendix B lists two that matter here: failure to make necessary changes to systems or programs, and inappropriate manual intervention. If a financial application fails, or a batch run produces wrong figures, and nobody logs it, investigates it and corrects the underlying cause, errors can flow into reported numbers without anyone noticing. Your job is to show that failures are caught, escalated, resolved and traced to a permanent fix. Management owns that conclusion, and the external auditor tests whether the process works.
Three habits make this hard in practice. The first is incidents handled in chat or by phone, where the timeline, the people involved and the workaround exist only in memory. The second is problems that are never closed: a root cause is suspected, a temporary fix goes in, and the record stays open or disappears. The third is fixes that bypass change control, applied directly to production to restore service and never formally authorized, tested or approved afterward. Each habit breaks the chain an auditor needs to follow from a failure to its cause to an approved change. Before your next assessment, pick three recent incidents on a financial application and ask whether you can produce the ticket, the approval, the root cause analysis and the change record that closed them. If you cannot, that gap is what the auditor will find.
Which incidents and teams fall inside SOX ITGC scope
Scope starts with the financial reports, not the incident queue. Work backward from each report to the applications, interfaces, jobs, databases and hosts that produce it, then bring in the teams and tickets that touch those components. Management only needs the ITGCs that keep financial reporting controls operating properly, so the boundary is drawn by that test.
Financially significant applications and databases
Start with the ledgers, subledgers, consolidation tools and reporting databases that feed financial statements and the reports management relies on. Each one that holds or calculates financial data is a candidate for scope, and so is the database layer under it. Incidents against these systems, such as failed postings, locked periods or corrupted balances, need a ticket category that the audit team can filter and trace. Confirm the list against the scoping document, not against whatever the service desk currently flags as critical.
Interfaces and batch jobs
Interfaces and scheduled jobs are where most processing failures surface. A payroll feed, a currency rate load or an overnight close job can fail without touching the ledger screen, and the first sign is a missing or duplicated balance. Map each interface to the report it feeds, and make sure failed or rejected runs open a ticket linked to that mapping. Ask whether a job that reruns automatically still leaves a record of the original failure.
Infrastructure and third-party hosts
Servers, network segments, identity services and hosting platforms are in scope when a failure in them can stop or alter financial processing. Hosted and cloud components are included too, even when the provider runs the platform. Incidents raised with a provider still need an internal ticket that records impact on financial systems, and the provider's reports and your own tickets should be reconciled for the audit period. Confirm which provider controls you rely on and where their evidence is kept.
Ticket queues and on-call teams
Every queue and rota that can act on an in-scope component belongs in the scope conversation, including the service desk, application support, database administrators, network operations and the security operations on-call. Define which queue owns each component and who may close a financial-impact ticket. Teams that handle only operational issues, such as printer faults or a dashboard that loads slowly, usually sit outside scope, but confirm that the routing rules actually send financial-impact events to the right queue.
Operational-only incidents
Management evaluates only the IT general controls necessary for the proper operation of controls that address financial reporting risks. An incident that affects only operational efficiency, such as a slow report that finishes on time, generally falls outside the ICFR evaluation. The boundary is a judgment, so document the criteria, the example cases that were excluded and who approved the exclusion. An incident can move in or out of scope once its impact on financial data becomes known.
Changes to scope over time
New systems, migrated interfaces, retired applications and new hosting arrangements all change the scope. Review the scope list whenever a system is added, a provider changes or an incident shows a component feeds a report nobody had mapped. Auditors test whether the scope was current during the period, so keep dated versions of the list. Changes made through the change process should update the scope record in the same cycle.
How an assessor tests incident and problem controls
The assessor starts with a walkthrough: they follow one incident from detection to closure and ask the people involved to explain each step. The goal is to confirm that the process exists as described, that alerts from monitoring and job failures reach a queue someone owns, and that severity and escalation rules are written down and used. Under PCAOB AS 2110, the assessor also considers whether the organization has identified IT risks such as failure to make necessary changes to systems or programs and inappropriate manual intervention, and whether the incident process addresses them.
- Intake sources: Which alerts, user reports and job failures create tickets, and whether any financially significant source bypasses the queue.
- Severity and escalation: The written criteria for classifying an incident as affecting financial data, and who is notified.
- Ownership: Named queues or roles responsible for triage, resolution and problem analysis.
- Manual workarounds: How staff record manual interventions to processing so they are visible to the process.
- System support: The ticketing or case tool configuration that enforces required fields and approvals.
Confirm that the walkthrough matches the written procedure and the tool configuration, and ask for any gap between them.
Operating effectiveness testing under PCAOB AS 2201 combines inquiry of personnel, observation of operations, inspection of documentation and re-performance of the control. For incident management, the assessor first requests the complete population of incidents and problems for the period, then selects samples and inspects each record. Auditors typically check that the population is complete, often by reconciling it to monitoring alerts or job logs, because a sample drawn from an incomplete list tells them little.
- Population request: Full export of incidents, with open and close dates, for the testing period.
- Sampled tickets: Each sampled record checked for detection time, triage, assignee, resolution notes and closure approval.
- Timestamps: Creation, acknowledgment and closure times recorded in a system that cannot be silently edited.
- Re-performance: The assessor may re-run the escalation logic on a sample to see if the expected notification occurred.
- Common findings: Missing timestamps, tickets closed without resolution notes, and incidents recorded only in email or chat.
Ask for the population report and its reconciliation before sampling starts, since the assessor will.
The assessor then checks whether recurring or significant failures became problem records, whether those problems were investigated to root cause, and whether any fix that changed a financially significant system went through the change process. This stage tests the link between incident management and program changes. A fix applied directly in production with no approved change record is one of the most frequent findings, because it means the change control over that system was bypassed.
- Problem records: Evidence that repeated or high-impact incidents were escalated into problem records with an owner.
- Open problems: Problems left unclosed past their planned resolution, with no documented risk acceptance.
- Change linkage: Each resolving change traced to an approved, tested change ticket, with the incident referenced.
- Emergency changes: Post-implementation review evidence for urgent fixes made outside normal approval.
- Trend analysis: Whether the organization reviewed incident statistics and acted on them.
Before fieldwork, trace two or three real fixes from incident to approved change yourself to find any break in the chain.
Implementing incident and problem management step by step
This sequence turns scattered processing failures into a controlled record: each incident is categorized, logged, escalated and resolved, recurring causes are traced to root cause, and fixes flow back through change management where auditors can test them.
Define financially significant incident categories
Management, with input from finance and the application owners, defines which incident types can affect financial data: failed or partial batch runs, interface errors, database corruption, unauthorized access to financial systems, and failed restores. Each category gets a written definition, the systems it covers and the people who must be told. Done means the categorization standard is approved, versioned and linked to the SOX system inventory, so every in-scope application has named incident types.
Configure logging and intake channels
The IT team configures a single ticket queue for incidents, reachable from monitoring alerts, service desk email and phone intake. In a tool such as GLPI, the Assistance module can hold tickets, problems and changes under ITIL practices, while a helpdesk such as Zammad can bring requests from several channels into one system. Done means every financially significant category has a queue or form, required fields are enforced, and a test ticket shows the timestamp, reporter and affected system are captured automatically.
Set escalation and severity rules
Set severity levels that describe financial impact, not only technical outage, and define who is notified at each level, including finance or the control owner when a reporting process is affected. Alerting tools such as Grafana Alerting can build rules from metrics and logs across data sources, so a failed job or unusual error rate opens a ticket automatically. Done means the escalation matrix is approved, the alert rules are tested against a known failure, and the test notification reached the named recipients.
Investigate, contain and resolve incidents
Assigned engineers record investigation steps, workarounds and any manual intervention in the ticket, because manual fixes to financial data are an IT risk auditors look for. Where a security event is involved, a case tool such as DFIR-IRIS can keep assets, indicators, tasks and evidence in one case with an audit trail. Done means each closed ticket shows the root symptom, the actions taken, who approved any manual correction and confirmation that the financial output was checked.
Open problem records for root-cause analysis
When incidents recur or a single failure could recur, a problem record is opened and linked to every related incident. The problem owner performs root-cause analysis, documents the cause, and records a permanent fix or an accepted workaround with its risk. Done means each problem has a documented cause, a named owner, a decision on the fix, and links to all related incidents, so the problem log can show how the organization learned from failures.
Link problems to the change process
Every permanent fix is raised as a change request that follows the organization's program change controls: authorization, testing and approval before production. The problem record stays open until the change is implemented and verified. Done means each closed problem points to an approved change identifier, and no fix to a financially significant system reached production without that link.
Run a periodic review of recurring incidents
On a recurring schedule set by management, the IT and finance control owners review incident and problem statistics, recurring tickets, open problems and overdue actions. Reports can be generated from the ticket system's statistics. Done means the review record names attendees, the incidents and problems examined, decisions taken and follow-up owners, and it is retained as evidence that the process operates.
Why every financial fix must trace back to a change record
Every fix to a processing failure that touches financial data should be traceable through a single chain: the incident that surfaced it, the problem record that identifies its root cause, the change request that corrects the cause, and the approval and test evidence that cleared the change for production. Auditors start from the financial impact and work backward through that chain. A correction that lives only in a ticket comment, a direct database update or an engineer's personal script breaks the chain, and the auditor then has to ask whether the fix was authorized, tested and reflected in the system of record at all. The risk is named in PCAOB AS 2110, which lists failure to make necessary changes to systems or programs and inappropriate manual intervention among the IT risks to internal control over financial reporting. AS 2201 adds that changes in the volume or nature of transactions and the complexity of a control affect how risky that control is. A payment interface that is patched repeatedly under pressure, or a reconciliation that is corrected by hand each month, raises both factors at once. Management should identify these recurring patterns in its problem records and decide, in writing, whether each one needs a permanent program change or a documented manual control. The ticket chain auditors typically sample includes the incident ID and its timestamps, the linked problem record with its root cause analysis, the change request with its risk rating and approver, the test results and any emergency change justification, and the production deployment record with the person who moved it. Check that the same identifiers appear in each record, that no closed incident lacks a linked problem or a stated reason for having none, and that emergency changes receive retrospective review. Platforms such as GLPI, which follows ITIL-style tickets, problems and changes, can hold these links natively. Confirm with your own administrators that the links are mandatory fields in your configuration, not optional references that people can skip.
Evidence that passes an incident and problem review
An auditor testing incident and problem management looks for a traceable chain: a logged event, a documented response, a root cause, and a change that fixed it. The cards below cover the records that form that chain and the routines that keep them complete between audit dates.
Incident log exports
A dated export of every incident affecting financially significant processing, showing the opened and closed timestamps, severity, assignee and current status. Auditors sample from this population, so the export must be complete for the audit period and filtered by the same criteria every time. Confirm that the export is generated by the ticketing system, not compiled by hand, and that its filter logic is documented.
Escalation records
Evidence that incidents with financial impact reached the people defined in the escalation matrix within the time set for their severity. Keep the timestamps for each handoff, the name of the person notified and the acknowledgment. Missing or late escalations are a frequent source of exceptions, so check whether severity changes are logged with their own timestamps.
Problem records with root-cause analysis
A problem record groups related incidents and documents the underlying cause, the analysis method and the decision on whether to fix, accept or work around it. The root-cause write-up should name the failing component or process step, not restate the symptom. Auditors reading these records look for a conclusion that matches the incident evidence.
Linked change identifiers
Each problem resolved by a change should carry the change identifier, and each change should reference the problem or incident it addresses. This two-way link lets an auditor trace a fix from the failure to the authorized, tested change that reached production. Check for problems closed with no change reference, which may indicate a fix applied outside the change process.
Periodic review minutes and recurring incident report
Minutes from periodic problem review meetings, along with a report of incidents that recur by application, job or interface. The minutes should record attendees, the items reviewed and the actions assigned with owners and due dates. The recurring incident report is the input auditors use to judge whether management is learning from failures.
Reconciliation to monitoring alerts
A periodic comparison between incidents raised in the ticketing system and alerts fired by monitoring for financial processing jobs and services. Unmatched alerts with no ticket, or tickets with no alert, point to gaps in detection or logging. Record the reconciliation date, the reviewer and the resolution of each exception. Grafana Alerting can show metrics and logs in a single view, which helps the reviewer build this comparison.
What meeting incident and problem controls costs
This table breaks down the cost components of running incident and problem controls for financially significant systems, marking each as one-time or recurring and showing who is paid. Use it to frame a quote request, since the largest variable is usually labor rather than software licensing.
| Cost component | One-time or recurring | What drives it |
|---|---|---|
| Ticketing and incident platform (license or self-hosted hosting) | Recurring | Number of users, ticket volume and whether hosting runs in your own infrastructure; open-source options remove license fees but not hosting or upkeep |
| Monitoring and alerting stack | Recurring | Number of financial data sources, log volume and alert rules that must cover batch jobs, interfaces and databases |
| Configuration engineering | One-time, with later changes | Number of ticket categories, escalation paths, integrations with monitoring and how many financial systems are in scope |
| Process design and documentation | One-time, reviewed periodically | Number of incident and problem procedures, severity definitions and how well they map to the change process |
| Problem review time | Recurring | Frequency of recurring incidents, depth of root cause analysis and how many problems reach documented fixes |
| Evidence upkeep | Recurring | Volume of tickets to retain, review sign-offs, and whether reviewers can pull complete records for a sample period |
| Sampling support during audit | Recurring, per audit cycle | How many incidents the auditor selects, how quickly records can be produced and how clearly links to change records are kept |
| External review or advisory support | Varies by engagement | Scope of the written engagement, whether an outside party designs the process or only tests it, and the number of systems reviewed |
Who owns incident and problem management, and who helps
The organization owns its SOX IT general controls, including how processing failures and IT incidents affecting financial data are logged, escalated, resolved and linked to changes. Management decides which incidents count as financially relevant, who is accountable for each queue, and whether a root cause is closed. Those decisions create the evidence an auditor samples, so they cannot be delegated to a vendor or a consultant. Operations, application owners and finance representatives typically share this responsibility, with the IT service owner holding the accountable role.
- Incident criteria: Define which failures, such as failed financial batch runs or interface errors, must open a ticket and which must reach the controller.
- Escalation paths: Name the people who triage, who can declare a major incident and who approves closure.
- Problem review decisions: Decide which recurring incidents become problem records and whether a permanent fix or documented workaround is accepted.
- Change linkage: Require that fixes to financially significant systems go through the change process with authorization and testing.
- Periodic review: Schedule management review of open and aged problems, and retain minutes or sign-offs.
Check that each control has a named owner, a written procedure and a dated record of the review it depends on.
An implementation partner can configure the ticketing and alerting tools the organization chooses, build intake forms and categories, connect monitoring sources and design the evidence the control produces. This work is usually outsourced because it is technical and repetitive. The partner does not decide what counts as an incident, does not approve problem closure and does not sign off that the control operated. Those decisions stay with management, and the partner's deliverables are the configured systems, documented procedures and evidence exports that management then uses.
- Tool configuration: Set up ticket categories, priorities, workflows and approval steps in the chosen platform, such as GLPI or Zammad, following the organization's written criteria.
- Alert integration: Connect monitoring and job-scheduling sources so failures create records with timestamps and affected systems.
- Evidence design: Specify which fields, reports and audit trails show that incidents were logged, escalated and resolved.
- Access setup: Restrict who can close or reopen records, and document that configuration.
- Handover documentation: Provide runbooks so the organization can operate and evidence the process after go-live.
Confirm in the statement of work that the partner will not issue attestations, sign approvals or make accounting judgments.
The external auditor tests whether the controls operated effectively during the period under audit. Under PCAOB AS 2201, operating effectiveness testing combines inquiry of personnel, observation, inspection of documentation and re-performance. For incident and problem management, the auditor typically selects a sample of incidents and problems, traces them to supporting records and checks that fixes were approved through change management. The auditor reports on effectiveness; neither management's tooling vendor nor the implementation partner issues that conclusion.
- Sample selection: Auditors choose items across the period and may consider changes in transaction volume or control complexity when sizing samples.
- Inspection: Auditors examine tickets, timestamps, approvals and linked change records.
- Re-performance: Auditors may recreate a sample of escalations to confirm the documented path was followed.
- Inquiry and observation: Auditors ask operators how they handle failures and may watch a live triage.
- Reporting: Deficiencies are evaluated and communicated to management and the audit committee under the auditor's own standards.
Ask early which populations and reports the auditor will request, so that evidence exports are designed to answer those questions.
Common gaps that fail incident and problem testing
Auditors testing IT incident and problem management usually find the same breakdowns: work done outside the ticket system, recurring failures without a root cause, and fixes that never reach the change process. Each card below names one gap, why it matters for ITGC testing, and the check to run before the auditor does.
Incidents resolved in chat
Operators restart a batch job or fix a failed interface in a chat channel, and no ticket records the failure, the time it was detected or who approved the fix. Auditors who inspect the ticket queue for a period find no population to sample, so the control cannot show that failures were logged and resolved. Check whether your chat tools post into the ticket system and whether the on-call procedure requires a ticket before any corrective action on a financial process.
Recurring failures without root cause
The same reconciliation break or job abend appears several times in a quarter, and each ticket closes with a workaround and no analysis. Under AS 2110 an auditor reads repeated failures as evidence that a system or program was not corrected, which is one of the IT risks the standard lists. Check that repeat incidents are linked to a problem record with a documented root cause and an owner.
Problems closed without linked changes
A problem record is marked resolved, but no change request exists for the code, configuration or data fix that removed the cause. The fix may have reached production through an emergency path that skipped approval, or it may never have been applied. Check that every problem with a permanent fix references the change record, and that the change went through testing and approval before production.
Inconsistent severity assignment
One team rates a failed month-end feed as low priority, while another rates a similar failure as critical, so escalation to finance and IT management depends on who picks up the ticket. Auditors look for defined severity criteria tied to financial reporting impact and for evidence that high-severity events reached the right people on time. Check that severity definitions name financial close and reporting deadlines, and sample tickets to confirm they were applied the same way.
Monitoring alerts that miss tickets
Grafana or another monitoring tool fires alerts on a failed job or a queue backlog, but the alert goes to a shared channel or an inbox and never creates a ticket. The monitoring evidence shows the failure existed, while the ticket system shows nothing was done about it. Check that alert rules for financially significant systems route to the ticketing platform, and that alert acknowledgment and closure are traceable to a ticket number.
Questions buyers ask about incident and problem controls
How much effort does incident and problem management take in-house?
Expect the effort to be ongoing rather than a one-time project. Someone must define what counts as a processing failure that could touch financial data, configure a ticketing workflow that records each event, assign owners, and review open items on a set cadence. The first cycle takes the most work because the team must agree on severity levels, escalation paths and what a closed ticket must show. After that, effort follows the volume of incidents and how often problems recur. Ask your finance systems owner and IT operations lead to estimate the hours for each role, and confirm whether your team already runs a service desk process you can extend.
What drives the cost of building these controls?
Cost depends on how many financially significant systems feed incidents into the process, how many teams handle them, and whether you already own a ticketing or monitoring tool. The main cost components are internal staff time, any licensed software, integration work that connects alerts to tickets, and external help for design or testing. Costs usually rise with the number of interfaces, batch jobs and locations in scope. They fall when one workflow covers several systems and when alerts already land in a tool your team uses. When requesting a quote, ask for separate line items for design, configuration, integration, testing and ongoing support, and state which systems are in scope.
Do we need an implementation partner for incident and problem controls?
A partner is not required, but many teams bring one in for specific tasks. Internal staff usually own the policy, the owners of each control and the review of results. A partner can help configure a ticketing platform, connect monitoring alerts to tickets, document the workflow and prepare sample evidence for the external auditor. Be clear about roles: your organization owns its controls, a partner prepares systems and evidence, and only an independent auditor issues the opinion on whether controls operated effectively. DeployOpen is one option for the implementation side, and its work is scoped in writing before it starts.
How long does implementation usually take?
The supplied research does not give a standard duration for this work, so treat any figure you hear with caution. Timing depends on how many systems are in scope, whether a ticketing tool is already deployed, how mature your change process is, and how much history you need to show the auditor. Controls must operate over a period before an auditor can test them, so plan for both build time and a period of operating evidence. Ask any provider for a written timeline tied to a defined scope, and confirm with your external auditor how much operating history they expect before testing.
What does the operations team need to provide?
Operations staff need to supply the facts that make the controls work. They should name the owners of each system and batch process, agree on severity definitions, and commit to logging incidents at the time they occur rather than reconstructing them later. They also need to provide access to job logs, monitoring data and change records, and to take part in reviews that link recurring incidents to root-cause fixes. Plan time for these people in the first few weeks, because the controls depend on them following the process consistently. Confirm with your operations lead which shifts and locations need coverage.
Will the auditor accept tickets generated by a tool as evidence?
Auditors generally accept system-generated records when they can see that the records are complete, unaltered and reviewed. An auditor will test whether tickets capture the failure, the impact assessment, the owner, the resolution, and the link to any change that fixed the root cause. They may request a sample of incidents and trace each one through the process, a method that combines inquiry, observation, inspection of documentation and re-performance of the control. Confirm with your auditor which report formats and audit trail settings they want to see, and document who can edit or delete tickets. Tool output alone does not prove the control. The review evidence and the reasoning behind decisions matter too.
How do incident tickets link to the change process?
A problem record should point to the change that fixed it, and the change record should point back to the incident or problem that triggered it. This two-way link lets an auditor confirm that a fix was authorized, tested and approved before reaching production, and that the original failure was closed for the right reason. Many teams configure their ticketing tool so that a problem cannot close until a linked change reference exists, or so that a change request automatically references the originating incident. Confirm how your chosen platform handles these relationships before you design the workflow.
Which open-source tools can support this workflow?
Several self-hosted open-source tools can cover parts of this workflow, though none replaces the process itself. GLPI includes an Assistance module for tickets, problems and changes following ITIL practices, with a Kanban view and recurring ticket tracking. Zammad provides a web-based helpdesk that gathers requests from email, chat and telephone into one ticket system. Grafana Alerting builds alert rules from metrics and logs across multiple data sources, which helps detect failures before they reach finance. DFIR-IRIS suits cases that become security investigations and keeps an audit trail of tasks and evidence. Confirm each tool's fit with your audit scope and your own environment before you commit.
How DeployOpen prepares incident and problem evidence
DeployOpen's role in this area is to plan, implement and document self-hosted tooling inside your own infrastructure, then prepare the systems and evidence that your incident and problem process produces. The organization still owns the controls: it defines what counts as a financially significant failure, who triages it, who approves a root cause and when a problem record closes. DeployOpen configures the ticketing, case and alerting platforms so those decisions leave a trail, and it does not issue audit reports, attestations or opinions on whether the controls work. Independent auditors perform that testing.
Engagements are fixed-scope. Before work starts, the parties agree in writing which platforms, integrations, ticket categories, escalation paths and evidence exports are in scope, along with the deliverables and the timeline. Confirm with any proposed partner that the written scope names the specific tickets, problem and change linkages, and alert sources it will cover, and that it states who signs off each deliverable. A quote follows from that written scope, so a vague scope will produce a vague quote.
Work after go-live is handled through a retainer. A retainer covers ongoing support, upgrades and continuous testing of the platforms, which matters because a helpdesk or alerting configuration that drifts after an upgrade can break the link between an incident and its fix without anyone noticing. Ask whether the retainer includes periodic exports of the incident and problem records for the auditor, and who in your organization receives them. Before you sign, confirm the handover of administrator access and documentation so that your own team can operate the controls once the engagement ends.
