CMMC incident response automation with Shuffle

What CMMC Level 2 asks of incident response, and where automation fits

IR.L2-3.6.1 to 3.6.3 require an operational incident-handling capability, a tracking and reporting process, and a way to show both work. Automation produces the records, timers and evidence those requirements depend on, but people still decide what an incident is, how far containment goes and what gets reported. Consider a defense contractor that handles covered defense information. Its contract carries DFARS 252.204-7012, its CMMC Level 2 scope is the 110 NIST SP 800-171 Rev. 2 requirements, and its security team is small. That team must detect, handle, track and report incidents without a dedicated function for each step. The Level 2 requirement IDs map to the assessment objectives in NIST SP 800-171A (June 2018), which ask the assessor to see preparation, detection, analysis, containment, recovery and user response activities, plus incident records and notifications to the right officials and authorities.

Current status matters for planning. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and the DFARS 252.204-7012 obligations remain in force. The DFARS clause requires rapid reporting within 72 hours of discovery of a cyber incident, so the reporting timer does not depend on the certification schedule. Confirm with your contracting officer and the current DoW CIO guidance which obligations apply to your contracts before you rely on any phase date.

In practice, a Shuffle workflow can open a case when an alert from a source such as Wazuh is triaged, record each action it takes, start a 72-hour clock from the discovery time the analyst enters, and collect the evidence the DFARS review step names, such as affected hosts, servers, data and user accounts. The analyst still classifies the event, decides whether it is a reportable cyber incident and approves any destructive containment. Confirm with your assessor how the incident register, reporting log and lessons-learned records will be presented as evidence, and ask your implementation partner which steps are automated and which need a recorded human approval.

How IR.L2-3.6.1 to 3.6.3 map to playbooks, case tracking and reporting in Shuffle

This table maps each CMMC Level 2 incident response requirement and the DFARS 72-hour reporting step to the function it asks for and to how that function can be built in self-hosted Shuffle. Read each row as a design target: the configuration column describes where the evidence is produced, and the assessor's objectives still decide whether the requirement is met.

Requirement	What the function must do	How to configure it on self-hosted Shuffle
IR.L2-3.6.1 (operational handling)	Show an operational incident-handling capability covering preparation, detection, analysis, containment, recovery and user response, assessed against the seven NIST SP 800-171A objectives.	Build one playbook per stage, with a documented trigger, owner and output for each. Store the runbook versions, playbook export history and run logs in the case record so each stage can be shown in operation.
IR.L2-3.6.1 (containment gate)	Containment actions on endpoints, accounts or network paths must be controlled and traceable, not left to ad hoc changes.	Place a manual approval step before any destructive action, such as isolating a host or disabling an account. Record the approver and timestamp in the workflow output so the decision is evidenced.
IR.L2-3.6.2 (tracking and documenting)	Track and document each incident from first alert to closure, using records that a reviewer can follow.	Create a case record at the first alert and have each playbook stage write its enrichment results, decisions and actions to that record. Keep the case system of record outside the automation platform if your reviewers expect a separate tool.
IR.L2-3.6.2 (reporting to officials and authorities)	Identify the internal officials and external authorities who receive incident reports, and show that each notification was sent.	Maintain a routing table in the playbook that maps incident category to recipients. Log each notification as a workflow step with its result, so the record shows both who was identified and who was notified.
DFARS 252.204-7012 (72-hour rapid report)	Report cyber incidents to DoD within 72 hours of discovery, using the reporting channel at dibnet.dod.mil.	Start a reporting timer when the case is created or confirmed as a cyber incident. Add escalation tasks at set intervals before the deadline and a checklist step that a named person completes in the DoD reporting portal.
DFARS 252.204-7012 paragraph (c) compromise review	Review for evidence of compromised computers, servers, covered defense information and user accounts, and record the findings.	Add enrichment steps that query endpoint, identity and log sources for each affected asset class. Output the results into the case so the review is documented for each incident, including negative findings.
IR.L2-3.6.3 (incident response testing)	The requirement is about testing the incident response capability. Testing evidence must be confirmed against the CMMC Level 2 assessment guide before you rely on any playbook run as proof.	Use test cases and tabletop records in your case tool to document exercises. Confirm with your assessor and the assessment guide what form of testing evidence they will accept.

