Your SIEM Is Missing Critical M365 Logs

Ever wonder why your SIEM dashboards are telling only half the
story on Microsoft 365 activity? You're not alone. The truth is,
most out-of-the-box configurations miss critical M365 audit
logs—leaving risky blind spots. Today, I'll show you exactly
which logs Sentinel, Splunk, and others are skipping, why that
matters, and how to truly close the gap.Stick around if you want
your security monitoring to move beyond check-the-box compliance
toward real, data-driven protection. Let’s make sure your SIEM
finally sees what actually matters.


Why Your SIEM Still Misses the Big Picture


If you’ve ever pulled up Sentinel or Splunk expecting to see who
accessed a critical file in SharePoint, you’re probably familiar
with that sinking feeling when the dashboard has nothing. It’s
not just you—almost every admin I’ve talked to assumes that once
they connect Microsoft 365 to their SIEM, they’re set. The
checklists in the documentation say the connector is active, you
get a handful of logs starting to trickle in, and it’s easy to
feel like the hard part’s over. The reality? That first
integration barely covers the basics, and a pile of your most
important events never makes it into your SIEM at all.Let’s say
you’re asked to produce a timeline of mailbox activity for a
sensitive user. Or your boss wants to know who shared a
confidential folder in Teams two weeks ago. The expectation is
your SIEM should have this, right? Nine times out of ten, you’re
left scrambling when your own dashboards come up blank. That
moment when you realize you’re missing key info—especially when
leadership is watching—doesn’t get less painful with
experience.Here’s why this happens. Those default connectors, the
ones marketed as “plug-and-play” for Microsoft 365, turn out to
be a lot more limited than most people realize. Out of the box,
most SIEM integrations grab a thin layer of generic activity, but
miss entire categories of logs that matter most during an
incident. Think about Exchange mailbox auditing—actions like
“mailbox accessed by someone other than the owner” or “mail
forwarding rule created” are bread-and-butter audit events for
any real investigation. Yet, unless you’ve explicitly enabled
mailbox auditing (and shelled out for premium licenses), those
events just don’t show up.And it isn’t just email. SharePoint
file access, Teams chat deletions, and especially Power Platform
activity—the stuff that attackers target when they move
laterally—often stay in the dark. You might see user logins or
“file modified” totals, but not the details. The difference? One
tells you something suspicious happened. The other gives you
enough facts to actually respond.Let’s get concrete. I’ve worked
with a security team that was dead certain their SIEM would help
during a potential data leak investigation in Teams. Someone had
shared a sensitive financial document externally. Everyone felt
confident until the SIEM had nothing more than a “file shared”
record, missing details like who the recipient was, whether the
link required authentication, or if additional downloads
occurred. Only by logging directly into the Compliance
Center—separately from their SIEM—could they reconstruct any kind
of useful story. That lag cost them hours and made their report
look amateur. Unfortunately, it wasn’t a one-off. These kinds of
gaps crop up everywhere, especially if you’re not checking
connector documentation week after week.So, what actually governs
which logs appear in your SIEM? A lot of it depends on
Microsoft’s own auditing defaults and the version of Microsoft
365 you own. Basic audit logging, which is included with most
subscriptions, captures only a slice of workload activity. Need
mailbox details or sensitivity label events? Get ready to talk to
finance about E5 or at least buy an advanced compliance add-on.
Even then, not everything’s covered—some logs only flow via
special APIs or need extra configuration. On top of that,
Microsoft throttles API requests or batches logs, introducing
delays or rate limits that make real-time investigation
impossible at times.SIEM vendors add their own wrinkles here.
Some connectors only support certain APIs or log schemas, so
you’ll see Defender alerts but not granular mailbox events.
Others drop categories like Power Automate runtime details, which
attackers are increasingly relying on for quiet lateral movement
and exfiltration. Microsoft’s own footnotes admit this if you
read between the lines. I’ve run into documentation notes buried
at the bottom that say things like “export of certain Exchange
logs only available for E5 customers” or “SharePoint sharing
events require advanced audit.” Even seasoned admins get caught
off guard here—the fine print is relentless.There’s also the
constant issue of API volume and throttling. Microsoft 365
generates millions of records, especially in busy organizations.
SIEM connectors have to balance between pulling
everything—risking cost and performance—or skipping
“low-priority” logs based on size and frequency. The loser in
that tradeoff? You, when you need the details after an
incident.It all adds up to a messy, incomplete picture. Most
organizations, even ones with mature security teams, are missing
at least 30% of actionable M365 events in their SIEM—sometimes a
lot more. These are the exact areas where attackers love to hide,
knowing those actions are less likely to trigger alerts. It’s a
weird loophole where you feel secure because your SIEM is
“connected,” but the most dangerous activity still slips
through.If you actually want to close those gaps, it isn’t as
simple as just flipping another switch in the admin center. The
questions start piling up. How much will the extra logging cost?
Can your SIEM even handle the volume? Are you about to blow up
your licensing budget just to see who did what in a shared
mailbox? The price tag—both in licensing and in tech—starts to
get real, fast. So, what does it really take to pull in the right
logs and get true visibility? The real story might surprise you.


