Enabling the Three Lines of Defense in Dynamics 365 Finance & Operations - LINE3: Internal Audit Assurance

ENABLING THE THREE LINES OF DEFENSE IN DYNAMICS 365 FINANCE & OPERATIONS - LINE3: INTERNAL AUDIT ASSURANCE

CONTENT Introduction Line 3 Internal Audit in a D365FO-Centric Environment Independent Assurance Through System Evidence Reviewing Transaction and Ledger Integrity Validating Control Execution and Effectiveness Sampling and Testing High-Risk Transactions Auditing Configuration Changes and Access History Leveraging Reporting and Data Extraction Tools A Third Line Scenario: From Audit Request to Finding Conclusion

INTRODUCTION 

The Third Line of Defense within the Three Lines of Defense (3LoD) model is responsible for independent assurance. Unlike Line 1 (which executes controls) and Line 2 (which monitors and oversees), Line 3 evaluates whether the control framework is designed appropriately, operating effectively, and aligned with the organization’s compliance obligations.

In a Microsoft Dynamics 365 Finance & Operations (D365FO) environment, Line 3 does not create workflows, assign roles, or approve transactions. Instead, Internal Audit uses the system’s data, logs, and reports to test and verify that Lines 1 and 2 are performing their responsibilities and that risks are being managed within tolerance.

This article focuses on how internal audit teams can use D365FO’s capabilities—alongside standard audit methodologies—to perform independent reviews and produce evidence-based assurance for stakeholders such as the audit committee, regulators, and external auditors.

LINE 3 | INTERNAL AUDIT IN A D365FO-CENTRIC ENVIRONMENT

Internal Audit’s primary value lies in its objectivity. It operates separately from both operations and compliance functions, ensuring that its assessment is unbiased and evidence-driven. In D365FO, this objectivity is enhanced by the system’s ability to generate immutable records of transactions, changes, and approvals.

Typical responsibilities of Line 3 include:

• Assessing whether controls designed by Line 1 and monitored by Line 2 are functioning as intended
• Reviewing the completeness and accuracy of transaction data
• Identifying process gaps or control weaknesses not previously detected
• Recommending improvements to strengthen the overall control environment

INDEPENDENT ASSURANCE THROUGH SYSTEM EVIDENCE

1. Reviewing Transaction and Ledger Integrity

Internal auditors frequently begin by validating the accuracy and completeness of financial transactions. In D365FO, this involves:

• Using General ledger > Inquiries > Voucher transactions to trace transactions from source documents to ledger postings
• Verifying that subledger entries (e.g., Accounts Payable, Accounts Receivable, Fixed Assets) reconcile to the general ledger
• Checking for manual journal entries that bypass standard workflows

View of subledger journal of a purchase order invoice (Voucher transactions inquiry showing linkage between subledger and ledger entries)

2. Validating Control Execution and Effectiveness

Line 3 evaluates whether preventive and detective controls are consistently applied. This includes:

• Reviewing workflow history to ensure approvals occurred as designed
• Checking whether SoD violations identified by Line 2 were remediated or mitigated
• Confirming that exception handling processes were documented and followed

D365FO’s workflow history logs and exported SoD violation reports are primary data sources for these validations.

View of workflow history screen with an invoice approval chain

3. Sampling and Testing High-Risk Transactions

Internal Audit applies sampling methods (statistical or judgmental) to test transactions for compliance with policy. Examples include:

• Testing a sample of vendor changes to verify proper approval and supporting documentation
• Reviewing high-value payment transactions for dual authorization evidence
• Confirming that purchase orders over threshold values received required managerial approvals

Sampling can be done by exporting data from D365FO using Data Management > Export into Excel or Power BI for analysis.

4. Auditing Configuration Changes and Access History

Unauthorized or undocumented configuration changes can weaken controls. Internal Audit reviews:

• Database Log entries for high-risk tables (e.g., posting profiles, vendor bank accounts)
• Historical user role assignments to detect privilege escalation
• Removal of access for terminated employees

While D365FO’s native tools provide much of this data, external solutions like Fastpath or Guardian may enhance visibility, especially for historical access reporting.

View of database log entries showing a change to a vendor’s bank account.

5. Leveraging Reporting and Data Extraction Tools

To streamline evidence collection, Line 3 can leverage:

• Task Recorder to document test steps for re-performance by external auditors
• Data entities to pull standardized datasets for repeatable audits
• Power BI integration to visualize trends in control exceptions and workflow performance

By using system-generated evidence, Internal Audit reduces reliance on manual screenshots or user attestations, improving both efficiency and credibility.

A THIRD LINE SCENARIO: FROM AUDIT REQUEST TO FINDING

Imagine Internal Audit is performing a quarterly review of vendor master data changes:

