Microsoft Purview Audit - Simply Explained

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.