System and Information Integrity is the control family that shows whether your environment can actually recognize trouble and respond to it before a small issue becomes a serious security event. Most organizations do not struggle here because they lack security tools entirely. They struggle because patching is inconsistent, malware protections are only partially deployed, monitoring is collecting data without producing action, and suspicious activity is detected too late or not investigated at all.

That is what makes this family so important in a CMMC assessment. A C3PAO is not just asking whether Microsoft 365 GCC High includes Defender, antivirus, or security alerts. They are evaluating whether your organization can identify vulnerabilities, remediate flaws in a defined timeframe, keep protection mechanisms current, scan for malicious code, monitor the environment for attacks, and identify unauthorized use in a way that is repeatable and defensible.

GCC High provides a strong foundation for the SI family. Microsoft handles patching and maintenance of the underlying cloud service infrastructure, publishes platform security advisories, and provides tools such as Microsoft Defender for Endpoint, Defender for Office 365, Exchange Online Protection, Intune, and Microsoft Sentinel in Azure Government. But none of that means the family is satisfied by default. Five of the seven SI controls require direct configuration in your tenant or your Azure Government environment, and the other two still require active customer process and evidence.

This is Part 14 of the NIST 800-171 GCC High Configuration Guide. It assumes you already have a functioning GCC High tenant, understand the shared responsibility model, and are implementing against NIST SP 800-171  Rev. 2.

System and Information Integrity family overview

The System and Information Integrity family includes seven controls focused on identifying and remediating flaws, protecting systems from malicious code, monitoring security alerts and advisories, keeping protection mechanisms current, scanning systems and external files, monitoring communications for signs of attack, and identifying unauthorized use of organizational systems.

At a practical level, this family breaks into two implementation groups. Some controls are shared between Microsoft and your organization, especially where the platform handles service-side patching or publishes security advisories but your team still has to monitor, evaluate, and respond. The rest require direct configuration in your GCC High tenant and Azure Government environment, including malicious code protection, scan policies, communications monitoring, and unauthorized-use detection.

Operationally, those controls still tend to cluster around flaw and advisory management, malicious code protection, and monitoring and detection. But from an assessment and implementation standpoint, the more important distinction is whether Microsoft is providing part of the control at the platform layer or whether your team must configure and operate the control directly.

If Configuration Management is the discipline that defines what your environment should look like, System and Information Integrity is the family that helps you notice when reality starts to diverge from that standard. It is where patching, malware protection, monitoring, and investigation come together.

SI controls and CMMC scope

The SI family applies across the full CMMC assessment boundary. Any endpoint, server, mailbox, collaboration workload, administrative system, or network segment that is in scope needs to be covered by the relevant flaw remediation, malware protection, monitoring, and unauthorized-use detection controls.

That matters in enclave architectures. An enclave can reduce the number of assets that need full CMMC implementation, but everything inside that enclave still needs to be monitored and protected as part of a coherent SI program. If CUI is accessed through managed Windows endpoints, Exchange Online, SharePoint Online, Teams, or administrative interfaces, those assets need to be patched, protected, and visible to the monitoring stack.

This is also one of the clearest places where scoping mistakes show up during readiness work. Organizations may believe they have defined a narrow CUI boundary, only to discover that contractor laptops, shared workstations, unmanaged mobile devices, legacy servers, or network devices are still part of the real operating environment. In the SI family, scope is not just about where CUI resides. It is also about every location where malicious code can enter, every place attacks can be observed, and every system whose misuse would affect the confidentiality of controlled data.

How system and information integrity works in GCC High

Before walking through the controls, it helps to understand the architecture you are actually using in GCC High.

Microsoft Defender for Endpoint is the primary endpoint protection and detection layer. It provides antimalware, endpoint visibility, vulnerability information, attack surface reduction telemetry, and incident investigation support for managed devices. In GCC High, Defender for Endpoint requires the government-specific onboarding package and government cloud portals.

Microsoft Defender for Office 365 and Exchange Online Protection extend malicious code protection and monitoring into the email layer. Safe Attachments, Safe Links, anti-malware, anti-phishing, and related alerting features are especially important because email remains one of the most common ways malicious activity enters the environment.

