How to Enable Unified Audit Log for Microsoft 365

The cis microsoft 365 foundations benchmark expects that you:

• Enable auditing across your tenant
• Retain logs for a reasonable period
• Protect access to those logs

While the transcript we’re basing this on doesn’t name CIS directly, in practice the unified audit log maps cleanly to several CIS controls around logging, monitoring, and incident support. If you are aiming for cis certified microsoft 365 status or aligning to the cis benchmark microsoft 365 guide, this is one of the foundational pieces.

It also becomes a core data source for automated m365 compliance assessment tools that check your configuration and generate reports for audits.

Microsoft 365 plans handle audit log retention differently:

• Microsoft 365 E3 / Office 365 E3: typically around 90 days of unified audit log retention
• Microsoft 365 E5 / Office 365 E5: typically 365 days of retention

You can export logs (for example to Azure SQL or a SIEM) if you need longer retention, but out of the box, those are the main options.

From a m365 security audit perspective, this matters. If your auditors ask for six months of activity and you’re on E3 with no export, you may simply not have the data. So, part of your m365 compliance checklist should be:

• Confirm audit log is enabled
• Confirm how long logs are retained
• Decide whether to export logs for long‑term storage

Because Microsoft keeps evolving the admin experience, you may see slightly different URLs depending on your tenant. In most current environments, you’ll do something like this:

1. Sign in as an admin
Go to office.com and sign in with your Global Admin (or compliance admin) account.

2. Open the Microsoft 365 compliance portal

• Either go to compliance.microsoft.com directly, or
• From the admin portal, click Show all → Compliance.

3. Find the Audit section
In the left navigation, look for something like:

• Audit or Audit search under the Solutions or Solutions catalog section.

In older tenants, you might be redirected to protection.office.com (the classic Security & Compliance Center). In that interface, you’ll typically do:

• Expand Search in the left nav
• Click Audit log search

Don’t worry if the label is slightly different; if you see "Audit" or "Audit search," you’re in the right area.

Once you land in the audit area for the first time, you’ll usually see a message along the lines of:

> To start recording user and admin activity, you must first turn on auditing.

From there:

1. Click the button to turn on auditing
Typically labelled Start recording user and admin activity or similar.

2. Confirm the action
The portal may ask you to confirm that you want to enable auditing for the tenant. Click Turn on or Yes.

3. Be patient
This part trips people up. A few important points:

• The activation can fail temporarily in very new tenants while services are still spinning up. If it fails, wait a bit (sometimes even a day) and try again.
• After you enable it, it can take up to 24 hours before events start appearing in search results.
• You won’t see historical data from before you turned it on. The clock starts when auditing is enabled.

This is exactly why I always recommend: as soon as your Microsoft 365 tenant exists and you can access the compliance portal, enable audit logging immediately, even if you haven’t fully rolled out mailboxes or SharePoint yet.

In the Audit search interface, you typically have filters for:

• Start date / End date – the time window you’re interested in
• Users – one or more users whose actions you want to see
• Activities – types of actions (file accessed, file deleted, mailbox accessed, site created, etc.)

A simple workflow for an investigation might look like:

1. Choose a date range around when the incident occurred.
2. Filter by activity type – for example:

• File accessed / file deleted (for SharePoint or OneDrive)
• Mailbox login or mailbox messages accessed (for Exchange)
• Team created / channel deleted (for Teams)

3. Optionally filter by user if you have a suspected account.
4. Run the search and scroll through results.

As you scroll, more results will load (you’ll see the result count increment). This is handy but can feel a bit clunky in larger tenants, so don’t be surprised if you end up exporting to CSV pretty quickly.

When you click on a single event in the results list, you get detailed information such as:

• User ID (who performed the action)
• Operation (what they did)
• Date and time (when it happened)
• Client IP address (where they did it from)
• Affected object (file path, site URL, mailbox, etc.)
• User agent / browser details

This is often enough to answer most "what happened" questions.

If you need deeper analysis, you can:

• Export loaded results – downloads only the events currently loaded in the UI
• Export all results – pulls the full result set for that query to a CSV file

The CSV has a few basic columns (creation date, user, operation) and then a big AuditData field, which is a JSON blob. It’s a bit ugly in raw form, but it contains all the structured properties. In practice, many teams either:

• Use Excel with some light Power Query or formulas to parse it, or
• Load it into a SIEM or database for more advanced reporting.

