Preparing for a Microsoft security audit: scope, access, documents and stakeholders
An audit has a limited duration. Every half-day spent waiting for access, looking for the right contact or reconstructing an architecture diagram is a half-day lost for analysis. Here is how we recommend preparing an Entra ID, Microsoft 365 or Active Directory security audit so that it delivers the most value.
Defining scope and objective
An audit without a clear objective produces a generic report. Before starting, answer a few simple questions: why this audit now (regulatory requirement, incident, change of provider, certification preparation); which tenants, forests and domains are in scope; whether subsidiaries and test environments are included; which topics are excluded. The more precise the scope, the more actionable the findings.
Format matters too: configuration audit, architecture review, attack path analysis, or a combination. A configuration audit does not replace a penetration test, and vice versa.
Preparing read-only access
A configuration audit does not need write permissions, and should not have them. The usual access:
- Entra ID and Microsoft 365: a named account with the Global Reader and Security Reader roles, subject to MFA and Conditional Access; possibly an app registration with read-only Microsoft Graph permissions, consented for the duration of the audit and then deleted;
- Active Directory: a standard domain account is enough to read most of the directory; some checks (Group Policy objects, certification authority configuration) may require additional, temporary access, to be discussed;
- Audit workstation: a domain-joined machine or access to an administration host, with the collection tools approved in advance.
Tell your SOC. Collection and attack path analysis tools generate large volumes of LDAP queries and may trigger detection alerts. Inform the monitoring team of the dates, accounts and machines involved, rather than disabling detection.
Gathering documents
Existing documents avoid rebuilding what is already known, and allow intent to be compared with reality. Gather:
- architecture diagrams: forests, trusts, Entra Connect servers, federation, certification authorities;
- the list of known administrator and service accounts;
- the security policy and the joiner and leaver procedures;
- previous audit reports and the status of their action plans;
- the list of providers with privileged access, including delegated administration relationships;
- recent security incidents and the lessons learned.
Involving the right people
An audit draws on interviews as much as on data. Useful contacts: the head of security, the directory and tenant administrators, the network team, the managed service provider where relevant, the data protection officer for compliance topics, and a management sponsor who will arbitrate priorities. Book their time at kick-off: diaries often set the pace of the audit.
A short kick-off meeting confirms scope, schedule, access and the communication channel. Also agree on what happens if a critical finding emerges during the engagement: a compromised administrator account or an exploitable flaw should not wait for the final report, and an immediate alert to the designated contact is preferable. Finally, avoid major configuration changes during data collection as far as possible: the audit captures a state, and a tenant in the middle of a transformation makes findings hard to interpret. If a significant project is under way, say so, so the analysis can take it into account.
What the deliverable contains
A useful deliverable reads at two levels. A summary for management: overall risk level, main findings, decisions required. Then the technical detail: each finding with its description, the evidence observed, the concrete risk, a severity rating and an actionable recommendation. A roadmap orders the actions, separating quick wins from structural work. Raw data and exports go in the appendices, so the checks can be replayed.
What an audit checks
- That scope and objectives were agreed in writing before starting.
- That audit accounts are named, read-only, protected by MFA and disabled at the end of the engagement.
- That app registrations created for the audit are deleted.
- That key documents and stakeholders were brought in.
- That every finding in the deliverable is backed by evidence and comes with a recommendation.