Microsoft Internal Controls Software

COSO's internal control framework starts with the control environment — the entity-level controls that set the tone for everything downstream. In a Microsoft-centric enterprise, several of the IT-governance entity-level controls that SOX 404 documentation has to describe are literally tenant configuration: the organization's password and MFA policy enforced through Entra ID Conditional Access, the data classification and retention policy enforced through Purview, and the acceptable-use and data-loss-prevention policy enforced through Power Platform DLP and Microsoft Purview DLP more broadly. Documenting these as narrative policy statements without linking them to the actual tenant configuration that enforces them is a common gap — the written policy says MFA is required, but the control's actual evidence is whether Conditional Access enforces it, not whether an employee handbook mentions it.

The connection between written policy and enforced configuration is what an ITGC walkthrough tests directly. A policy document stating 'all privileged access requires approval' is not itself a control; the control is the PIM configuration that technically prevents standing privileged access. Internal controls software built on Microsoft 365 is strongest when it treats the tenant's actual configuration — exportable, dated, versioned — as the primary evidence, with the written policy serving as the narrative that explains why the configuration exists.

Process-level financial controls — three-way match exceptions, journal entry approval, credit memo authorization — are usually built into the ERP's native workflow. But when a Power Automate flow supplements or overrides that native workflow (routing an exception to a different approver, adding an extra approval step above a dollar threshold the ERP's own configuration does not enforce), the flow itself becomes the control, and it has to be documented, tested, and change-managed with the same rigor as any ERP-native workflow. The common oversight is that these flows are built by finance operations staff to solve an immediate problem and never formally added to the internal control matrix, meaning the control the business actually relies on is invisible to the SOX program until an auditor's transaction walkthrough surfaces it.

Bringing Power Automate-based process controls into the internal control matrix requires three things: a documented control owner distinct from the flow's original builder, a change-management process requiring approval before the flow's logic is modified, and a periodic control-design review confirming the flow still matches its documented behavior — because a flow's connectors and conditions can be edited by anyone with edit rights to the underlying environment, silently changing what the 'control' actually does without any corresponding update to its control narrative.

Traditional SOX testing samples a control a handful of times per year. Microsoft 365's tooling makes near-continuous control monitoring achievable for controls with a clean data source: a Power BI report that flags every Conditional Access policy change, every new Global Administrator assignment, or every Power Automate flow newly classified as touching financial data, refreshed daily rather than reviewed quarterly. This shifts some ITGC testing from a sample-based approach to a population-based approach — instead of testing five of two hundred PIM activations, the control monitoring dashboard shows all of them, and exceptions surface immediately rather than at the next testing cycle.

The limitation is that continuous monitoring built this way still depends entirely on the completeness of the underlying Purview audit log and the correctness of the Power BI report's logic — a monitoring dashboard that silently stops refreshing, or that has a filter condition excluding a category of event by mistake, will show a clean control environment that is not actually being monitored. Internal controls programs that lean on continuous monitoring need a control over the monitoring itself: periodic validation that the dashboard's data source is complete and the refresh schedule is running, which is easy to treat as obvious and skip documenting formally.