Direct data and database access under SOX ITGC

Why direct database changes matter to SOX ITGC auditors

When an auditor asks who can change account balances directly in the database, the control being tested is whether unauthorized or unreviewed changes to financial data can reach the reported numbers without anyone noticing. Auditors care because most financial figures are produced by applications, but the data those applications read, such as balances, master records and rate tables, can often be altered outside the application entirely. PCAOB AS 2110 lists unauthorized changes to data in master files among the IT risks to internal control over financial reporting, and it singles out the particular risks that arise when many users access a common database. It also lists inappropriate manual intervention as a separate risk. A compliance lead or DBA preparing for this question should expect the auditor to ask for the population of direct updates, not only a policy statement.

The reason the risk reaches financial controls is that automated controls depend on what sits underneath them. PCAOB AS 2201 notes that an automated control can depend on related files, tables, data and parameters, and gives the example of an interest calculation that relies on the integrity of a rate table. A correct application control can therefore produce a wrong result if someone edits the rate table directly. Before the audit, the organization should list the tables, parameters and master files that feed in-scope automated controls, then confirm which of them can be written to by database administrators, batch jobs or support staff.

This is hard in practice for three reasons. DBA access is usually broad, because the same accounts are needed for patching, tuning and recovery, so the write rights that matter for financial data are rarely separated from the rest. Data fixes are often ad hoc, raised by a ticket or an email and run as a one-off script under time pressure. And the logs that would show what changed are scattered across the database engine, the operating system, the application and the ticketing tool, so reconstructing a single update takes manual effort. The first practical step is to decide which tables are financially significant, restrict direct write access to them, and require every direct change to carry a request, an approver and a log entry that can be matched.

Which databases, tables and people fall inside direct access scope

Scope for direct data and database access is set by the company's own ICFR risk assessment, not a fixed list. The cards below cover the decisions that most change how much control work follows, from the data stores themselves to the people and scripts that can reach them.

Databases holding financially significant data

Start with the databases that store ledgers, subledgers, customer balances, inventory valuations and other data that feeds financial statements. Scope the database itself, not only the application on top of it, because a user with direct database rights can change figures the application never shows. Confirm the list against the risk assessment, and record which reports or account balances each database supports.

Master files and common tables

Master files such as customer, vendor, chart of accounts and product records are where unauthorized changes do the most damage. Where several users or applications share one database, the risk of conflicting or untracked edits rises. Identify which master tables are shared, who can write to them, and whether a change to one can alter results in several reports.

Rate, pricing and parameter tables

Automated calculations such as interest, tax, discounts or depreciation often read from rate or parameter tables rather than hard-coded logic. An accurate calculation can still produce wrong results if the table changes without authorization. Illustrative example: a changed interest rate row can misstate every loan accrual until someone notices. Scope these tables even when they look like configuration data.

DBA and vendor support accounts

Database administrators, application vendor support staff and managed service providers often hold broad rights to alter data directly. Each named account, shared login and vendor remote session should be listed with its purpose and approval path. Confirm whether vendor access is enabled only during approved tickets and whether those sessions are logged to a place management can review.

Batch scripts and service accounts

Scheduled jobs, import scripts and application service accounts can write to tables without a person signing in. Inventory each script, the account it runs under, the tables it touches and who may change the script itself. Auditors often find that service account passwords are known to more people than the owning team, so confirm who holds those credentials and how they are rotated.

Data fix requestors and approvers

People who ask for direct corrections, such as finance analysts or support staff, belong in scope because they initiate changes that bypass the application. Record who can request a data fix, who approves it, and who executes it, and confirm that the executor is not the approver. Check whether the population of data fix tickets is complete, since auditors compare it against database change logs.

How an assessor tests direct data changes

The assessor starts by tracing how a direct change to a financial table would happen and whether anything would stop it or record it. The walkthrough covers who holds database administrator and superuser rights, how data fixes are requested and approved, which database and operating system logs capture direct updates, and where those logs go. The assessor is checking design, so they want to see the path from request to execution to record, not a sample of past changes yet.