For m365 security assessment work or forensic investigations, that export option is extremely valuable.

One of the most practical uses is simply figuring out what happened to a file.

Typical scenario:

• A user says, "My file is gone" or "This folder moved and now nobody can find it."

You can:
1. Go to Audit search.
2. Filter by:

• File and folder activities (moved, deleted, renamed)
• Date range around when the user noticed the issue
• Optionally the user account, if known

3. Search for part of the file name or folder path.

From there, you can often see:

• Who moved or deleted the file
• The original location
• The new location (destination URL)
• Exact timestamp

Then you can go back to the person (politely) and say something like:
"Looks like this was moved to X site by Y user last Tuesday at 3 PM"—which tends to resolve a lot of internal confusion without drama.

The unified audit log can expose sensitive details:

• File names and paths (which may be confidential)
• Email subjects and mailbox activity patterns
• Executive or HR‑related content locations

So, you really don’t want every helpdesk admin to have free‑for‑all access.

In my experience, a good practice is:

• Limit full audit search access to Security, Compliance, and a very small set of senior admins.
• Use role-based access control in the compliance and security portals.
• Regularly review who can access the audit logs.

This also aligns nicely with expectations from auditors and with standards like ISO 27001 and the cis benchmark microsoft 365, which both emphasize restricting access to security logs and monitoring data.

Within the compliance or security portals, you can define alert policies that trigger when certain audit events occur. Some examples:

• Alert when many files are deleted in a short period (possible ransomware, or just someone going wild in a document library).
• Alert when a specific sensitive SharePoint site is accessed by unexpected users.
• Alert when admins create new mail forwarding rules or new mailboxes.

A typical flow looks like:
1. Go to the Alerts or Alert policies section in the compliance/security portal.
2. Create a new policy.
3. Choose the activities to monitor (these map to unified audit log operations).
4. Define conditions and who should receive email notifications.

It’s not a full SIEM replacement, but it’s a useful baseline, especially in smaller organizations without advanced tooling.

Where things really scale is when you combine the unified audit log with automated assessments and benchmarks.

For CIS, SOC 2, ISO/IEC 27001, or NIST CSF, you typically don’t want to be manually checking settings before every review. Instead, you want an automated m365 compliance assessment that continuously evaluates your tenant against a standard like the cis benchmark microsoft 365.

This is where tools like ConfigCobra come into play for Microsoft 365:

• It continuously checks your Microsoft 365 tenant against the CIS Microsoft 365 Foundations Benchmark (129 controls across Level 1 and Level 2).
• It acts as a kind of living m365 compliance checklist, running scheduled assessments (daily, weekly, monthly) so you always know where you stand.
• It generates audit-ready PDF reports with evidence and remediation guidance, which significantly simplifies microsoft 365 audit preparation.
• It maps CIS controls to multiple standards (NIS2, HIPAA, PCI DSS, ISO/IEC 27001, NIST CSF), so one configuration assessment supports multiple compliance programs.

Instead of scrambling before an audit and manually proving that logging is enabled and properly configured, a tool like this gives you:

• A current view of how your tenant aligns with the cis benchmark microsoft 365
• Documentation that you can hand to auditors
• Ongoing detection of configuration drift

That’s much closer to what most people mean when they say microsoft 365 compliance automation or microsoft 365 compliance automation tools.

Here’s a simple, practical m365 compliance checklist focused just on auditing and logging. You can adapt this into your broader m365 security assessment framework:

1. Audit log enabled

• Confirm unified audit logging is turned on for the tenant.

2. Retention understood and documented

• Document how long logs are kept (90 vs 365 days).
• Decide if you need to export logs for longer retention.

3. Access to audit logs restricted

• Review who can run audit log searches.
• Ensure only appropriate security/compliance roles have access.

4. Alert policies in place

• Define at least a few key alerts (suspicious admin actions, mass deletions, risky access).

5. Testing and drills

• Run a mock investigation: track who accessed a file or moved a folder.
• Capture the steps and screenshots as part of internal documentation.

6. Integration with CIS and other standards

• Map audit logging settings to relevant CIS Microsoft 365 Foundations controls.
• If possible, use an automated assessment to track this continuously.

When auditors ask, "how do you log and monitor activity in Microsoft 365?" you can walk them through this checklist and demonstrate that your unified audit log is not just switched on, but actively used and governed.