Safeguard
Compliance•

CMMC for DevOps leads: levels, scope and evidence

CMMC has three levels with different assessors. DevOps leads should know which level applies, how scope is drawn and what evidence the assessment needs.

Safeguard Security Team
4 min read

CMMC is the Defense Department's cybersecurity certification program for contractors. It has three levels, each tied to a requirement set and an assessment type. A DevOps lead should learn which level a contract demands, how to draw the boundary around the systems in scope, and how to keep evidence for each requirement.

What are the three levels?

The final rule, 32 CFR part 170, defines the structure. Level 1 uses the 15 requirements in 48 CFR 52.204-21(b)(1) and is assessed by self assessment. Level 2 uses 110 requirements from NIST SP 800-171 Revision 2 and is assessed either by self assessment or by a certification assessment from a C3PAO, a third party assessment organization, depending on the contract. Level 3 adds 24 requirements selected from NIST SP 800-172 and is assessed by the Defense Contract Management Agency's DIBCAC. Statuses are recorded in SPRS, the Supplier Performance Risk System.

Which level your company needs comes from the contract and the type of information involved, not from your preference. Ask your contracting officer or prime.

How is a requirement judged?

The rule says that meeting a requirement means meeting all applicable assessment objectives defined in NIST SP 800-171A for Level 2 or 800-172A for Level 3. That matters for evidence. Each requirement breaks into objectives, and an assessor looks for proof of each one, usually through documents, interviews and tests.

What about POA&Ms?

The rule includes plans of action and milestones and a closeout assessment that covers only the requirements marked not met in the first assessment. The rule limits what may be left open, so read the current text before you plan around a POA&M.

What does the boundary look like in DevOps terms?

You draw an assessment scope around the systems that handle the covered information and the assets that protect them or can affect their security. For a delivery team, that includes build and deployment systems that can change in scope software, identity providers, logging and the endpoints used by administrators.

Constructed example: a contractor keeps controlled data in a storage account and deploys the application through a shared CI service that also builds commercial products. Any engineer with CI admin rights can alter what runs in the data environment. The assessor will treat the CI system as in scope. The cleaner option is a dedicated deployment path and runner for the covered environment, with its own access group.

What evidence should you plan to collect?

Match NIST SP 800-171 families to your tooling: access control and identity records, audit logs and review records, configuration baselines, change records, vulnerability scans with remediation times, incident response tests and media protection settings. Store them where an assessor can be shown them without a scramble, and keep dated exports.

What do you do about suppliers?

Your tooling vendors may be in scope too if they handle the information. Ask each how they support your assessment, and keep their attestations. Check with your assessor how a cloud provider fits your boundary.

What do teams underestimate?

Two things. First, the assessment objectives: a team may have multifactor authentication and still fail an objective because it cannot show it is enforced for every account class. Second, the people side of evidence. Assessors interview administrators, so the person who runs the pipeline must be able to explain it without reading from a script. Rehearse that conversation, and keep diagrams current enough to match what the interviewee describes.

How to apply this

  1. Confirm the required level and assessment type with your contracting officer or prime.
  2. Draw a written boundary and a data flow diagram of the covered environment.
  3. Separate or tightly control CI and admin paths that reach the boundary.
  4. Map each requirement to a system of record and an owner.
  5. Run an internal assessment against the objectives in 800-171A, not just the requirement headings.
  6. Track gaps in the same backlog as engineering work, with dates.
  7. Check the current 32 CFR 170 text, because rules and phase dates have been updated.

Quick check

Who assesses Level 2?

Depending on the contract, either a self assessment or a certification assessment by a C3PAO, as defined in 32 CFR 170.

How many requirements are in Level 2?

110, drawn from NIST SP 800-171 Revision 2 according to the rule's definitions.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.