Microsoft Intune supports several SI controls by enforcing Windows Update for Business policies, managing antivirus configurations, defining scan schedules, and helping maintain endpoint configuration state. Microsoft Sentinel in Azure Government is the main SIEM option for many GCC High environments. It connects multiple data sources, correlates suspicious activity, and turns raw security events into detectable incidents.

Defender Vulnerability Management helps identify and prioritize vulnerabilities on onboarded endpoints. Entra ID contributes identity signals, risk detections, and sign-in telemetry that become especially relevant for unauthorized-use detection.

One practical note matters here as well. In GCC High, Defender and the rest of the security stack use government-specific endpoints and onboarding packages. Intune is at intune.microsoft.us, Entra at entra.microsoft.us, Microsoft 365 admin at admin.microsoft365.us, Defender at security.microsoft.us or related government-specific portals, and Sentinel in portal.azure.us. Commercial endpoints and onboarding packages are not interchangeable with the government environment.

What GCC High configures by default

Two SI controls are partially supported by the platform, but even those are not fully handled for you.

3.14.1 Identify, report, and correct system flaws in a timely manner

SI.L2-3.14.1

This control requires system flaws to be identified, reported, and corrected within a defined timeframe.

At the platform level, Microsoft patches the GCC High cloud infrastructure on its own release cadence. You do not schedule patches for Exchange Online, SharePoint Online, Teams, or Entra ID, and Microsoft is responsible for maintaining those service components as part of its cloud operations and authorization obligations. Microsoft also publishes vulnerability information and service notices through channels such as the Microsoft Security Response Center and the Microsoft 365 Message Center.

That does not satisfy the control on its own. Your organization is still responsible for the endpoints, mobile devices, operating systems, third-party applications, firmware, and other assets inside the assessment boundary. You also need to define what “timely” means in your own environment. If the SSP says flaws will be corrected promptly but does not define specific timeframes, assessors will usually treat that as incomplete.

In practice, this control often depends on Intune update rings, vulnerability visibility through Defender Vulnerability Management, and a documented flaw remediation procedure that ties severity to deadlines. The strongest implementations also include an exception process for vulnerabilities that cannot be corrected immediately.

The most common weaknesses here are vague patching language in the SSP, update configurations that exist without compliance review, and third-party applications that were never brought into the remediation program.

3.14.3 Monitor system security alerts and advisories and take appropriate action

SI.L2-3.14.3

This control requires your organization to monitor security alerts and advisories and take appropriate action in response.

Microsoft contributes several useful advisory channels, including the Microsoft 365 Message Center, service health communications, Microsoft Security Response Center publications, and threat-related information surfaced through Defender. Those are valuable inputs, but your organization still needs a defined process for reviewing them, deciding whether they apply to your environment, and tracking the response.

That process should also extend beyond Microsoft-specific sources. If your assessment boundary includes third-party applications, endpoints, network appliances, browsers, VPN clients, or other software, advisory monitoring has to include those vendors as well. Many organizations also include CISA’s Known Exploited Vulnerabilities catalog and related government alerting sources in their review workflow.

This control usually fails because advisory consumption is informal. People may read alerts, skim vendor notices, or discuss security news in chat, but there is no written cadence, no review log, and no record of whether a given advisory was applicable, remediated, or determined not to require action.

The five SI controls you must configure yourself

This is where the real implementation work begins. These controls are where most GCC High environments either operationalize the SI family or reveal that they are mostly relying on unused licensing and default settings.

3.14.2 Provide protection from malicious code at designated locations

SI.L2-3.14.2

This control requires malicious code protection at the locations where malware can realistically enter or operate within the environment.

In a GCC High implementation, those designated locations usually include endpoints, email, and cloud file storage. That means the control is rarely satisfied by a single product. Defender for Endpoint covers managed devices. Defender for Office 365 and Exchange Online Protection cover the email layer. SharePoint, OneDrive, and Teams protections matter for files that users receive or share through collaboration workloads.

The first major requirement is endpoint onboarding. Every in-scope endpoint should be onboarded to Defender for Endpoint using the government-specific package and reporting to the government cloud portal. This is one of the clearest places assessors compare evidence sets directly. If the in-scope device inventory does not match the Defender device list, it is an immediate weakness.

