Preparing a Microsoft 365 security audit: the method

A security audit is not a surprise exam. The difference between a calm audit and a stressful one comes down to preparation. The goal is simple: when the auditor asks a question, you have the answer and the evidence, immediately. Here is how to structure that preparation on a Microsoft 365 environment, from the areas to check to the people to mobilise on the day.

Areas to check first

Most audits cover the same broad areas. Reviewing each one before the deadline saves you from nasty surprises and focuses your effort on what genuinely matters.

• Identities: MFA enabled, legacy authentication blocked, privileged accounts limited and monitored.
• Devices: encryption, antivirus, updates and Intune compliance across the whole estate.
• Access: consistent Conditional Access policies, with no forgotten exceptions.
• Data: controlled external sharing, data loss prevention enabled.
• Logging: retention of audit and sign-in logs for a sufficient period.

An efficient order of play

Start with identities: that is where the highest risks and the auditor's most frequent questions concentrate. Move on to devices, then access, before handling data and logging. This order gets you covering the high-impact topics first, and stops you spending disproportionate time on details while major gaps stay invisible.

Gather evidence in advance

An auditor expects factual, dated items, not assertions. Anticipate the recurring requests and assemble an evidence file before the audit even begins. That avoids the last-minute scramble for screenshots and the stress that comes with it.

1. 1Export the applied policies and their assignment scope.
2. 2Document the device compliance rate, backed by figures.
3. 3List exceptions with justification and review date.
4. 4Prepare a summary linking each framework requirement to its measure.

The classic mistakes

The most common gaps are not spectacular flaws but oversights: a report-only policy never enforced, a temporary exclusion that became permanent, an administrator account without MFA, logs kept for too short a time. These details are exactly what an auditor looks for, because they reveal the gap between intent and reality.

• A policy left in report-only mode and never actually enforced.
• A temporary exclusion group forgotten, turned into a permanent gap.
• An admin or service account escaping MFA.
• A log retention period too short to cover the audited window.

Involve the right people

An audit is not purely technical. The auditor will also question the processes: who decides, who applies, who verifies. Appoint in advance someone able to present the measures and quickly retrieve a piece of evidence. A clear file but a vague explanation leaves a poor impression.

• Name a lead who knows the scope and the available evidence.
• Prepare a simple answer for each documented exception.
• Make sure the policies genuinely reflect what the teams do in practice.
• Ensure quick access to logs and configuration exports.

A successful audit is not one with no gaps, but one where every gap is known, explained and tracked.

Run a mock audit internally

The best preparation is to play out the audit before the auditor does. Take the target framework, go through each requirement and ask yourself, honestly, what evidence you would present. This dry run reveals the fragile areas while there is still time to act, and it trains your teams to answer with confidence on the day. Many gaps are fixed in a few hours when spotted in advance, against several days of stress if they surface in front of the auditor.

• Go through each framework requirement and identify the matching evidence.
• Note the requirements where evidence is missing or out of date.
• Give the review to someone who did not configure the environment, for a fresh eye.
• Prioritise the gaps that cannot be fixed retroactively.

Document the context, not just the settings

An auditor also assesses the maturity of your approach. Beyond screenshots and exports, prepare a short narrative: why a given measure, what scope, which exceptions and for what reasons. This context turns a list of settings into a coherent, controlled story, which inspires confidence and often shortens the exchanges. It also protects you when a question falls outside the strict scope of the settings: you can explain the reasoning behind a choice rather than improvise, and an auditor who sees a considered rationale is far less likely to dig for problems that are not there.

Build a preparation timeline

Effective preparation is planned backwards from the audit date. Working back from the deadline, you identify the tasks that must start early, notably those that depend on an observation period, such as log retention, which cannot be caught up at the last minute.

1. 1At D-60, launch the review of retention periods, impossible to fix retroactively.
2. 2At D-45, inventory the policies and their assignment scope.
3. 3At D-30, run an internal mock audit and list the gaps found.
4. 4At D-15, fix the quick gaps and document those that remain.
5. 5At D-7, finalise the evidence file and the requirement-by-requirement summary.

A company schedules its ISO audit in two months. As early as D-60, it discovers its logs are kept for only thirty days, too short to cover the audited period. By immediately extending retention, it ensures the evidence will cover the requested window when the day comes. Spotted two months early, this gap is handled without stress; discovered during the audit, it would have become an impossible-to-catch-up gap.

How AuPoint helps

AuPoint speeds up this preparation: the platform draws up a picture of your protections, flags the gaps, and generates a dated compliance report with a coverage score per framework (ISO 27001, NIS2, GDPR), exportable to PDF. You arrive at the audit with an evidence file already assembled, instead of building it under pressure. You also spot the oversights yourself before the auditor does, giving you time to fix or explain them.

Frequently asked questions

How long before the audit should preparation start?

As early as possible, ideally several weeks ahead. Some gaps, like a log retention period that is too short, cannot be fixed retroactively: better to catch them well before the deadline so the evidence covers the audited window.

Do we have to fix everything before the audit?

No, and it is often unrealistic. A successful audit is not free of gaps: it is one where every gap is known, justified and tracked by an action plan. An owned, documented gap makes a better impression than a shortfall discovered by the auditor.

Is a screenshot enough as evidence?

It can support a specific point, but solid evidence is dated, linked to a requirement and reproducible. A dated compliance report showing scope and coverage rate carries far more weight than an isolated screenshot with no context.

Who should be present on audit day?

At minimum a technical lead able to present the policies and retrieve a piece of evidence, and a governance contact for process questions. A clear split of roles avoids awkward silences in front of the auditor.

How do you handle a gap discovered the day before?

Do not try to hide it. Document it, explain the cause and present a dated action plan. An owned, tracked gap leaves a far better impression than a shortfall the auditor ends up discovering alone.

Preparing an audit turns an ordeal into a simple verification. With AuPoint, you draw up a snapshot of your protections, spot the gaps upfront, and generate a dated compliance report exportable to PDF, with a coverage score per framework. You face the auditor with a ready evidence file, rather than a spreadsheet rebuilt in a hurry.