1. Audit extracts vendor bank account changes from the Database Log for the last 90 days.

2. A sample is selected focusing on changes made outside normal business hours.

3. One entry shows a bank account change by a user whose role assignment was supposed to be temporary.

4. Further investigation reveals the role removal was delayed, allowing the user to make changes after their project ended.

5. Audit issues a finding recommending stricter monitoring of role deactivations and improved coordination between HR and IT.

This example illustrates how Line 3 moves beyond detection—providing recommendations that close process gaps and strengthen Lines 1 and 2.

CONCLUSION

The Third Line of Defense in D365FO is not about running the business or overseeing it—it’s about independent validation that both are working as intended. By leveraging D365FO’s inquiry screens, workflow histories, database logs, and data exports, Internal Audit can perform efficient, evidence-based reviews without disrupting daily operations.

When Lines 1 and 2 perform their roles effectively, Line 3’s job becomes one of confirmation and continuous improvement—ensuring that the organization’s control environment is not only compliant, but resilient.

This completes the three-part series on enabling the Three Lines of Defense in Dynamics 365 Finance & Operations. Together, these articles provide a blueprint for embedding operational control, compliance oversight, and independent assurance into your ERP system.

Enforcing Item and State Regulations in Dynamics 365 Finance & Operations

ENFORCING ITEM AND STATE REGULATIONS IN DYNAMICS 365 FINANCE AND OPERATIONS

CONTENT Introduction Restricted Products Regional Lists – Enforcing Sales Restrictions Example: Restricting Motorcycle Sales in California Regulated Products Regional Lists – Tracking Compliance Requirements Example: Licensing Requirements for Agricultural Chemicals Product Safety Data Sheet Validity – Managing Hazardous Material Compliance Example: Auto SDS Creation When Packing Slip is Posted Conclusion

INTRODUCTION 

Many organizations operate in industries where product distribution is tightly regulated by geography. These rules may originate from international trade restrictions, environmental standards, safety requirements, or state-level laws. Examples include:

• Blocking exports of controlled chemicals to certain countries
• Restricting motorcycle sales in specific U.S. states
• Requiring a valid safety data sheet before selling hazardous materials

Managing these rules manually is inefficient and risky. To ensure compliance, enforcement needs to be embedded into the ERP system, where controls are consistently applied without relying solely on user awareness.

In Microsoft Dynamics 365 Finance & Operations (D365FO), the Product compliance framework provides several built-in tools to manage these requirements, located under:

Product information management > Setup > Product compliance

The key compliance features include:

• Restricted products regional lists – Blocks or allows sales of certain products in defined regions
• Regulated products regional lists – Tracks regulatory requirements for specific products in specific regions
• Product safety data sheet validity – Manages the validity of safety data sheets to ensure compliance before sale

This article focuses on how these features work together to help organizations enforce jurisdiction-based sales rules, illustrated with real-world scenarios.

RESTRICTED PRODUCTS REGIONAL LISTS - ENFORCING SALES RESTRICTIONS

The Restricted products regional lists feature is used to prevent or permit sales of certain items in specific jurisdictions. These restrictions are validated during sales order entry, based on the shipping address in the order header.

Key Configuration Elements:

• Jurisdiction type: Country/region, State/province, County, or City
• List type
• Inclusive: Only listed items can be sold in the jurisdiction
• Exclusive: All items except those listed can be sold
• Product association: Items explicitly linked to the list

Product information management > Setup > Product compliance > Restricted products regional lists

EXAMPLE: RESTRICTING MOTORCYCLE SALES IN CALIFORNIA

Scenario: A company sells motorcycles nationwide but is prohibited from selling them in California due to regulatory requirements.

Configuration Steps:

Create an exclusive restricted product list for California:

Let's now make sure that related parameter is active. 

Note that compliance check can be done packing slip stage as well.

Expected behavior: Sales orders with California shipping address cannot include the restricted motorcycles. 

Let's create a sales order that includes motorcycle with California address.

Insert restricted product.

Note that system throws an error when the sales line is saved.

Product 'XYZ' is restricted for sale to the delivery address on the sales line. Change the address or the product.

REGULATED PRODUCTS REGIONAL LISTS - TRACKING COMPLIANCE REQUIREMENTS

While restricted product lists block or allow sales, the Regulated products regional lists feature manages regulatory requirements that must be met before a product can be sold in a specific region.

This is essential when:

• A product is legal to sell but requires specific permits or licenses in certain regions
• Compliance documentation must be recorded before shipment
• Different regions impose different regulatory conditions on the same product

Product information management > Setup > Product compliance > Regulated products regional lists

EXAMPLE: LICENSING REQUIREMENTS FOR AGRICULTURAL CHEMICALS

Scenario: A company sells agricultural chemicals across multiple states, but some states/countries require a pesticide applicator license before purchase.