How the DFARS 72-hour clock starts and how a playbook tracks it

The 72-hour clock starts at discovery, not at the moment the incident happened or when someone decides it is reportable. Under DFARS 252.204-7012, a cyber incident is any action taken through computer networks that results in a compromise, or an actual or potentially adverse effect on an information system or its information. Compromise is defined broadly enough to include unauthorized disclosure, modification, destruction or loss, and copying information to unauthorized media. That breadth means a playbook should treat a suspicious alert on a covered system as a candidate incident from the first minute, and should record the discovery time as an auditable event rather than reconstructing it later. Confirm with your counsel and your DIBNet registration owner exactly which systems and accounts fall under covered defense information in your environment, because the workflow can only route what you have scoped.

In Shuffle, the first workflow steps can do the mechanical work. A trigger from your SIEM or EDR alert source can stamp the discovery time in UTC, write it to the case record, and open a case in your case management tool through its API. The workflow can then run the compromise review that paragraph (c) of the clause calls for: pull the affected host, account and data identifiers from the alert, query authentication logs for the user accounts involved, and attach the results to the case as evidence. Each action should be logged with its run identifier so the review is reproducible. When the review finishes, the playbook creates a reporting task that shows the deadline 72 hours after the recorded discovery time and assigns it to a named officer. Illustratively, an alert discovered at 09:00 UTC on a Monday would produce a task due at 09:00 UTC on Thursday, with reminders to the reporting owner before that point.

The reporting decision and the submission to DoD through DIBNet remain human steps. The workflow should present the evidence and the deadline, then stop at an approval gate that requires a named person to decide whether the event meets the clause definition, to report, and to submit. Do not let an automated step submit or mark an incident as closed. Ask your implementation partner to show how the approval gate, the deadline calculation and the audit log are tested before production, and confirm with your contracting officer or counsel what the clause requires in your contracts, since the workflow records compliance but does not provide it.

Which self-hosted platforms fit each part of the incident workflow

An incident under CMMC Level 2 moves from detection to response to a reporting decision, and each stage needs a different platform. The cards below show which open-source tool fills each role, what it records, and what to verify before the incident record can support IR.L2-3.6.1 to 3.6.3 and the DFARS 72-hour report.

Shuffle as the playbook engine

Shuffle runs the triage, enrichment and response playbooks and keeps a record of what each workflow did. It is licensed under AGPL-3.0, and v2.3.0 was published on September 28, 2026. Architecture options include Docker Compose, Docker Swarm, a hybrid with Shuffle Cloud, and Kubernetes with Helm charts. Confirm the OpenSearch backend sizing, that more than one Orborus node runs for high availability, and that the SHUFFLE_ENCRYPTION_MODIFIER secret is backed up, because losing it breaks every saved app authentication.

Wazuh as the alert and endpoint source

Wazuh supplies host and endpoint alerts through its agents, decoders and rules, and stores them in its indexer for the dashboard and for Shuffle to query. It is distributed under GPL-2.0, and the 4.14 line includes 4.14.9. The dashboard offers prebuilt views for HIPAA and NIST 800-53, which help with evidence review but do not map to CMMC requirement IDs. Check agent coverage for the CUI systems in scope and confirm which alert fields Shuffle will receive.

Suricata and Zeek or Security Onion for network sources

Network detections come from Suricata alerts and Zeek logs, either deployed directly or bundled in Security Onion. Suricata is GPL-2.0 and Zeek uses a BSD-style license, while Security Onion is licensed under Elastic License 2.0, so review that license with counsel before use. Sensor placement determines what the reporting review can see, particularly traffic into CUI enclaves. Confirm which segments carry sensors and how long packet and log data is retained.

