Monitoring Data Changes with Database Log in Dynamics 365 Finance and Operations

MONITORING DATA CHANGES WITH DATABASE LOG IN DYNAMICS 365 FINANCE AND OPERATIONS

CONTENT Introduction Why database log is critical for sox Key tables and fields for SOX logging Step-by-step: enabling SOX-aligned logging Tips for aligning with SOX controls What database log doesn't do Complementary tools Conclusion

INTRODUCTION 

In SOX-regulated environments, proving that key data is accurate, properly changed, and fully auditable is non-negotiable. Internal and external auditors expect more than high-level assurances—they want verifiable system-generated evidence that data-altering activities are monitored and controlled. This is especially critical for master data and configuration records that directly influence financial reporting.

Microsoft Dynamics 365 Finance & Operations (D365FO) provides a built-in tool—the Database Log—that supports these objectives. When used strategically, it becomes a reliable method to capture evidence for IT General Controls (ITGCs) and automated key controls, allowing organizations to meet SOX compliance requirements directly from within the application.

This article outlines how to configure and use the Database Log in a SOX-compliant manner, what fields and tables are typically in scope, and how to review the logs during audit cycles.

WHY DATABASE LOG IS CRITICAL FOR SOX

The Database Log supports the first and second lines of defense in a SOX environment:

The table below explains how Database Log features map to specific SOX control expectations. 

On the left, you can find the control capability the Database Log provides; on the right, you can find how this helps your organization meet SOX compliance requirements.

Control Capability (What Database Log Enables)	SOX Compliance Justification (Why It Matters)
Tracks changes to master and configuration data	Supports ITGC – Program Change Management by ensuring that changes to critical configuration are logged and reviewable
Captures timestamp, user ID, old/new values	Satisfies Control Evidence Requirements under SOX Section 404 – logs prove that data changes were authorized and monitored
Provides system-generated, immutable logs	Enables auditability of key system controls, which auditors require for walkthroughs and control testing
Detects unauthorized or unapproved updates	Helps mitigate financial misstatement risks by identifying configuration tampering or fraud
Complements workflow approvals with field-level logging	Supports control operating effectiveness by ensuring the final values match what was approved, not just that a workflow was completed

Auditors routinely ask for evidence that configuration values (e.g., posting profiles, bank accounts, tax parameters) have not changed unexpectedly. The Database Log gives you a timestamped, user-specific record of those changes—including the before/after values.

Without it, organizations often scramble to piece together email threads or screenshots—none of which meet the bar for system-generated audit evidence.

KEY TABLES AND FIELDS FOR SOX LOGGING

This section advises which specific tables and fields in D365FO should be monitored via Database Log in a SOX-compliant environment. It directly answers the question:

"What parts of the system should I enable Database Log on to satisfy SOX auditors?"

You're essentially curating a SOX logging scope—focused only on the configuration and master data elements that impact financial reporting and compliance.

Here are common objects that should be considered for Database Log configuration in a SOX-compliant implementation:

Table	Fields to Log	Why It Matters
VendBankAccount	Bank account number, Routing number	Fraud prevention & payment redirection risk
LedgerPostingSetup	Posting profiles, Main accounts	Impact on financial statements
MainAccount	Posting type, Account category	GL reporting structure
Ledger	Fiscal calendar, Reporting currency	Disclosure and period-end reporting
InventModelGroup	Inventory valuation method	COGS calculation

You're not logging everything—only SOX-sensitive fields that can impact the financials or introduce fraud risk.

This sample list helps define your logging scope, often maintained as part of your SOX control matrix.

Every field listed should map to a SOX control objective (e.g., “Changes to posting configuration must be logged and reviewed”).

STEP-BY-STEP: ENABLING SOX-ALIGNED LOGGING

In this guide, we will enable change tracking functionality for vendor bank accounts.

Navigate to database log setup. System administration > Setup > Database log > Database log setup. 

Click + New.

Click Next.

Select tables and fields.

Vendor bank account table is under General Ledger.

Expand the note and select the fields that need to be tracked.

Limit field selection to SOX-relevant configuration items only. Avoid enabling it for operational or high-volume transactional tables.

According to our scenario, we will track the following fields.

• Account num
• BankIBAN
• Modified by
• Modified date and time
• Vendor account

Choose the logged events. Enable Insert, Update, and/or Delete based on your SOX control narrative.

Click Next.

System doesn't allow you to continue before deleting existing database log.

Delete it first.

Note that Finish button is now enabled.

Click Finish to complete the wizard and enable logging.

Note that you now see all tracked fields on the database log setup screen.

