CMMC Level 3 requirements: what the 24 controls ask for

What CMMC Level 3 requires beyond Level 2

A contract or program that now requires CMMC Level 3 adds 24 selected requirements from NIST SP 800-172 on top of the Level 2 requirements, which are drawn from NIST SP 800-171 Rev. 2. Several of the Level 3 requirements carry DoD-assigned organization-defined parameters, so the exact obligations depend on the program and on what the government assigns. Level 3 certification is performed by DCMA DIBCAC, and no other body can issue it. Your organization owns its controls and evidence, while DIBCAC alone records the outcome of the certification assessment.

The Department of War suspended CMMC Phase II on 13 July 2026, and the Level 3 timing and clause language in your contract may not match what was originally scheduled. Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place. Before you plan engineering work, ask the contracting officer which CMMC clause and level appear in the solicitation or contract, whether a Level 3 certification is required before award or at a later date, and which parameters DoD has assigned. Get the answers in writing, because they define the scope you will need to build and evidence.

Treat the Level 3 requirements as a separate build on top of a Level 2 environment that already passes. The Level 3 list includes a 24/7 security operations capability, threat hunting, annual penetration testing and isolation of specialized assets such as operational technology and test equipment. Each of these needs an owner, a documented procedure and evidence that holds up in a DIBCAC review. Ask whether your current Level 2 boundary includes every system the Level 3 parameters will reach, because adding scope late is the most common source of rework. Plan for a Level 2 certification first, since DIBCAC assesses Level 3 only after that prerequisite is met.

How the 24 requirements group into operational areas

IR.L3-3.6.1e asks for a security operations center capability that runs 24 hours a day, 7 days a week, and allows remote or on-call staff to cover parts of that schedule. IR.L3-3.6.2e asks for a cyber incident response team that can be deployed within 24 hours. An assessor will read these together, because monitoring that runs around the clock still fails if no one can act on what it finds. The expectation is operational, so evidence should show how the capability works on an ordinary night, beyond what the plan describes.

Shift coverage: a rota or on-call roster covering nights, weekends and holidays, with named backups and escalation paths.
Alert handling records: queue and ticket timestamps showing triage happened across shifts, including periods outside business hours.
Deployment clock: a documented activation procedure and contact list that show how the team is assembled and how long each step takes.
Playbooks: runbooks for common incident types that connect detections to response steps and named owners.
Exercise results: records of drills that tested the 24-hour deployment and remote analyst access.

Before an assessment, confirm that your shift model, activation clock and remote access arrangements have been exercised, and ask your assessor how they plan to sample evidence across shifts.

What a 24/7 SOC and a 24-hour response team must show

The two Level 3 incident response requirements set a staffing standard and a response clock, and an assessor will test both against records rather than org charts. The cards below cover what the organization decides, what to hold as evidence, and where a remote or on-call model stops being acceptable.

The 24/7 SOC requirement

IR.L3-3.6.1e requires a security operations center capability that operates 24/7, and it allows remote or on-call staff to cover off-hours. The organization decides whether the SOC is in-house, hybrid or outsourced, but it stays accountable for coverage around the clock. Confirm early how the assessor will judge a model where people work from home or are paged after hours, since coverage gaps are usually found in the schedule, not the design.

The 24-hour cyber incident response team

IR.L3-3.6.2e requires a cyber incident response team that can be deployed within 24 hours. The team must be named, trained and reachable, with defined roles for forensics, containment, legal and communications. Test the deployment clock in a drill, because a team that exists only on paper will not meet the requirement when an assessor asks for proof of deployment.

Staffing rosters and on-call schedules

Keep dated rosters that show who covered each shift, including on-call rotations, backups and handoffs for holidays and leave. Gaps in these records are a common finding because the schedule exists but the proof of coverage does not. Store rosters with the system security plan so an assessor can trace a staffed shift to a named person.

Runbooks and escalation records

Runbooks should define triage steps, severity levels, escalation paths and handoff rules from the SOC to the response team. Alert escalation records show that the runbook was followed in practice, with timestamps from detection to acknowledgment. Compare sample tickets against the runbook before the assessment, since mismatches between written procedure and recorded practice are easy for an assessor to spot.

Drill results and corrective actions

Run tabletop and live drills that test both the 24/7 alert path and the 24-hour deployment of the response team. Record the start time, who responded, what was contained and what failed. Track each finding to a closed corrective action, because open findings from drills that were never fixed undermine the claim that the capability works.

Managed SOC provider roles

