Dynamics 365 Internal Audit Software

Building an ERP-relevant risk universe for Dynamics 365 starts with mapping business processes to the security-role and duty structures that support them — procure-to-pay to the accounts payable and procurement role families, order-to-cash to sales order and accounts receivable roles, record-to-report to general ledger and period-close roles. Internal audit uses this mapping to decide where testing effort goes first: a process with high transaction volume, manual workarounds, or a history of prior findings gets more testing depth than a low-risk, low-volume process even if both run through the same ERP instance.

A Dynamics 365-specific risk that generic ERP risk assessments miss is role sprawl from customization. Every cloned security role, every ISV-provided role bundled with an add-on module, and every custom duty created to close an access gap adds a combination internal audit has to evaluate for segregation-of-duties exposure. A risk universe built once at implementation and not revisited as roles accumulate understates risk within twelve to eighteen months in most active Dynamics 365 environments, because role creation in F&O is easy enough that business users and functional consultants do it without necessarily looping in security governance.

For access and SoD testing, internal audit works from the native segregation-of-duties violation report (System administration > Security > Segregation of duties), which evaluates actual role assignments against the organization's defined conflict rules. For process-control testing — approval thresholds, workflow routing, three-way match configuration — internal audit pulls the workflow history log, which records submitter, approver, action, and timestamp for every routed transaction, and can be filtered to a sample population for a given testing period. Both sources are queryable without a third-party tool, which is why most Dynamics 365 internal audit programmes build their own extraction layer rather than buying a platform-specific audit connector.

Configuration and change testing draws on two additional sources: database-level change tracking on financially relevant tables inside F&O, and Microsoft Purview audit logging for tenant-wide and Power Platform administrative activity. Internal audit functions that test only F&O-native change tracking develop a blind spot around Power Platform, because a Power Automate flow or a Power App connected to Dataverse can alter data or trigger transactions without ever appearing in the F&O change log — the activity shows up in Purview instead. A complete internal audit test plan for Dynamics 365 has to pull from both.

Because Dynamics 365 has no native issue-tracking or remediation workflow, internal audit findings against the ERP — an unremediated SoD conflict, a workflow threshold that was never configured, a change-tracking gap on a sensitive table — live in whatever GRC or audit management tool the function already uses, with a reference back to the specific role, duty, or table involved. The practical difficulty is keeping that reference current: a finding written against 'the Accounts Payable Clerk role' becomes ambiguous evidence if that role gets cloned, renamed, or restructured before remediation closes, which is common in Dynamics 365 environments undergoing active development.

The remediation step that closes fastest is SoD conflict resolution through role redesign, because it is a configuration change internal audit can re-test directly against the violation report. Remediation that depends on Power Platform governance — restricting a DLP policy, retiring an ungoverned Power Automate flow — tends to take longer because it usually requires coordination with a citizen-developer or business unit outside the core ERP administration team, and internal audit's re-testing has to extend into the Power Platform admin center rather than stopping at the F&O client.