The True Cost of Complete Visibility


Picture this: you finally do it. Every M365 audit log rolls into
your SIEM, just like the security blogs suggest. Log for log,
you’re pulling in mailbox auditing, every single SharePoint file
event, Teams message edits, and enough Power Automate activity to
make anyone’s eyes glaze over. You tell the security team you’ll
catch anything that moves. And then—almost on cue—the finance
team walks past your desk, waving a storage bill that somehow
rivals your entire O365 subscription. That’s the moment plenty of
security projects hit an unexpected pause. Full visibility, it
turns out, isn’t free. In fact, most folks underestimate just how
quickly log volume—and raw cost—spikes once you start letting
everything through the front door.Here’s where things get almost
comical. Most admins start their M365 SIEM journey using
whatever’s included “for free”—the default audit log connector,
sometimes a bit of Defender alert forwarding. You dip your toes
in and see a manageable trickle of events. But that’s just
surface level. The minute you need granular event details—mailbox
auditing, confidential SharePoint sharing, or Data Loss
Prevention (DLP) events—the magic words show up in Microsoft’s
documentation: “Requires E5 or advanced compliance add-on.” It’s
easy to overlook until you realize E5 licensing doubles or even
triples the per-user cost for audit coverage. Even then, that’s
just the M365 side of things. The minute these logs hit your
SIEM, every vendor has its own take on billing. Sentinel, Splunk,
QRadar—they’ll all charge for every gigabyte they ingest, and
sometimes for how long you post-process or store those logs. It’s
not unusual to watch SIEM costs go from a footnote to line item
number one on your IT budget.Let’s talk real numbers for a
minute. I worked with a midsize org—two thousand seats, mostly
frontline, but a vocal finance and legal team. They’d always
skipped Exchange mailbox auditing, thinking it was overkill. A
new compliance push changed that. They flipped on unified audit
log ingestion into Sentinel. Within a month, their Sentinel bill
had doubled. They were shocked, so we dove in. Turned out,
mailbox logs churned out page after page of duplicated event
records—one log for the user, one for the delegate, one for every
folder touched in a multi-folder mailbox view. On top of that,
SharePoint events kept firing for background sync jobs, automated
document saves, and compliance scans—events with about as much
security value as a printer notification. When Teams and
SharePoint usage spiked (annual budget season always does it),
the logs came in faster than anyone could make sense of. No one
had modeled out the spike in volume or factored in duplicates, so
overnight, the SIEM bill was the surprise of the year. SIEM
vendors are happy, but security teams often end up doing triage,
figuring out how much log noise they can afford while still
covering their regulatory obligations.For a lot of admins, the
shock isn’t just quantity—it’s relevance. Not every log helps
during an investigation, and parsing every message just
introduces noise. The more logs you have, the slower queries get,
and the more likely important signals drown in routine activity.
Trying to chase every single Teams reply or SharePoint folder
access isn’t just expensive, it’s also a recipe for alert fatigue
and slow response when something actually matters.So, what do the
pros do? They break down expected log volume ahead of time. Most
SIEMs let you preview how much data each log type generates. You
can estimate storage requirements for a typical month, then
double that for periods when audits or incidents hit. Planners
now start every new logging request with a data model: what
categories actually yield security outcomes, and what’s just
digital dust? For mailbox auditing, you might only need access by
non-owners or changes to forwarding rules—those actually signal
risk. With SharePoint, external sharing events or new anonymous
links matter more than routine version saves. It’s not just about
collecting everything, but making each log entry work for you.To
keep the cost in check, smart organizations filter
upstream—usually before ingestion. They use ingestion filters,
block duplicate categories, or set up event enrichment so only
the most informative logs even land in the SIEM. Some will sample
noncritical logs during peak times or shift “nice to have” events
to cold storage, out of the main dashboard. Others map out what
they need for compliance (think SOX or GDPR) and treat the rest
as optional, maybe pushing it to secondary analytics systems with
cheaper storage per gigabyte. All this thinking isn’t just
penny-pinching: it unlocks the upside of good logging without
turning your SIEM into a money pit.The best part is, a little
strategic filtering can lower SIEM spending by about forty
percent—but you don’t lose sight of what matters most. Instead,
your team spends less time clicking through duplicates and more
time spotting actual threats. You get to keep all the signals
worth investigating, drop the noise, and earn points with finance
for trimming fat nobody misses.Of course, all this log triage
only works when your logging pipeline can keep up. Collecting and
storing the right logs is nice in theory, but if the architecture
falls over, you’re still stuck in the dark. So, what does it look
like to actually build a logging pipeline that’s robust, scales
with demand, and avoids the most common SIEM pain points?