The second requirement is email protection. Many organizations do well on endpoint malware protection but leave Safe Attachments, Safe Links, or anti-malware policies underconfigured. Since email remains a primary malware delivery path, assessors usually look for both endpoint and mail-layer coverage.

The third requirement is file-based protection in Microsoft 365 workloads. If users are receiving or storing files in SharePoint, OneDrive, and Teams, those collaboration paths also need protection.

This control often breaks down when endpoint coverage is incomplete, non-Windows platforms are ignored even though they are in scope, or the email protection stack is left at basic defaults rather than deliberately configured.

3.14.4 Update malicious code protection mechanisms when new releases are available

SI.L2-3.14.4

This control is about making sure the protective tools themselves stay current. It is not enough to deploy antivirus or antimalware technology once and assume it remains effective forever.

In GCC High, that usually means ensuring Defender security intelligence, engine updates, and related protection components are updating properly on endpoints. Cloud-based protections such as Safe Attachments and Exchange Online Protection are maintained by Microsoft, but your organization still needs to verify that those services are enabled and functioning as expected.

The practical assessment question here is whether you can show that protection mechanisms stay current across the environment. A strong implementation includes an Intune antivirus policy, cloud-delivered protection enabled where appropriate, and a monitoring process that identifies endpoints with stale definitions or failed update behavior.

What makes this control tricky is that automatic updates can hide silent failures. Devices that stop syncing, lose connectivity, stay off VPN too long, or encounter local issues may drift behind even when the policy is configured correctly. That is why monitoring matters just as much as configuration.

A common finding here is an organization that can show automatic updates are enabled but cannot show whether those updates are succeeding on actual devices.

3.14.5 Perform periodic scans and real-time scans

SI.L2-3.14.5

This control has two distinct parts. You need periodic scans performed at a defined frequency, and you need real-time scans of files from external sources as they are downloaded, opened, or executed.

In practice, that means your endpoint protection configuration needs both real-time protection enabled and scheduled scans defined. Organizations sometimes do one but not the other. Real-time protection may be turned on, but there is no scheduled full scan cadence. Or scheduled scans exist, but exceptions and local troubleshooting have left real-time scanning disabled on some systems.

It also means your file-ingestion paths need to be considered carefully. Email attachments are one obvious external source, which is why Safe Attachments matters here. SharePoint, OneDrive, and Teams file uploads also matter because users commonly receive external content through those collaboration channels. USB-delivered files, downloaded content, and files opened locally on endpoints should also be covered by the endpoint protection layer.

One practical point matters here more than it often gets credit for: the scan frequency needs to be stated in the SSP, not just configured in Intune. Assessors regularly compare the technical settings against the written policy. If the environment is set for daily quick scans and weekly full scans but the SSP never defines that schedule, the implementation feels incomplete.

This control often fails because scan schedules are not formally defined, SharePoint and Teams scanning settings were overlooked, or organizations never review which devices are showing overdue scans.

3.14.6 Monitor communications at external and key internal boundaries to detect attacks

SI.L2-3.14.6

This is one of the most technically demanding controls in the family because it requires real monitoring, not just passive data retention.

The first step is defining your boundaries. In a GCC High environment, the external boundary often includes internet-facing traffic into Microsoft 365, your corporate network edge, VPN entry points, and email ingress paths. Key internal boundaries may include the line between the CUI enclave and the rest of the organization, between administrative networks and user networks, or between users and sensitive services.

Once those boundaries are defined, the monitoring stack needs to align to them. Sentinel is the most natural SIEM layer for many GCC High implementations because it can ingest data from Entra ID, Microsoft 365, Defender, and other sources in Azure Government. But deploying Sentinel is only the beginning. You still need meaningful connectors, analytics rules, investigation workflows, and operational review of incidents.

Email-related alerting also matters here. Defender for Office 365 can surface indicators of phishing, malicious URLs, malware delivery, suspicious forwarding activity, and other attack patterns moving through the communication layer.

For organizations with on-premises or hybrid boundaries, firewall, IDS, IPS, proxy, DNS, or VPN logs often need to be brought into Sentinel as well. This is where many cloud-first programs discover a blind spot. They are monitoring Microsoft 365 well enough, but they have little visibility into the actual network edge or boundary devices that still matter to the enclave.

