Last year I watched an external auditor ask a simple question during a SOX readiness review: "Show me who approved the change to Supplier 4821's bank account number in January." The room went quiet for about ten seconds. The IT manager opened SQL Server Management Studio, ran a query against the ERP's change log, and found a timestamp and a system account name. No person. No approval. No reason recorded.
The auditor wrote it down without expression. That single finding turned into a control deficiency on the final report. The remediation cost the company four months of work and an external consultant.
Regulators assume you know who changed what
Every regulation written in the last decade shares one assumption: that organizations can trace data changes back to a responsible person. GDPR calls it accountability. SOX calls it internal controls. DORA calls it data integrity management. The language differs. The expectation is identical.
Master data sits at the center of this. Supplier bank accounts feed payment runs. Cost center codes feed financial consolidation. Customer records contain personal data protected under privacy laws. A single unauthorized change to any of these can trigger a reportable incident, a control failure, or both.
And yet, in most organizations, master data is the least governed data category. Transactional systems have approval chains. HR systems have access controls. The supplier master in the ERP? Someone with edit rights makes a change, and it goes live. Maybe a log entry appears somewhere. Maybe.
The ERP log is not an audit trail
I hear this defense regularly: "We have change tracking enabled in the ERP." And technically, they do. The ERP records a timestamp, the table name, the old value, and the new value. Sometimes it records a user ID.
What the ERP does not record: why the change was made, who decided it was correct, whether anyone reviewed it before it went live, and whether the person who made the change had the authority to do so. The ERP log tells you what happened. Regulators want to know who authorized it.
Segregation of duties is the specific gap. SOX auditors expect that the person proposing a change to a financially material master data record is not the same person approving it. In most ERPs, there is no such separation for master data edits. One user opens the record, changes the bank account number, clicks save. Done. One actor, no reviewer, no approval gate.
GDPR and the right to know who touched what
GDPR gets specific about this. Article 30 requires records of processing activities. Article 5(2) requires that organizations demonstrate compliance, not just claim it. If your supplier master contains contact names, email addresses, or phone numbers (and it does), then every modification to those fields is a processing activity.
A data subject asks: "What personal data do you hold on me, and who has accessed or modified it?" Under Article 15, you have 30 days to answer. If your master data system cannot produce a list of every change to that person's record, with the name of the user who made each change, you have a compliance problem. Not a theoretical one. Dutch and German DPAs have issued fines for exactly this kind of inadequate record-keeping.
The right to erasure (Article 17) adds another layer. When you delete a supplier contact from your master data because they requested it, can you prove the deletion happened? Can you prove it was complete? An audit trail that records "record deleted by User X on Date Y per GDPR request #Z" is the minimum. Most ERP change logs cannot produce that.
DORA and operational resilience
DORA went into effect in January 2025, and it applies to banks, insurers, investment firms, and their critical ICT service providers across the EU. Article 9 requires ICT risk management frameworks that include data integrity controls. Article 10 requires detection of anomalous activities, including unauthorized data modifications.
For financial institutions, the master data feeding risk models, trading systems, and regulatory reporting is a critical information asset under DORA's definition. If a counterparty record changes without authorization and that change propagates into a risk calculation, the institution needs to trace the incident back to the specific data modification. Without field-level audit trails and approval workflows on master data, that trace is impossible.
What auditors actually look for
I have sat on the receiving end of three SOX audits and two ISAE 3402 reviews. The questions follow a pattern:
"Show me a change to a financially material master data record from the last quarter."
They want a specific example, picked at random, not one you prepared.
"Who made the change? Who approved it?"
Two different people. If it is the same person, that is a segregation-of-duties finding.
"What was the previous value?"
Before-and-after comparison. If you only have the current value, you cannot demonstrate control.
"Is this change documented outside the system?"
They are checking whether you rely on emails and tickets, or whether the system itself contains the evidence.
If your master data system can answer all four in under a minute, you pass. If answering requires querying three different tables, cross-referencing an email chain, and asking Dave from IT who he thinks made the change, you have a finding.
How governed MDM closes the gap
The fix is structural, not procedural. You do not solve this with a policy document that says "all master data changes must be approved." You solve it with a system that makes unapproved changes impossible.
In Primentra, every governed entity works the same way. A data steward opens a record and edits one or more attributes. The edits become a changeset. The changeset goes to a reviewer. The reviewer sees old values and new values side by side, adds a comment, and approves or rejects. Only approved changesets commit to the live data. The audit trail records the proposer, the reviewer, the timestamp, the before-and-after values, and the comment. Every field, every change, every time.
That gives you three things regulators care about: segregation of duties (proposer and approver are different users), preventive controls (bad changes never reach production), and a complete evidence trail (the system contains the proof, not an email thread). When the auditor asks about Supplier 4821's bank account, you pull up the changeset. Name, date, old value, new value, reviewer, comment. Done.
The cost of fixing this after the audit
Organizations that discover their master data governance gap during an audit, rather than before it, pay more. The remediation work is identical: implement approval workflows, build an audit trail, assign data stewards, document the control framework. But now it happens under time pressure, with auditor scrutiny, and with a finding already on the report.
A Protiviti survey from 2024 found that 62% of SOX-reporting companies identified at least one material weakness or significant deficiency related to data management controls. The median remediation time was five months. Five months of parallel work, auditor check-ins, and management attention diverted from actual business operations.
The alternative is to put governance in place before the auditor arrives. Not because it makes the audit pleasant. Because it makes the audit short.
Common questions
How does GDPR affect master data management?
GDPR requires you to know where personal data lives, who accessed it, and who changed it. Master data systems storing customer, employee, or supplier records with personal data need a complete audit trail of every modification. Article 30 requires records of processing activities, and Article 5(2) requires demonstrable accountability. Without a governed MDM system that logs every change with the responsible user, you cannot satisfy these requirements during a supervisory authority audit.
What audit trail do SOX controls require for master data?
SOX Section 404 requires management to assess the effectiveness of internal controls over financial reporting. Master data feeding financial reports (cost centers, GL accounts, legal entities, customer credit limits) falls under these controls. Auditors expect to see who changed each record, when, what the previous value was, and whether the change was authorized. Direct edits without approval workflows create a control gap that external auditors will flag.
What is DORA and how does it relate to master data?
DORA (Digital Operational Resilience Act) is an EU regulation effective January 2025 requiring financial entities to maintain operational resilience, including data lineage tracing and change control over critical information assets. Master data feeding trading systems, risk calculations, or regulatory reporting qualifies as critical. DORA Article 9 requires ICT risk management frameworks with data integrity controls.
Can you use an ERP audit log for master data compliance?
ERP audit logs capture that a record changed, but rarely capture who authorized the change or why. Most ERPs log the technical user who executed the write, not the business user who decided the change was correct. They also lack the changeset concept. Auditors want an authorization chain: who proposed, who reviewed, who approved. ERP logs do not provide that level of detail for master data.
How does approval workflow-based MDM help with regulatory compliance?
Approval workflows create a built-in authorization chain. A steward proposes an edit, a reviewer inspects the before-and-after, and only approved changes go live. This gives you segregation of duties, a complete audit trail, and preventive controls. Bad changes are blocked before they reach production rather than discovered after.
Need an audit trail that holds up to scrutiny?
Primentra logs every master data change with the proposer, reviewer, before-and-after values, and comment. Approval workflows enforce segregation of duties. The data lives in your SQL Server, so your existing backup and compliance tooling covers it. The 60-day trial includes everything.