Incident Response is one of the smallest families in NIST 800-171 , but it carries outsized importance in both CMMC certification assessments and real-world federal contract performance. That is partly because the control family covers one of the clearest tests of operational readiness: whether your organization can detect, manage, document, and report a security incident under pressure. It is also because 3.6.2 connects directly to DFARS 252.204-7012, which requires reporting covered cyber incidents to the Department of Defense within 72 hours of discovery.

That distinction matters. In many control families, a weak implementation creates a compliance gap. In Incident Response, a weak implementation can also create contractual exposure. If your team does not know how incidents are escalated, when the reporting clock starts, who files a DC3 report, or how forensic evidence is preserved, the issue is not just assessment readiness. It is whether your organization can meet its obligations when a real event occurs.

GCC High gives you strong supporting tools for the family. Microsoft Sentinel, Defender for Endpoint, Defender for Office 365, Entra ID signals, and the unified Defender incident queue can all support detection, triage, investigation, and portions of technical response. But those tools do not satisfy the family on their own. Incident Response is primarily a policy, process, and people family. The plan, the team, the communication paths, the testing cadence, the documentation, and the reporting obligations all remain your responsibility.

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

Incident Response family overview

The Incident Response family includes three controls focused on establishing an operational incident-handling capability, tracking and reporting incidents to the appropriate internal and external parties, and testing the organization’s incident response capability over time.

At a practical level, the family breaks into two implementation groups. Some controls are shared in the sense that Microsoft provides the detection, investigation, and workflow tooling, but your organization still has to define and operate the actual response process. The remaining control is primarily customer-owned because testing the incident response capability depends almost entirely on your planning, execution, documentation, and follow-through.

Operationally, the family clusters around three themes: building the capability, running the reporting process, and proving through exercises that the capability actually works. That is why this family often becomes a litmus test for whether a compliance program is real. It is difficult to fake operational maturity in Incident Response because assessors can ask simple, practical questions and quickly see whether the team knows how the process actually works.

If System and Information Integrity is about detecting trouble, Incident Response is about what your organization does next.

IR controls and CMMC scope

The IR family applies across the full CMMC assessment boundary because an incident can originate anywhere inside that boundary and still affect CUI. That includes endpoints, collaboration workloads, mailboxes, cloud storage locations, administrative systems, identity infrastructure, and any supporting technology that stores, processes, or transmits covered data.

That has important implications for enclave environments. An enclave may narrow the technical scope of the systems that need full control implementation, but it does not narrow the need for a coherent response capability. If CUI is handled inside a GCC High tenant, on managed endpoints, or through defined supporting systems, the organization needs an incident process that can detect and respond to events affecting that environment specifically.

This is also where many organizations discover hidden dependencies. A Sentinel workspace may sit in Azure Government, investigations may rely on Defender telemetry, notifications may flow through internal Teams channels, and reportability may depend on whether the affected asset was inside the CUI boundary. Incident Response scope is therefore not just about where the incident happened. It is also about which systems, people, and evidence sources the team relies on to determine impact and respond.

How incident response works in GCC High

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

Microsoft Sentinel is usually the central incident management and correlation layer for organizations building an IR capability in Azure Government. It ingests security data, correlates alerts, creates incidents, and can trigger automation rules or playbooks. It is often the first place analysts look when triaging a serious event.

Microsoft Defender for Endpoint supports endpoint-focused investigation and containment through alerts, device timelines, advanced hunting, live response, and device isolation. Defender for Office 365 adds visibility into phishing, malicious links, malicious attachments, and collaboration-borne threats. Entra ID and related identity signals add another layer of visibility for suspicious sign-ins, impossible travel, and other account compromise indicators.

The unified Microsoft 365 Defender incident queue is important because it correlates alerts across multiple Defender products into a single incident view. That reduces some of the fragmentation that otherwise occurs when teams have to hop across separate consoles during an investigation.

But it is important to keep the distinction clear. These are response-support tools, not the incident response capability itself. They can help you detect, triage, investigate, and automate pieces of response. They do not replace the Incident Response Plan, the team structure, the escalation path, the reporting decision tree, or the testing program.