Privileged holders: A list of accounts that can write to in-scope tables directly, reconciled to the privileged access listing.
Data fix procedure: The written process that defines when a direct change is allowed, who approves it and what ticket must exist first.
Logging configuration: Evidence that database audit logging is turned on for in-scope schemas and that logs leave the database host.
Tooling in the path: Whether a change tool, bastion or break-glass process is the only route to write access.
Walkthrough record: A dated note of what the assessor observed, including a live demonstration where the auditor requests one.

Confirm before the walkthrough that every person on the privileged list can be tied to a named role, so the assessor does not find undocumented access during the walkthrough itself.

How to implement direct data access controls step by step

This sequence moves from knowing which databases and master files matter, to limiting who can touch them directly, to proving with logs and reconciliations that every direct change was authorized and reviewed.

Inventory in-scope databases and master files
Start by listing every database, schema, table set and file store that holds financially significant data or feeds automated controls, such as rate tables, chart of accounts and vendor master files. Include the applications, reports and interfaces that read or write them, and name an owner for each. Management usually builds this list from the SOX scoping work, then confirms it with IT and finance. The step is complete when the inventory is signed by the data owners and every entry maps to an application or control that relies on it.
Restrict DBA and service account use to documented duties
Identify every account that can change data directly, including database administrators, application service accounts, batch users and vendor support accounts. For each one, document the duty that justifies its access, remove rights the duty does not need, and separate day-to-day administration from data change rights where the platform allows it. Shared and service accounts should have a named owner and a recorded purpose. The output is an access matrix that lists each account, its permitted actions and its approver, reviewed before it is treated as the baseline.
Define a formal data fix procedure
Write a procedure for any change to financial data made outside the application. It should cover when a direct fix is allowed, the request form, the business justification, the technical change plan, and the approval by someone who is not the person executing the change. Execution should use a named account or a controlled script, and the procedure should require a post-change review by a second person. The output is an approved procedure with templates for each stage, and a rule that no direct update runs without a ticket.
Enable and protect database and file-level audit logging
Turn on logging for direct data changes at the database, file and application layers that the inventory identified. Capture who changed what, when and from where, and send logs to a location the database administrators cannot edit. Confirm that log settings survive restarts and upgrades. Where the platform supports it, log audit requests and responses separately from business data, and hash or mask sensitive values. Test the logging by making a harmless change in a non-production copy and confirming the entry appears with the expected fields. The output is a tested logging configuration and a short description of where each log lives and who can read it.
Monitor file and table integrity
For master files and configuration files that should not change outside a known process, set a baseline of checksums and attributes, then alert when a user or process creates, modifies or deletes them. Compare this against the approved change tickets so that alerts from unplanned changes are triaged. Scheduled comparisons can complement real-time alerts where a platform supports both. The output is a monitored file list, an alert routing rule and evidence that a test modification produced an alert with user, process and timing details.
Reconcile logged direct updates against approved tickets
At a set frequency, pull the audit logs and integrity alerts for the period and match every direct update to an approved fix ticket. Each logged change should show a requester, an approver, an executor and a post-change review. Unmatched entries go to the data owner and the security team for investigation, and the outcome is recorded. The reconciliation itself is reviewed by someone outside the team that made the changes. The output is a signed reconciliation report with exceptions, their disposition and the follow-up actions.
Document the procedure and retain evidence
Bring the inventory, access matrix, fix procedure, logging configuration, monitoring rules and reconciliation reports into one controlled document set. Assign an owner to each section, record review dates and version history, and state how long evidence is kept and where it is stored. Walk the auditor through the sequence so the documentation matches how the controls operate. The output is a versioned control description that an assessor can follow from inventory to reconciliation without asking how the process actually runs.

Evidence that passes a direct data access test

