Why Internal IT Teams Alone Are Not Enough
Most defense contractors and federal agencies running Microsoft 365 believe their internal IT team has the environment locked down. Policies are in place, licenses are purchased, and the Secure Score looks reasonable. What they do not realize is that a well-configured tenant and a compliant tenant are two entirely different things.
A Microsoft 365 compliance assessment conducted by an outside specialist consistently surfaces findings that internal teams miss—not because those teams lack technical skill, but because compliance requires a different lens. Internal IT professionals are trained to keep systems running. Compliance assessors are trained to find every gap that a CMMC auditor, OCR investigator, or contracting officer would flag.
Here are the five findings that come up most often when we conduct these assessments at Cleared Systems—and what each one means for your organization's risk posture.
1. Tenant Type Mismatch: You Are in the Wrong Cloud
This is the most consequential finding we encounter, and it surprises executives every time. Organizations handling Controlled Unclassified Information (CUI) under DFARS 252.204-7012, CMMC Level 2, or ITAR are often running on commercial Microsoft 365 or even Microsoft 365 GCC—when their regulatory obligations require GCC High.
Commercial and GCC tenants do not meet the data residency, personnel screening, or sovereignty requirements that federal regulations demand for CUI. Microsoft 365 GCC High is built on infrastructure that restricts access to screened U.S. persons and meets FedRAMP High and DoD IL4 baselines. Running CUI in the wrong tenant is not a configuration problem you can patch—it is a structural compliance failure that requires migration.
Internal IT teams often select the tenant during initial setup based on cost or familiarity, without a regulatory analysis. A proper IT compliance services engagement maps your data classification requirements to the correct Microsoft cloud environment before a single control is evaluated.
If you are unsure whether your current tenant type aligns with your contract requirements, our post on CUI in Microsoft 365 and tenant type requirements is a useful starting point.
2. Data Loss Prevention Policies That Exist on Paper but Not in Practice
Nearly every organization we assess has some form of Data Loss Prevention configured in Microsoft Purview. Nearly every one of those configurations has significant gaps. The most common problems we find include:
- DLP policies set to audit mode rather than enforcement mode, meaning sensitive data is being tracked but not actually blocked
- Policies that cover email but miss SharePoint, OneDrive, and Teams—the collaboration surfaces where CUI most commonly leaks
- Overly broad exceptions carved out by IT to reduce helpdesk tickets, which effectively neutralize the policy
- No documented testing or review cycle to confirm policies are functioning as intended
Internal IT teams often enable DLP as a checkbox exercise during initial deployment. Without compliance-driven tuning against frameworks like NIST SP 800-171 or CMMC, those policies do not map to the specific data types regulators care about. Our post on understanding Data Loss Prevention explains how DLP should function as a substantive control, not a report generator.
A compliance assessment reviews every active and inactive policy, tests enforcement behavior, and documents the gaps in a format that supports your System Security Plan.
3. Conditional Access Gaps That Leave Privileged Access Exposed
Microsoft 365 offers a robust Conditional Access framework through Azure Active Directory (now Entra ID), but misconfiguration is endemic. When we assess contractor environments, we routinely find:
- No Conditional Access policies applied to privileged administrator accounts, meaning an admin logging in from an unmanaged personal device faces no additional authentication challenge
- Multi-factor authentication enforced for standard users but excluded for service accounts and break-glass accounts
- Device compliance policies in Microsoft Intune that are assigned but not enforced due to licensing gaps or incorrect policy scope
- Guest and external collaboration enabled without restriction, allowing access to CUI-bearing SharePoint sites from accounts outside the organization's control boundary
These gaps matter enormously under CMMC Level 2, which requires access control, identification and authentication, and configuration management practices that directly map to Conditional Access behavior. Your CMMC, CUI, and DFARS compliance obligations cannot be met with a misconfigured identity plane, regardless of how many other controls are in place.
Internal IT teams configure Conditional Access to support business operations. Compliance assessors configure it to satisfy specific control requirements and defend that configuration under auditor scrutiny.
4. Sensitivity Labeling That Does Not Match Your CUI Categories
Microsoft Purview Information Protection provides sensitivity labeling that can classify, mark, and enforce protections on CUI-bearing documents and emails. Most organizations we assess have labels deployed. Almost none of them align those labels to their actual CUI categories as defined by the National Archives CUI Registry.
The typical scenario: an IT team creates generic labels like "Internal," "Confidential," and "Highly Confidential" that mirror commercial data classification schemes. What the contract actually requires is labels aligned to specific CUI Basic and CUI Specified categories—Technical Data, Export Controlled, Privacy, Procurement and Acquisition, and others depending on your program scope.
When CUI is not labeled according to its regulatory category, downstream controls fail. DLP policies cannot trigger correctly. Retention policies apply the wrong rules. Audit logs do not capture the right events. And when an auditor asks for evidence that CUI is being marked and handled in accordance with your SSP, you have no defensible answer.
Understanding the distinction between CUI Basic and CUI Specified handling requirements is essential before configuring your labeling taxonomy. A compliance assessment maps your label architecture to your actual data types and contract obligations—something internal teams rarely have the regulatory context to accomplish on their own.
5. Audit Logging Gaps That Undermine Incident Response and Compliance Evidence
Microsoft 365 generates extensive audit log data, but collecting it is not the same as retaining it, protecting it, and making it available as compliance evidence. When we conduct assessments, we consistently find:
- Unified Audit Log enabled, but with retention set to 90 days rather than the one-year minimum required under CMMC and NIST SP 800-171
- Audit logs not exported to an external SIEM or immutable storage, meaning they can be modified or deleted within the tenant
- Specific event types not captured, including mailbox access by administrators, sensitivity label changes, and guest access events
- No documented log review process, so even when logs exist, no one is reviewing them for anomalous activity
NIST SP 800-171 and CMMC both require audit log generation, protection, review, and retention. An environment that has logs but cannot produce them in a defensible chain of custody will fail audit review just as completely as an environment with no logging at all.
This is also a critical issue in healthcare environments. Organizations operating under HIPAA that use Microsoft 365 face similar audit trail requirements under the Security Rule's technical safeguard provisions. If your organization operates across both regulated spaces—as many federal defense and healthcare-adjacent contractors do—the logging configuration requirements stack in ways that require deliberate architecture, not default settings.
What Drives These Gaps
The common thread across all five findings is not negligence—it is role mismatch. Internal IT teams are responsible for availability, performance, and end-user support. Regulatory compliance requires a separate discipline: knowledge of the specific control frameworks, the authoritative sources those frameworks reference, and the evidentiary standards that auditors apply.
A Microsoft 365 E5 license gives you the tools. A compliance assessment tells you whether those tools are actually satisfying your regulatory obligations. Without the latter, you are spending on infrastructure that creates a false sense of security.
Our Regulatory vCISO services are specifically designed to bridge this gap—providing ongoing compliance leadership that keeps your Microsoft 365 environment aligned to your framework requirements as your contracts, personnel, and technology evolve.
Take the Next Step
If your organization handles CUI, operates under CMMC, DFARS, or ITAR, or serves federal agency clients, a professional Microsoft 365 compliance assessment is not optional—it is a prerequisite for sustainable compliance. The five gaps described here are consistently the ones that surface in CMMC assessments, DIBCAC audits, and OCR investigations. Finding them yourself, before an auditor does, is the only defensible posture. Request a quote to learn how Cleared Systems can assess your Microsoft 365 environment against your specific regulatory obligations and deliver a remediation roadmap your team can act on immediately.