What the audit log is — and is not
In Microsoft 365 the unified audit log records events you can search later: who signed in, who changed a role, who granted an app consent, who shared in SharePoint or OneDrive. It is not a real-time alarm centre and not a substitute for multi-factor authentication. It is evidence after the fact — or the lack of it if logging was off or retention was too short.
Depending on your subscription and settings, retention and available workloads differ. For an SME what matters most is: is logging on at all, how long you keep records, and who may search. Without those three answers you have little to fall back on after a suspicious sign-in or a missing file.
See admin accounts for who should hold search rights at all, and multi-factor authentication for the layer that stops a stolen password from getting in — same tenant hygiene, different control.
What SMEs typically get wrong
Four patterns come back. Logging never enabled — then after an incident there is nothing to search. Logging on, but no retention or purpose — then records disappear before you need them, or you keep everything without knowing why. Nobody reviews — the logs exist, but nobody looks at suspicious admin actions or mass sharing. Or the opposite: log everything “just in case” without who-may-search and without a written purpose — then you have data without a steering wheel.
The practical line: confirm audit logging is on; pick a retention period that fits your SME (often months to a year; longer only with a reason); name one or two people or Floor ICT who may search; and tie reviews to signals — not to “read everything every week”.
When to enable it — and what to retain
Enabling fits almost every SME with Microsoft 365: you have staff, guests, apps and admins. Without a log you miss reconstruction after phishing, after a leaver who still had rights, or after an app that received too much access. Exceptions are rare; “we have nothing to hide” is not a reason to leave logging off.
What you retain depends on what you want to answer: who signed in from an unknown location; who changed admin roles; who shared a folder externally; who granted an app consent. Agree a period that still makes those questions reachable. Longer is not always better: keeping more without purpose or without who may search creates false comfort.
Real threat: an account that suddenly searches many mailboxes, an admin handing out rights outside the normal path, or a guest account mass-downloading files. The audit log is then your reconstruction — alongside guest accounts and inactive accounts.
Who may search — and when
Searching the audit log is a sensitive privilege: you see behaviour of staff and guests. Limit those rights to admins you trust (or to Floor ICT under your instruction). Agree when searches happen: after an incident, on suspicion, or in a targeted review — not casual browsing.
Write down who may start a search, how you keep the result, and that you do not treat audit logs as continuous monitoring of people. The purpose is reconstruction and security, not surveillance without an agreement.
What you decide in writing
Keep it short enough to decide this quarter:
- whether audit logging (unified audit log) is on in your tenant;
- which retention period you keep, with a short reason (for example reconstruction after incidents);
- who may search the logs (roles or names, or Floor ICT under instruction);
- when searches happen (incident, suspicion, periodic sample — not “always everything”);
- ties to admin accounts, inactive accounts, guest accounts, app consent and multi-factor authentication — one identity hygiene;
- what you expect after a hit: escalate to Floor ICT or the process owner, do not silently ignore it.
Write those points on one page. That is your audit-log agreement; the tenant follows that text.
What Floor ICT configures — and what you decide
In the Microsoft 365 tenant we typically: turn audit logging on or confirm it is on; set a retention period that matches your agreement; limit search rights to the right admin roles; and explain how we consult logs on a ticket or incident. We help with targeted searches (suspicious sign-in, odd admin action, mass sharing) without “fully monitoring” your tenant without instruction.
You still decide: how long you retain; who may search on your behalf; and how firmly you respond if a search shows something concerning. Technical switches without that agreement create false comfort; policy without working logging does not help either.
More depth
Checklist for SME directors
1) Ask whether the unified audit log is on in your tenant. 2) Know the retention period — does it fit “we want to look back half a year”? 3) Know who may search (not every admin role “for convenience”). 4) Tie this to reviews of admin, guest and inactive accounts. 5) Agree: suspicious hit = report, do not silently dismiss. 6) Have Floor ICT include this in the same Microsoft 365 hygiene as multi-factor authentication and app consent.
Audit log versus sign-in logs only
Sign-in logs mainly show who got in. The unified audit log also covers admin actions, sharing, search and app consent. For an SME you want that broader layer — not only “who signed in”. Floor ICT points to which console or query fits your question.
Relation to app consent and admins
When someone grants an app broad rights, or changes an admin role, you want to find that later. Without an audit log you miss that reconstruction. See app consent and admin accounts — logging makes those agreements checkable.