MISP or OpenCTI for indicator enrichment

Enrichment playbooks in Shuffle can check file hashes, IP addresses and domains against a threat intelligence platform before an analyst sees the alert. MISP is licensed under AGPL-3.0, and OpenCTI ships a Community Edition under Apache 2.0 alongside an Enterprise Edition under a separate license. Enrichment results should be recorded in the case so that the investigation can show what was checked. Confirm whether indicators shared with external communities contain CUI before enabling sharing.

Keycloak, authentik or ZITADEL for SSO

Analysts and approvers need individual accounts when they log in to Shuffle and to the case tool, so that each action in the audit trail traces to a person. Keycloak is Apache-2.0 and supports OpenID Connect and SAML 2.0, authentik is MIT outside its enterprise directory, and ZITADEL is AGPL-3.0 with MFA and passkeys. Shuffle supports SAML and OpenID Connect, so choose OpenID Connect where possible. Confirm that MFA is enforced for every account with rights to run response actions.

OpenBao for stored secrets

API keys for Wazuh, the threat intelligence platform and the case tool should not sit in plain-text workflow configuration or container environment files. OpenBao is MPL-2.0 licensed, hosted under the OpenSSF, and can hold these secrets, which Shuffle's app credentials can be sourced from. Confirm how each secret is rotated and who can read it. HashiCorp Vault 1.15.0 and later uses the Business Source License, so check whether that license fits your procurement policy.

Configuration decisions that decide whether the records hold up

The configuration choices that matter most for CMMC incident response are the ones that keep the evidence intact. An assessor reviewing IR.L2-3.6.2 will sample the workflow execution history and the case record, so those must survive restarts, node failures and upgrades. Shuffle's architecture is the first place to plan for this. Its backend stores workflow data in an OpenSearch document database, and the Shuffle high availability guidance recommends an OpenSearch cluster rather than a single node. Run more than one Orborus node so workflows keep executing if one fails, and if several backends share files, plan NFS as the shared store and confirm with your platform team how it is backed up and who can write to it. Test a failover during the rollout and keep the results, because a playbook that silently stopped halfway through a reporting step is a gap in the record.

The encryption key is the configuration item most likely to cause a quiet failure. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and the configuration documentation warns that losing or changing it breaks every saved app authentication. Store that value in your approved secrets vault, record who holds a copy, and include it in your recovery procedure with a documented rebuild test. Plan licensing the same way. Shuffle prices on app runs, meaning actions that actually execute in a workflow, so a playbook that polls a SIEM every few minutes can consume runs faster than the number of incidents suggests. Estimate runs from your alert volume and ask the vendor or partner to show the calculation. Also confirm that the open-source edition includes the features your playbooks need, because since v2.1.1 the limits between the open-source and enterprise editions are actively enforced.

For environments without internet access, the offline question affects both the SIEM and the SOAR. Wazuh publishes an offline installation guide, and its vulnerability detection can use an offline vulnerability repository instead of the Wazuh Cyber Threat Intelligence platform, so the alert sources feeding your playbooks can run inside a controlled enclave. Confirm which Shuffle app containers, enrichment feeds and update channels can be mirrored into that enclave, because a playbook that reaches out to a public service at run time will fail or leave a gap in the record. Keep a dated record of each container version and playbook revision in use during a reportable incident, so the workflow history can be tied to the exact configuration an assessor asks about.

How deployment constraints change the design for a defense contractor

This model fits a contractor whose general corporate network and cloud accounts sit outside the CUI boundary, with a separate enclave for covered systems. The self-hosted Shuffle server, OpenSearch store and Orborus workers can run in the company's own cloud accounts or data center, and playbooks can call corporate identity, endpoint and ticketing tools directly. The main risk is scope creep: alerts from enclave systems can be copied into corporate tools that were never assessed.