Auditors testing direct data changes look for a chain of records: who was allowed to touch the database, what they changed, why they changed it, and whether anyone reviewed it. The cards below cover the artifacts that connect those records and the completeness checks that show the population was not trimmed before it reached the auditor.

Approved data fix tickets

Each direct update to a financial table or master file should trace to a ticket that states the business reason, the affected records, the expected before and after values, and the approver. A second approver independent of the requester is the detail auditors check first. Confirm that tickets close only after the change is verified against the ticket's stated values.

Database audit logs of changes

Audit logs should show the account, the statement or operation, the object changed and the timestamp for every direct write to in-scope data. Confirm that logs capture changes made through shared or service accounts, not only named administrators. Check that the log destination is separate from the database host so that a DBA cannot quietly alter their own trail.

File integrity records for master files

File integrity monitoring keeps a baseline of checksums and attributes for monitored files and reports when a user or process creates, modifies or deletes them, with details on who made the change and when. For master files and rate or parameter tables that automated controls depend on, the alert history is evidence that unexpected changes were detected and investigated.

Periodic reconciliation sign-offs

Reconciliations that compare application balances with database contents after a data fix show whether the change reached the intended records and nothing else. Auditors look for dated sign-offs by someone outside the change process, with the reconciled totals and any differences explained. Ask whether the reconciliation covers every table touched during the period, not only the tables someone remembered to check.

DBA role access lists

A current list of accounts holding database administrator or equivalent write rights, with the approval for each grant, is the population the auditor uses to test whether direct access was authorized. Compare this list against the directory and the privileged account inventory at the same date. Any account that can write financial tables but is missing from the list is a gap in the population.

Complete and retained log populations

Logs only support a test if they are complete for the audit period and retained long enough to be pulled. Document the retention setting, the storage location and any log rotation, and confirm that gaps such as disabled logging or failed log shipping would show up in monitoring. Ask the auditor which date range and system list they will sample from, then generate the population from the same source they will use.

What direct data access controls cost to meet

This table breaks down the cost components of controlling direct database and data fix access, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Read it to scope a quote, since most of the spend follows the number of databases, the volume of manual fixes and how long logs must be kept. No fees are estimated here because none were supplied; the rows show what to ask for.

Cost component	Who is paid or who bears it	One-time or recurring	What drives the cost
Logging and monitoring tooling	Licenses to the vendor, or internal time to run self-hosted tools	Recurring (licenses or hosting), one-time setup	Number of databases in scope, event volume, retention period; open-source options can remove license spend but not operating effort
Engineering time to build logging	Internal platform or DBA staff, or an implementation partner under a fixed-scope agreement	One-time, with later changes	Number of database engines, whether audit logs reach a central store, and how many systems must be reconfigured
Engineering time to build data fix workflows	Internal application owners, or a partner who builds the request, approval and execution path	One-time build, recurring use	How many distinct fix types exist, and whether fixes can be routed through an application rather than run directly
DBA time for reviews and reconciliations	Internal DBAs or finance and IT reviewers	Recurring, usually per review cycle	Frequency of direct changes, number of reviewers, and how much of the review is automated comparison versus manual reading
Investigation of unexpected direct changes	Internal DBAs, security staff and application owners	Recurring, variable	Volume of unexplained changes and quality of logs that link each change to a ticket and an approver
Evidence upkeep across the audit period	Internal control owners, sometimes supported by a partner preparing evidence	Recurring for the full period	Number of in-scope databases, how often evidence is pulled, and whether it is collected automatically or by hand
Auditor sampling and follow-up	External auditor fees, with internal time to answer requests	Recurring each audit cycle	Number of fix events in the population, number of databases tested, and how complete and readable the logs are
Retention and storage of audit logs	Internal infrastructure or cloud accounts	Recurring	Required retention period as set by company policy, log volume and whether logs are hashed or stored in a tamper-evident store

Who owns direct data access controls and who can help

