Strengthening Internal Controls with User Termination in D365FO

CONTENT Introduction Importance of User Termination in a SOX Environment Terminate User and Remove Their Security Roles Alternative: Disable User and Remove Their Security Roles Address Workflow Delegations Monitor Batch Jobs Monitor Disabled and Deleted Users via Database Logging Conclusion

STRENGTHENING INTERNAL CONTROLS WITH USER TERMINATION IN D365FO

Introduction

User lifecycle management is one of the most critical aspects of securing any ERP system, and Microsoft Dynamics 365 Finance and Operations (D365FO) is no exception. From the moment a user is onboarded to the time their access must be revoked, organizations must ensure that system access aligns with employment status and compliance requirements.

In a Sarbanes-Oxley (SOX) regulated environment, user termination becomes more than just a technical activity—it is a key internal control. When employees, contractors, or consultants leave the organization, their access to the system must be promptly revoked to prevent unauthorized activities, reduce fraud risk, and maintain the principle of least privilege.

This article explains the steps, options, and considerations for terminating users in D365FO. It provides practical instructions, highlights SOX compliance implications, and points out potential pitfalls if termination is not handled effectively.

Importance of User Termination in a SOX Environment

SOX Section 404 requires companies to establish and maintain adequate internal controls over financial reporting. One of these controls is ensuring that only authorized personnel have access to financial systems like D365FO.

Failure to properly terminate users creates several risks:

• Unauthorized Access: Former employees may still be able to log into the system.
• Segregation of Duties (SoD) Violations: Inactive but enabled accounts could be exploited, creating audit findings.
• Workflow Disruption: Unattended approvals may remain pending if workflow delegations are not reassigned.
• Batch Job Failures: Critical scheduled processes may stop running if they are tied to a disabled user account.

Therefore, an effective user termination process in D365FO must include technical steps (role removal, account disabling, workflow reassignment) as well as compliance checks to verify that no residual risks remain.

Terminate User and Remove Their Security Roles

The preferred approach is to terminate users directly in D365FO using the HR framework. If your environment integrates HR and system access, user termination can be initiated from the Employees form.

1. Navigate to Human Resources > Workers > Employees.

2. Select the employee record.

3. In the Action Pane, under Personnel actions, click Terminate.

4. Select the termination action, enter the termination date, and save the record.

If personnel actions workflows are enabled under HR Shared Parameters, the termination can be routed for approval before becoming effective.

5. OPTIONAL: Execute the termination workflow if selected personnel action type requires a workflow approval.

Workflow submission

  Workflow approval  

Workflow completion

Employee determination

Once the termination is processed, you should also ensure the user’s security roles are removed. This step is critical because it directly revokes system privileges and ensures compliance with SOX. 

NOTE: A standard termination workflow in Dynamics 365 for Finance and Operations (D365FO) does not automatically disable a user account. The standard workflow process in Human Resources primarily handles the worker's employment status, moving them from active to terminated. The user account and security roles must be handled separately.

6. User termination and security role removal 

User termination and security role removal - Before

User termination and security role removal - After

Alternative: Disable User and Remove Their Security Roles

In some organizations, HR and IT systems are not fully integrated, or there may be licensing constraints preventing full use of the HR module. In these cases, you can directly disable a user account in D365FO.

1. Go to System Administration > Users > Users.

2. Select the user record.

3. Toggle the Enabled field to Off.

4. Remove all assigned security roles as shown in the previous section.

This approach is faster but less structured compared to personnel action termination. However, it still meets the SOX requirement of revoking access promptly.

Address Workflow Delegations

Terminated users may still be assigned workflow tasks or delegation rules. If these are not reassigned, business processes (such as vendor invoice approvals, purchase requisition approvals, or journal approvals) could stall. There isn’t any screen that shows all delegations in D365FO, but there is a workaround — a table stores that information: WorkflowWorkItemDelegationParameters

To identify active delegations, use the following link in your environment:

<yourD365FOurl>/?mi=SysTableBrowser&tablename=WorkflowWorkItemDelegationParameters

This opens the table browser to review current workflow delegation records.

Any delegations tied to the terminated user should be reassigned to active employees.

Monitor Batch Jobs

Another critical check is to monitor background batch jobs. Many automated processes in D365FO—such as periodic invoicing, financial consolidations, or integrations—run under a specific user account. If a terminated user owns a batch job, the process may fail after their account is disabled.

To monitor this:

1. Go to System Administration > Inquiries > Batch Jobs.

2. Review the Run by field for each job.

3. Recreate critical jobs with a valid service account or another active user.

This review is especially important during offboarding to prevent system disruptions.

Monitor Disabled and Deleted Users via Database Logging

As a detective control, organizations can enable Database Logging in D365FO to track changes to user accounts. This ensures auditability of user termination activities and provides evidence during SOX testing.

Recommended logging events include:

• User creation
• User deletion
• User enabled/disabled changes
• Security role assignments and removals

For example user activation/deactivation can be followed as below:

Note that the above screen shows enabled and disabled users, giving admins full visibility to take necessary actions.

Database logging not only provides assurance but also strengthens the organization’s ability to demonstrate compliance during external audits.

Conclusion

User termination in D365FO is not just about removing access—it is about safeguarding financial data, preventing fraud, and ensuring compliance with SOX requirements. By following a structured process that includes terminating or disabling users, removing security roles, reassessing workflow delegations, monitoring batch jobs, and tracking changes through database logging, organizations can significantly reduce risk.

An effective termination process bridges the gap between IT operations and compliance, providing assurance to management, auditors, and regulators. Whether you use the HR-driven personnel action approach or the direct disablement method, what matters most is consistency, timeliness, and proper documentation.

In short, closing the door properly when a user exits is just as important as granting them access in the first place.

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.