Most Microsoft 365 teams put enormous effort into passing regulatory audits – then relax the moment the report lands. However, as Mark Cravotta explains the real risk is that your tenant keeps changing every day, while your “compliance” story is frozen in time.
Inside this article:
Most enterprises treat regulatory audits as annual finish lines, not as evidence that they genuinely control what’s happening inside Microsoft 365 (M365). Auditors typically assess policies and narratives at a high level, but lack the deep M365 context to probe configuration drift, privilege creep, and day‑to‑day change in the tenant where much of the real risk lives. As a result, organizations can “pass the audit” while their control environment is effectively unmanaged – self‑service sprawl, opaque changes, over‑privileged accounts, and no realistic way to rebuild the tenant after a major configuration incident.
A more meaningful M365 compliance posture looks very different: you define and maintain a baseline aligned to CIS and international standards, continuously detect and remediate drift, treat joiner/mover/leaver activity as core security events, and build a living evidence trail of changes, approvals, and access over time. SIEM logs and annual access reviews aren’t enough; you need ongoing visibility into baseline, drift, change, access, and configuration resilience so executive leadership can credibly say, “We’re not just compliant on paper – we’re in control of the tenant every day.”
In this article, Mark Cravotta argues that traditional regulatory audits rarely reflect the real, fast‑moving risk inside your M365 tenant, and that true compliance requires continuous control over baseline, drift, change, access, and configuration resilience – not just a clean report once a year.
If you look at most enterprises using Microsoft 365 (M365) – large commercial organizations, mid‑market, state and local government – they all have to hit similar regulatory standards. SOC 2 and ISO 27001 being the most prominent. Someone in the organization owns that responsibility. They manage the quality system, the audits, the cadence of meetings, the evidence collection, and the incident clean‑up during the audit period. They do that work, they pass the audit, and they move on.
From what I see in the field, that’s where the real problem starts.
Most organizations don’t aspire to be “the most compliant company in the world.” They want to be compliant to their standard and make sure they pass the audit each year. They want the process to be smooth, especially if they operate in highly regulated industries where fines and liability come into play – healthcare with patient information, EMEA organizations under GDPR, anyone handling sensitive personal data. They’re looking to stay out of trouble and make sure the system doesn’t get them into an obvious data breach. The bar, for many, is “don’t get burned,” not “really understand and control the environment.”
On paper, SOC 2 and ISO 27001 should help you get there. The AICPA common criteria for SOC 2 start with the control environment and move through communication, risk assessment, monitoring, and the rest. ISO is built on the spirit of the same NIST fundamentals with some added focus on people and technology controls. In theory, those frameworks should force you to look hard at what’s happening inside your M365 tenant.
In practice, they often don’t – because the auditors themselves usually don’t have deep Microsoft expertise.
They’re auditing at a high level. They’re excellent at asking, “Tell us how you do it. Map it to our standard. Prove you’re doing what you said.” They’re much weaker when it comes to asking, “Show me how you actually control configuration drift in your M365 tenant,” or “Walk me through how you know who changed what last week and under whose authority.” They don’t live in the tenant. They don’t see the pitfalls: the constant change, the self‑service sprawl, the lack of central visibility.
So, you end up with an audit that validates your narrative about compliance without really touching the operational reality inside M365. You pass, but you may still have no meaningful control over the place where a huge chunk of your risk lives.
SOC 2 starts with the control environment, and for M365 that’s your tenant. The control environment isn’t an abstract concept; it’s the sum of all the configurations, policies, and permissions that shape your security posture.
To be genuinely compliant in a way that matters, you’d want to:
What I see in most organizations is the opposite. The M365 environment is effectively unmanaged as a control environment. It changes every day. Self‑service is everywhere. In multi‑tenant setups, central control is even weaker. Nobody has a clean, unified view of what changed, who changed it, or whether it was approved. The environment is not static; it is a living system that most organizations only touch when something breaks or when the auditor is coming.
From an audit standpoint, that might not immediately trigger a failure, especially if you can speak confidently about policies and procedures. But from a maturity standpoint, this is where compliance falls down. If the auditor doesn’t know enough about M365 to probe deeply, they won’t hold you to a standard that reflects your real risk. You can hit the minimum bar and still be blind to substantial gaps in your control environment.
A lot of organizations treat “evidence” as something they scramble to assemble once a year. In the run‑up to an audit, teams pull reports, take screenshots, chase down approval emails, and try to reconstruct what happened in the tenant over the last period. It’s a huge amount of work, and it often exposes issues the business wasn’t aware of until someone had to go digging.
If I were building evidence to support a meaningful SOC 2 or ISO story, I’d think about it very differently.
Real evidence in M365 should look like an ongoing narrative: here’s our baseline configuration, here’s how it maps to recognized standards like CIS and international best practice, here’s how we detect drift from that baseline, here’s the sequence of changes and approvals, and here’s how we remediate and close the loop. It should show that you have control over the environment, not just that you can talk about control.
That includes being able to demonstrate least privilege, show how you manage joiners, movers, and leavers, and confirm that you’re enforcing and revoking privilege when it’s no longer needed. It includes clear logging of changes, visible workflows around change management, and a remediation trail that makes sense to anyone who reads it. That’s an evidence pack; it’s not a folder of screenshots pulled together the week before the auditor arrives.
Monitoring is one of the most misunderstood parts of the whole picture.
Many organizations proudly tell auditors they have a Security Information and Event Management (SIEM) system. They send logs from M365 and other systems into the SIEM. On paper, that sounds impressive. They can say, “We log everything.”
But when you ask how much of that log data anybody actually looks at, the answer is is that they can’t possibly consume that data in a meaningful way without automation.
Thousands, sometimes millions, of events are collected. They flow into the SIEM and sit there. The organization has the comfort of knowing, “We logged it,” but there’s no practical monitoring. Nobody is actively analyzing those logs in a structured way. There’s no defined path from a risky event to a clear decision. The logs become like a storage unit you rented five years ago. You know there’s stuff in there; but you have no idea what it is.
Are they “monitoring” in the strict sense that logs exist? Yes. Are they proactive? No. Do they reliably react to signals of risk? Usually only when there’s a big, visible incident.
For M365, where configuration changes, privilege changes, and data access patterns matter as much as sign‑in events, that kind of passive logging doesn’t meet the spirit of monitoring.
Change management is another area where the narrative and the reality diverge.
On paper, a solid change process in M365 has a simple structure: you plan the change, you get it approved, you implement it, and you verify it was done correctly. That aligns nicely with SOC and ISO expectations around operations.
In day‑to‑day life, that’s not what most organizations are doing. There might be a formal process for large, high‑profile projects, but the countless minor configuration changes that happen every week don’t go through any real workflow. People make changes to “get something done,” often without written plans or explicit approvals. Sometimes they take more authority than they should. Nobody circles back to check whether the change had unintended consequences.
Those “little gotchas” in change management are exactly what data breaches are made of. It’s rarely the grand strategic initiative that exposes you; it’s the quietly misconfigured setting or the over‑permissive policy someone created three months ago and forgot about.
From a SOC auditor’s perspective, you might not fail simply because you don’t have every minor change approved. But it introduces uncertainty in the findings and leaves you exposed in ways the audit doesn’t surface. Again, the audit is a minimum bar. It’s not a guarantee of operational safety.
Access control is one of the most common problem areas I see, and audits bring it into sharp focus.
Before an audit, there’s always a flurry of activity around access reviews. People run reports and start asking the hard questions: do we really manage least privilege? Who actually has what? What did we do when people left the organization?
Almost every time, this process uncovers the same story. Somewhere in the environment, an employee who was terminated six months ago still has access. Someone who moved roles a year ago never had their old access removed. A group was created for a temporary project and never cleaned up.
When that happens, you don’t just have an embarrassing moment with the auditor. You have hard proof that you don’t have the control you thought you had. The process that was supposed to enforce least privilege and secure deprovisioning isn’t working in practice.
The deeper issue is that joiners, movers, and leavers are treated as administrative checklists rather than core security and compliance events. New hires are often given more access than they need. People accumulate rights as they move through the organization. Departing staff get partially deprovisioned, but not completely. Then the audit reveals the gaps.
If you want to get serious about compliance in M365, you have to move these lifecycle events right into the center of your control model. They need repeatable workflows, automation where it makes sense, and clear evidence of when access was granted, changed, and revoked.
When we talk about business continuity in M365, most of the conversation focuses on data: email, files, Teams content. Those are important, but there’s a piece that doesn’t get nearly enough attention – the configuration of the tenant itself.
I make a simple point when I talk to customers: if you don’t have something like CoreView, you don’t really have a backup of your tenant configuration. If a major incident or mistake significantly alters that environment, you’re looking at manually rebuilding tens of thousands of settings. Doing that over three or four weeks, from memory or scattered notes, and expecting to get everything right is unrealistic. You will lose something on the way back.
That’s not just a technical inconvenience; it’s a business continuity problem. It should be near the top of the risk list. Yet most audits don’t push hard on this area, and many organizations don’t push themselves on it either, mostly due to lack of awareness of the challenge.
There’s also a cultural gap.
In many enterprises, the person responsible for compliance attends a security briefing once a month. It’s a 20‑minute session. Someone presents a report. The compliance lead gets enough to respond to auditors, but they’re not truly embedded in the operational reality of the Microsoft 365 tenant.
At the same time, most management teams – CEOs, CIOs, CISOs – are largely in the dark about the specific risks inside the tenant. They know they’re “compliant” to a standard because they have the report. They don’t know, in any concrete way, how much over‑privilege exists, how change is really managed, or how quickly they could recover from a major configuration incident.
Without the kind of surveillance and insight I’m describing – baseline, drift, change, and access evidence – most management teams are oblivious to the true level of risk they carry in M365. They’re trying to comply with a high‑level standard. It’s not enough.
If I were a CEO, I’d want something different. I’d want to say, “Make sure we’re not breached. Make sure we don’t have major gaps in business continuity. Come back and tell me how you were able to come to that assurance.” When leadership gets to that point, the conversation usually changes. That’s when they start saying, “We’re going to need some tools for that.”
I’ve kept this discussion focused on what I see going wrong across organizations, not on products. But once you decide you want your compliance story to match your operational reality in M365, you’re going to look for ways to make that practical.
You’ll need help to:
That’s the space where CoreView operates. We help you understand and control what’s happening inside your Microsoft 365 tenant, not just who gets in. We give you the baseline and drift visibility, the workflows, the access and change evidence, and the configuration safety net you need to make your SOC 2 or ISO story match the real state of your environment.
If the article made you question whether “passing the audit” is really enough, the next step is to ask yourself a harder question: how will you prove, continuously, that you’re in control of what’s happening inside your Microsoft 365 tenant – not just once a year, but every day?
When you’re ready to answer that, you’ll know where to start.