Making changes on the vendor's bank account screen.

Navigate to Accounts payable > Vendors > All vendors.

Select a vendor and click Bank accounts.

Vendor bank account form is now opened.

Click Edit button.

Add '9' at the end of the bank account number field value.

Save the screen, close the form.

EVIDENCE GENERATION FOR SOX AUDITS

Once enabled, logs become available under:

System administration > Inquiries > Database > Database log.

You can export logs to Excel, filter by user/date/table, and review changes in detail.

Note that you now see all the required values.

They also serve as evidence for ITGC testing, especially for configuration change control.

Logged Attribute	SOX Value
Timestamp	Validates when a change occurred
Changed by	Identifies the responsible user
Old value	Ensures no unauthorized configuration overwrite
New value	Shows what the system is using now

TIPS FOR ALIGNING WITH SOX CONTROLS

• Separate duties: Only IT control owners or system admins should configure or disable logging.
• Control design mapping: Tie each logged field to a documented SOX control ID.
• Alerting: Consider combining Database Log with Alerts to notify compliance teams of sensitive updates.
• Change control alignment: Ensure all changes logged were also approved via Change Request or IT ticket.

WHAT DATABASE LOG DOESN'T DO

Database Log is not a silver bullet. It doesn’t:

• Track who approved a change (use workflows for that)
• Cover external systems (e.g., CRM, payroll)
• Replace robust SOD enforcement or Fastpath analysis

It does not log changes made via SQL, which is why production databases should restrict direct write access under SOX principles.

COMPLEMENTARY TOOLS

Purpose	Tool
Cross-app user access review	Fastpath Assure
Data loss prevention and export alerts	Microsoft Purview
Workflow approvals	D365FO native workflows
Full audit across Power Platform	Microsoft Dataverse Audit Log

Use Database Log for configuration integrity, and combine it with these tools for a full compliance coverage model.

CONCLUSION

Database Log is a first-party feature designed for compliance. When configured properly, it satisfies critical SOX control objectives such as:

• Evidence of configuration control
• Traceability of key data changes
• Accountability of users with elevated privileges

For internal auditors, external auditors, and control owners, the value lies in having a system-generated, non-editable, filterable trail—available directly in the ERP system, with no external tools or integrations required.

This makes the Database Log an essential tool in your D365FO SOX compliance toolbox—especially for automated ITGC evidence.

Enabling the Three Lines of Defense in Dynamics 365 Finance & Operations - LINE1: Operational Management

ENABLING THE THREE LINES OF DEFENSE IN DYNAMICS 365 FINANCE & OPERATIONS - LINE1: OPERATIONAL MANAGEMENT

CONTENT Introduction Why the Three Lines of Defense Matters in D365FO LINE 1 Operational Management in D365FO Role-Based Access Control Segregation of Duties (SoD) Enforcement Workflow Approvals in Core Processes Field-Level Audit and Setup Change Monitoring Sample Scenario Conclusion

INTRODUCTION 

As regulatory expectations increase and ERP systems take a central role in financial reporting, organizations are under pressure to demonstrate effective governance within their core business applications. In the context of Microsoft Dynamics 365 Finance and Operations (D365FO), aligning system capabilities with the Three Lines of Defense (3LoD) framework has become a practical way to structure risk and control activities.

The Three Lines of Defense model is a well-established framework used to separate responsibilities for risk ownership, compliance oversight, and independent assurance:

• First Line: Business operations responsible for executing controls
• Second Line: Risk and compliance functions that guide and monitor control performance
• Third Line: Internal audit functions that provide independent assurance

This article explains how D365FO can support all three lines of defense by leveraging built-in features such as workflow approvals, segregation of duties (SoD), security role configuration, audit trails, and external monitoring tools. It is written for consultants, compliance professionals, and ERP stakeholders who are responsible for strengthening internal controls, especially in regulated environments (e.g., SOX-compliant organizations).

By the end of this article, you will understand how to map D365FO features to each line of defense, what implementation activities to prioritize, and how to structure your environment to meet both compliance and operational needs. Screenshot indicators are included throughout the article to help you illustrate the guidance using your own sandbox data.

WHY THE THREE LINES OF DEFENSE MATTERS IN D365FO

Modern regulators and auditors expect ERP environments to reflect the Three Lines of Defense (3LoD) model:

• LINE 1: Operational Management owns risk and executes controls.
• LINE 2: Risk & Compliance oversees, advises, and monitors.
• LINE 3: Internal Audit provides independent assurance.

