Audit trails in D365 without killing performance

Government agencies and regulated enterprises implementing D365 face a dual requirement that's easy to describe and hard to configure correctly: track enough activity to satisfy auditors, without degrading performance for users. The instinct is to "log everything just in case". The result is predictable: a system that crawls and a log volume nobody can review.

The architecture question is which controls satisfy the audit requirement while keeping the platform responsive.

What over-logging costs

Enable database logging for all tables, including transactional data. Sounds comprehensive. Actually breaks F&O:

• Every INSERT/UPDATE/DELETE on a logged table runs additional I/O for the log write
• High-volume transactional tables (general journal entries, inventory transactions, posted sales lines) can generate millions of log records per day
• Storage costs balloon; query performance on logged tables degrades
• Log tables become the new performance bottleneck nobody anticipated

Within a month of "log everything" the team has to disable logging on the high-volume tables and only kept the compliance-critical ones. Getting this right upfront saves the stop-and-retrofit cycle.

What under-logging misses

Rely on role-based security alone and trust users to follow documented processes. This is "we have controls in procedures" approach. Auditors want evidence, not trust. Document-only compliance fails every serious audit.

Periodic database backups + manual comparison scripts. Reconstructs history after the fact, which is both slow and error-prone. Auditors asking "who changed this field last Tuesday?" don't want a forensic reconstruction, they want a log line.

The pattern that works

Policy-based audit configuration on the audit-sensitive tables, combined with Security Diagnostics and LCS environment monitoring for the broader activity picture.

What each piece covers:

Database logging on the compliance-critical tables:

• Master data subject to governance (customers, vendors, products, employees, GL accounts)
• Configuration that drives behavior (posting profiles, tax codes, approval hierarchies, security role assignments)
• High-sensitivity tables (bank accounts, credit limits, pay rates)

Not on:

• High-volume transactional tables that roll up to the logged master data
• Temporary or staging tables

Audit policies at the platform level:

• Azure audit logs for tenant-level activity (user sign-ins, role assignments at the tenant level)
• Microsoft Purview for cross-service compliance including D365
• Retention set to the jurisdiction's requirement (typically 7 years for government)

Security Diagnostics report:

• Who has which roles - snapshot available on demand
• Role-to-privilege mapping - shows the effective access
• Change report showing role assignments over time
• Run quarterly, archive each run for audit trail

LCS Environment Monitoring:

• Performance metrics showing the system is operating within designed parameters
• Operational incidents and their resolution
• Release history - which code versions deployed when

Together, the four layers give auditors a complete picture of who did what, when, from which identity, with which access - without killing performance.

Table selection for database logging

A concrete rule of thumb: log tables where the change reflects a control-relevant decision, not where the change reflects routine operation. Under this rule:

Log (examples):

• CustTable - customer master, credit limit changes, payment-term changes
• VendTable - vendor master
• HcmWorker - employee master, pay-related changes
• SecurityUserRole - role assignments to users
• MainAccount - GL account master
• TaxCode - tax configuration
• LedgerParameters - ledger-level configuration

Don't log (examples):

• GeneralJournalAccountEntry - millions of rows, posting-engine driven
• InventTrans - inventory movement transactions
• SalesLine - line-level transactional detail
• BatchHistory - system batch-job history

The first set reflects governance-relevant changes someone makes and someone else might challenge. The second set reflects routine operation.

Storage and retention

Log retention follows the regulatory requirement. Government typically requires 7 years for financial records. Practical pattern:

• Hot storage (F&O database): current quarter's logs live in F&O's standard log tables for fast query
• Warm storage (Azure Blob cool tier): 3-year rolling archive for routine audit queries
• Cold storage (Azure Blob archive tier): 4-year-plus archive for long-term retention at lowest cost
• Scheduled job moves logs through tiers on the schedule; query-path transparent to auditors

Total storage cost is bounded because high-volume tables aren't generating log data.

Reporting on audit data

Auditors typically ask:

• "Show me all changes to the credit limit of customer X between these dates"
• "List all users who had role Y at any point in the past 18 months"
• "How many master data edits did user Z make last quarter, and to what tables?"

Each of these queries the audit logs with time and entity filters. Build pre-configured audit report templates that auditors (or internal compliance) can run without developer involvement. Standard F&O inquiry screens cover most questions; complex queries land in Power BI dashboards on top of BYOD.

User activity monitoring

Beyond data changes, user activity matters:

• Sign-in events via Entra ID audit
• Session duration and pattern (odd-hour access is an investigation trigger)
• Elevated-privilege use (admin actions are specifically tracked)
• Failed authentication attempts (alerting on patterns suggests compromise)

Entra ID and Purview cover this layer; D365 doesn't need to reimplement.

What ships with the architecture

A working audit architecture has:

• Database logging enabled on governance-critical tables, not on high-volume transactional tables
• Audit policies at the Entra ID and Purview level for tenant and cross-service activity
• Security Diagnostics report run and archived quarterly
• LCS Environment Monitoring dashboards for operational traceability
• Log retention implemented via tiered Azure storage for cost control
• Pre-configured audit report templates for common auditor queries
• Quarterly log review procedure with sign-off

The discipline is in what to log, not in whether to log. Selective, well-chosen audit coverage beats exhaustive logging every time.