The two IR controls that depend on both Microsoft tooling and your process

These controls are often described as shared because the platform can support them technically, but the actual control is still exercised through your organization’s procedures and people.

3.6.1 Establish an operational incident-handling capability

IR.L2-3.6.1

This control requires the organization to establish an operational incident-handling capability that includes preparation, detection, analysis, containment, recovery, and user response activities.

That wording is important because it means the organization needs more than a plan on paper. It needs a functioning capability that covers the full lifecycle of an incident. The strongest implementations usually start with a documented Incident Response Plan aligned to a recognized framework such as NIST SP 800-61, then tie each phase of that plan to specific roles, decision points, communication paths, and supporting tools.

Preparation should define the team, escalation paths, communication protocols, outside counsel or external partners where relevant, and the tools the organization uses during investigations. Detection should define which sources the team monitors and how alerts are triaged. Analysis should define how scope is determined, what evidence is gathered, and how investigators decide whether CUI may be affected. Containment and recovery should define who can isolate devices, disable accounts, block indicators, restore systems, and approve returning assets to production. User response activities should address how affected users are instructed, notified, or reset after a suspected compromise.

This is also the control where the Incident Response Team needs to be real, not generic. “The IT team will handle incidents” is rarely a strong answer. Assessors typically want to see defined roles, named or role-based assignments, alternates, and evidence that the people involved know their responsibilities.

Microsoft tooling supports this control best when it is mapped deliberately to the plan. Sentinel may support detection, correlation, assignment, and response orchestration. Defender may support investigation and containment. But the plan still has to explain who uses those tools, when they use them, and how their output feeds the response process.

A common weakness here is an IRP that exists but does not feel operational. It may mention detection and containment in broad terms, but it does not identify who does what, how incidents move through the organization, or how the team would actually use the environment’s tools in a real event.

3.6.2 Track, document, and report incidents

IR.L2-3.6.2

This control requires incidents to be tracked, documented, and reported to the appropriate internal and external parties.

This is where the family becomes especially consequential for federal contractors because DFARS 252.204-7012 overlays a very specific reporting obligation. If a cyber incident affects a covered contractor information system or the CUI residing on it, the contractor must report that incident to DC3 through DIBNet within 72 hours of discovery. That clock starts at discovery, not at confirmation.

That timing issue is one of the most important practical realities in the family.

The 72-hour clock starts when the organization discovers a potentially reportable incident, not when the investigation is complete.

That observation needs to be clear in the article because many organizations intuitively treat the reporting deadline as something that begins after internal validation. In reality, a preliminary report may need to be filed while the investigation is still underway.

In practical terms, this control usually requires three parallel capabilities. First, the organization needs an incident tracking mechanism, whether that is Sentinel, an integrated ITSM platform, or another formal system. Second, it needs a consistent documentation approach so incidents are recorded with enough detail to support investigation, lessons learned, leadership review, and if necessary legal or contractual follow-up. Third, it needs a reporting decision process that identifies who must be notified internally and when an external authority such as DC3 or a contracting officer must be notified.

Sentinel can support much of the tracking function well. It can create incidents, record severity, owner, status, related alerts, and supporting timeline information. That is useful evidence, but it is not enough by itself. The organization also needs an incident register, documentation standards, escalation rules, and preserved records for reportable events.

This control is often where assessors probe for maturity. They may ask whether DIBNet registration has already been completed, whether the team knows who owns the DC3 submission, whether the contracting officer notification path is documented, and whether forensic preservation requirements are understood. If the team has to figure those things out during an incident, the process is not really ready.

The most common weaknesses are no incident register, informal documentation through email or chat, no explicit DFARS reporting procedure, and no evidence preservation process tied to potentially reportable incidents.

The IR control that is primarily customer-owned

3.6.3 Test the organizational incident response capability

IR.L2-3.6.3

This control requires the organization to test its incident response capability.

Unlike the other two controls, this one is almost entirely about your own operational discipline. Microsoft tools can support exercises, but the actual planning, facilitation, execution, documentation, and improvement cycle all belong to the organization.

