Do not read 110 → 97 as relief. Rev. 3 merged requirements rather than removing their substance, added three families (Supply Chain Risk Management, Planning, System and Services Acquisition), introduced organization-defined parameters you must choose and defend, and grew the assessment-procedure catalog. The work concentrates in six places: a formal supply chain program, ODP decisions and their documentation, planning and acquisition discipline, continuous monitoring maturity, identity coverage, and documented shared responsibility with providers. Each lands differently depending on your seat — this article splits every section for OSCs (contractors) and ESPs (the MSPs and providers operating their environments).
Why 97 requirements is not easier than 110
NIST SP 800-171 Rev. 3 (May 2024) is the first revision that looks smaller: 97 requirements against Rev. 2's 110. Almost everything about that impression is wrong. The count dropped because Rev. 3 merged requirements — four password rules became one Password Management requirement, transmission and at-rest encryption became one confidentiality requirement, remote-access rules folded into one Remote Access parent. The substance moved; it did not leave.
Three things then pushed the workload up. First, three new families arrived — Supply Chain Risk Management, Planning, and System and Services Acquisition — writing requirement language over ground Rev. 2 left implicit. Second, organization-defined parameters (ODPs) now appear across dozens of requirements: values you must select, justify, and defend rather than boxes you check. Third, the assessment side grew: the determination-statement catalog in SP 800-171A expanded materially between editions — from roughly 320 statements to more than 400 — so an assessor has more to examine per engagement, not less.
NIST has withdrawn Rev. 2 as a publication, superseded by Rev. 3 — but publication status and contractual applicability are different things. Most DIB contracts still reference Rev. 2 through DFARS 252.204-7012, and DoD held assessments to Rev. 2 by class deviation while rulemaking settles. Read your contract, and track the moving parts on the policy status page. Everything in this article is preparation guidance, not a statement of what your contract requires today.
Two seats at the same table: OSC and ESP
Every section below carries a toggle, because the same requirement lands differently depending on where you sit. An OSC — Organization Seeking Certification — is the contractor whose contracts carry the requirements and who answers for them in an assessment. An ESP — External Service Provider — is the MSP, MSSP, or cloud operations partner running parts of the OSC's environment; in the CMMC ecosystem, the services an ESP performs and the assets it touches are examined as part of the OSC's scope, and how ESP assets are treated is determined by the current CMMC scoping guidance and the assessor — not by either party's assumptions.
Pick your seat once; the choice applies to every section on this page and is remembered in this browser. Both versions are always in the page if you print it.
1 · Supply Chain Risk Management: the family that did not exist
The SR family (03.17.01–03.17.03) is widely regarded as the hardest genuinely new ground in Rev. 3: a maintained supply chain risk management plan, acquisition strategies, tools, and methods that manage supply chain risk at buying time, and enforced supply chain requirements and processes for the components and services the system depends on. The requirement-by-requirement breakdown walks all three; the short version is that supplier security stops being a procurement instinct and becomes an assessable program.
The reason it hurts: most contractors have historically treated supplier risk as a quality or purchasing concern, not a security control family. A living SCRM program needs owners, a supplier register, security terms in agreements, and follow-through — and it needs them continuously, not once per contract award.
As the contractor, the SR family is asking for a program you probably run informally today, written down and operated: who your critical suppliers are, what security you expect of them, how that expectation enters agreements, and what happens when a supplier falls short.
- Start with the register, not the plan: list critical suppliers, integrators, and single-source components — the vendor risk assessment worksheet and supplier security questionnaire exist for exactly this.
- Keep the SCRM plan short and true: a five-page plan you follow beats a fifty-page plan you don't. It should name the register, the assessment cadence, the contract-terms approach, and the escalation path.
- Flowdown is the hard edge: your obligations to your customer and your expectations of your suppliers are different instruments. Keep them separate on paper, and never present a supplier questionnaire as a contractual flowdown — see the supplier toolkit thinking on this site.
- OT changes the emphasis: component provenance, firmware integrity, and vendor maintenance access matter more than paperwork depth — the OT-09 practice guide is the operational companion.
As a service provider you sit on both sides of this family at once: you are an entry in every client's supplier register, and you often operate supplier-facing processes on the client's behalf. Treat both seriously and SR becomes a differentiator instead of a burden.
- Expect to be assessed as a supplier by every client: build one reusable evidence package — your own security posture, personnel access model, incident-notification terms, and subcontractor list — instead of answering fifty questionnaires from scratch.
- Your subcontractors and tooling vendors are part of your clients' supply chains: your RMM platform, your ticketing system, and your offshore NOC are exactly the kind of dependency 03.17.03 wants identified and governed.
- If you manage procurement or vendor relationships for clients, document which SR activities you perform, which the client retains, and what evidence you hand over — a supplier register you maintain silently earns the client nothing in an assessment.
- Put incident-notification commitments in writing with timeframes. 'We would obviously tell you' is not a process; a clause with a clock is.
2 · Organization-defined parameters: the end of the unexamined default
Rev. 3's most pervasive change is not a requirement at all. Scores of requirements now contain organization-defined parameters — the number of failed logons before lockout, session and inactivity timeouts, audit retention periods, review and scan frequencies, password rules, response times. (The exact parameter count depends on how you count multi-part parameters; by any counting it runs to dozens upon dozens.) Under Rev. 2 you could inherit a vendor default and nobody asked why. Under Rev. 3, you select the value, document the selection, and defend it as a risk decision.
Two failure modes dominate. The first is silence: settings exist in tools but no document says what was chosen or why, so the assessor finds configuration without decision. The second is contradiction: the SSP says one value, the tenant enforces another, and the MSP's baseline imposes a third. Both are documentation problems before they are technical ones — which is why this is the cheapest area to start early and the most expensive to fix late.
If DoD or an agency later mandates specific ODP values for its contracts, your previously chosen values may need to change. Record every ODP decision with its justification and its enforcement point, so a mandated value is a controlled change rather than an archaeology project.
As the contractor, ODPs are your decisions even when a provider operates the control. The practical move is one artifact: a parameter register that lists each ODP, the value you chose, why, where it is enforced, and where the evidence lives.
- Harvest before you decide: export what your tenant, directory, and tools actually enforce today. Most organizations discover their real values first and justify or fix them second.
- Justify against risk, not habit: 'vendor default' is not a rationale; 'aligned to our incident-response staffing and the sensitivity of the data' is.
- Keep the register beside the SSP, not inside it — values change more often than narratives, and a standalone register keeps SSP churn down.
- The security metrics register and configuration baseline worksheet carry parts of this; the register's owner should also watch the policy status page for any future mandated values.
As a service provider, ODPs collide with your standardization. Your platform baseline enforces one set of values across all clients; Rev. 3 lets every client choose differently — and their choice, not your baseline, is what their assessor examines.
- Build a per-client parameter matrix: your standard value, the client's chosen value, and the delta. A conflict you can show is manageable; one discovered mid-assessment is a finding with your name on it.
- Decide which parameters your service allows clients to vary, and say so in the service description — an honest 'we enforce X for all tenants' lets the client document inheritance deliberately.
- When a client never chose a value, do not let your default stand in silently: surface it, get it ratified or changed, and record who decided.
- Version your baselines. When you change a platform default, every affected client's parameter register needs the ripple — that is a service obligation under Rev. 3 economics, not a courtesy.
3 · Planning and acquisition: the paperwork families with teeth
The PL family (03.15.01–03.15.03) makes explicit what Rev. 2 assumed: policies and procedures covering the requirement families, the system security plan (moved here from Security Assessment), and signed rules of behavior. The SA family (03.16.01–03.16.03) is sharper than it looks: security engineering principles, a standing requirement to replace or mitigate unsupported system components, and governance of external system services. None of this is exotic — but contractors whose SSP was a static proposal artifact, or whose policy 'framework' is a folder of unread PDFs, now face requirement language that assessors can sample directly.
03.16.02 deserves special mention: the end-of-life problem finally has a requirement number. An EOL register with replace-or-mitigate decisions — the discipline the technical-debt practice builds — moves from good hygiene to assessable expectation.
As the contractor, PL and SA reward what you maintain, not what you once wrote. The SSP, the policies, and the rules of behavior need owners, review dates, and a believable history.
- Treat the SSP as an operated document: version history, a named owner, a review cadence, and updates driven by change control. The SSP development worksheet structures the inputs.
- Rules of behavior are cheap and visible: one page, CUI-specific, actually signed, refreshed at onboarding — an easy early win with the rules of behavior template.
- Stand up the EOL register now (the asset inventory carries support-status columns): every unsupported component gets replace-by-date or documented mitigation, and 'we know about it' is neither.
- For external services, your posture is the responsibility matrix plus evidence you actually monitor the provider — see section 6.
As a service provider, the SA family is substantially about you. 03.16.03 asks your clients to define the security requirements you must meet, the responsibilities on each side, and the oversight they apply to you.
- Author the customer responsibility matrix yourself, per service, and keep it current — the provider who arrives with a clear 'we do / you do / we both do' beats the one who makes each client reverse-engineer it.
- Expect oversight, and make it easy: periodic evidence delivery (reports, exports, review notes) turns 'monitoring the provider' from an awkward audit into a subscription.
- Your own platform has an EOL story too: clients inherit risk from the aging components of your stack, and 03.16.02 logic reaches them through you.
- Contribute to client SSPs in writing, not folklore: a provider-supplied description of how your service implements its share of a requirement, reviewed annually, is the artifact everyone wishes existed at assessment time.
4 · Monitoring, flaw remediation, and integrity: where tooling meets cadence
Rev. 3 consolidated the System and Information Integrity family (7 requirements to 5) while making its expectations more explicit: system monitoring with organization-defined objectives, flaw remediation within timeframes you declare, malicious-code protection with its updates and scanning folded in, and configuration management with sharper baseline and change-control language in the CM family. The consolidation removes duplicate statements, not work — and for organizations that ran an annual scan and called it monitoring, this is where the tooling and staffing bill arrives.
As the contractor, the trap is buying tools and skipping cadence. Rev. 3's monitoring and remediation language is about declared frequencies and response times you then have to live up to — visible in the record, not just in the license inventory.
- Declare achievable numbers: a 14-day critical-fix commitment you meet beats a 72-hour one you miss. Your ODP choices here are commitments, and the vulnerability register and patch tracker are where they show up as met or missed.
- Map log coverage before buying anything: the logging and monitoring coverage matrix usually reveals that the gap is unforwarded sources and nobody reviewing, not a missing SIEM.
- If a provider runs monitoring for you, the evidence question is yours anyway: who reviews, how often, and where the review record lives — get it in the responsibility matrix.
- For OT, passive monitoring remains the realistic mechanism; the OT-07 guide covers the production constraints.
As the provider, this area is your core product — and Rev. 3 quietly raises what 'managed' has to mean. Detection without documented review cadence, or patching without per-client remediation commitments, will not stand up as the client's evidence.
- Sell cadences, not tools: your service description should state review frequencies, alert-handling commitments, and remediation timeframes per severity — because those are the client's ODP answers now.
- Deliver evidence as part of the service: monthly patch-completion and monitoring-review reports the client can file are worth more to their assessment than dashboard access they never open.
- Be precise about log ownership and retention: whose SIEM, whose retention clock, and what happens to the client's data at offboarding are questions with requirement numbers behind them.
- Do not let your standard severity SLAs silently stand in for the client's declared response times — reconcile them the same way as any other parameter conflict.
5 · MFA and identity assurance: broader coverage, fewer excuses
MFA is not new — Rev. 2's 3.5.3 already required it. Rev. 3 consolidates identity management (identifier lifecycle, password management aligned to modern federal guidance, a new authenticator-management requirement) and phrases scope through parameters rather than a fixed privileged/non-privileged split. The practical effect: coverage questions get sharper, and the corners where MFA never quite reached — legacy applications, local access paths, service interfaces — get harder to leave unexamined.
As the contractor, the work is coverage arithmetic: every account, every access path, every system in scope, with the exceptions written down and dated rather than silently tolerated.
- Track coverage by tier with the MFA deployment tracker; the number an assessor believes is enrolled-and-enforced over active accounts, not 'MFA is on'.
- Phishing-resistant methods (FIDO2, passkeys, PIV) exceed the requirement's floor and are where the IT-01 practice points first — method choice is your decision to document.
- Legacy systems are the budget line: where a system cannot do modern authentication, the compensating architecture (isolation, brokered access) needs to be deliberate and written.
- Authenticator management (03.05.12) formalizes the lifecycle around keys and tokens — issuance, loss, revocation — which good MFA rollouts already do; now keep the records.
As the provider, your technicians hold the most dangerous credentials in every client environment. Rev. 3-era assessments increasingly look at your staff's authentication into client tenants as part of the client's privileged-access story.
- Phishing-resistant MFA for your own technicians, on every client-touching system, is table stakes — a compromised MSP account is a compromise of every tenant it reaches.
- Per-client, per-technician named accounts beat shared 'admin@' patterns; your access model becomes evidence in the client's assessment.
- Offer identity uplift as a product: the coverage tracking, legacy-remediation, and conditional-access work in this section is exactly what small OSCs cannot staff.
- Document your break-glass paths into client environments and reconcile them with each client's session and lockout parameter choices.
6 · External services and shared responsibility: 'my MSP handles it' retires
The most common compliance assumption in the small-contractor DIB — our provider handles that — was never sound, and Rev. 3 removes its cover. 03.16.03 expects external service providers to be bound to your security requirements, responsibilities to be defined on both sides, and you to oversee their performance. 'It's FedRAMP' describes the provider's platform, not your use of it; a cloud authorization inherits you nothing without your configuration and your evidence on top.
As the contractor, accountability does not outsource. The artifact set is small and unambiguous: a responsibility matrix per provider, security terms in the agreement, and evidence you actually watch the provider do its share.
- Complete the MSP/MSSP responsibility matrix together, in one sitting — the column that gets skipped is always who evidences each control.
- Put security requirements in the agreement at renewal: incident notification with a clock, data location and return, subcontractor disclosure, evidence delivery.
- Keep an oversight record: the quarterly review of the provider's reports, with a date and a note, is what 'monitoring the provider' looks like as evidence.
- Your cloud services belong in the same discipline — the cloud and SaaS inventory is where the sprawl becomes visible.
As the provider, being easy to oversee is about to be a competitive feature. The OSCs that survive Rev. 3-era scrutiny will consolidate toward providers who show up with the matrix, the terms, and the evidence stream already in hand.
- Publish your responsibility matrix per service line and review it with each client annually — silence about a control reads as 'nobody owns it'.
- Accept contractual security terms you can actually meet, and price them; a commitment you cannot evidence is worse than one you decline.
- Build the periodic evidence package once (patching, backup tests, monitoring reviews, access recertification) and deliver it to every client on a schedule.
- Be explicit about the limits of inheritance: what your service does not cover is information your client's assessor will find with or without you — better it comes from you, in writing, early.
Where the impact concentrates
| Area | Difficulty | Cost impact | Typically under-implemented today? | Note |
|---|---|---|---|---|
| Supply Chain Risk Management (SR) | High | High | Yes | Genuinely new family; program, not paperwork |
| Organization-defined parameters | High | Medium–High | Yes — as documentation | Decisions plus justification, kept current |
| Continuous monitoring / SI | Medium–High | High | Often | Tooling and cadence together |
| External services / shared responsibility (SA) | Medium–High | Medium | Yes | Especially provider-dependent OSCs |
| Planning (PL) family | Medium | Medium | Variable | SSP and policy maturity decides |
| MFA / identity assurance | Medium | Medium–High | Variable | Legacy coverage is the cost driver |
The difficulty and cost columns are directional editorial judgments for a typical small-to-midsize contractor, not measurements — your contract mix, environment, and provider model move every row.
The practical takeaway
Rev. 3 is not easier than Rev. 2; it is more honest about work Rev. 2 let organizations defer. The hidden costs are documentation quality (above all, ODPs), supply chain process, and monitoring cadence — none of which can be bought in a quarter. A contractor with a strong Rev. 2 program and real operating evidence will cross without drama. A checkbox program, or one that leans on a provider it has never documented, faces a genuine project.
The cost-effective sequence, even while your contracts still reference Rev. 2: start the ODP register and the supplier register now — both are cheap to begin, slow to mature, and useful under either revision. Then work the maturity-based roadmap from wherever you honestly are.
The SR, PL, and SA families, requirement by requirement walks each new requirement with its ODPs, evidence, and OSC/ESP splits. The prioritized remediation roadmap sequences the work for three honest starting points. Every requirement named in this series links into the site's Rev. 3 mapping.
Sources
- NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems (May 2024) ↗
- NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI (May 2024) ↗
- NIST SP 800-171 Rev. 2 (withdrawn; superseded by Rev. 3) ↗
- NIST SP 800-161 Rev. 1, Update 1 — C-SCRM Practices (November 2024) ↗
Cloud consoles and federal guidance change; confirm control text and clause language against the official publication that applies to your contract. This article is independent education and does not by itself establish compliance or confer CMMC certification.