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.
Top comments (0)