Dynamics 365 Finance & Operations (D365FO) offers native functionality—augmented by common ISV tools such as Fastpath or RSM Guardian—to embed each line directly in the application. Implementing these capabilities up-front reduces external audit findings, accelerates SOX readiness, and lowers the cost of ongoing compliance.

LINE 1 | OPERATIONAL MANAGEMENT IN D365FO

The First Line of Defense is composed of operational users—those in finance, procurement, inventory, or accounts payable—who are responsible for executing daily business processes and applying system controls as part of their regular duties. These are the people who create journals, submit purchase orders, manage vendors, and approve transactions.

In Dynamics 365 Finance and Operations, these users can directly perform their responsibilities in a way that enforces preventive and detective controls, ensuring they own the associated risks while remaining compliant with internal policies and external regulations.

Let’s explore how this works in practice.

Role-Based Access Control: D365FO uses a security model based on the roles, duties, privileges, which allows you to strictly limit user access to only those tasks they are responsible for. This means each user can be aligned with the specific business function they perform—such as AP clerk, GL accountant, or procurement manager—without having unnecessary access to sensitive or conflicting tasks.

For example, an accounts payable clerk can be granted access to create and edit invoices, but not post journals or create vendors.

By enforcing least privilege access, this model helps organizations meet the core requirement of Line 1: enabling business users to operate efficiently while containing access risk. 

System administration > Security > Assign users to roles

Segregation of Duties (SoD) Enforcement: While access control is about what a user can do, SoD is about what combinations of access should not exist. D365FO provides built-in SoD rules and conflict-checking tools that help prevent users from having access to incompatible duties—such as being able to both create a vendor and approve a payment.

The system allows you to:

• Define SoD rules between duties (e.g., "Vendor master maintenance" and "Vendor payment approval")
• Check for violations when assigning roles
• Enforce review and approval workflows for exceptions

SoD enforcement supports Line 1 by preventing control failures at the point of access assignment and ensuring business users are only responsible for the right set of tasks.

System administration > Security > Segregation of duties > Segregation of duties rules

Workflow Approvals in Core Processes: To ensure operational users follow proper approval paths before high-risk actions are taken, D365FO includes a Workflow engine for many key transaction types, such as:

• Vendor edits
• Purchase requisitions and purchase orders
• General ledger journal entries
• Expense reports
• Vendor invoice journals
• Vendor payment journals

Workflow ensures that a second individual reviews and approves key actions before the transaction is posted or finalized—enabling proper oversight without relying on manual follow-up. This is a critical component of Line 1, as it ensures controls are built into business processes, not applied reactively.

For example, a workflow can require that any purchase order over $25,000 must be approved by a finance manager, even if submitted by an authorized clerk. You can find this end-to-end scenario here.

Accounts payable > Setup > Accounts payable workflows

Field-Level Audit and Setup Change Monitoring: In many control environments, configuration data is just as sensitive as transactional data. The Database Log in D365FO allows you to track changes to high-risk fields—for example, when someone changes a vendor's bank account number or modifies the posting profile for a journal.

This capability supports Line 1 by creating transparency and accountability for operational teams responsible for configuration or master data. Once enabled, the database log tracks:

• Who changed the field
• When it was changed
• What the old and new values were

Although this feature is often reviewed by the second or third line, its purpose is to empower operational users to self-monitor and prevent unintentional misconfigurations.

Enable database logging for a critical table such as VendBankAccount and show the change log after a test update.

System administration > Setup > Database log > Database log setup

Sample Scenario: Let’s walk through an end-to-end example that shows how Line 1 is supported in a real-life AP process:

1. Vendor clerk initiates a vendor change request via the Vendor changes workflow.

2. Workflow routes the request to an AP supervisor for approval.

3. The clerk creates a vendor invoice journal and submits it into Journal approval workflow.

4. The invoice is posted only after a second-level approver signs off.

5. Security roles and SoD rules ensure the same user cannot both create a vendor and approve their invoices.

6. Any change made to vendor bank info is recorded in the Database Log.

Each of these activities is completed by a business user—not the compliance or IT team—meaning risk is being managed where it originates: within business operations.

CONCLUSION

Operational users are the first line of defense in managing risk within Dynamics 365 Finance and Operations. As shown in this article, D365FO provides native capabilities—such as role-based security, segregation of duties enforcement, workflow approvals, and field-level logging—that enable these users to execute controls effectively as part of their daily responsibilities. Embedding such functionality directly into core processes ensures that risks are addressed where they originate: within business operations.

This article is the first in a three-part series on enabling the Three Lines of Defense in D365FO. The next installment will focus on Line 2: Risk and Compliance, and how system capabilities can support oversight, guidance, and control monitoring activities.