This control usually fails in one of four ways. Sentinel is deployed but not operationalized. Boundary definitions are vague or undocumented. Network-layer logs never make it into the SIEM. Or alerts are generated but nobody can show that they were reviewed and investigated.

3.14.7 Identify unauthorized use of organizational systems

SI.L2-3.14.7

This control depends on something many organizations under-document: a clear definition of authorized use.

Before you can identify unauthorized use, your organization has to define what authorized use looks like. That usually means an Acceptable Use Policy, SSP language, and supporting standards that identify who is allowed to use the system, from which devices, for what purposes, and under what conditions. Without that definition, “unauthorized use” remains too vague to detect meaningfully.

Once that baseline exists, the technical side of the control becomes much clearer. Entra ID Identity Protection can detect risky sign-ins, suspicious sign-in patterns, anonymous IP usage, and other anomalous identity behaviors. Sentinel can correlate those events with file access, admin activity, mailbox rule creation, or unusual user behavior. Unified Audit Log and related alerting can also help identify suspicious actions such as forwarding rules, large-scale deletions, external sharing changes, or unusual permission changes.

This control is not just about detection logic. It is also about investigation. Even benign detections can be useful evidence if the organization can show that an anomaly was reviewed, evaluated, and resolved. Assessors often care as much about the response path as the original alert.

Common findings here include Acceptable Use Policies that are too generic to support detection, Identity Protection licensing that exists but is not enabled, analytics rules that focus on generic threats rather than unauthorized use patterns, and no investigation records for the alerts that did fire.

SI quick-reference PowerShell commands

The following PowerShell commands help administrators quickly verify several System and Information Integrity controls in a GCC High environment. These examples focus on areas where assessors commonly request evidence, including device patch visibility, Defender protection status, stale definition identification, scan status, and audit log confirmation.

Export managed device patch and compliance status (supports 3.14.1)

This command exports a high-level view of managed devices, including operating system version, compliance state, and last sync time. It is useful for showing visibility into the endpoint population that must be patched and monitored.

# Connect to Microsoft Graph (GCC High)
Connect-MgGraph -Environment USGov -Scopes "DeviceManagementManagedDevices.Read.All"

# Export managed device patch/compliance visibility
Get-MgDeviceManagementManagedDevice -All |
    Select-Object DeviceName,
                  OperatingSystem,
                  OsVersion,
                  ComplianceState,
                  LastSyncDateTime,
                  @{N="DeviceId";E={$_.Id}} |
    Export-Csv -Path "SI_3.14.1_Device_Patch_Status.csv" -NoTypeInformation

Assessors often want to see that the organization can identify the systems in scope and determine whether they are current and compliant.

Export Microsoft Defender protection status (supports 3.14.2, 3.14.4, and 3.14.5)

This command exports core Defender protection data for Windows devices, including real-time protection, antimalware version, engine version, signature version, and recent scan timestamps.

# Connect to Microsoft Graph (GCC High)
Connect-MgGraph -Environment USGov -Scopes "DeviceManagementManagedDevices.Read.All"

# Export Defender protection status
Get-MgDeviceManagementManagedDevice -All -Filter "operatingSystem eq 'Windows'" |
    Select-Object DeviceName,
                  @{N="RealTimeProtection";E={$_.WindowsProtectionState.RealTimeProtectionEnabled}},
                  @{N="AntiMalwareVersion";E={$_.WindowsProtectionState.AntiMalwareVersion}},
                  @{N="EngineVersion";E={$_.WindowsProtectionState.EngineVersion}},
                  @{N="SignatureVersion";E={$_.WindowsProtectionState.AntiVirusSignatureVersion}},
                  @{N="LastQuickScan";E={$_.WindowsProtectionState.LastQuickScanDateTime}},
                  @{N="LastFullScan";E={$_.WindowsProtectionState.LastFullScanDateTime}},
                  @{N="QuickScanOverdue";E={$_.WindowsProtectionState.QuickScanOverdue}},
                  @{N="FullScanOverdue";E={$_.WindowsProtectionState.FullScanOverdue}},
                  @{N="SignatureOutOfDate";E={$_.WindowsProtectionState.SignatureUpdateOverdue}} |
    Export-Csv -Path "SI_Defender_Protection_Status.csv" -NoTypeInformation