If a managed SOC provider covers any of these hours, the organization still owns the requirement and must document what the provider does, what it does not do and how its staff are reached. Confirm with the assessor, before scoping, whether the provider's records and personnel count as organizational evidence and how its contract and service levels will be examined.

Threat intelligence, hunting and the annual supply chain plan

Three Level 3 risk assessment requirements ask the organization to act on threats before they become incidents: RA.L3-3.11.1e requires threat intelligence from open or commercial sources and any DoD-provided sources, RA.L3-3.11.2e requires threat hunting on an ongoing, aperiodic basis, and RA.L3-3.11.7e requires a supply chain risk management plan that is updated at least annually. An assessor will look for records that show each one running, not a policy that says it should. For the threat intelligence requirement, that means a feed inventory listing each source, its owner, how often it is ingested, which DoD-provided sources are included, and a dated record of how intelligence changed a detection, a configuration or a risk decision. Confirm with the DoD contracting office which DoD-provided sources apply to your contracts before the assessment, because the requirement names them explicitly.

For threat hunting, the evidence is a hunt log: hypotheses, data sources queried, queries or searches run, the analyst who ran them, results including negative results, and any findings that became tickets, detection rules or incidents. Because the requirement is aperiodic, the schedule should not be fixed in a way that makes the hunts predictable, but the log should still show that hunting happened across the period assessed. Open-source tools such as a SIEM or log platform, endpoint telemetry collectors and query languages can produce the raw logs and the query history that a hunt record depends on. They cannot decide which hypotheses matter for your environment, judge whether a weak signal is an intrusion, or own the threat intelligence program. Those judgments belong to your security staff, and a partner can help build the workflow and the records but should not be the party whose analysis you present as your own.

The supply chain plan under RA.L3-3.11.7e is evidenced by the document itself and its revision history. Assessors will check that it names the suppliers and components in scope, the risks identified for each, the mitigations and monitoring you apply, and the roles responsible. The annual update requirement means each revision should be dated and approved, and the change record should explain what was reviewed, such as a new subcontractor, a changed software dependency or an updated threat report. Ask your legal and procurement teams to confirm which flowdown terms and supplier attestations feed the plan, so the document reflects contracts you actually hold. If you cannot show two or more dated revisions tied to real reviews, expect the assessor to treat the requirement as not yet operating.

How the annual penetration test requirement works in practice

CA.L3-3.12.1e turns penetration testing into a repeatable cycle: defined scope, authorized testing, triaged findings, tracked remediation and retest evidence that an assessor can follow from start to finish. The organization owns the cycle, and an independent testing firm produces the test evidence.

Define the test scope
Start by listing the systems that process, store or transmit CUI within the Level 3 boundary, plus the specialized assets (OT, IoT, test equipment and government furnished equipment) that the organization has placed in scope or segregated. The scope statement should match the system security plan and the asset inventory, so the assessor can trace every tested system back to a documented boundary. The output is a signed scope document that names the systems, the test types and the owner who approved it.
Agree rules of engagement
Before any packet leaves the tester's workstation, the organization and the testing firm agree in writing on permitted techniques, excluded systems, testing windows, notification contacts, data handling for any sensitive material encountered, and the steps to take if a test causes an outage. Authorization should come from someone with the authority to approve production testing. The output is a signed rules of engagement document that the assessor can review alongside the scope.
Run automated scanning and expert testing
CA.L3-3.12.1e expects two layers of work: automated scanning tools that cover the whole scope, and ad hoc tests by subject matter experts who attempt to chain weaknesses the scanners cannot see, such as access control logic, segmentation gaps and social engineering paths. Testers keep time-stamped logs of what they tried and what happened. The output is raw tool output plus the expert's working notes, both retained as evidence.
Triage and validate findings
Each finding is reproduced, rated against the organization's risk method and mapped to the affected system and requirement. Duplicates from the scanner are merged, and false positives are documented with the reason they were dismissed. Severe findings are escalated to the incident response process when there is evidence of compromise. The output is a validated findings register in which every entry has a reproduction step, an owner and a rating.
Track remediation in the plan of action
Each validated finding becomes a tracked remediation item with an accountable owner, a planned fix and a target date set by the organization. Accepted risks need a written decision signed by a named authority, not a silent closure. Items that cannot be closed in time belong in the plan of action and milestones, which an assessor will read. The output is a remediation log linked to the findings register, showing status changes with dates and approvals.
Retest and close with evidence
Once a fix is applied, the tester or an independent reviewer repeats the original test against the changed system and records whether the weakness is gone. Retest results are stored with the original finding so the chain from discovery to closure is visible. Findings that remain open are carried into the next cycle. The output is a closure record per finding that pairs the retest result with the change record.
Repeat on schedule and after significant change
The requirement sets the cadence at least annually, and it also applies after significant security changes, so the organization should define what counts as significant in its change management procedure. Each cycle reuses the scope and rules of engagement, updated for changes since the last test. Confirm the exact interpretation of significant change with the contracting authority or assessor before the first cycle. The output is a dated test calendar tied to the change log.
Keep the testing firm independent of the assessor
The firm that performs the penetration test produces test evidence. It does not issue a certification, and it should not be the same party that performs the Level 3 assessment by DCMA DIBCAC. Ask the testing firm to confirm in writing that it has no reporting role in the assessment. Only the government assessor records the outcome, so the test report is an input the organization presents, not a verdict. Reference the CMMC Program rule for the assessment roles.