Management owns the controls over direct data and database access. That means deciding who may connect to financial databases and master file tables, approving each direct update or data fix before it runs, and reviewing the logs of those changes on a defined schedule. The people who sign these reviews must understand the financial data well enough to recognize an update that looks wrong, and they must be independent of the people making the changes.

Access decisions: Name the database administrators, service accounts and emergency users allowed to touch financial data, and document why each needs that access.
Data fix approvals: Require a written request, business justification and second-person approval before any manual correction to a master file.
Periodic review: Assign an owner to review the log of direct changes and confirm each one matches an approved ticket.
Policy and procedure: Write the data fix procedure and keep it current with the systems it covers.
Exceptions: Track unapproved or unexplained changes and open follow-up actions with owners and dates.

Before the audit, confirm that your reviewers can show the review was performed, not only that the procedure exists.

Common gaps that fail direct data access testing

Auditors testing direct data and database access usually find the same few weaknesses: shared accounts, fixes that bypass the change process, logs nobody reads, and gaps in monitoring of the master files that feed automated controls. Each card below names one gap and the check that shows whether it is closed in your environment.

Shared database administrator accounts

When several DBAs log in with one administrator account, the database cannot show who ran a given statement, and the audit trail loses its meaning. Auditors will ask whether each privileged action traces to a named person. Check whether every DBA has an individual account, whether shared credentials exist in scripts or password vaults, and whether the database audit log records the individual identity for each session.

Data fixes run without tickets

A correction to a balance, rate or master record made directly in the database, outside the application, is a manual intervention that AS 2110 lists among IT risks. Such fixes often happen under deadline pressure and skip approval. Check that every direct update has a request, a business justification, a second-person approval and a link to the resulting change record before the statement runs.

Logs that exist but are not reviewed

Audit logs that nobody reads prove activity happened but do not detect misuse, which is what the control is meant to do. Reviewers often sign off without evidence of what they examined. Check that a named reviewer receives a defined extract of direct update and privileged activity on a set schedule, and that the review record shows which entries were examined and what follow-up was taken.

Log retention shorter than the audit period

If database or application logs roll over before the period the auditor tests, the evidence for early-year changes no longer exists. Retention is often set by a storage default rather than by the audit calendar. Confirm the retention setting covers the full fiscal year plus the auditor's testing window, that logs are copied off the source system, and that the copies are protected against alteration.

Service accounts with unrestricted write access

Batch jobs, integrations and application connections often hold broad write rights to financial tables, and their credentials are rarely rotated or reviewed. Any process with those rights can change financial data without a person being involved. Check each service account's grants against the tables it actually needs, confirm it cannot run ad hoc statements, and confirm its activity appears in the logs reviewed.

Master file changes outside any monitored path

Rate tables, chart of accounts and vendor master files can change through files, scripts or direct writes that no monitoring covers, so the change never reaches an alert or a review. Automated controls that depend on these files then run on data no one has checked. Confirm the list of master files is documented, that file integrity monitoring or database triggers cover each one, and that alerts route to someone who reviews them.

Direct data access questions buyers ask before hiring help

How much effort does direct data access control take to run in-house?

Most of the effort sits in building the inventory and the logging, not in the control itself. Your team must first list every route into financial data outside the application: database administrator accounts, scripts, ETL jobs, reporting tools and vendor support paths. Then it must prove each route is restricted, logged and reviewed. The effort grows with the number of databases, the number of people who hold direct access, and how many data fixes run each period. Teams that already run a documented change process and keep database logs usually need less rework. Ask any consultant for a quote that separates the one-time inventory and design work from the recurring review and evidence collection.

Can open-source tools produce the evidence for direct database changes?

Open-source tools can produce much of the evidence, but they do not decide what is authorized. Database audit logging, a central log store, and file integrity monitoring can show who changed a table or file and when. For example, Wazuh's file integrity monitoring records a baseline of checksums and attributes for monitored files and directories, then alerts when a user or process creates, modifies or deletes one. Bareos Verify jobs compare files against previously cataloged attributes. Nextcloud's admin_audit app writes event details to a log file. OpenBao keeps JSON audit logs of API requests for secrets access. Confirm with each product's documentation which events it captures for your specific database platform, because database-level auditing often needs separate configuration.