Building a Resilient M365 Logging Pipeline


So, you know the costs now, but the big hurdle is actually
getting meaningful, usable logs where they need to be, when you
need them. And that’s where most environments stumble—not because
teams are lazy or uninformed, but because connecting M365 to a
SIEM feels deceptively simple. You set up a connector, enter some
API details, and you’re rewarded with a dashboard that shows data
flowing in. But those dashboards often hide headaches from the
folks who will need to put these logs to use. The tech promises a
straight line from cloud to SIEM, but the real world keeps
throwing wrenches into the gears.The first bottleneck comes the
minute you go beyond basic integration. Pulling all types of
audit logs from Microsoft 365 to your SIEM means wrestling with
API throughput limits, understanding when data is batched or
delayed, and living with the dreaded “throttled request” message.
Organizations usually pick one of a few routes: direct API pulls,
routing logs through Azure Event Hub, or using a third-party
cloud collector. Each choice brings its own flavor of pain.
Pulling direct from the API seems clean but will bump you into
limits fast, especially if you’re chasing high-frequency sources
or want long retention. Event Hub is more durable but adds
complexity—now you’re maintaining another Azure resource,
handling access controls, and watching for message loss if your
pipeline ever slows down or breaks. Third-party collectors often
claim to simplify things, but they aren’t immune to rate limits
and can introduce their own parsing quirks. Choosing between
these comes down to how much control you want over timing,
format, and resilience if something goes sideways.Parsing is the
next landmine. Microsoft 365 logs aren’t universally
structured—Teams, SharePoint, Exchange, and Power Platform each
have their own schema, field names, and “gotchas.” So, unless
you’re normalizing logs as they come in, your alerts will be
inconsistent. One org I know piped everything into Splunk
assuming their default parser could handle whatever Microsoft
threw at them. Within weeks, their dashboards were a noisy mess:
field mappings broke with schema updates, mailbox audit logs came
through missing “actor” information, and critical DLP events
showed up as gibberish in the main timeline. The amount of manual
clean-up post-incident ended up being bigger than the original
integration project. And that’s common. If parsing rules lag
behind Microsoft’s constant tweaks, you end up with alerts that
mean nothing, or—worse—miss truly risky actions because they
didn’t map to the expected field.Then comes retention. Few topics
stir up as much internal debate as how long to keep these logs
and where to store them. Too short, and your compliance or legal
teams throw a fit during audit season—“where’s the two-year
mailbox access log our regulator wants?” Too long, and not only
does your storage bill balloon, but you could be running afoul of
regulations like GDPR, which gives users the right to erasure.
Some orgs rush to keep everything “just in case,” but get caught
out when privacy or data residency rules change. Others go the
opposite way, keeping only thirty days of security logs to avoid
costs, and find out the hard way that a dormant threat actor only
tripped their sensors after sixty. The best-run teams figure out
exactly which logs must be kept for each regulation—GDPR, SEC,
regional data sovereignty—and assign specific retention periods
and storage tiers. These settings get documented and revisited
before the next big change in law or Microsoft licensing.But
maintaining a good pipeline isn’t just about initial choices—it’s
about building in review and automation. Good teams automate log
cleansing: scripts that weed out obvious noise, roll up duplicate
events, or flag malformed records before they ever reach the SIEM
proper. Validation jobs spot-check event completeness daily so
you don’t get a nasty surprise at three a.m. during an incident.
When something breaks—API limits, Event Hub outages, weird schema
changes—alerts hit the right Slack channel, so you’re not left
hoping someone happens to notice the gap. Even quarterly, sharp
organizations hold parsing and retention reviews, checking if new
M365 features are generating valuable logs, or if a recent
incident points to a missing field or overlooked source. These
adjustments aren’t just busywork. One financial org started
holding quarterly reviews after an incident where a single missed
log category cost them three days of investigation time. After
tuning their pipeline, they slashed future incident timelines and
found new patterns earlier.What all this adds up to is pretty
straightforward: the real value of your M365 audit logs
multiplies when your pipeline stays healthy, current, and tuned
to what matters. Clean, parse, and enrich logs early so alerts
make sense. Automate the sanity checks so you never fly blind.
Review retention and parsing regularly so you’re ready for the
next compliance curveball or workflow change. An investment here
repays itself when investigations run faster, alerts surface real
issues, and you actually know what’s happening in your
environment. Of course, even the best logging pipeline falls
short if your SIEM isn’t doing something useful with the logs—so
let’s turn our focus to what actually happens once those logs
land: the last mile, where integration choices and alert rules
shape whether any of this work pays off in real security insight.