This is one of the most practical exports in the family because it supports multiple SI controls at once.

Identify devices with stale Defender definitions (supports 3.14.4)

This command isolates Windows devices where Defender signatures are out of date.

Get-MgDeviceManagementManagedDevice -All -Filter "operatingSystem eq 'Windows'" |
    Where-Object { $_.WindowsProtectionState.SignatureUpdateOverdue -eq $true } |
    Select-Object DeviceName,
                  UserPrincipalName,
                  @{N="SignatureVersion";E={$_.WindowsProtectionState.AntiVirusSignatureVersion}},
                  @{N="EngineVersion";E={$_.WindowsProtectionState.EngineVersion}},
                  @{N="LastSyncDateTime";E={$_.LastSyncDateTime}} |
    Export-Csv -Path "SI_3.14.4_Stale_Definitions.csv" -NoTypeInformation

This is useful evidence when demonstrating that the organization does not just configure automatic updates but also monitors for update failures.

Identify devices with overdue scans (supports 3.14.5)

This command highlights devices that are missing scheduled quick scans or full scans.

Get-MgDeviceManagementManagedDevice -All -Filter "operatingSystem eq 'Windows'" |
    Where-Object {
        $_.WindowsProtectionState.QuickScanOverdue -eq $true -or
        $_.WindowsProtectionState.FullScanOverdue -eq $true
    } |
    Select-Object DeviceName,
                  UserPrincipalName,
                  @{N="QuickScanOverdue";E={$_.WindowsProtectionState.QuickScanOverdue}},
                  @{N="FullScanOverdue";E={$_.WindowsProtectionState.FullScanOverdue}},
                  @{N="LastQuickScan";E={$_.WindowsProtectionState.LastQuickScanDateTime}},
                  @{N="LastFullScan";E={$_.WindowsProtectionState.LastFullScanDateTime}} |
    Export-Csv -Path "SI_3.14.5_Overdue_Scans.csv" -NoTypeInformation

This export helps show that scan scheduling is not only configured but actively reviewed.

Confirm Unified Audit Log ingestion is enabled (supports 3.14.7)

This command verifies that Unified Audit Log ingestion is enabled in the tenant.

# Connect to Exchange Online (GCC High)
Connect-ExchangeOnline -ExchangeEnvironmentName O365USGovGCCHigh

# Verify Unified Audit Log ingestion
Get-AdminAuditLogConfig |
    Select-Object UnifiedAuditLogIngestionEnabled

While this is not the whole answer for unauthorized-use detection, it is still a useful foundational check for audit-backed investigations.

Export recent suspicious inbox rule changes (supports 3.14.7)

This command searches for mailbox rule changes that may indicate suspicious forwarding or redirection behavior.

# Connect to Exchange Online (GCC High)
Connect-ExchangeOnline -ExchangeEnvironmentName O365USGovGCCHigh

# Export suspicious inbox rule activity from the last 30 days
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
    -Operations "Set-InboxRule","New-InboxRule" -ResultSize 100 |
    Where-Object { $_.AuditData -like "*ForwardTo*" -or $_.AuditData -like "*RedirectTo*" } |
    Select-Object CreationDate,
                  UserIds,
                  Operations,
                  AuditData |
    Export-Csv -Path "SI_3.14.7_Suspicious_Mailbox_Rules.csv" -NoTypeInformation

This is a good example of an unauthorized-use detection export that assessors often find credible because it ties directly to real misuse scenarios.

Export recent security alert activity from audit logs (supports 3.14.6)

This command exports a sample of recent security-related alert events captured in the audit log.

# Connect to Exchange Online (GCC High)
Connect-ExchangeOnline -ExchangeEnvironmentName O365USGovGCCHigh