Log location: Confirm whether enclave alerts are forwarded to the SOAR, and if so whether the destination is inside the assessed boundary.
Administration: Limit who can change workflows and read saved app credentials, since those are encrypted with the SHUFFLE_ENCRYPTION_MODIFIER secret.
Connector reach: List every app that can write to enclave systems, such as an EDR or firewall app, and mark those actions for approval.
Case records: Decide whether incident records that mention CUI are stored in the SOAR's OpenSearch store or in a case system inside the boundary.
Reporting path: Map which playbook step prepares the DFARS 72-hour report and who submits it.

Confirm the boundary diagram, the list of in-scope assets and the placement of the SOAR with the security officer before the assessor reviews the scope.

What assessors ask to see, and which component produces it

This table pairs each evidence item an assessor is likely to request for the CMMC Level 2 incident response requirements with the component that produces it. Read it as a checklist: if an item has no owner or no retained copy, the requirement is harder to show as MET. Evidence must be in final form, not drafts, to count toward a MET determination.

Evidence item	Produced by	What the assessor checks
Written incident response plan	Documented process owned by the security team, stored in version control or the document system	Covers preparation, detection, analysis, containment, recovery and user response, and is approved and in final form
Incident tickets and case history	Case management record linked to alerts and Shuffle workflow IDs	Incidents are tracked and documented from detection through closure, with timestamps and owners
Workflow execution history	Shuffle workflow execution records stored in the OpenSearch backend	Automated triage, enrichment and notification steps ran, with inputs, outputs and any failed runs
Detection source records	Wazuh alerts from the indexer, or network sensor logs from Suricata and Zeek	The event that triggered the incident is traceable to a specific source, host and time
DIBNet submission records and timestamps	Reporting step in the playbook plus the manual submission receipt from dibnet.dod.mil	Reports under DFARS 252.204-7012 were filed within 72 hours of discovery, with proof of submission time
Reporting contact lists	Maintained roster of designated officials, DoD reporting contacts and customer contacts	Each required recipient is identified, current and reachable, with the escalation path written down
Test or tabletop records	Exercise reports and playbook test runs stored with dates and participants	Incident response capability is tested, and findings led to recorded changes
POA&M entries, where applicable	Plan of action and milestones tracked in the GRC or ticketing system	Open items meet the conditions in 32 CFR 170.21 and have owners and dates

What do buyers ask before they build CMMC incident response automation?

How much effort does CMMC incident response automation take, and what drives it?

Effort is driven mainly by the number of playbooks, the number of alert sources, how many connectors have to be built or adapted, and how many approval gates the team wants before any containment step runs. Each playbook needs written triggers, enrichment steps, decision points, evidence capture and a tested rollback path. Connector work grows with every tool that lacks an existing Shuffle app, because custom apps are built from OpenAPI specifications or written with the Shuffle app SDK. Ask any partner to break the quote into playbooks, sources, connectors and approval design, so you can see which items drive the total.

Can our internal team build this in-house with Shuffle?

A capable internal team can build it, provided it has people who understand both the incident response requirements and the Shuffle architecture. Shuffle's open-source edition includes all features, so licensing is not the constraint. The harder work is operating the platform: running the server with OpenSearch, keeping more than one Orborus node for high availability, protecting the SHUFFLE_ENCRYPTION_MODIFIER secret, and maintaining connectors as vendor APIs change. Also plan for the evidence side, since playbooks must produce records that match the assessment objectives. Many teams split the work, keeping decision-making in-house and bringing in outside help for the build and the first rollout.

Does the suspension of CMMC Phase II change our incident response work?

No. The Department of War suspended CMMC Phase II on 13 July 2026, but Phase I self-assessments, SPRS postings, annual affirmations and the DFARS 252.204-7012 obligations remain in place. The 72-hour reporting requirement applies to any cyber incident discovered on a covered contractor system, whatever the certification timeline. The incident response requirements in NIST SP 800-171 Rev. 2, which CMMC Level 2 incorporates, still apply. Confirm the current status with your contracting officer and the DoW CIO's CMMC page, because the review by the CMMC Reform Task Force may change later milestones.