At minimum, most organizations meet this requirement through a tabletop exercise. That is usually acceptable for CMMC so long as the scenario is relevant and the exercise is documented well. But the most useful exercises go further. They do not just discuss a generic outage or hypothetical malware event. They walk through a realistic CUI-relevant scenario that forces the team to test escalation, containment, evidence preservation, reportability decisions, and the 72-hour DC3 timeline.

That is an important point for this control. A test is far more valuable when it pressures the parts of the process that would matter most during a real federal compliance incident.

A functional exercise adds even more value by requiring the team to perform actual actions such as executing Sentinel queries, testing notification playbooks, isolating a device, or practicing how evidence would be exported and preserved. A full red-team or purple-team style exercise can go further still, but it is not required for most organizations pursuing this level of maturity.

What matters most is that testing produces evidence and improvement. The organization should retain exercise documentation, after-action notes, identified gaps, action items, due dates, and proof that the Incident Response Plan was updated based on what was learned. A tabletop held once, lightly documented, and never revisited will usually look weak to an assessor.

A common finding here is not just that testing was missing, but that the organization held an exercise that never touched the most important CUI-specific procedures. If the test scenario never addressed reportability, evidence preservation, or the internal and external reporting path, it did not really validate the parts of the process that matter most in a DFARS environment.

A practical PowerShell reference for the IR family

Because the Incident Response family is heavily process-driven, most evidence comes from documentation rather than command output. The PowerShell examples below focus on verifying the technical infrastructure that supports the response process.

Verify Sentinel workspace configuration (supports 3.6.1)

This command confirms the Sentinel workspace exists and displays key configuration information such as retention settings.

# Connect to Azure Government
Connect-AzAccount -Environment AzureUSGovernment

# List Sentinel-enabled Log Analytics workspaces
Get-AzOperationalInsightsWorkspace |
    Select-Object Name, ResourceGroupName, Location, Sku, RetentionInDays |
    Format-Table -AutoSize

This helps demonstrate that the SIEM platform supporting your incident response capability is deployed and configured.

List Sentinel data connectors (supports 3.6.1 detection capability)

This command lists the data sources connected to the Sentinel workspace.

$WorkspaceName = "your-sentinel-workspace"
$ResourceGroup = "your-resource-group"

Get-AzSentinelDataConnector -WorkspaceName $WorkspaceName -ResourceGroupName $ResourceGroup |
    Select-Object Name, Kind |
    Format-Table -AutoSize

Assessors often look for connectors to Microsoft 365 Defender, Entra ID, and other security sources to confirm that incident detection telemetry is flowing into the SIEM.

Export Sentinel analytics rules (supports 3.6.1 detection capability)

This command exports active analytics rules responsible for generating incident alerts.

Get-AzSentinelAlertRule -WorkspaceName $WorkspaceName -ResourceGroupName $ResourceGroup |
    Select-Object DisplayName, Kind, Severity, Enabled |
    Export-Csv -Path "Sentinel_Analytics_Rules.csv" -NoTypeInformation

This output shows which detections are configured and whether they are enabled.

Export Sentinel automation rules (supports 3.6.1 response workflows)

This command lists automation rules that assign incidents or trigger response playbooks.

Get-AzSentinelAutomationRule -WorkspaceName $WorkspaceName -ResourceGroupName $ResourceGroup |
    Select-Object DisplayName, Order, TriggeringLogicIsEnabled |
    Export-Csv -Path "Sentinel_Automation_Rules.csv" -NoTypeInformation

Automation rules help demonstrate that incidents are routed and handled consistently rather than manually triaged every time.

Export Sentinel incident history (supports 3.6.2 incident tracking)

This command exports incident records that can help support the incident register and documentation process.

Get-AzSentinelIncident -WorkspaceName $WorkspaceName -ResourceGroupName $ResourceGroup |
    Select-Object Title,
                  IncidentNumber,
                  Severity,
                  Status,
                  Classification,
                  CreatedTimeUtc,
                  LastModifiedTimeUtc,
                  @{N='AlertCount';E={$_.AdditionalDataAlertsCount}} |
    Export-Csv -Path "Sentinel_Incident_History.csv" -NoTypeInformation

