One control, three frameworks: a crosswalk that holds

Editor's note, 2026-07-14: The Department of War suspended CMMC Phase 2 on 2026-07-13, pending a 60-day review. Two lines below describe the program as it stood then: the certification mechanism and the third-party assessment are suspended, and Level 2 is currently self-assessed. The program is suspended, not cancelled. The crosswalk itself is unaffected, because the control set did not change. 800-171 still restates 800-53, and CMMC Level 2 still assesses 800-171. Source: DoW memo 26-P-1023.

NIST 800-171 restates part of NIST 800-53, and CMMC Level 2 assesses NIST 800-171. The three frameworks a defense contractor works to descend from one source, so a single implemented control and a single piece of evidence can answer the equivalent requirement in all three. Teams that miss this keep three sets of paperwork and describe the same access policy or log configuration three times, in three places, by three different sentences. That is wasted effort, and it creates three versions of the truth that drift apart.

How the three frameworks relate

The three frameworks form a chain, each link derived from the one before.

NIST 800-53 is the full control catalog. It is large, and a federal system selects a baseline from it (low, moderate, or high) based on impact level. NIST 800-171 is narrower. Its requirements were built by taking the moderate baseline of 800-53, keeping the controls that protect the confidentiality of Controlled Unclassified Information on a non-federal system, and dropping the ones that are federal-only or already covered by other law. So a 800-171 requirement is a tailored restatement of one or more 800-53 controls, and the NIST publication itself carries a mapping table that names them.

CMMC Level 2 sits at the end of the chain. Its practices align to the 110 security requirements of NIST 800-171. CMMC Level 2 is the assessment and certification mechanism, not a separate control set with new technical demands. When an assessor checks a Level 2 practice, they are checking a 800-171 requirement, which in turn traces back to specific 800-53 controls.

That chain is the reason a crosswalk is possible. Because the requirements descend from a common source, the same implementation can satisfy the equivalent requirement at each layer. You are meeting one bar and describing it against three catalogs.

A worked example: audit logging

Take audit logging. In 800-53 this is the Audit and Accountability family: AU-2 covers which events you log, AU-3 covers the content of each record, AU-6 covers reviewing the logs, and AU-9 covers protecting them from tampering. In 800-171, the same ground is covered by the Audit and Accountability requirements, which ask you to create and retain system logs, ensure the logs let you trace actions to individual users, and review logged events. CMMC Level 2 assesses those same 800-171 requirements as its Audit and Accountability practices.

Now look at what you actually build. You configure a centralized log pipeline. It collects authentication events, privileged actions, and configuration changes. Each record carries a timestamp, a source, an outcome, and the user identity behind the action. The logs are shipped to storage that the originating hosts cannot rewrite, and a named person reviews flagged events on a set cadence.

That single implementation answers all three framework layers at once. The configuration that ties a log record to a user identity is the AU-3 content requirement, the 800-171 traceability requirement, and the corresponding CMMC practice, in one build. You implemented logging once and mapped it three ways.

A second example: access control and least privilege

Access control shows the same pattern. In 800-53, AC-2 governs account management, AC-3 governs enforcement of access decisions, and AC-6 governs least privilege. The 800-171 Access Control requirements restate these: limit system access to authorized users, limit what those users can do to what they need, and control the flow of CUI. CMMC Level 2 assesses the 800-171 versions.

The implementation is your identity and access setup: role definitions scoped to job function, a joiner and leaver process that provisions and removes accounts, and periodic access reviews that confirm each person still needs what they hold. One role-based access model, defined once, answers the account management requirement, the least privilege requirement, and the access enforcement requirement across every layer of the chain.

Where the mapping is not one to one

The crosswalk holds most of the time, but a clean one-to-one mapping is the exception at the edges, not the rule everywhere. A few cases need care.

• One to many. A single 800-171 requirement can trace to several 800-53 controls. The 800-171 requirement to limit system access covers the ground of AC-2, AC-3, and parts of AC-17. If your evidence only speaks to account creation, you have answered part of the requirement, not all of it.
• Non-technical requirements. Some 800-171 requirements are about process, not configuration. The requirement to review logged events is a recurring human activity. Its evidence is a review record with a date and a reviewer, not a system setting, and a screenshot of a dashboard does not prove the review happened.
• CMMC adds assessment rigor, not new controls. CMMC Level 2 does not invent technical requirements beyond 800-171, but it does raise the bar on proof. An implementation that a self-attestation accepted may need an artifact that a third-party assessor can examine. The control is the same. The evidence has to be stronger.
• Scoping differences. 800-53 applies to a full federal system boundary. 800-171 applies to the parts of your environment that store or process CUI. A control that is in scope federally may only matter for the CUI enclave in your case, so the mapping depends on where your boundary sits.

The practical rule: treat the crosswalk as a starting map, then confirm each mapped pair actually covers the same ground before you reuse one artifact for both.

What makes an evidence artifact reusable

An artifact that answers one framework and no other is usually written to a framework's vocabulary instead of to the system. A reusable artifact describes what the system does, and lets the mapping connect it to each requirement.

• It names the system component and the concrete setting, so it stands on its own rather than referring to a control number.
• It carries a date and a source, so an assessor can see when it was true and where it came from.
• It maps to the requirement through a crosswalk table rather than being rewritten for each framework, so one artifact is cited by three requirements.
• It is generated from the running environment where possible, so it reflects current state instead of a snapshot someone assembled by hand.

A log export that shows user-attributed records with timestamps is reusable, because it proves a property of the system that three requirements happen to ask about. A paragraph that says "we comply with AU-3" is not, because it is bound to one catalog and proves nothing on its own.

The trap of three separate narratives

The failure mode is maintaining three control narratives that describe the same implementation in three documents. At first they agree. Then the environment changes. Someone updates the 800-171 description when the log retention period changes, but the 800-53 narrative still cites the old value, and the CMMC package was frozen at the last assessment. Now you have three descriptions of one system, and at least two of them are wrong.

The fix is to describe the implementation once and map that single description to each framework's requirements. Maintain one control statement per implemented control, keep one evidence artifact per property, and hold the crosswalk table as the layer that connects them to 800-53, 800-171, and CMMC. When retention changes, you edit one statement and one artifact, and every framework view stays correct because they all point at the same source.