# Export recent security-related audit events
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) `
    -RecordType SecurityComplianceAlerts -ResultSize 50 |
    Select-Object CreationDate,
                  UserIds,
                  Operations,
                  AuditData |
    Export-Csv -Path "SI_3.14.6_Security_Alerts_Sample.csv" -NoTypeInformation

This can help support evidence that the organization is collecting and reviewing security-relevant events tied to monitoring workflows.

The evidence a C3PAO will usually want to see

For the SI family, evidence needs to show that protections are deployed, current, monitored, and used in practice.

That usually includes Windows Update for Business configuration, vulnerability management dashboards or exports, patch compliance reporting, defined flaw-remediation timeframes in the SSP, advisory monitoring procedures and review logs, Defender for Endpoint onboarding evidence, Safe Attachments and Safe Links configurations, antivirus policy settings, scan schedules, current definition status, Sentinel data connectors, analytics rules, incident records, risk detection policies, Acceptable Use Policy language, and examples of investigated alerts or anomalies.

For shared-responsibility controls such as 3.14.1 and 3.14.3, assessors usually want to see that the organization understands what Microsoft handles and what remains customer-owned. For configuration-based controls, they will often compare live portal settings, exported reports, and SSP language to make sure the implementation tells a consistent story.

The most common SI assessment findings

One of the most common problems in this family is incomplete endpoint coverage. Organizations believe Defender for Endpoint is deployed across the enclave, but when the device inventory is compared to the onboarding list, there are missing systems. The gaps often include contractor laptops, shared workstations, non-Windows endpoints, or devices that were onboarded incorrectly to the commercial portal instead of the government environment.

Another common issue is patching language that sounds responsible without being specific. The SSP says the organization patches systems in a timely manner, but nowhere defines what that means by severity, asset type, or exception path. Without concrete timeframes, the flaw-remediation control becomes difficult to defend.

Monitoring is another frequent weak point. Sentinel may be provisioned and collecting data, but analytics rules are thin, investigations are inconsistent, or incidents are never documented. In that state, the SIEM functions more like a log repository than an operational detection system.

Protection mechanisms also tend to be configured more confidently than they are monitored. Antivirus definition updates may be enabled, but no one is reviewing which endpoints are stale. Scan schedules may exist, but overdue scans are not being tracked. Safe Attachments may be active for email but not extended to SharePoint, OneDrive, or Teams.

Advisory monitoring often remains informal. Organizations know they should pay attention to vendor and government alerts, but they do not keep a review log, record applicability decisions, or document the actions taken in response. That becomes visible very quickly during an assessment.

And finally, unauthorized-use detection often suffers from weak definitions. If authorized use is not described with enough specificity in policy and SSP documentation, the detection logic ends up vague as well. It is difficult to prove you can identify unauthorized use when the organization has never clearly defined what authorized use looks like in the first place.

How the SI family supports other control families

System and Information Integrity is tightly connected to the rest of the framework.

Configuration Management supports SI because secure baselines, update configurations, and hardened settings determine what the environment should look like before monitoring begins. Audit and Accountability supports SI because alerts, anomaly detection, and unauthorized-use investigations depend on reliable logs and attributable activity. Incident Response depends on SI because detections and monitoring outputs are often what trigger formal response activities. Risk Assessment intersects closely with flaw remediation because vulnerability findings often drive patching and exception decisions. Access Control and System and Communications Protection also connect directly to SI where boundaries, remote access paths, and communications monitoring overlap.

That is why this family matters so much in real assessments. SI is not just about running antivirus. It is the control family that shows whether your environment can detect, adapt, and respond when things stop behaving the way they should.

Get started

System and Information Integrity is where security tooling has to become operational discipline. Patch cycles, malware protections, advisory reviews, detections, and investigations all need to point to the same conclusion: your GCC High environment is not just configured for protection, it is actively being monitored and maintained over time.

Secureframe Defense connects directly to your GCC High environment and continuously monitors the controls that support the SI family, including patch compliance for 3.14.1, malicious code protection coverage for 3.14.2, scan completion and protection status for 3.14.5, communications monitoring readiness for 3.14.6, and unauthorized-use detection signals tied to 3.14.7. When a C3PAO asks how you know your protections are current and operational, the goal is not to assemble screenshots from multiple portals after the fact. The goal is to already have that evidence organized and ready.

See how Secureframe automates CMMC evidence collection for the SI family by scheduling a demo with a product expert.