Microsoft IT Audit Software Consulting

IT audit frameworks — COBIT, and the ITGC structure most external auditors use in practice — organize testing into access to programs and data, program changes, program development, and computer operations. In a Microsoft tenant, access to programs and data maps to Entra ID provisioning and deprovisioning plus Conditional Access; program changes maps to change management over Power Platform flows, Azure DevOps pipelines, and Entra ID Conditional Access policy edits; program development maps to how custom Power Apps and Power Automate flows touching financial data move from a developer's personal environment into a governed Managed Environment; and computer operations maps to backup, incident response, and the Purview audit log's own retention and completeness.

The practical value of mapping to this four-domain structure is that it gives IT audit a testing plan that does not depend on knowing the ERP's internals. A tester can complete access-to-programs-and-data testing entirely from Entra ID sign-in logs and access review records, without needing SAP or Dynamics-specific security-role knowledge, because the question at this layer is whether the right person has SSO access at all — the ERP-specific question of whether that person's role within the ERP creates a segregation-of-duties conflict is a separate, later test.

The highest-value ITGC test in a Microsoft tenant is privileged role sampling through Privileged Identity Management: pulling PIM activation history for Global Administrator, Application Administrator, and any custom role capable of altering SSO configuration for a financially relevant application, and confirming each activation had a business justification, a time-boxed duration, and — where required — an approval. Standing (non-expiring) assignment of these roles outside PIM is the single most common ITGC exception IT auditors find in Microsoft tenants that have not deliberately migrated off legacy always-on admin accounts.

Conditional Access testing follows a similar sampling logic but on policy configuration rather than activation history: pulling the Conditional Access policy set via the Microsoft Graph API or the admin center, confirming policies actually enforce what the control narrative claims (device compliance required for finance-system sign-in, MFA required tenant-wide, legacy authentication blocked), and checking the policy's modification history in the Purview audit log to confirm no undocumented change occurred mid-cycle. A control narrative describing a Conditional Access policy that was quietly disabled for troubleshooting three months prior and never re-enabled is a common finding this test surfaces.

Program-change testing in a Microsoft tenant extends beyond traditional application code to Power Automate flows, Power Apps, and any Azure Logic App or Function touching a financially relevant data source. Because Power Platform's citizen-development model allows a maker to modify a flow's logic without a formal deployment pipeline, the ITGC question becomes whether Managed Environments and a defined promotion process (dev, test, production environments with solution-based deployment) exist for in-scope flows, versus flows built and modified directly in a production environment by their original author with no change ticket.

Computer-operations testing closes the loop by confirming the evidence infrastructure itself is sound: Purview audit log retention configured for at least the length of the audit cycle, Microsoft Sentinel or an equivalent SIEM retaining sign-in and Conditional Access events beyond the 90-day Entra ID default, and a documented incident-response process for the tenant covering how a compromised privileged account would be detected and contained. An ITGC program that thoroughly tests access and change controls but has never verified that the underlying audit log actually retains long enough to support next year's testing sample is a gap auditors increasingly probe directly.