This export provides a record of incidents detected and managed through Sentinel.

Verify Log Analytics retention settings (supports 3.6.2 evidence preservation)

This command confirms the retention configuration for the Sentinel Log Analytics workspace.

Get-AzOperationalInsightsWorkspace -ResourceGroupName $ResourceGroup -Name $WorkspaceName |
    Select-Object Name, RetentionInDays, Sku |
    Format-Table -AutoSize

Retention settings help determine how long investigation data and alerts remain available for analysis and evidence preservation.

What evidence a C3PAO will usually want to see

For the IR family, evidence is usually more documentation-heavy than in many other families.

That typically includes the Incident Response Plan, incident team roster, escalation paths, communication templates, incident register, completed incident reports, proof of DIBNet registration, procedures for DC3 and contracting officer notification, evidence preservation procedures, and after-action reports from recent testing.

On the technical side, assessors often also want to see that the supporting tools are configured well enough to make the response capability believable. That can include Sentinel workspace configuration, connected data sources, active analytics rules, automation rules or playbooks, and examples of incidents or alerts moving through the system.

The strongest evidence packages tell a coherent story. The documentation defines the process, the tooling supports it, the team has practiced it, and past incidents or exercises show that the process is actually used.

Common IR assessment findings

One of the most common weaknesses in this family is an Incident Response Plan that exists but is not operational. The document may be complete enough on paper, but team members do not know their roles, escalation paths are unclear, the process has not been exercised, and the plan does not reflect the actual tools or environment the organization uses today.

Another common issue is incomplete DFARS reporting readiness. Organizations may know there is a 72-hour rule, but they have not registered for DIBNet, have not defined who files a report, and have not documented how reportability decisions are made when CUI may be involved. In those cases, the organization has awareness, but not readiness.

Incident documentation is another frequent gap. Security alerts may be triaged in email, chat, or ad hoc notes, but there is no central incident register and no consistent record of what happened, who responded, how decisions were made, or whether the incident was ultimately reportable.

Testing is also a major differentiator. Some organizations have never exercised the plan at all. Others have conducted a tabletop, but the scenario never touched CUI compromise, evidence preservation, or external reporting obligations. In both cases, the organization has not really validated the procedures that matter most.

And finally, many organizations deploy the underlying Microsoft tools without making them operational for IR. Sentinel may exist, Defender may be licensed, and alerts may be available, but no one is reviewing the incident queue consistently, no playbooks are configured, and the technical environment is not being used as part of a mature response capability.

How the IR family supports other control families

Incident Response is tightly connected to the rest of the framework.

Audit and Accountability supports IR because investigations depend on complete, attributable, and retained logging. System and Information Integrity supports IR because detections, anomalies, and suspicious activity often serve as the initial trigger for response. Risk Assessment intersects with IR because incidents frequently expose vulnerabilities or control weaknesses that need to be reevaluated and prioritized. Security Assessment supports IR where ongoing monitoring or control validation reveals conditions that may need escalation. Media Protection can also become relevant during containment and evidence preservation where media handling and sanitization requirements come into play.

That is why this family matters so much even though it contains only three controls. Incident Response is not mainly about the volume of controls. It is about whether the organization can act decisively, document clearly, and meet its obligations when a security event affects the systems and data that matter most.

Get started

Incident Response is where policy, people, tooling, and contract obligations all have to work together under pressure. The plan needs to be current, the team needs to know its roles, the environment needs to support detection and investigation, and the reporting path needs to be clear before an incident ever occurs.

Secureframe Defense connects directly to your GCC High environment and continuously supports the evidence and workflows behind the IR family, including incident tracking for 3.6.2, detection and response tooling readiness for 3.6.1, and audit-ready documentation that supports testing and review under 3.6.3. When a C3PAO asks how your team would handle a reportable incident affecting CUI, the goal is not to describe a process nobody has ever practiced. The goal is to show a response capability that has already been documented, supported, and exercised.

See how Secureframe automates CMMC evidence collection for the IR family.