Most teams use Microsoft 365 every day,
but when something goes wrong,
they can't answer a basic question.
Who opened that file?
Who shared it outside the company?
Who deleted it, changed it,
or changed the rule that was meant to protect it?
I'm Mirko Peters from M365.
FM and this knowledge nugget puts Microsoft
Perview Audit into plain English.
By the end, you'll see what it records,
why compliance teams depend on it,
and where it fits in the wider Perview platform.
Think of Microsoft 365 like an office building.
You've got rooms for email, files, meetings,
chat and administration.
Perview Audit is the security camera
logbook running behind the scenes.
It records who entered what they did
when it happened, where it happened,
and sometimes how they got there.
But here's the key distinction.
It records actions, not the full contents
of every file or message.
That difference matters a lot.
The problem audit solves.
Before cloud services work together,
every system kept its own log.
Email had one set of records, file storage had another,
and meeting tools, devices,
sign-ins and admin portals,
each kept their own history somewhere else.
So when an incident happened,
someone had to pull records from several places
and try to build a timeline by hand.
That takes time, and during an investigation,
time is everything.
Imagine a finance employee shares a file
from one drive with an external address.
A few minutes later, someone changes a mailbox rule.
Then an administrator edits a data protection policy
in Perview.
Maybe none of those actions connect,
or maybe there are three parts of the same problem.
Without a shared activity record, your team has to guess.
That's where Microsoft Perview Audit comes in.
It brings activity from connected Microsoft 365 services
into one searchable audit log.
Instead of opening separate portals
and comparing separate timestamps,
you can start with one question and search from one place.
You might need to know who shared a file
outside the company, or when a mailbox rule changed,
especially if messages suddenly started forwarding
somewhere they shouldn't.
Maybe you need to confirm whether an administrator
changed a sensitivity label, a retention setting,
or a data loss prevention policy.
Or perhaps an employee is leaving,
and HR or security needs to understand
which files that person accessed before their last day.
These questions aren't about blame by default.
Sometimes a person clicks the wrong sharing option,
sometimes an admin changes a setting during normal work,
and sometimes a security alert turns out to be harmless.
Still, you need facts before you can decide what happened.
The unified audit log gives you those facts
as activity records.
An activity record includes the person who took the action,
the time, the Microsoft service involved,
and the item involved like a file mailbox, site, or policy.
Depending on the activity,
it can also include details like an IP address
and other context around the event.
That means you can move from, we think something changed
to this account changed, this setting at this time
from this location.
That's a very different conversation.
Now notice what an audit record does not promise.
It doesn't automatically give you the full contents
of an email, chat, or document.
It tells you that an action happened around that item.
Think of the logbook at a building entrance.
It shows someone entered a room at 10.14,
but it doesn't tell you every word spoken inside the room.
Per view audit also keeps a trail for more than everyday users.
It records actions by administrators
and it records activity around per view settings themselves.
So if someone changes a protection policy,
your investigation can include that change,
not just the activity that followed it.
Compliance depends on this kind of evidence
and auditor, legal team, security team,
or manager can't work from a hunch.
They need to show what happened, when it happened,
and what the organization did next.
Once you see the problem audit solves,
the logbook starts to make much more sense.
Blas, how purview audit works behind the scenes.
Per view audit is a central record of activity
from all the connected Microsoft Cloud services you already use.
It doesn't replace Exchange Online SharePoint OneDrive or Teams,
those still run your email files and chats.
Instead, audits it's behind those services
and records selected actions that those services report.
Let's break down the main building blocks.
Exchange Online can record activity around email and calendars.
That might include mailbox actions, mail flow activity,
or changes that affect how messages are handled.
SharePoint and OneDrive can record actions around files
when someone opens a file, edits it, moves it,
deletes it, syncs it, or shares it.
Those are different actions and they can create
different records.
Teams adds collaboration activity.
Your team might create a workspace,
change membership, work around a meeting,
or interact with files linked from a channel.
The exact events depend on the service and your licensing,
but the point stays the same.
Actions can leave a record.
Enter ID, Microsoft's identity service,
adds, sign in an identity context where it's available.
That helps you connect an action to the account
that's signed in rather than looking at a file event on its own.
Then there is PerView itself.
A policy doesn't protect anybody if someone can quietly
change it without a record.
Audit can track activity around policy changes,
sensitivity labels, data loss prevention rules, retention
settings, and other admin work in PerView.
That link matters because an investigation often
starts with a file or email then turns into a question
about the controls around it.
Imagine a confidential spreadsheet stored in OneDrive.
On Monday morning, an employee shares it
with an external address.
Later that day, the same employee opens the file again.
A manager notices the sharing alert
and asks whether the spreadsheet left the company by mistake.
You wouldn't search for everything in the tenant.
You would start with a narrow question,
which account shared this specific file,
and when.
The audit search can then help you build
a timeline around that question.
You might find the sharing event, the file location,
the account involved, and other nearby actions
that give the event context.
Perhaps the account signed in shortly before the share,
perhaps the file moved from a team site
into a personal OneDrive folder first.
Or perhaps the employee removed the external link
shortly after realizing the mistake.
Those records are breadcrumbs.
They help you follow the path.
They do not decide intent for you.
A person sharing a file externally
could be doing normal work with a supplier.
It could also be an error.
In a more serious case, it might need a deeper investigation.
Audit gives you the activity trail
and your people apply judgment to the facts.
The search screen gives you ways to narrow that trail.
You can set a date range.
You can search for a person.
You can choose an activity such as a file share
or a policy update.
You can filter by service, file, mailbox, sharepoint site,
object, or a keyword.
When that fits the question, you are trying to answer.
Start small.
A search for every event from every user
across a long period can leave you with far too much noise.
A search for one person, one file, and one day
gives you a place to begin.
Give the search a clear name as well.
Finance File External Share 14 May
tells the next investigator what you looked for.
Search seven tells them almost nothing.
If the case returns weeks later, a clear name, a defined scope,
and a recorded reason make it easier to repeat the work
and compare the results.
When the search returns useful records,
you can export them.
That export may go to security for incident work, HR,
for an internal review, legal for a case,
or an outside reviewer who needs evidence
without direct access to your Microsoft 365 tenant.
Keep track of what you exported, who received it, and why.
Audit data can be sensitive because it
describes real actions by real people,
but a long list of audit events still leaves one question open.
You may know that someone opened, shared, or changed something.
How do you find the actual document, email, chat, or compliance
case that belongs with that activity?
Audit finds the actions.
The other purview tools answer different parts
of the investigation.
Where audit fits in the purview building.
Microsoft purview has several tools that sound close enough
to confuse almost anyone.
Audit, compliance manager, e-discovery, content search,
insider risk management, and communication compliance
all deal with data, risk, or investigations.
But they don't do the same job.
Start with audit and compliance manager.
Audit answers what happened.
You search it when you need the history of an action.
A person shared a file, an admin changed a policy,
a mailbox setting changed.
You want the record of that event.
Compliance manager answers a different question.
What controls does our organization need?
And how far along are we?
Think about a company working toward a rule set such as HIPAA, ISO 27001,
or another industry requirement.
Compliance manager helps the team track the controls,
the work still left to do, and the evidence connected
to those controls.
So audit gives you the event history.
Compliance manager gives you the wider compliance work list.
One can support the other, but neither replaces the other.
Then there is e-discovery.
Audit can tell you that somebody opened, shared,
downloaded, or deleted something.
It gives you the timeline and the event details.
E-discovery helps when you need the actual content.
Maybe legal needs to find emails connected to a case.
Maybe HR needs to review team's chats.
Maybe an investigation needs to preserve documents
so they are not removed while the case continues.
That's e-discovery work.
It can find content, place it on hold, bring it into a case,
support review, and export it when the people handling the case
need it.
A simple way to remember the difference is this.
Audit tells you that a person opened a document
at a certain time.
E-discovery helps you find the document itself
and manage it as evidence.
Content search sits close to e-discovery,
but it has a narrower job.
Suppose audit shows that an employee shared a file
or that a message left a mailbox.
You now know an action took place.
Content search helps you locate the actual file
or message by searching the places where that content lives.
You might search a mailbox, a SharePoint site,
or one drive account, or a Microsoft 365 group.
So audit can point you toward the item.
Content search helps you find the item.
For a larger legal HR or regulatory matter,
that search may become part of an e-discovery case
where access, review, preservation, and exports
need tighter control.
Inside a risk management works differently again.
Audit gives you raw activity evidence.
It can show a download, a share, a sign-in,
or another recorded event.
By itself, each event may be normal.
Inside a risk management looks for patterns
that might point to risky behavior.
For example, one download may mean nothing.
A pattern of downloading sensitive files,
moving them to a personal location,
and then sharing them outside the company
deserves a closer look.
Inside a risk management brings signals together
and can raise an alert for reviewers.
It doesn't declare somebody guilty.
It helps the right people notice behavior that needs context,
and audit can help them examine the actions behind that alert.
Communication compliance has an even more focused role.
Audit can record communication-related actions.
It may help show that an activity happened around a mailbox,
chat, or collaboration service.
Communication compliance helps approve reviewers
examine actual messages that were flagged by a policy.
That might involve inappropriate language,
sensitive information, a conflict of interest,
or another defined concern.
Because reviewers can see real conversations,
this process needs strict controls.
Not every admin should see every audit record,
and not every investigator should read every message
or enter every case, give people only the access
they need for their job.
An audit reader can search activity records,
and e-discovery case can limit access
to the people handling that case.
Communication compliance can restrict message review
to trained reviewers.
This protects privacy, reduces unnecessary exposure,
and makes the process fairer for everyone involved.
A typical investigation can move from question
to evidence in a clear order, and alert arrives,
or somebody asks a question.
Audit helps build the activity timeline,
content search, or e-discovery helps locate
and manage the content.
Then the right team reviews the evidence
and decides what responses needed.
Different tools, different jobs, one connected process.
The next decision changes how far back you can search
and how much detail you can retrieve.
Audit standard or audit premium.
Audit standard and audit premium simply explained.
So which version do you need?
Let's break it down.
The choice really comes down to whether you need
a basic activity history or a deeper record
for longer, more detailed investigations.
Audit standard is where most organizations start.
It comes with many Microsoft 365 plans
and gives you the everyday records most teams need
when they're trying to answer a focused question.
You can search for sign-ins, file actions,
sharing activity, and admin changes
across the services you use.
When a manager asks whether a project document
was shared outside the company yesterday,
that's a normal audit standard question.
You know the likely user, the file, and the time period.
So you run a focused search, check the activity record,
and decide whether more work is needed.
For many organizations that covers a lot of ground.
By default, audit standard keeps many audit records
for up to 180 days.
Six months is enough when your team spots problems quickly,
investigates them within a reasonable time
and doesn't have a rule that requires a much longer history.
But some questions arrive much later.
A legal team may begin reviewing a matter that started last year.
A security team may discover that an account
has been misused for months or a regulated business
may need to keep records for years because a rule requires it.
That's where audit premium comes in.
To get audit premium, you need Microsoft 365 E5, E5 compliance,
or a suitable add-on depending on your licensing setup.
It includes the standard capabilities,
then adds a longer lookback period and more detail
for certain investigations.
Premium keeps eligible audit records for one year by default.
It also allows custom audit retention policies,
which can keep selected records for up to 10 years
when the right licensing is in place.
You don't have to treat every user
and every activity the same way.
A finance team may need longer records
than a general project team.
Prove-ledged administrators may need longer records
than ordinary users.
A mailbox access event may matter more to your organization
than a routine file edit.
Premium lets you shape retention around those real needs
rather than applying one broad rule to everything.
It also provides more event detail, intelligent insights,
and higher bandwidth API access.
In plain English, you get richer information
for more complex investigations
and larger organizations can move audit data
into their own security tools more efficiently.
Picture two situations.
In the first, someone asked whether a file was shared
externally this morning.
Audit standard may give you everything you need.
In the second, an organization needs to rebuild
a long-running security or legal case.
It may need a year or more of activity,
deeper mailbox records,
and a way to send large volumes of audit data
to a security platform.
That's the type of work audit premium is built for,
but don't fall into one common licensing trap.
Longer retention only keeps records from the point
where the service began recording them under the right setup.
It cannot go back in time and create events
that were never kept.
So if you decide in June that you need five years
of audit history, you can't recover four missing years
from the past.
Your retention plan needs to exist before the incident.
Start with your business needs.
Ask which users create the most risk
if their accounts are misused.
Ask which workloads hold sensitive information.
Then check the rules that apply
to your industry, contracts, and internal policies.
Keep records longer where there is a clear reason.
Even the best audit record fails
if nobody can search it safely, understand it,
or act on what they find.
Starts more, then build a process
your people can follow when the pressure is on.
A simple audit plan for your organization.
A useful audit plan starts before anyone reports a problem.
First, make sure audit is enabled,
then confirm that records are actually arriving.
Don't assume a setting exists
because someone turned it on years ago.
Run a simple search and check that recent activity appears.
That small check can save a difficult conversation later.
Next, separate the jobs.
An audit reader searches records and reviews the results.
An audit manager handles the settings, retention policies,
and the wider care of the audit service.
Those roles don't need to sit with the same person.
In fact, separating them often gives you better control.
The person who searches a record
doesn't always need the power to change
how long that record stays in the system.
Sensitive cases need another boundary.
E-discovery case access should stay separate
from general audit access.
A person may need to confirm that a file was shared
without needing permission to open a legal case
or review private documents.
Give people the access their work requires and no more.
Then write down the questions your organization needs to answer.
Keep the list practical.
Can we see who shared or accessed a file?
Can we investigate mailbox and sign in activity
when an account looks unusual?
Can we confirm who changed a policy?
Can we trace a data loss prevention event
back to the action that triggered it?
These questions give your team a starting point
when they build searches, choose retention periods
and write incident plans.
Without them, audit can turn into a large tool
that nobody feels confident using.
Retention needs the same clear thinking.
Don't keep everything forever just because you can.
More records can also mean more sensitive data
for your organization to protect and manage.
Look at your legal duties, contracts, industry rules
and internal policies.
Then decide what you need to keep for how long and why.
Start with the areas where a missing record would hurt most.
Finance may handle payment details and forecasts.
HR may handle employee information.
Administrators can change settings that affect the whole company.
Those teams and workloads give you a focused place to begin.
You can expand later when you understand
what your organization needs.
Now test the process before it becomes urgent.
Set up a safe practice investigation.
Have someone share a test file.
Change a test mailbox rule.
Download a test document from a controlled location.
Edit a test policy.
Then ask your team to find the action in audit.
This isn't about catching anyone out.
It's about finding gaps while there is no real incident.
Maybe the search is too broad.
Maybe the wrong people have access.
Maybe the team can find the event,
but doesn't know what to do next.
And boom, you found something useful before it costs you.
For every real investigation,
keep a simple record of the work.
Write the search name.
Record the scope, the reason for the search
and the person responsible.
If you export results, note what was exported,
who received it and where it is stored.
That record helps the next person understand the case.
It also helps your organization show
that it handled sensitive information carefully.
Audit rarely works alone.
A security alert in Defender may lead your team to an audit search,
and inside a risk case may need audit events to add context.
Any discovery case may need the content connected
to an action you found in audit.
Build those handoffs into your process early.
Decide who owns the first review
when a case moves to another team
and who can approve the next step.
The common mistake is waiting until something goes wrong.
At that point, people are under pressure.
Names and dates aren't clear,
and everyone wants answers immediately.
A tested process changes that.
Your team can begin with a known search,
a known owner and a timeline that is already there.
Perview audit can't decide whether an action
was harmless, accidental or deliberate.
Your people still need to make that call.
It gives them a record to work from.
Perview audit takes all the scattered activity
across Microsoft 365 and turns it into a searchable log,
so you can see who did what and when.
First, check if audit is enabled,
then run a focused search for a file, a user,
or a policy action you already know.
You're not looking for a crisis.
You're just confirming the record exists.
Next, figure out where audit fits with eDiscovery,
compliance manager and insider risk.
When a question comes in,
every team should know exactly where to start
and where to go next.
I'm Mirko Peters from M365 FM.
Subscribe on your favorite podcast platform
and share this knowledge nugget
with someone building their Microsoft 365 Compliance Foundation.