Closing the Gaps: From Integration to Real Security Insights


Plugging Microsoft 365 into your SIEM and seeing data light up on
the dashboard feels like a win, but that part is just the
handshake. What matters is what happens after the logs land in
your SIEM. Nobody brings this up during kickoff calls, but here’s
the reality: default SIEM rules, especially for cloud workloads,
are notoriously bland. They’re designed as templates—enough to
meet compliance checklists but rarely deep enough to alert you to
how attackers actually move in a modern Microsoft 365 tenant.
Most environments, by default, will pick up brute force login
attempts or maybe the odd “impossible travel” event. But
attackers who know what they’re doing avoid the obvious, using
mailbox forwarding rules, subtly escalating permissions, or
quietly sharing Teams documents with just enough ambiguity to
stay off radar.Let’s look at where those SIEM integrations so
often fall flat. The first pitfall is assuming your connector
maps events and fields correctly out of the gate. For Sentinel,
you’ll get the core OfficeActivity table, but out-of-the-box
mapping might call a mailbox access event a generic “user
action.” If you don’t crack open the normalization process,
you’re left guessing whether a logon to a VIP mailbox was
legitimate or risky. Similarly, with Splunk, a common move is to
dump all M365 JSON into a central index, then trust the default
field extractions. Without tuning, mailbox rules show up with
cryptic names, SharePoint external sharing is just a wall of
audit events, and Power Automate tracking gets lost in
translation. The result? SOC analysts need a secret decoder ring
to diagnose even the simplest incident.That’s why successful
teams go beyond “connect and forget.” They dive back into field
mapping, making sure key M365 actions—mailbox delegate access,
sharing to external users, Power Platform flow creation—are
consistently parsed, labeled, and easy to query. In Sentinel,
that can mean customizing the OfficeActivity parser to surface
critical mailbox operations as their own columns, rather than
burying them in a generic field. Splunk admins write custom
regular expressions or update sourcetypes, so an Exchange
“Add-MailboxPermission” stands out as a discrete event and not
just part of a noisy JSON blob. Nobody loves tuning parsers, but
it makes a real difference when you’re chasing down an
incident.Then there’s the auditing layer itself. Out of the box,
most tenants don’t have advanced auditing enabled. Power users in
M365 might have some mailbox audit events captured, but until you
flip on advanced auditing—and confirm you’re licensed for
it—you’ll miss non-owner access to mailboxes, detection of
forwarding rule abuse, and every Power Automate run. Sentinel and
Splunk both let you pull these logs, but only if they exist in
the first place. Organizations with frequent personnel changes or
sensitive data pipelines are usually first to notice these gaps.
They launch a post-incident review and realize their SIEM
reported nothing because M365 never produced the relevant log
entry. The fix isn’t just enabling a checkbox; it often means
paying for E5, then auditing configuration drift to make sure
those logs stay enabled across every mailbox and workload.After
logging and parsing, you land at detection—the part where SIEM
rules either let you down or save the day. Most default rules
look for high-volume stuff: risky logins, mass deletions, changes
in role membership. But actual threats in M365 often look like
routine activity to these rules. Take mailbox forwarding: a
single, subtle rule can exfiltrate every C-level email, but if
your detection only fires on mass mailbox exports, you’ll miss it
until it shows up in a data loss review months later. Or think
about Power Platform misuse—a spike in flows from a single user
might mean someone’s automating data theft, but without a custom
rule tuned to normal versus abnormal usage, that noise never
triggers an alert. Smart teams develop correlation rules that
span activities: for instance, linking an account email
forwarding setup with elevation of access in the same hour for
that user. These rules don’t ship with your SIEM—you write and
refine them yourself.It’s easy to miss the need for enrichment,
too. Audit logs by themselves are often thin—sure, you know a
file was shared externally, but who’s the external recipient? Is
that user on your allowlist? Are they even in your CRM? Without
pulling in HR or identity context, alerts lack enough information
for fast triage. This is one reason why attackers can blend into
normal collaboration; the SIEM never links the dots unless you
tell it how.One story that sticks with me: a security team in
healthcare was sure they had Power Platform covered, because all
flow creation events were logging to Sentinel. During a periodic
SIEM rule review, someone noticed repeated spikes in flows from
accounts in the HR department at odd hours. Once they wrote a
custom rule—“alert if flows increase 300% for any user in a
single day”—they caught a contractor using Power Automate to
exfiltrate protected data. None of the preset rules even blinked.
It wasn’t a technical limitation; it was just a gap in alert
design and regular review that kept the threat invisible until
someone got curious.This brings us to ongoing maintenance—the
unglamorous but critical process of making SIEM work long-term.
Microsoft keeps tweaking log schemas, adding or renaming fields,
and moving auditing features behind new licenses or permission
gates. If you aren’t reviewing parser updates monthly and
confirming your alerts still trigger, you’ll fall behind and miss
emerging attacks or lose compliance coverage. Teams that treat
parser and rule review as a quarterly task—especially after a
Microsoft 365 roadmap update—find and fix issues before they
become breaches. These regular tune-ups keep your investment
relevant and your team confident that no change has left you
blind.After all, the point of hauling all these logs into your
SIEM isn’t just to check a compliance box. Constant review,
enrichment, and homemade rules are what turn your M365 audit logs
from a mountain of paperwork into real, actionable insight. When
it’s done right, you catch the next attack hiding in the
seams—before it becomes tomorrow’s incident headline. So if
you’re ready to finally see the whole picture, making these
adjustments is how you make your SIEM actually deliver on its
promise.


Conclusion


If you’re relying on default settings, your M365 audit logs
aren’t telling you the whole story—and your SIEM isn’t actually
helping you defend what matters. The real difference between
basic compliance and real security is understanding those blind
spots and doing the work to close them. That’s not just about
collecting more logs; it’s about knowing what each workload needs
and keeping your integrations up to date. So, dig into your own
setup, check for those hidden gaps, and figure out where things
might be falling short. Drop a comment with your biggest
Microsoft 365 monitoring question—let’s tackle it together.


Get full access to M365 Show - Microsoft 365 Digital Workplace
Daily at m365.show/subscribe