Isolation, software integrity and specialized assets

Three Level 3 requirements decide how far a Level 3 boundary reaches: how systems are isolated, how security-critical software is proven genuine, and how specialized assets are brought into scope. Assessors test each one with records an organization produces continuously, so the design decisions and their documentation matter as much as the technical controls.

Isolating systems and components

SC.L3-3.13.4e requires physical or logical isolation techniques in organizational systems and components. In practice, the organization must show where Level 3 systems sit relative to general business networks, which isolation mechanism is used at each boundary (separate hardware, VLANs, virtual routing, or enclaves), and how that design is enforced rather than only drawn. Confirm that every isolation claim appears in the network diagrams an assessor will review.

Verifying software integrity

SI.L3-3.14.1e requires verifying the integrity of security-critical and essential software using root of trust mechanisms or cryptographic signatures. The organization needs a list of which software counts as security-critical, a signing process for internally built components, and a verification step before installation or update. Ask for records showing that signatures were checked, including failed checks and how they were handled.

Bringing specialized assets into scope

SI.L3-3.14.3e requires specialized assets, including IoT, IIoT, OT, Government furnished equipment, restricted information systems and test equipment, to be either included in the enhanced scope or segregated in purpose-specific networks. For each asset class, the organization must choose one path and document why. Operational technology and test equipment are common gaps because they are often outside IT inventories and cannot easily be patched or monitored.

Asset inventories with classification

An assessor testing specialized assets will start with the inventory. Each entry should record the asset type, owner, location, network zone, whether it handles CUI or Government furnished equipment, and whether it falls within the enhanced scope or a segregated network. Ask the implementation partner to confirm that the inventory is generated from discovery tooling where possible, so it can be compared against what is actually connected.

Evidence an assessor examines

For these three requirements, assessors typically review current network diagrams showing boundaries and enforcement points, signing and verification logs for security-critical software, and classified asset inventories tied to the scope decision. Each artifact must match the live environment on the assessment date. Confirm with the assessing body how it expects evidence to be presented before the assessment is scheduled.

How DIBCAC tests these requirements and what counts as MET

Level 3 certification is performed by DCMA DIBCAC, and Level 2 must already be in place before DIBCAC will assess Level 3. The organization owns its controls and the evidence behind them. DIBCAC is the independent assessor that decides whether the 24 Level 3 requirements are met. Under 32 CFR 170.17 and 170.18, Level 3 certification assessments are performed by DIBCAC, and the Level 2 certification that a C3PAO issues is the prerequisite, so the Level 2 scope, system security plan and evidence need to be stable before a Level 3 assessment is requested. Organizations that treat Level 3 as a separate project with its own scope often discover late that a gap in Level 2 blocks the whole certification.

The assessment objectives are applied to evidence in final form. A requirement counts as MET only when every applicable objective is satisfied with evidence that is complete, approved and dated, not drafts, screenshots taken for the day or policies awaiting sign-off. For Level 3, that means a 24/7 security operations capability, incident response runbooks with records of deployment time, threat intelligence and hunting records, an annual supply chain risk management plan, penetration test reports and training records with their completion dates. Check each requirement against the objectives and ask which artifact an assessor would open first, then confirm that artifact exists in final form.

NIST SP 800-172A is the companion assessment procedure document for the enhanced requirements, and it sets out the objectives an assessor uses to judge each one. Because the objectives for the DoD-assigned parameters can vary by contract, confirm the exact objectives, the parameter values and the evidence DIBCAC expects with DIBCAC or the contracting officer before you build the evidence set. The step-by-step request, scope definition, eMASS recording and POA&M limits are covered in the Level 3 DIBCAC assessment process guide, so use that page for the procedure and this one to decide what evidence to prepare.