What does our organization need to supply before the work starts?

Most of the input has to come from your side. Expect to provide your current incident response plan, a named list of internal and external contacts including the designated officials who receive reports, and an inventory of systems and accounts within the assessment scope. You also need a clear description of the CUI boundary, showing which networks, enclaves, cloud tenants and users handle covered defense information. Access to existing SIEM, EDR, email and identity logs, plus change control and approval rules for automated containment, will also be needed. Confirm the exact list in the written scope before kickoff.

How long does delivery take for a CMMC incident response automation project?

The duration depends on the agreed scope, which DeployOpen sets out in writing before work starts, so no timeline is stated here. The main variables are the number of playbooks, the number of connectors that must be built, how many systems are inside the CUI boundary, and how quickly your team can review approval gates and evidence samples. Ask for milestones tied to deliverables, such as a tested reporting workflow for the DFARS 72-hour step, a first set of triage playbooks, and a documented test run. Clarify which items depend on your inputs, since delays on contacts or inventories often extend the schedule.

Does DeployOpen certify that our CMMC environment is compliant?

No. DeployOpen plans, implements, hardens and documents the incident response systems, and it prepares the controls and evidence that an assessment will examine. It does not issue audit reports, attestations or certifications. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, and assessors decide whether each requirement is met. Self-assessments remain the organization's own responsibility. Under 32 CFR 170.16, 170.17 and 170.24(b), a requirement counts as met only when the applicable objectives are satisfied with evidence in final form, so plan your evidence retention accordingly.

What automation alone will not satisfy

Shuffle can gather evidence, route cases and open reporting tasks quickly, but IR.L2-3.6.1 to 3.6.3 are assessed against people, decisions and records as much as tooling. The cards below cover the parts an assessor will ask to see that no playbook can produce on its own.

Written plan and named roles

The incident-handling capability under IR.L2-3.6.1 must be operational, which means a written plan that names who declares an incident, who leads containment, who approves destructive actions and who backs them up when they are unavailable. Each playbook in Shuffle should point to a role in that plan, not to a shared mailbox. Check that the plan covers preparation, detection, analysis, containment, recovery and user response, and that the people named in it have actually run the steps.

The reporting decision and legal review

Whether an event is a cyber incident under DFARS 252.204-7012 is a judgment that a playbook can prepare but should not finally make. Someone accountable must decide whether covered defense information was compromised, including through user accounts, and then start the report to DoD within the 72-hour window. Document who reviewed the decision, when the clock started at discovery, and which counsel or contracts lead was consulted.

Testing and tabletop exercises

Playbooks that have never run against a realistic alert are not evidence of a working capability. Test each Shuffle workflow in a staging environment with sample alerts, then run tabletop exercises that walk the written plan end to end, including the reporting decision. Keep dated records of what was tested, what failed and what changed, because an assessor will ask for the most recent cycle rather than a one-time demonstration.

Training and after-hours staffing

A 72-hour reporting clock does not pause on weekends, so someone must be able to approve containment and start a report outside business hours. Define an on-call rota, train each responder on the playbooks they may trigger, and confirm how alerts reach them if the Shuffle server or the upstream SIEM is down. Staffing gaps and untrained backups are common findings when the plan looks complete on paper.

The assessment and the rule text

Level 2 certification assessments are performed by C3PAOs, but the Department of War suspended Phase II on 13 July 2026, so confirm with your contracting officer whether certification or self-assessment applies to your contracts. Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place. NIST SP 800-171 Rev. 3 changes the requirement wording, so check the Rev. 2 to Rev. 3 change analysis before you design evidence around current text.

How a CMMC incident response automation engagement runs

The sequence moves from a confirmed CUI boundary and a mapped incident response plan to tested Shuffle playbooks, a reporting workflow and runbooks the internal team can operate. Each step closes with a artifact an assessor or internal owner can review.

