Prepare the response before an incident forces you to improvise.
Work through all three requirements and 14 assessment objectives. Give people clear roles, preserve the information needed to investigate, make reporting decisions and rehearse recovery. Start with the tools and services you already have.
Sources reviewed October 27, 2026. These instructions have not been tested in a Microsoft tenant. This guide does not establish compliance or replace an official assessment. Suggested checks and manual worksheet states are working aids.
Confirm the systems and responsibilities. Include CUI systems, supporting services, providers and people who can authorize response. Start with Do we handle CUI? if the information is unclear.
Name a lead and a backup. Include technical response, business decisions, reporting, user support and outside assistance. Keep trusted alternate contact instructions available if email or the usual administrator is unavailable.
Check reporting before an incident. Confirm actual contract and legal duties, recipients, timing, required portal access and backup responsibility. A plan that relies on one unavailable person is a gap.
Keep evidence and containment together. Limit harm using authorized actions while preserving needed records. Agree recovery and evidence handling before wiping, rebooting or automatically replacing an affected system.
Rehearse safely. Use the fictional exercises and record actual observations. Do not run malware, disrupt production or submit real incident reports for a tabletop.
This is preparation guidance, not an incident response service. During a real incident, use your approved response team and official reporting routes. Keep CUI, incident details, logs, credentials and evidence in your approved environment. This website does not collect incident reports or exercise answers.
Build a response capability people can actually use
Decide who handles an incident, what they can do and how they get help. A response plan is useful only when people can find it, reach the right contacts and carry out the work with the access and tools available.
Official requirement and assessment objectives
Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.6.1
Objective
Official text
3.6.1[a]
an operational incident-handling capability is established.
3.6.1[b]
the operational incident-handling capability includes preparation.
3.6.1[c]
the operational incident-handling capability includes detection.
3.6.1[d]
the operational incident-handling capability includes analysis.
3.6.1[e]
the operational incident-handling capability includes containment.
3.6.1[f]
the operational incident-handling capability includes recovery.
3.6.1[g]
the operational incident-handling capability includes user response activities.
What to do
Prepare roles, access and a backup route
Name a response lead and backup, technical responders, the business decision maker and the person responsible for reporting. Include providers and contract responsibilities. Keep approved contact and response instructions available if email, identity or the usual ticket system is unavailable. Check access and recovery arrangements without sending a real incident report.
Connect detection to a person who will act
List useful alerts, staff reports, directory/endpoint events and provider notifications for the systems in scope. Assign review and escalation responsibility, including coverage outside normal hours. Give staff a way to report quickly and get instructions through a trusted alternate channel. Missing or expired logs leave a gap; no alert does not prove no incident occurred.
Analyze what is known and decide containment
Record discovery time and time zone, affected identity/device/data references, observed facts and what remains uncertain. Establish scope and impact with available evidence. A named authorized responder decides how to limit harm, preserve evidence and protect dependent services. Containment may need to happen while analysis continues. Record action, authority, time, result and side effects. Avoid routine reboots, deletion or reimaging that could destroy evidence.
Recover and support users
Address the cause and unauthorized access before approving return to service. Use a known-good recovery method, check access and business function, monitor for recurrence and give users clear instructions. Define who may approve restoration and close remaining actions. Restoring a backup or resetting one password does not by itself establish recovery.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the response works.
3.6.1[a]
Trace a safe rehearsal or actual restricted response record through the people, access, tools and assistance needed to handle an incident.
Records to keep: Plan/version, named roles and backups, available access, response records and capability gaps.
3.6.1[b]
Check preparation covers contacts, responsibilities, reporting access, evidence locations and an alternate way to work if normal systems fail.
Records to keep: Current contact checks, approvals, access prerequisites, provider duties and offline instructions.
3.6.1[c]
Show how a staff report or relevant alert reaches an assigned responder and is escalated.
Records to keep: Detection sources, review coverage, safe test or actual receipt and response references.
3.6.1[d]
Review how facts are gathered, uncertainty is recorded and affected systems/data/business impact are analyzed.
Records to keep: Timeline, scoped investigation, source references, hypotheses kept separate from facts and missing evidence.
3.6.1[e]
Check a responsible person can choose and verify authorized containment while considering evidence and dependencies.
Records to keep: Authority, selected action, expected impact, observed result and recovery/alternate-access arrangements.
3.6.1[f]
Check recovery has defined acceptance checks, an approver and follow-up monitoring after the cause and unauthorized access are addressed.
Records to keep: Recovery source, changes, access/business tests, approval, monitoring and unresolved work.
3.6.1[g]
Ask representative users how to report, whom to trust for instructions and what to do while responders investigate.
Records to keep: Staff instructions, alternate contact route, reporting exercise and user follow-up/support records.
Records to keep
Approved roles, contacts, provider responsibilities and accessible response instructions.
Restricted timeline, analysis, authorized containment, recovery checks and user communications. Use references in ordinary trackers.
If a check fails
If the usual administrator or communications service is unavailable, use the approved backup and trusted alternate route. Escalate to qualified assistance if the team cannot contain or investigate safely. Record that limitation; do not turn off working protections or rebuild systems simply to clear an alert.
Working with a small budget
Start with existing event logs, service audit records, supported administration tools, Office materials and a phone/contact plan. Manual coordination can work if it provides the necessary coverage. Built-in Windows antivirus does not include every Defender investigation or isolation feature; advanced response services and specialist help can cost money.
Maintain a usable record and a reporting process that works under pressure. Know the internal officials, external authorities and other contract recipients before an incident. Do not confuse a drafted message with a delivered report.
Official requirement and assessment objectives
Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.6.2
Objective
Official text
3.6.2[a]
incidents are tracked.
3.6.2[b]
incidents are documented.
3.6.2[c]
authorities to whom incidents are to be reported are identified.
3.6.2[d]
organizational officials to whom incidents are to be reported are identified.
3.6.2[e]
identified authorities are notified of incidents.
3.6.2[f]
identified organizational officials are notified of incidents.
What to do
Open a restricted incident record
Assign an incident ID, owner and backup. Record discovery time with time zone, reported source, affected references, current impact and evidence location. Keep a timeline of decisions, actions, notifications, results and unknowns. Protect originals and track who collected or transferred evidence, when and how. Keep sensitive details out of broad tickets and ordinary email.
Prepare the reporting matrix
For each applicable contract, law or policy, identify the trigger, timing rule, recipient, approved channel, required access, reporting owner and backup. Include internal business/security officials and relevant prime/customer/provider obligations. Have the responsible contracts/legal personnel confirm applicability and deadlines. Do not invent one deadline for every incident or wait for proof of exfiltration before evaluating a reporting trigger.
Send required notifications and retain the result
Use the authorized destination and approved information handling. Record actual submission time and time zone, report/receipt reference, recipient and follow-up. Escalate failed delivery or unavailable portal access promptly through the designated process. An internal ticket, vendor notification or call to an insurer does not establish that a required government or customer report was submitted.
Preserve and follow through
Apply the retention and preservation duties that actually govern the incident. Restrict evidence access, retain originals with their context and record integrity checks and transfers where appropriate. Track requested updates, evidence requests, recovery approval and lessons learned. A cloud service retention window or VM snapshot alone does not prove complete evidence preservation.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the response works.
3.6.2[a]
Trace an incident ID through ownership, state, actions and follow-up without losing open work.
Records to keep: Restricted register and linked action history, including current owner and unresolved items.
3.6.2[b]
Check the record explains discovery, scope, facts/unknowns, decisions, evidence references and results.
Records to keep: Dated timeline with time zones, decision basis, evidence handling and review references.
3.6.2[c]
Locate the external reporting authorities and applicable triggers, timing and approved destinations.
Records to keep: Reviewed contract/legal reporting matrix, portal/access prerequisites and backup responsibility.
3.6.2[d]
Locate the designated internal officials, escalation route and backups.
Records to keep: Approved internal contact matrix, role responsibilities and contact-route checks.
3.6.2[e]
Check required external notifications against actual restricted submission/receipt records. Rehearse without submitting a false report.
Records to keep: Trigger decision, authorized recipient, submission time, receipt/reference, updates or documented failure escalation.
3.6.2[f]
Check required internal notifications reached the designated officials and were escalated when needed.
Records to keep: Recipient and time, delivery/acknowledgment reference, backup escalation and resulting decisions.
Records to keep
Restricted incident register and evidence references, with facts separate from assumptions.
Confirmed internal/external reporting matrix, actual notification receipts and failed-delivery escalation.
Applicable preservation decisions, collection/transfer records and follow-up actions.
If a check fails
If a reporting channel fails or access is missing, invoke the approved escalation and record attempts and times. Obtain current official instructions through a verified route. Do not assume a help request extends a deadline, or delay a required report until every fact is known. Keep reporting and technical response moving together.
Working with a small budget
Use the free incident register and action tracker in an approved restricted location. A Word contact/reporting matrix can provide a practical starting point. Verify portal prerequisites in advance; some reporting credentials, evidence storage and legal/forensic assistance may have costs. These templates are not a reporting service.
Run a test with defined goals, participants and observations. Find out where the response breaks down, assign corrections and check the repair. Merely downloading a plan or reading a scenario does not show the capability was tested.
Official requirement and assessment objectives
Test the organizational incident response capability.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.6.3
Objective
Official text
3.6.3
Determine if the incident response capability is tested.
What to do
Choose what the test will establish
Select a scenario relevant to the systems and people in scope. Define objectives, participants, roles, evaluator, safe boundaries and success criteria. Set a schedule and change-triggered retests appropriate to your risk and applicable obligations. This Revision 2 requirement does not prescribe one universal annual frequency.
Walk through the real decision process safely
Use fictional accounts, messages and data. Ask participants to find their actual approved plan and contact route, analyze the situation, identify authorized containment/recovery and make the reporting decision. Do not call emergency services, submit government reports, run malware, disable real users or disrupt production for a tabletop. Arrange any technical tests separately with authorization and recovery.
Record observations and follow up
Capture actual date, attendees/roles, actions, expected versus observed results, missing access, delayed decisions and limits. Mark a proposed action as not performed. Assign each failure an owner, due date and retest. A discussion can test coordination and decisions; it does not prove that device isolation, backup restore, session revocation or portal submission works.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the response works.
3.6.3
Examine an actually conducted test with defined scope, observed results, limitations and assigned follow-up. Verify a failed step is corrected and retested where needed.
Records to keep: Test plan/version, date, participants, observations, after-action record, owners/dates and retest results. Do not replace observations with this example answer key.
Records to keep
Test objectives, method, participants, actual date and safe scope.
Expected versus observed results, unperformed actions, corrections and retest references.
If a check fails
Stop a rehearsal if it affects a real system or generates an actual report/alert. Use the real incident process if harm occurred. Keep that record separate from the exercise, then repair the unsafe test design before resuming. Do not backdate attendance, results or technical checks.
Working with a small budget
Start with the three fictional exercises below and the Word pack, record actual observations in the Excel action tracker and review the plan together. Free public exercise resources can add variety. A paid simulation platform is optional; a completed discussion does not establish every technical capability.
CMMC reporting and contract reporting are separate checks
CMMC 3.6.2 asks whether incidents are tracked, documented and reported to designated internal officials and external authorities. Your contracts and applicable law determine the specific triggers, recipients and timing. Confirm them with the people responsible for contracts and legal decisions.
Where DFARS 252.204-7012 applies
The clause covers discovery of a cyber incident affecting a covered contractor information system or covered defense information on it, or the ability to perform designated operationally critical support. It requires rapid reporting to DoD within 72 hours of discovery. Do not wait for a completed investigation or confirmed data theft.
Preserve and protect the specified affected-system images and relevant monitoring/packet capture data for at least 90 days from submission of the incident report. Follow the clause and current official instructions for additional evidence and isolated malicious software. Do not email malware to the contracting officer or to this website.
Prepare the clause's required reporting access, including its DoD-approved medium assurance certificate prerequisite, through the official process. Review subcontractor report-number duties and additional contract terms. Notifying a prime alone does not establish DoD reporting.
Trigger, governing clause/policy, timing rule and the event that starts its clock.
Named internal officials, external authorities and other required recipients.
Approved channel, required access, reporting owner and backup.
Actual discovery/submission times with time zones, receipt references, updates and failed-delivery escalation.
Applicable evidence preservation and responsible custodian.
The Word procedure provides editable fields. The spreadsheets hold references and manually reviewed actions; they do not decide reportability, calculate legal deadlines or submit notifications.
Microsoft setup paths
Use the actual tenant, account authority, device join and service instance. The steps below describe preparation and checks. Live containment needs authorization, appropriate access, evidence handling and a supported recovery route. These instructions have not been tested in a Microsoft tenant.
AD DS and hybrid joined Windows
Identify who controls domain accounts, local accounts, devices and synchronized cloud identities. Prepare access to relevant domain-controller, host, identity and application records. A cloud account action does not establish that local/domain access, cached access or every existing session ended. Coordinate cloud and on-premises responders and review service dependencies before acting on a shared or service account.
Microsoft Entra joined Windows
List cloud users, local administrators, application/service identities and connecting devices. Use supported account/session response procedures and verify the resource result. Revocation can take time, and applications can maintain their own sessions. An Entra join or password reset does not prove the endpoint is clean. Include local access, recovery and unwanted methods or application consent in the investigation.
Commercial Microsoft 365 and Azure
Before an incident, confirm roles and access to available identity, mailbox, audit and endpoint records. Use the Audit and Accountability guide to record coverage, retention and gaps.
For a suspected mailbox compromise, use Microsoft's compromised-account procedure with the actual account authority. Preserve relevant records while containing harm. Review sessions, forwarding/rules, authentication methods and application access as applicable; verify results rather than assuming a reset was enough.
If your subscription and device support Defender response actions, inspect the affected device and action status under the authorized procedure. Isolation affects connectivity and can disrupt management. Missing, failed or pending actions remain open; the portal button alone is not evidence that containment succeeded.
Keep exports in restricted approved storage with collection time, source/query range, time zone and collector. Audit retention, event availability and export limits depend on the service and license. Record missing periods; buying a license later does not recreate unavailable evidence.
GCC, GCC High and Azure Government
Record the identity tenant and each service cloud separately. Use that environment's official portals, national-cloud endpoints, support route and documented feature availability. GCC and GCC High have different arrangements. Check audit access, response features, integrations, provider responsibilities and evidence location before an incident. Keep CUI and evidence inside the approved boundary; do not use a commercial upload tool as an unreviewed workaround.
Azure Virtual Desktop
Map the AVD service, actual AD DS/hybrid/Entra host join, each session host, users, applications and profile/storage services. Separate provider actions from customer response duties. A shared host incident can affect several users.
Review selected AVD diagnostics alongside host, identity and storage records. Diagnostic settings must already be configured for the data you expect; service connection logs do not cover every action inside a session. Log Analytics ingestion, retention and supporting resources can cost money.
Prepare an authorized method to limit harm and preserve evidence before scale-in, image replacement or other automation removes an affected host. Consider access to shared storage, users, management and collection. A VM snapshot can be one record, but does not establish complete forensic collection or include every memory, profile and external service record.
Agree recovery from a known-good source, validation of identity/profile/storage access, business acceptance and monitoring. Rebuilding a host does not remove unauthorized cloud sessions or persistence elsewhere. Never treat signing a user out as complete containment of the incident.
Included tools and costs to check
Use the free Word/Excel materials, supported Windows event tools, existing service records and a tested contact process first. Defender Antivirus alone is different from licensed Defender response services. Automated investigations, endpoint actions, longer retention, SIEM storage and forensic help may require additional subscriptions or spending. Check exact licenses, permissions, onboarding and cloud support. A no-cost plan still needs people who can carry it out.
These situations are fictional. Rehearse with the response lead, technical staff, reporting owner and business decision maker. Use the Word exercise pack for facilitator notes. Record what participants actually did and what was only proposed. These example answers are not test results.
Supports 3.6.1, 3.6.2, 3.6.3
The password was reset but mailbox access is still uncertain
Fictional exercise: a contractor receives a report that an employee's mailbox sent an unexpected file-sharing message. The mailbox may contain covered defense information. An administrator has reset the password, but nobody has reviewed sessions, forwarding, authentication methods or application access. The usual incident lead is unavailable.
Discuss
Who takes the lead and how do users reach the team if the mailbox cannot be trusted?
What facts, evidence and affected connections need review before recovery is approved?
Which reporting triggers and recipients need a decision while the investigation continues?
What a useful response includes
Use the approved backup lead and alternate trusted contact route. Open a restricted incident record with discovery time and time zone, observed facts, unknowns and evidence references.
Plan authorized checks of cloud and any on-premises account authority, sign-ins, sessions, mailbox rules, authentication methods and application access. A password reset does not prove every session or persistence path ended. Preserve evidence while responders contain harm, and verify recovery before returning access.
Use the actual contract/legal reporting matrix. Evaluate covered-system/data impact and required recipients without waiting for a final investigation. In this discussion, record proposed actions and fictional receipt references only; do not change accounts or submit reports.
Lesson: An account action is one part of response. The team still needs analysis, reporting, user instructions and a supported recovery decision. Missing evidence remains unknown.
Record: Write fictional incident and action rows, identify the backup owner, list unperformed technical checks and reporting decisions, then assign corrections and a retest.
Supports 3.6.1, 3.6.2, 3.6.3
An AVD host is about to be rebuilt before evidence is preserved
Fictional exercise: a shared AVD session host shows unexpected processes and file changes. Automation will soon remove the host. Users share the host but have separate profiles in a storage service. Service connection logs exist, while the availability of host and profile evidence is unknown. Someone suggests rebuilding immediately to restore service.
Discuss
Who can authorize containment and prevent automated deletion while limiting further harm?
Which host, identity, profile/storage and service records might be needed?
What would demonstrate safe recovery without treating a fresh VM as proof that the incident ended?
What a useful response includes
Escalate to the authorized responder and service owner. Review effects on other users, management access and evidence before an approved containment or automation change. A discussion does not isolate the host or pause a real job.
Map the session host, users, identity provider, applications, profile/storage and provider duties. Plan protected collection with qualified help. A connection log, snapshot or rebuilt image alone does not establish full evidence preservation or scope.
Evaluate reporting and preservation duties in parallel. Define recovery from a known-good source, access and business checks, approval and monitoring for recurrence. Track lost or unavailable evidence and any remaining unauthorized access rather than marking the incident resolved on rebuild.
Lesson: Shared hosts and separate profile storage create multiple places to investigate. Automatic replacement can remove evidence without removing the cause or other affected access.
Record: Record fictional host and evidence references, the containment decision and dependencies, reporting review, recovery acceptance checks, owners and retest work. Do not collect actual memory or incident files for this exercise.
Supports 3.6.1, 3.6.2, 3.6.3
A required report cannot wait for the usual contact to return
Fictional exercise: the organization's contract includes DFARS 252.204-7012. The team discovers a cyber incident affecting a covered contractor information system. The investigation is incomplete. Only one person has prepared the reporting access, that person is unavailable and a subcontractor has sent a separate incident notice to the prime.
Discuss
When does the applicable reporting clock start and what information should the team preserve?
Who has backup responsibility and what happens if portal access fails?
Does notifying the prime alone establish that the required report to DoD was submitted?
What a useful response includes
For this fictional contract and trigger, evaluate rapid reporting within 72 hours of discovery. Do not wait for a final investigation. Identify the applicable preservation duty for specified images and relevant monitoring/packet capture data, measured for at least 90 days from report submission.
Use the approved backup reporting owner and current official process. Record failed access and escalate promptly; do not assume the failure extends a deadline. In a tabletop, inspect prerequisite and escalation records without submitting a false report or sharing credentials.
Separate internal, prime and government recipients. Review the clause's subcontract reporting and incident-report-number duties, plus any additional contract terms. Record actual receipt references only for notifications that really occurred; use clearly fictional references in the exercise.
Lesson: An investigation, an internal ticket and a notice to another party do not establish timely submission to every required recipient. Reporting access and backup responsibility belong in preparation.
Record: Write a fictional reporting decision, discovery time and time zone, timing rule, responsible owner/backup, approved destination, preservation reference and missing-access correction. Do not calculate or submit a live report.
Five free Word and Excel materials
Download a copy and adapt it in your approved environment. Blank inputs and fictional examples are separate. Use restricted references; keep incident details, CUI and evidence in approved storage. The templates do not calculate a compliance score.
Excel
Incident register
Track discovery, scope, ownership, evidence references, reporting decisions and recovery without putting sensitive incident details in an ordinary spreadsheet.
Ready for record review means a row is prepared for someone to examine. It is not a resolved incident, completed notification or compliance result. Keep remaining limitations and next actions explicit.
Turn a rehearsal failure into a specific next action
In a fictional exercise, staff find the response plan but cannot identify a backup reporting owner. The team records that failure and keeps the relevant preparation and reporting objectives as Evidence to check in the Level 2 gap-and-action worksheet. It assigns the missing access/contact work and retests the route. Reading the exercise answer does not close the gap.
Sources reviewed October 27, 2026. Official text is separate from our suggestions. Product documentation supports the features and limits described; it does not establish that your deployment works or that a service is suitable for your CUI. Reporting duties depend on actual contracts and applicable law. The examples do not determine reportability or replace an official assessment.
Response capability, internal/external reporting and tests including tabletop exercises. A suggested exercise schedule is not a universal required frequency.
Contract-specific incident reporting, specified evidence preservation, malware handling and subcontractor duties. Read the version and additional terms that apply to your contract.
Account recovery and checks for unwanted forwarding, authentication methods and application consent. Adapt actions to the actual account authority and approval.
Device isolation and other actions depend on subscription, operating system, onboarding, permissions and connectivity. Built-in antivirus is not the full Defender response service.
Configured diagnostic settings send selected AVD activity to Log Analytics. Service connection data does not replace session-host and application evidence.
Session hosts and supporting services need their own security controls. Include shared hosts, identity and profile/storage dependencies in response planning.
An additional free rehearsal resource for small organizations. Check registration, handling terms and suitability before using an external service; keep actual CUI and incident evidence in approved systems.
Email cmmc@purposefulsecurity.com with a general description. Keep CUI, incident details, credentials, logs, evidence and completed worksheets in your approved environment. Do not email them to us.