Configuration Steps:

Create a regulated product regional list for each state requiring a license and associate the relevant agricultural chemical items.

This setup can also been seen from the item itself.

Last check, let's now make sure that related parameter is active. 

Expected behavior: Sales orders with Canada shipping address must have an active product safety data sheet when weed killer is sold. If not, system throws a warning.

Let's create a sales order that contains weed killer with Canada address.

Note that system throws an error when the sales line is saved.

Please deliver the latest active product safety data sheet to the customer.

Let's try to post the packing slip.

Note that system throws an error:

No valid product safety data sheet exists for the item on the sales order

PRODUCT SAFETY DATA SHEET VALIDITY - MANAGING HAZARDOUS MATERIAL COMPLIANCE

Some products, especially chemicals, require a Safety Data Sheet (SDS) that must be current and valid at the time of sale. The Product safety data sheet validity functionality ensures that a product cannot be sold if its SDS is expired or missing.

Product information management > Setup > Product compliance > Product safety data sheet validity

EXAMPLE: AUTO SDS CREATION WHEN PACKING SLIP IS POSTED

Scenario: A hazardous chemical (weed killer) sales automatically generates an SDS when packing slip is posted.

Configuration steps:

Create a regulated product regional list for each state requiring a license and associate the relevant agricultural chemical items. (Already done in the previous step).

Define SDS validity rules for the chemical product.

Define a safety data sheet (SDS) for the chemical product.

Attach the actual SDS document. 

The last step is the parameter configuration. Navigate to

Inventory management > Setup > Inventory and warehouse management parameters > Product compliance

Remember that system throws an error shown as below when there is no active SDS.

After configurating product safety data sheet validity, attaching a safety data sheet to the product, and configuring compliance parameters properly, system allows user to generate packing slip and safety data sheet simultaneously.

CONCLUSION

This article explains how Microsoft Dynamics 365 Finance & Operations (D365FO) enforces jurisdiction-based product regulations using its Product compliance framework. It covers three key features:

• Restricted products regional lists: Prevents sales of certain items in specified regions (e.g., blocking motorcycle sales in California).

• Regulated products regional lists: Tracks and enforces regional regulatory requirements before sale (e.g., pesticide license requirements for agricultural chemicals).

• Product safety data sheet (SDS) validity: Ensures hazardous materials have a current SDS before shipping, with the option to auto-generate SDS documents during packing slip posting.

Through step-by-step configuration examples, the article demonstrates how these tools work together to automate compliance, reduce manual oversight, and ensure that regional sales restrictions, licensing obligations, and hazardous material documentation requirements are met directly within D365FO.

Enabling the Three Lines of Defense in Dynamics 365 Finance & Operations - LINE2: Risk and Compliance Oversight

ENABLING THE THREE LINES OF DEFENSE IN DYNAMICS 365 FINANCE & OPERATIONS - LINE2: RISK AND COMPLIANCE OVERSIGHT

CONTENT Introduction Line 2 Risk and Compliance Oversight in D365FO-Centric Organizations Governance Through Monitoring: A Functional View Oversight of Security Role Changes and Privilege Escalation Monitoring Segregation of Duties Violations and Exception Approvals Evaluating the Effectiveness of Workflow Controls Analyzing Field-Level Configuration Changes Performing Periodic Risk Reviews and Reporting A Second Line Scenario: From Oversight to Intervention Conclusion

INTRODUCTION 

The purpose of the Second Line of Defense within the Three Lines of Defense (3LoD) framework is not to execute business controls, but to ensure that those controls are functioning consistently, remain aligned with risk tolerance, and are subject to ongoing review. In Microsoft Dynamics 365 Finance & Operations (D365FO), Line 2 does not directly perform journal postings, approve transactions, or assign user roles—that’s the job of Line 1. Instead, Line 2 is accountable for designing policy frameworks, overseeing access governance, monitoring control adherence, and responding when execution deviates from expected behavior.

This article explains how D365FO supports Line 2 professionals—compliance officers, internal control owners, and risk managers—in supervising control environments without directly interfering with operational workflows. It is written for readers who already understand D365FO’s built-in features such as role-based access, segregation of duties (SoD), workflow approvals, and audit trails. Instead of re-explaining these tools, we focus on how Line 2 uses them for governance and monitoring purposes.

LINE 2 | RISK AND COMPLIANCE OVERSIGHT IN D365FO-CENTRIC ORGANIZATIONS

Line 2 functions as the system’s compliance backbone, tasked with embedding internal control principles into application governance. These responsibilities include:

• Establishing risk-aligned access policies
• Defining SoD rules and exception handling criteria
• Monitoring workflow effectiveness across departments
• Reviewing audit trails and configuration changes
• Providing structured guidance to Line 1 users
• Liaising with auditors and reporting on internal control health

