CMMC20X
Six roles · one security system

The DIB is one
security system.

No contractor secures the mission alone. Contract requirements, shared services, implementation, evidence, independent findings, and Government decisions move between organizations. CMMC has to make those handoffs work without blurring who is accountable.

The system

Security depends on the handoffs.

Each party has different work and different authority. The record can cross an organizational boundary. Responsibility cannot disappear when it does.

Find your part

Six roles. Six different jobs.

Start with the role guide closest to your work. Each guide names what that role owns, what it gives the other parties, what it needs from them, and when the work must be checked again.

  1. Contractors / OSAs

    Know what you are affirming.

    A contractor can hire an MSP or advisor. It still owns its scope, safeguards, gaps, evidence, and organizational affirmation.

    Open guide
  2. MSPs / MSSPs / ESPs

    State what the service does and what the customer must do.

    A provider logo on a diagram proves nothing. The provider needs to identify the security function, evidence, limits, and customer configuration.

    Open guide
  3. RPOs / Advisors

    Help the contractor get ready. Do not certify your own work.

    Advisors add value by making scope decisions, finding gaps, and guiding remediation—not by producing another generic template set.

    Open guide
  4. C3PAOs / Assessors

    Test the claim instead of cleaning the package.

    Consistent inputs should give assessors more time for interviews, testing, conflict, and judgment. A valid data file is not a passing result.

    Open guide
  5. Primes / Supply-chain leads

    Tell the supplier what the contract actually protects.

    A supplier cannot scope the work correctly when a flowdown omits the CUI, system boundary, mission consequence, or shared service behind it.

    Open guide
  6. Government / Program authorities

    Publish the evidence and review rules.

    Government should define what information every tool must produce, which review method applies, how results are sampled, and who can make each decision.

    Open guide
What crosses the boundary

The six handoffs CMMC has to get right.

These exchanges are where vague scope, stale evidence, duplicated work, and confused authority enter the system.

  1. 01
    PrimesContractors

    Contract and mission context

    The supplier needs to know which information, systems, shared services, and mission consequences the contract brings into scope.

  2. 02
    ProvidersContractors

    Service facts and operating evidence

    A provider shows what its service does, what the customer must configure, what evidence exists, and what changed.

  3. 03
    AdvisorsContractors

    Scope, gaps, and preparation

    An advisor can prepare the work and identify unresolved questions. It cannot certify its own work or make the contractor’s assertion.

  4. 04
    ContractorsAssessors

    Scope, implementation, and evidence

    The contractor presents the system it protects, the safeguards it operates, the evidence behind each claim, and the gaps that remain.

  5. 05
    AssessorsContractors + Government

    Independent findings

    The assessor records what it examined, interviewed, and tested; which evidence it accepted; and why it reached each finding.

  6. 06
    GovernmentThe whole system

    Rules, tests, review depth, and decisions

    Government defines the common rules and decision authority, tests new methods, watches program performance, and changes the system when results demand it.

Source basis

Built from the rules that govern the work.

The CMMC 20X vision goes beyond the current implementation. These public sources anchor the role, scope, evidence, and assessment facts used in the ecosystem model.

  1. 01
  2. 02
  3. 03
  4. 04

    Open Security Controls Assessment Language (opens in new tab)

    National Institute of Standards and Technology
Work across the ecosystem

Contribute from where you stand.

Bring a supplier case, service handoff, assessment question, program constraint, or test environment. You can contribute without endorsing every recommendation.