Who owns each Level 3 requirement

Your organization owns every Level 3 requirement, regardless of who builds or operates the tooling. Accountability for the security operations center, the incident response team, threat intelligence, the supply chain risk management plan and the risk acceptance decisions stays with your leadership, and an assessor will ask people in your company to explain and demonstrate these controls. Outside help cannot take that ownership over.

Staffing and on-call coverage: Decide how the 24/7 security operations capability is staffed, including whether remote or on-call staff are part of the model, and who holds authority to deploy the incident response team within 24 hours.
Threat intelligence and hunting: Select the open or commercial intelligence sources and any DoD-provided sources you use, and run threat hunting on an ongoing, aperiodic basis with staff who can act on the findings.
Supply chain risk management plan: Write, approve and update the plan at least annually, and decide which suppliers and components it covers.
Risk decisions and POA&M ownership: Decide which risks to accept, which to remediate and by when, and sign off on the system security plan and any plan of action.
Specialized assets: Decide how IoT, OT, test equipment and government furnished equipment are scoped or segregated.

Confirm with your Level 2 assessor and DIBCAC's current guidance which evidence must be signed by a named owner in your company.

Where Level 3 projects usually stall

Level 3 programs rarely fail on technology alone. They stall on staffing, cadence, documentation and asset scope, which assessors check in final form. The cards below cover five recurring gaps, with the avoidance step for each, so the team can close them before a DIBCAC assessment starts.

Undefined 24/7 staffing

The SOC requirement (IR.L3-3.6.1e) expects a security operations capability that operates 24/7, and it allows remote or on-call staff. Many teams name a SOC on paper but cannot show who answers an alert at 3 a.m. Write a shift roster, escalation path and on-call rota, then test one overnight alert end to end. Ask the auditor which records prove coverage, such as ticket timestamps and acknowledgment logs.

No hunting cadence on record

Threat hunting must happen on an ongoing, aperiodic basis (RA.L3-3.11.2e), and assessors look for proof that it happened. A hunt plan with no dated hunts, queries and findings reads as a claim, not a practice. Schedule hunts, record hypotheses, data sources and results in a case log, and file each finding into the risk assessment or incident process.

Supply chain plan not updated

The supply chain risk management plan must be updated at least annually (RA.L3-3.11.7e). Teams often write the plan once for a bid and let it age. Set a yearly review owned by a named role, tie it to supplier inventory changes, and keep dated revisions with approval records. A plan with last year's supplier list will fail the first question an assessor asks.

Unsegregated OT and test equipment

Specialized assets, including IoT, OT, government furnished equipment and test equipment, must sit inside the enhanced scope or in purpose-specific networks (SI.L3-3.14.3e). Engineering labs often connect test rigs to the corporate network for convenience. Build an asset inventory first, mark each item as in scope or segregated, and verify the boundary with a documented network test. Confirm treatment of each asset class with your assessor before the review.

Unsigned software without verification records

Security-critical and essential software must have its integrity verified using root of trust mechanisms or cryptographic signatures (SI.L3-3.14.1e). Many organizations trust installers they downloaded, but cannot show signature checks. Document the software list, the verification method for each item, the public keys or hash references used, and the logs of each check. Where a vendor does not sign a component, record the compensating control and its approval.

Questions buyers ask about the Level 3 requirements

Do we need CMMC Level 2 certification before we can pursue Level 3?

Yes, in practice. Under the CMMC rule, Level 3 certification is assessed by DCMA DIBCAC only after the organization holds a current Final Level 2 (C3PAO) result, so the Level 2 work is the foundation the Level 3 controls build on. The Level 3 requirements are added on top of the 110 Level 2 requirements from NIST SP 800-171 Rev. 2, so gaps in access control, configuration management or audit logging will also block Level 3 readiness. Before scoping Level 3, confirm your current Level 2 status, your SPRS posting and whether the Department of War's current guidance on Phase II and self-assessments changes what your contracts require in the near term. Level 3 scope also depends on which programs are designated, which is covered on the who needs Level 3 page.

Does a managed SOC satisfy the 24/7 security operations requirement?