In D365FO, these tasks can be performed using native capabilities—augmented where necessary by ISV tools like Fastpath, RSM Guardian, or custom Power BI dashboards. Line 2 does not need to rely on external documentation or manual audits. Instead, the ERP system itself becomes the control environment, enabling real-time oversight of daily operational activity.

GOVERNANCE THROUGH MONITORING: A FUNCTIONAL VIEW

While Line 1 users rely on D365FO to execute controls, Line 2 uses the same system to oversee them. Below, we explore how this oversight manifests in the application.

1. Oversight of Security Role Changes and Privilege Escalation

Access provisioning is handled by IT or business operations (Line 1), but Line 2’s responsibility is to monitor whether those assignments adhere to policy.

In practice, this involves:

• Reviewing changes in user role assignments on a regular cadence
• Identifying users who have gained elevated privileges outside of standard provisioning processes
• Investigating any deviation from the principle of least privilege

While D365FO does not natively provide historical change tracking for user-role assignments, organizations often implement supporting tools or audit reports to capture this activity. Alternatively, Database Log can be enabled to track changes in the underlying security tables.

2. Monitoring Segregation of Duties Violations and Exception Approvals

Line 2 does not create SoD rules—that’s a shared responsibility between compliance and system administrators. But Line 2 governs how these rules are enforced and how exceptions are handled.

Typical activities include:

• Reviewing SoD violation reports and understanding the business context behind them
• Approving or rejecting temporary access exceptions requested by Line 1 users
• Validating that approved exceptions have compensating controls in place (e.g., increased monitoring or dual approval)

The objective is not to prevent the business from operating efficiently, but to ensure that risk-acceptance decisions are conscious, documented, and periodically re-evaluated.

3. Evaluating the Effectiveness of Workflow Controls

While Line 1 users initiate and participate in workflows (e.g., invoice approvals, vendor edits), Line 2 has a supervisory role to play: Are those workflows functioning as intended?

Key evaluation points include:

• Are workflows consistently routing to the correct approvers?
• Are approvals happening within expected timeframes?
• Are any steps being auto-approved due to escalation thresholds?
• Is there evidence of override behavior (e.g., approval by system administrators)?

These checks are often performed using the Workflow history log in D365FO or through exported workflow datasets analyzed in Power BI.

4. Analyzing Field-Level Configuration Changes

Control failures are not always transactional—they often begin in setup and master data. A well-designed workflow or SoD policy can be rendered ineffective if a key configuration setting is changed.

Line 2’s responsibility is to track changes to sensitive fields and ensure that:

• Only authorized users are making changes to configuration records (e.g., vendor bank account, posting profiles)
• All changes are traceable and explainable
• Recurring or off-hours changes are flagged for further review

D365FO’s Database Log feature supports this type of oversight. When enabled for the appropriate tables, it records the user ID, timestamp, and before/after values for each change.

5. Performing Periodic Risk Reviews and Reporting

Line 2 is accountable for translating system data into actionable risk insight. This typically includes:

• Monthly or quarterly reports on SoD exceptions, workflow behavior, and sensitive field changes
• User access reviews for high-risk roles (e.g., system administrators, finance approvers)
• Assessment of policy violations and recurring control issues
• Recommendations to IT or Line 1 leaders for control remediation or enhancement

Tools like RSM Guardian or Fastpath streamline this process by aggregating control data into prebuilt dashboards. However, even without ISVs, D365FO’s native data entities, export functions, and logging capabilities enable meaningful review cycles—if structured properly.

SAMPLE SCENARIO: FROM OVERSIGHT TO INTERVENTION

Consider this common use case:

A temporary SoD exception was approved last month, allowing a user to both create and approve vendors.

During a monthly review, Line 2 notices that this exception is still active—even though the stated expiration date has passed.

Further investigation reveals the same user submitted and approved three vendors, one of which was used in a high-value payment.

Line 2 flags the issue, revokes the role combination, and recommends a retrospective review of the payment by Internal Audit.

This type of oversight intervention highlights the true value of Line 2 in D365FO—not just spotting violations, but ensuring controls remain active, relevant, and risk-aligned.

CONCLUSION

The Second Line of Defense brings structure, oversight, and assurance to the control environment. In Dynamics 365 Finance & Operations, Line 2 professionals are not responsible for day-to-day transactions—but they are accountable for ensuring that the system itself enforces compliance principles.

By continuously monitoring role changes, SoD conflicts, workflow behavior, and audit logs, Line 2 can enforce risk policies without disrupting operations. The end result is a governance model where compliance is embedded within the ERP—not layered on top of it.

The final article in this series will focus on Line 3: Internal Audit, where we examine how independent assurance can be delivered using D365FO’s data and reporting capabilities.

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.