What detecting unauthorized changes asks for under SOX ITGC
Detecting unauthorized changes is a detective control: it reconciles changes actually found in production to approved change tickets, and flags anything that cannot be matched. When a finance-facing application, interface, database or server configuration has changed, management must be able to show that every change was requested, approved and tested, or else identify and investigate the ones that were not. Preventive controls such as access restrictions and change approval workflows stop most unauthorized changes before they happen, but PCAOB AS 2201 (paragraph A8) recognizes that controls over financial reporting may be preventive or detective, and a detective control is the check on the preventive ones that fail, are bypassed or were never configured for a given system. PCAOB AS 2110 (paragraph B4) lists unauthorized changes to systems or programs as an IT risk to internal control over financial reporting, which is why auditors expect management to know how it would catch them.
The control is hard to run because each of its inputs is incomplete. Production logs may not record every change, may not be retained long enough, or may not be readable by the team reviewing them. Change tickets may describe what was intended rather than what was deployed, or may be closed without a link to the actual objects touched. Nobody owns the comparison, so the two lists are never reconciled. Before designing the control, confirm which sources record changes for each in-scope system (operating system, database, application, network devices and cloud control plane), how long each source is retained, and who can alter it. Then decide what evidence proves the reconciliation was performed, including the population, the date run and the reviewer's sign-off on exceptions.
Some sources are better suited to this than others. File integrity monitoring tools such as the Wazuh platform record a baseline of checksums and attributes for monitored files and directories, then alert when a user or process creates, modifies or deletes a monitored file, with details of how, when and by whom. Backup verification can add a second view: Bareos Verify jobs compare files against previously cataloged attributes. Application audit logs, such as the admin_audit app in Nextcloud, write event detail to a file that can be forwarded for review, and OpenBao audit devices keep a JSON record of API requests and responses. Each source covers different ground, so the reconciliation should state which systems each one monitors. A tool that watches the wrong directories gives a false sense of coverage, so auditors will ask for the monitored scope and its baseline.
Which systems and changes fall inside detective change monitoring
Detective change monitoring only works where the scope is right. Start from the financial statement accounts and reports that depend on IT, then work down to the systems, data stores and accounts that could alter them. Each component below needs a named change source, so an unexpected change can be traced to an approved ticket or flagged as unauthorized.
Financially significant applications
Scope the applications that initiate, process or summarize transactions behind material accounts, such as general ledger, billing, payroll and consolidation tools. Management usually documents this from the top down: which accounts and disclosures are material, which systems produce them, and which automated controls rely on those systems. For each application, name the change source that will reveal modifications, such as application audit logs, build or release records, or file integrity monitoring on the deployed binaries. Confirm that the change source covers the production instance, not only a test copy.
Databases and data stores
Databases hold the transaction tables that applications read and write, and a direct change to a table can bypass every application control. Include the databases under the in-scope applications, along with any reporting or data warehouse copies that feed financial reports. Confirm which database audit trails record schema changes, privileged logins and direct updates to financial tables, and whether those logs are retained and reviewed. Auditors will ask whether the log can be altered by the same administrators it tracks.
Operating systems and infrastructure
Servers, hypervisors, container hosts and network devices run the in-scope applications, and changes at this layer can alter application behavior without touching application code. Scope the hosts by the systems they support, not by their technology. For each host group, decide whether file integrity monitoring, system logs or configuration management records will show changes to system binaries, libraries and security settings. Check that monitored paths cover the files that matter, since a monitor that watches only the application folder misses changes to shared libraries.
Interfaces and integration jobs
Interfaces move financial data between systems, and a change to a mapping, transformation or scheduled feed can misstate balances without any visible application change. Inventory the interfaces that carry financially significant data, including file transfers, API integrations and batch jobs. For each one, identify where the job definition lives and how modifications to it are logged. Ask whether an interface change would appear in the same monitoring output as application changes, or whether it needs a separate check.
Configuration tables and parameters
Parameter tables control tolerances, tax rates, approval limits, matching rules and posting logic, often outside the code path that developers review. Treat these tables as in scope when they drive automated calculations that affect financial reporting. Detective checks should compare the current values with an approved baseline or a changed-record report, and flag edits that have no matching ticket. Confirm that the report covers direct database edits as well as edits made through the application screen.
Privileged and service accounts
Administrator, root, database owner and service accounts can change in-scope systems, and they are the most common path for unauthorized change. List every account that can alter the scoped components, including shared accounts, break-glass accounts and automation credentials used by deployment pipelines. For each one, confirm that its activity is logged to a location the account holder cannot edit, and that someone independent reviews the log. Ask for the list of accounts with write access, since auditors use it to decide where to look.
How an assessor tests detection of unauthorized changes
This table compares each step an assessor takes when testing detective change controls, the evidence they request for that step, and the findings that most often come up. Read it as a checklist: if your evidence cannot answer the request in the middle column, expect the test to stall or fail at that step.
| Test step | Evidence the assessor requests | Common findings |
|---|---|---|
| Inquiry of the reconciliation owner | Named owner, documented reconciliation procedure, frequency, and the person who reviews the reconciliation output | Owner cannot explain the population or the matching logic, or the reconciliation is performed by the same person who makes production changes |
| Inspection of the production change population | Log exports, file integrity monitoring alerts or compile date reports covering the full period under test, with system and time range shown | Population is a partial extract, covers only part of the period, or omits a system in scope |
| Tracing detected changes to approved tickets | Change tickets with approval, implementation date, and the matching timestamp or checksum from the monitoring output | Detected changes have no ticket, or tickets were approved after the change was made |
| Completeness testing of the population | Evidence that monitored locations, hosts and databases match the in-scope inventory, and that agents or log sources were running throughout the period | Monitored scope is narrower than the in-scope inventory, or gaps in agent coverage are not recorded or investigated |
| Review of unmatched changes | Investigation records for each unmatched item, including who was contacted, the conclusion, and any remediation or rollback | Alerts are generated but not reviewed, investigations are open at period end, or conclusions are not signed off |
| Review of alert handling and escalation | Alert queue history, reviewer sign-off, and escalation records for unmatched or high-severity events | Alerts are auto-closed, reviewed without evidence of follow-up, or reviewed by someone outside the reconciliation design |
| Assessment of changes made outside the ticket process | Evidence from emergency access logs, privileged session records and configuration baselines compared with tickets | Direct production edits found during testing that were never raised as incidents or changes |
Implementing a change reconciliation control step by step
This sequence turns production change detection into a repeatable control that an auditor can test. It starts with defining what counts as a change, builds a known-good baseline, and ends with a signed reconciliation that ties each detected change to an approved ticket or an investigated exception.
Define the in-scope change population and sources
Management, with input from application owners and IT operations, lists the financially significant applications, databases, operating systems, configuration files and interfaces whose changes the control must cover. For each object, record where change evidence lives: file system paths, application logs, database audit trails, compile or build records and the change ticketing system. The output is a documented population with named owners and sources, approved by the control owner. Without this record, nobody can show that the reconciliation is complete.
Establish a baseline of approved state
Capture a known-good snapshot of the in-scope files, configurations and program versions at a point the organization can defend, usually after a verified deployment or a reviewed initial assessment. Record checksums, attributes and version identifiers, and store the baseline where administrators cannot alter it. The output is a baseline record with date, scope, method and the approver who accepted it. Auditors will ask how the organization knows what the system looked like before the period under test.
Configure monitoring and log retention
Enable file integrity monitoring or equivalent detection on the monitored objects, and turn on audit logging for applications and databases that record configuration or code changes. Decide whether checks run in real time or on a schedule, and set retention periods that cover the full audit period plus the time needed for testing. Restrict write access to logs and alerts so that privileged users cannot delete entries. The output is a configuration record listing each monitored object, its detection method and its retention setting.
Schedule the reconciliation against approved tickets
Define how often the control runs, who produces the change report, and who reviews it. Each run pulls detected changes for the period and matches them to approved change tickets by object, timestamp and implementer. Changes with no matching approved ticket become exceptions. The output is a reconciliation procedure with a defined frequency, named preparer and reviewer, and a documented matching rule that the reviewer can repeat.
Investigate and resolve exceptions
For each unmatched change, the reviewer determines whether it was an unauthorized change, an emergency change with a late ticket, a vendor patch, or a false positive caused by a scheduled process. Unauthorized changes go to incident handling and may require restoring the baseline and assessing whether financial data was affected. The output is an exception log with the disposition, evidence reviewed, and the person who closed each item. Open exceptions should be visible to the control owner before the reconciliation is signed.
Retain signed reconciliation records
After exceptions are resolved, the preparer and an independent reviewer sign the reconciliation for the period, attaching the change report, the matched ticket list, the exception log and the dispositions. Store the signed package in a location with version control and access logging. The output is a signed reconciliation record per period that an auditor can select a sample from and trace back to source logs and tickets. Ask the external auditor early which sample sizes and periods they expect to see.
Evidence that shows changes were detected and reconciled
A detective change control is only as credible as the records behind it. The artifacts below show that the complete population of production changes was captured, compared with approvals, and that exceptions were investigated. Keep each one current between audits so the reconciliation can be re-performed at any point in the period.
Complete change population extracts
The population is the full list of production changes for the audit period, pulled from the systems that record them: file integrity alerts, application audit logs, database change logs and deployment records. Record the date range, the source system, the query or filter used and the row count. Auditors test completeness by asking whether any system that can change financial logic is missing from the extract. Confirm each source is named and that the extract was generated by a repeatable method, not edited by hand.
Monitoring baselines and alert records
A file integrity monitoring baseline records checksums and attributes for monitored files, and alert records show each detected create, modify or delete with the user or process responsible. Retain the baseline version approved for each period, plus the alerts raised against it. An auditor will check that the monitored scope matches the in-scope applications and infrastructure identified in your scoping work, and that baselines were updated only through approved changes.
Compile-date and build reports
For compiled programs, reports of compilation dates for objects placed in production show whether executables changed during the period. Compare those dates to the approved change window and ticket. A compile date after the approval, or a build with no ticket, becomes an exception for investigation. Confirm that the report itself is produced from a source the team does not control, and that the build timestamps are reliable enough to rely on.
Reconciliation workpaper with ticket matching
The reconciliation workpaper matches each detected change to an approved change ticket ID, showing the approver, approval date and implementation date. Unmatched items go to an exceptions tab. Document the matching rules, such as tolerance for timing or naming differences, and who performed and reviewed the work. A workpaper without a reviewer signature and a date is hard to rely on, so confirm sign-off is part of the template.
Investigation notes for exceptions
Every exception needs a written investigation: what changed, who made the change, whether an authorized emergency or standard path existed, and what the impact on financial reporting might be. Close each exception with a conclusion and a link to any follow-up ticket or remediation. Auditors often sample exceptions, so an unexplained exception is weaker evidence than a documented one with a clear decision, even when the change turns out to be benign.
Log retention and integrity proof
The logs behind every artifact must still exist for the full audit period and be shown to be unaltered. Record the retention setting, the storage location and access controls, and any export to write-once or separately administered storage. Audit logs for the audit application, such as the admin_audit app in Nextcloud, write to a file in the data directory or a configured path, so confirm where they land and who can write to them. Test periodically that log entries are not missing or changed.
Which open-source tools produce change detection evidence
Wazuh's file integrity monitoring (FIM) module, licensed under GPL-2.0-only, records a baseline of checksums and attributes for the files and directories you choose to monitor. It then raises an alert when a user or process creates, modifies or deletes a monitored file. Checks can run on a schedule or in real time, and the alert carries details on how and when the file changed and who made the change. For change reconciliation, this is the closest match to a direct record of what changed on a financially significant server, because each alert can be compared to the change ticket open for that host and window.
- Baseline scope: Monitored paths must cover application binaries, configuration files and database connection settings for in-scope systems, not only operating system folders.
- Real-time versus scheduled checks: Real-time monitoring narrows the gap between a change and its alert, while scheduled scans may miss short-lived modifications.
- Who and when detail: Confirm that the user and process attribution is captured reliably on each platform you run, since attribution depends on the operating system.
- Alert routing: Route alerts to a queue the change team reviews, and keep the alert history for the period the auditor samples.
- Baseline changes: Authorized changes update the baseline, so record how baseline updates are tied to tickets.
Confirm with your platform team that the monitored paths match your in-scope inventory and that alert retention covers the audit period.
Bareos, licensed under AGPL-3.0-only, is a backup system. Its Verify jobs compare files on disk against the attributes stored in the Bareos catalog from an earlier backup, such as size, permissions and checksums. Any difference shows a file was changed after it was backed up. This gives a Tripwire-like capability: the catalog acts as a reference point, and a verify run reports differences. Because the record depends on backup timing, it is best treated as a detective check that complements, rather than replaces, real-time monitoring.
- Catalog as reference: The verify result is only as current as the last backup of the file, so align backup schedules with the change calendar.
- Level of verification: Choose the attributes compared, and confirm they include the items that matter for financial application files.
- Job reports: Keep verify job output, including the list of differing files, as dated evidence for the reconciliation.
- Coverage gaps: Files excluded from backup sets are not verified, so review the file selection against the in-scope inventory.
- Investigation use: The same reports can help investigate a suspected unauthorized change after an incident.
Confirm with your backup administrator which systems are in verify jobs and how often they run relative to your production change windows.
Nextcloud's admin_audit app, licensed under AGPL-3.0-only, logs additional event information to an audit log. By default the log is written to audit.log in the data directory, and you can set a different path with the logfile_audit configuration key. For change detection, the log is useful when financially relevant settings or shared finance records are altered within the platform. It records what the platform reports, so you must confirm which events are captured before treating it as complete evidence for a specific change.
- Log location: Confirm the default path or the value of
logfile_auditin your deployment, and restrict write and read access to the log. - Event coverage: Verify which administrative events the app records in your version, and test them with a sample change.
- Log protection: Forward the log to a central store so administrators cannot silently edit local copies.
- Retention: Set retention to cover the audit period and the time auditors may request older samples.
- Ticket linkage: Compare logged administrative events with approved tickets for the same dates and actors.
Confirm with your application owner which configuration and data changes fall in scope, and test that each one produces an entry.
OpenBao, licensed under MPL-2.0, is a secrets management platform. Its audit devices keep a detailed JSON log of every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256, so the log can show that a secret was read or written without exposing its contents. For change detection, this is evidence of changes to secrets, policies and access settings that the platform manages, such as database credentials or encryption keys used by financial applications.
- Request-level record: Each entry shows the operation attempted, which helps trace changes to policies and secret engines back to a caller.
- Hashed values: Confirm which fields are hashed in your configuration so the log remains useful without storing sensitive data in clear text.
- Device redundancy: Configure more than one audit device where your design allows, so a failing device does not silently stop logging.
- Log integrity: Ship the JSON log to a protected store and control who can alter or delete it.
- Mapping to tickets: Match privileged changes in the log to approved tickets, especially for keys used by in-scope systems.
Confirm with your security team that audit devices are enabled on every OpenBao cluster in scope and that failures in logging are alerted.
Where detective change controls usually fail
Detective change controls fail in predictable places: coverage, timing, ticket discipline and review quality. Each gap below breaks the link between what changed in production and what was approved, so an auditor cannot rely on the reconciliation. Each card ends with the check that closes the gap.
Monitoring covers only some systems
Teams often enable file integrity monitoring on the web tier or the main application server and assume the rest of the financial stack is covered. Databases, interface servers, batch hosts and reporting tools that hold in-scope logic can change without any alert. Build a written inventory of in-scope components, then compare it against the monitored agents and paths each period. Any gap needs an owner and a date, or a documented compensating review.
Logs roll over before reconciliation
Audit and system logs are often kept only for a default retention period, and nobody reconciles them until the quarter closes. By then the entries that show a change in the first weeks may be gone, and the auditor gets nothing to test. Set retention to cover the full reconciliation cycle plus the auditor's lookback, and confirm the storage location is protected from the administrators whose changes are being monitored. Ask for a sample restore to prove the archive works.
Tickets raised after the change
A reconciliation that matches detected changes to tickets only proves something if the ticket existed before the change. When a ticket is opened the next day to explain an alert, the control has become a retroactive paperwork exercise. Check the ticket creation timestamp against the change timestamp in the monitoring record, and flag any change that lacks a prior approval. Treat late tickets as exceptions, not as matches.
Exceptions signed off without investigation
A reviewer who signs a reconciliation with zero exceptions, or who clears every exception with the phrase reviewed, has not performed the control. Auditors look for evidence of the investigation: who looked, what they compared, and why an unmatched change was accepted or escalated. Require a written disposition for each exception, with a reviewer independent of the change implementer. Sample the dispositions yourself before the auditor does.
No evidence the control ran each period
Many detective controls run informally, so the reconciliation exists for some months and disappears for others. Without a dated record for every period, the auditor cannot conclude the control operated throughout the year, even if the process works. Keep a control calendar, a signed reconciliation for each scheduled period, and a record of any period skipped and why. Confirm with your auditor which period-end cadence they expect before the year starts.
Privileged accounts outside the reconciliation
Changes made with shared administrator accounts, service accounts or break-glass logins can be hard to attribute to a person or a ticket. If those actions are excluded from the reconciliation, the most sensitive changes are the ones nobody reviews. Include privileged and automated activity in the comparison, and require the change record to name the human who approved it. Confirm that the audit trail for privileged sessions is complete and stored outside the systems being monitored.
Questions buyers ask about detecting unauthorized changes
How much effort does detecting unauthorized changes take?
The effort depends on how many systems are in scope, how much of their change activity already produces logs, and how many changes the team reconciles each cycle. Most of the work is recurring: someone must review each alert or log exception, match it to an approved change ticket, and document the outcome. Effort rises when production systems change often, when logs are scattered across several platforms, or when baselines must be rebuilt after every release. It falls when monitored files and log sources are limited to what financial reporting depends on, and when the reconciliation is automated so that exceptions are the only items needing manual review. Ask any provider to estimate the monthly review workload from your change volume before agreeing to scope.
Can our own team detect unauthorized changes without outside help?
Often yes, if the team has people who understand the financial systems, the infrastructure that hosts them, and the change ticketing process. The core work is not exotic: collect change evidence from production, reconcile it to approved tickets, investigate exceptions, and keep the records. Outside help is most useful when the team lacks experience designing the control so an external auditor will accept it, when monitoring tools need to be deployed across many hosts, or when the reconciliation logic must be built for several platforms. Whatever you choose, management owns the control and must be able to explain how exceptions are investigated and resolved.
How long does it take to set up change detection?
Setup time depends on the number of in-scope systems, whether file integrity monitoring or log collection is already running, and how cleanly the change ticketing system can be matched to production activity. Setup usually includes defining the monitored scope, establishing a baseline, testing that alerts fire for real changes, agreeing on the reconciliation procedure, and running the control long enough to produce evidence for the auditor. No duration is given here because it varies widely. Ask any provider for a written timeline tied to a fixed scope, and confirm how many operating cycles of evidence your auditor expects before testing.
What does this control need from IT and finance?
IT owns the monitoring platform, log sources, baselines and the change tickets that the reconciliation depends on. Finance owns the decision about which applications and reports are financially significant, and it often needs to confirm that a detected change affecting a financial calculation has been reviewed for accuracy. Both groups must agree on the scope, the exception criteria and who signs off the reconciliation. Without that agreement, alerts pile up without an owner, and auditors may find that reviews happened late or not at all. Document the handoffs so that a named person can show the review was performed in each period.
Are open-source tools acceptable evidence for SOX change detection?
Auditors evaluate the control and its evidence, not the license of the tool that produced it. An open-source tool can generate acceptable evidence if the output is complete, reliable, retained and reviewable. Wazuh records a baseline of checksums and attributes for monitored files and directories, then alerts when a user or process creates, modifies or deletes a monitored file, with details on how, when and by whom. Bareos Verify jobs compare files against previously cataloged attributes. Nextcloud's admin_audit app writes event information to audit.log, and OpenBao audit devices keep JSON logs of API requests. Confirm with your auditor how they will test the completeness of the logs, how the baseline is protected, and how long records are kept.
How should we choose a partner to help with this control?
Start by clarifying roles. The organization owns its controls, an implementation partner prepares systems and evidence, and only an independent auditor issues the opinion on ICFR. Ask candidates to describe the monitoring and reconciliation design they would build, which open-source or commercial tools they would use, and how they would hand the control to your team. Request a written, fixed scope with deliverables and timelines, and confirm what happens if the auditor asks for different evidence. DeployOpen implements and documents self-hosted open-source platforms inside your own infrastructure and prepares systems and evidence for compliance assessments, but it does not issue audit reports or attestations. Ask for a written scope before comparing quotes.
What risk remains if unauthorized changes are not detected?
PCAOB AS 2110 lists unauthorized changes to systems or programs as an IT risk to internal control over financial reporting. If a change to a financial calculation, interface or configuration goes unnoticed, the automated controls that depend on it may produce wrong results without anyone seeing the error. Detective controls are one way to address that risk, since PCAOB AS 2201 recognizes that controls over financial reporting may be preventive or detective. Detection does not replace change authorization and testing, but it catches changes that bypassed those steps. Auditors will ask how quickly exceptions are investigated and what happens to a change that was never approved.
How DeployOpen prepares change detection evidence
DeployOpen works on detecting unauthorized changes as a self-hosted implementation inside your own infrastructure. We scope which systems, logs and file paths feed the reconciliation, build the monitoring and log collection, and hand over evidence that your team and your external auditor can reconcile to approved change tickets.
How we scope
- Agree in writing which financially significant applications, databases, servers and file paths are monitored for changes.
- Document which change sources feed reconciliation, such as audit logs, compile dates and file integrity alerts.
- Define who reviews unmatched changes, how often, and which tickets count as approval evidence.
How we build
- Deploy file integrity monitoring with a baseline of checksums and attributes for the agreed in-scope paths.
- Configure audit logging and retention so administrative events land in a location your team controls.
- Test that a deliberate change to a monitored file raises an alert and appears in the reconciliation output.
How we hand over
- Deliver configuration records, monitoring scope and alert rules that show what is detected and why.
- Provide a reconciliation procedure and template that matches each detected change to an approved ticket or exception.
- Train the reviewers who sign off on reconciliations so the process runs without our involvement.
How we support
- Offer ongoing support, upgrades and maintenance of the monitoring stack as a retainer if you want it.
- Review scope changes when new systems or applications enter financial reporting scope during the year.
- Confirm with your auditor which evidence they expect, since DeployOpen prepares evidence but does not issue audit opinions.