Confirm scope and the CUI boundary
The engagement starts with a written scope that names the systems that store, process or transmit covered defense information and the systems that connect to them. DeployOpen works with your security lead, IT owner and contracts or compliance contact to agree which environments the playbooks will touch and which are out of bounds. The step closes when the boundary, the in-scope tools and the named decision owners are signed off in the statement of work, so that later evidence can be tied to a defined system set.
Map the existing IR plan to 800-171A objectives
Your current incident response plan and procedures are compared against the assessment objectives in NIST SP 800-171A for IR.L2-3.6.1 and IR.L2-3.6.2, covering preparation, detection, analysis, containment, recovery, user response, tracking, documentation and notification. Gaps are recorded against each objective, not against a general sense of readiness. The output is a gap register that shows which objectives already have procedures, which have only informal practice and which have no artifact at all, and that register sets the order of the remaining steps.
Inventory alert sources and enrichment paths
Every tool that can raise an alert or hold evidence is listed with its owner, log format, retention period and connection method, such as an API, syslog, webhook or a Shuffle app built from an OpenAPI specification. Where a source is a self-hosted SIEM or EDR platform, the inventory records the agent or collector it depends on. The step closes with a source register and a list of enrichment systems, and your team confirms that each source's data can be retrieved during an incident before any playbook is written against it.
Build and test playbooks in staging
DeployOpen builds the first playbooks in a staging Shuffle deployment that mirrors production architecture, with the same app versions, credential handling and worker placement. Each playbook is exercised with replayed or simulated alerts, including the failure paths such as an unreachable API or a missing enrichment result. Playbooks that take containment actions on endpoints or accounts run with those actions disabled until your team has reviewed the test results. The step closes with a test record for each playbook that lists inputs, expected outputs and observed outputs.
Add the reporting workflow and approval gates
A case record is created automatically for each triaged incident, and a reporting workflow tracks the discovery time, the data needed for the DFARS 252.204-7012 review of compromised computers, servers, data and user accounts, and the steps for reporting to DoD through DIBNet. Approval gates require a named person to confirm the report, the containment action or the notification to an external authority before it leaves the platform. The step closes when a tabletop run shows the timer, the approvals and the report package working as designed, and your legal and compliance owners have confirmed the wording.
Collect evidence and hand over runbooks
Playbook execution logs, approval records, case timelines and test records are collected into an evidence folder mapped to IR.L2-3.6.1 and IR.L2-3.6.2, so that the artifacts an assessor will request are already organized. DeployOpen then writes runbooks for the operations team covering routine triage, failed playbook runs, credential rotation for connected tools and the change process for editing playbooks. The step closes with a handover session and a written acceptance that your staff have run each runbook at least once.

How DeployOpen works on this

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For CMMC incident response, that means a Shuffle deployment, its playbooks and case records built to the handling, reporting and testing requirements in your own environment, with evidence prepared for the assessment you actually face.

How we scope

Written scope lists the systems in the CUI boundary, the alert sources feeding Shuffle and the playbooks to build first
Scope names the 72-hour DFARS reporting steps, the reporting contacts and who approves each outbound report
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts
A quote follows from the written scope, and we list which components sit outside it

How we build

Deploy Shuffle in the architecture your client picks, including high availability options documented for the platform
Build playbooks for triage, enrichment and containment, with approval gates on actions that affect CUI systems
Store app credentials under the Shuffle encryption secret, with documented key custody and backup procedures
Test each workflow against recorded sample alerts before it runs against production sources

How we hand over

Document each playbook with its trigger, decision points, reporting branch and the IR.L2 requirement it supports
Deliver the case tracking and reporting workflow runbook, including the evidence checklist for a DFARS cyber incident review
Train the responders and officials who approve reports on running and changing playbooks safely
Provide a configuration and version record so auditors can trace which workflow produced each incident record

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Retainers can cover Shuffle version upgrades, connector updates and periodic playbook testing
Re-test workflows after changes to source systems, CMMC scope or the DFARS reporting process
Coordinate with your independent C3PAO or self-assessment team, which issues any assessment outcome

Security automation for CMMC incident response