It can, but only if the contracted service meets the requirement's intent and you can show it. The Level 3 incident response requirement calls for a security operations center capability that operates 24/7, with allowance for remote or on-call staff, and a cyber incident response team that can be deployed within 24 hours. A managed service provider can supply that capability, yet the organization still owns the control, so the contract, runbooks, escalation paths, on-call rosters and alert records must show who responds, how fast and against which systems. Ask the provider to show evidence from past incidents, confirm that its scope covers your Level 3 boundary, and confirm that any cloud or MSP staff who touch CUI meet your flowdown and personnel requirements.

Can we implement the Level 3 requirements in-house?

Often yes, if you already run mature security operations and have people who can own each control. The requirements cover threat intelligence, aperiodic threat hunting, annual penetration testing, an annually updated supply chain risk management plan, isolation of specialized assets, and software integrity verification. Each one must produce evidence that an assessor can test, and that evidence must be final, not draft. Organizations usually build in-house capability first where they already run a SOC, a vulnerability program and an engineering team that controls their build pipeline. Where those functions are thin, the gap is usually in repeatable evidence and independent testing rather than in tooling, so an internal gap review against each requirement is the fastest way to decide what to build, buy or outsource.

What do the Level 3 requirements need from our internal staff?

They need named owners with time and authority, not only tool licenses. Expect the work to draw on security operations analysts, incident responders, engineers who manage configuration and software signing, IT staff who maintain the asset inventory and network isolation, the people who run penetration tests and the people who own supplier relationships and the supply chain plan. Training for awareness, including the annual and post-event sessions and role-based exercises, also needs staff who can design and deliver it. Leadership must sign the system security plan and accept residual risk in plans of action. Ask a partner to map each of the 24 requirements to a named internal owner and a standing review cadence, because assessors test whether people actually perform the recurring activities.

Do the Level 3 requirements change under NIST SP 800-172 Rev. 3?

The current CMMC Level 3 requirements are drawn from SP 800-172 (February 2021), and the Level 3 list in the rule is what assessors use today. NIST published Rev. 3 as a final public draft on 29 September 2025, with comments due 16 January 2026. Rev. 3 aligns with SP 800-171 Rev. 3, adds Planning, System and Services Acquisition and Supply Chain Risk Management families, and extends assessment objectives to integrity and availability. Treat Rev. 3 as a planning signal: design new supply chain, acquisition and availability work so it can absorb Rev. 3 changes, but do not treat draft wording as a current assessment standard. Confirm with the Department of War and your contracting officer which revision applies to your contracts before you change your control set.

What can a partner deliver for Level 3, and what must stay with us?

A partner can plan, implement, configure, document and test the systems and evidence that support the Level 3 controls, and it can run security testing such as penetration tests and red teaming. A partner cannot own your controls, issue the assessment result, or act as the assessor. DCMA DIBCAC performs Level 3 certification assessments, and the organization remains accountable for its controls, its SSP, its POA&M decisions and its affirmations. DeployOpen, a Chainscore Labs company, plans, implements, hardens and documents self-hosted open-source platforms in your own infrastructure, runs security testing, and prepares systems and evidence for assessment. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. Cost follows from that written scope; the CMMC Level 3 cost page explains the cost components.

How DeployOpen prepares Level 3 systems and evidence

DeployOpen works on the CMMC Level 3 requirements as a self-hosted implementation partner inside your own infrastructure. We prepare the systems, controls and evidence that the 24 NIST SP 800-172 requirements call for, while your organization owns its controls and DCMA DIBCAC performs any Level 3 certification assessment.

How we scope

Scope is agreed in writing before work starts, listing which Level 3 requirements and environments are covered.
We map each requirement ID to the systems, networks and specialized assets in your boundary, including OT and test equipment.
Your organization confirms which requirements it will own, which it will outsource, and which depend on a Level 2 baseline.

How we build

We implement and integrate self-hosted open-source platforms for logging, monitoring, scanning and asset inventory in your accounts or data centers.
We configure isolation, segmentation and software integrity checks, such as signature verification, and test them against the assessment objectives.
We run penetration tests and threat-hunting exercises on a defined schedule and record the findings, remediation and retest results.

How we hand over

We deliver system documentation, procedures, runbooks and evidence packages mapped to each Level 3 requirement ID.
We walk your security and compliance staff through the operating procedures so the evidence keeps being produced after handover.
We identify evidence gaps and open items for your organization to confirm with your assessor before any assessment is requested.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope engagement ends.
A retainer can cover recurring tasks such as annual supply chain plan updates, penetration test cycles and training records.
Confirm with DeployOpen in the quote which support tasks are included, how changes to scope are priced, and who owns each deliverable.