Episode Details

You’ve spent months building a secure M365 environment, but one click can open the door to your entire document library. Frustrated by blind spots in SharePoint and OneDrive sharing?We’ll walk through a practical framework—policies, scripts, alerts—that lets you finally see and control what’s leaving your tenant, even at massive scale.Why Your Audit Settings Might Be Lying to YouIf you’ve ever opened your audit logs and felt a quiet sense of relief, thinking everything is covered—there’s a good chance you’re missing some of the biggest gaps. Most admins tick the auditing box in the compliance center and assume job done. They set the policy, see “audit log search enabled,” and move on. But Microsoft 365, especially SharePoint and OneDrive, hides a lot of nuance under those options. The default settings feel comprehensive, but the cracks show up at the worst possible times—like months into a sharing fiasco, when everyone is digging through logs and realizing half the story isn’t even there.Let’s take one scenario that comes up more often than we’d like. Imagine your finance team needs to work with an external consultant on a set of sensitive budgets. The SharePoint site owner shares a folder, makes it easy for the consultant with a guest link, and gets back to business as usual. Fast forward a few months—the consultant’s project finishes, and suddenly there’s an audit. The finance lead wants to know exactly what got shared, when, and with whom. You open the audit logs and…find nothing useful. No entries tracking when that folder link was created, no logs showing access or downloads. The environment looked secure, but the actual audit trail? Like Swiss cheese, more holes than data.Here’s the part that catches people out: Microsoft’s default audit policies are optimized for performance, not completeness. The documentation buries this point, but if you go digging through recent admin guides, you’ll notice that standard audit logs can miss entire categories of sharing actions. This is especially true for anonymous or guest access links. Any auditor who’s been burned by missing entries—like for “SharePoint external sharing invitation created” or “OneDrive anonymous link used”—knows the pain of scrambling to rebuild what happened after the fact.We’ve worked with organizations where the official stance was, “We’re secure, we have auditing.” Then, during a compliance review—maybe after a legal hold was triggered—someone tries to track back an external share. Instead of clear logs, they find entire gaps. During a recent legal review for a healthcare org, legal counsel pulled up the audit log to find out who accessed protected health info via a guest link. The entries stopped right before things really went off the rails. The project had to pause, teams went scrambling, and, worst of all, no one could say for sure what left the building and what stayed internal. It’s exactly this kind of uncertainty that puts compliance projects at risk and sends everyone into damage control mode.If you want a visual, picture two screens side by side. On the left: an environment running Microsoft’s out-of-the-box audit policies. The list of sharing events looks reassuring at first—until you notice the missing records for guest link creation, file previewing by external users, or cases where links were forwarded inside a thread. On the right: the same site, but audit logs are configured with advanced settings—catching not only who shared what but exactly how those links behaved after the fact. External accesses show up with timestamps, the types of links are noted, and even which files were accessed through a chain of guest forwards. You don’t just have a log—you have a map of what really happened.So why does this keep happening? For most environments, three audit policy settings don’t get touched during rollout. First, you need to explicitly enable enhanced auditing for SharePoint and OneDrive, which often means using PowerShell to set policy at the organ