What does the DBA team need to contribute to direct access controls?

The DBA team owns the technical controls: account inventory, privilege design, break-glass procedures and log configuration. They must confirm which accounts can write to financially significant tables, which service accounts run batch updates, and where vendor or emergency access is granted. They also need to tie each direct update to a ticket, an approver and a reason, and make sure logs cannot be altered by the people whose activity they record. Expect DBA time in the discovery phase and during each review cycle. A partner can prepare configuration evidence and reports, but the DBA team must confirm that the settings match production.

What does finance need to provide for direct data fix reviews?

Finance provides the business judgment that the data change is correct. For each data fix, the finance owner should confirm the affected population, the expected before and after values, and whether the correction is required for the reported balances. They also approve the fix request and review the result against the source records. This matters because an auditor will ask whether someone with knowledge of the balances reviewed the change, not only whether IT logged it. Finance involvement is usually concentrated at period close and at the start of the year, so plan the review calendar around those dates.

How far ahead of the audit cycle should preparation start?

Start early enough that you can run controls for a full period before the auditor tests them. Auditors generally need evidence that a control operated over the period under review, so a control that starts late cannot be tested for that period. The lead time depends on how many database platforms are in scope, whether logging is already enabled, and how many direct-access routes you must remove or document. Your external auditor can confirm the testing period and sample expectations for your year. Ask any partner to tie the preparation schedule to those dates, and to name which items must be live before the period begins.

Can a partner run the reconciliations between database changes and the ledger?

A partner can design, build and document reconciliation procedures, and can help your team run them, but the reconciliation itself must be owned by the people who understand the financial balances. A reconciliation compares the population of direct changes in the database log against approved requests and against the ledger or subledger impact. Finance must sign off on differences and explain them. A partner should not be the sole reviewer of its own work, and it cannot issue an audit conclusion. Ask for a written scope that names who performs each reconciliation, who reviews it, how often it runs, and where the evidence is stored.

What should a written scope include before hiring an implementation partner?

A useful scope lists the in-scope databases and applications, the direct-access routes you want covered, the logging and integrity tools to be configured, and the evidence package to be delivered. It should also state who approves each deliverable and what your team must provide, such as account lists, access to log sources and named reviewers. Because most DeployOpen engagements are fixed-scope, the written scope is the basis for the quote. Ask the partner to state which items it prepares, which items your staff perform, and which items only your external auditor can conclude on. Clear boundaries prevent gaps at audit time.

How DeployOpen scopes and prepares direct data access evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so direct database access and data fix logging can be designed into the platform from the start. The organization owns its controls, DeployOpen prepares the systems and evidence, and only an independent auditor issues conclusions on the controls.

How we scope

Inventory which databases and master file tables feed financially significant reports, and who can reach them directly.
Map direct database paths, including DBA consoles, command-line sessions and service connections, into the written scope.
Agree in writing which platforms, environments and evidence sources are in scope before work starts, since engagements are fixed-scope.

How we build

Configure audit logging on in-scope platforms so direct changes to financial data leave a reviewable record.
Set up file integrity monitoring on master data files, configuration tables and rate or parameter tables that automated controls depend on.
Design a documented data fix procedure with approval steps, so manual intervention is recorded and separated from routine application activity.

How we hand over

Deliver configuration records, log locations, retention settings and a description of how each log is reviewed.
Provide a test script that shows an auditor how to trigger, locate and read a direct update record in each in-scope system.
Document the data fix procedure, approval evidence template and integrity alert handling steps for the client's own control owners.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, if the client wants it.
Re-verify logging and integrity monitoring after platform upgrades, since changes can alter log paths or monitored file sets.
Confirm with your auditor which log retention period and sample size they expect before the audit period begins.