Rev. 3's three new families hold nine requirements between them, and they concentrate most of the revision's genuinely new work. Planning (03.15) writes requirement language over governance Rev. 2 assumed: policies and procedures, the system security plan, and signed rules of behavior. System and Services Acquisition (03.16) reaches engineering discipline, end-of-life components, and the external services your CUI runs through. Supply Chain Risk Management (03.17) is the only family with no Rev. 2 ancestry at all — a maintained plan, security built into buying, and supplier requirements you actually enforce. This article walks each requirement with its organization-defined parameters and its operating evidence, and closes every family with split guidance for the contractor seat and the provider seat.
Why these nine requirements exist — and why the new work concentrates here
When NIST SP 800-171 Rev. 3 (May 2024) added three families — Planning (03.15), System and Services Acquisition (03.16), and Supply Chain Risk Management (03.17) — it was not inventing new security ideas. It was writing requirement language over ground Rev. 2 left implicit: Rev. 2 assumed policies existed, treated the SSP as an assessment artifact, said nothing about end-of-life components or supplier risk, and reached external services only obliquely. Rev. 3 makes all of it assessable. That is why, for most contractors, the transition project concentrates in these nine requirements: everything else in Rev. 3 is mostly a reshaping of work you already owed, while much of this is work many organizations have never formally run.
The nine split unevenly by novelty. Two requirements moved here from elsewhere in the catalog — the system security plan from the old assessment family, security engineering principles from communications protection — and picked up sharper obligations in transit. The remaining seven are new as standalone requirements, and the entire SR family has no Rev. 2 counterpart of any kind. Throughout, you will meet Rev. 3's signature device: organization-defined parameters — review frequencies, imposed supplier requirements, and similar values the organization selects, documents, and defends. This article names where those parameters appear; it deliberately does not suggest values, because the choice and its justification are the point. And one framing rule holds everywhere: these requirements are the OSC's to implement within its defined system boundary, whoever operates the machinery day to day.
Because that last sentence has two sides, every family section below ends with a toggle. 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.
Whether Rev. 3 binds you today is a contract question, not a publication question — most DIB contracts still reference Rev. 2 through DFARS 252.204-7012 while rulemaking settles. Track the moving parts on the policy status page, and read this article as preparation for requirement language that is coming, on a schedule your contracts control. The full transition picture lives in the Rev. 2 to Rev. 3 crosswalk.
Planning (03.15): the governance family
The Planning family gathers the governance documentation Rev. 2 scattered or assumed: written policies and procedures, the system security plan, and rules of behavior. None of it is technically hard, which is exactly the trap — this family rewards documents that are operated (owned, reviewed on a cadence, matched to reality) and punishes documents that were written once and filed. An assessor can sample any of it directly.
03.15.01 · Policy and Procedures
In the site's summary reading, this requirement asks the organization to develop, document, and disseminate the policies and procedures its CUI-protection requirements need, and to review and update them at an organization-defined frequency. Rev. 2 contained no explicit policy requirement — governance documentation was implied, and assessors worked around its absence. Rev. 3 makes it a requirement in its own right, which changes the failure mode: a folder of unread PDFs, or a policy that operations contradicts, is now directly examinable rather than merely embarrassing. The stronger position is a modest policy set that is true — one structure following the catalog's families beats dozens of freestanding documents, with procedures kept closest to the teams that execute them.
Operating evidence is the policy and procedure set with version history and dissemination records, plus dated review records showing the defined frequency was honored — the review-and-update half is the part that silently lapses. The roles and responsibilities matrix puts a named owner on each document, and the review and approval record is the shape of the dated review trail. Full summary, considerations, and transition notes on the 03.15.01 requirement page.
03.15.02 · System Security Plan
The SSP is the document of record: the system boundary, the operating environment, how each requirement is implemented within that boundary, and the system's relationships and connections to other systems. Rev. 3 moves it out of the old assessment family into Planning and adds two operational teeth: the update cadence becomes an organization-defined frequency rather than 'periodically', and the plan itself must be protected from unauthorized disclosure — it is, after all, a map of your defenses. The craft point matters more than the relocation: implementation statements should name the actual mechanism (the enforcing policy, the specific configuration), because an assessor reads the SSP first and checks reality against it.
Evidence is the current plan with a version history measured against the defined frequency, access restrictions on wherever the plan lives, and change records connecting system modifications to plan updates — every new SaaS integration and network change is a potential SSP delta. The SSP development worksheet structures the inputs, and the system boundary definition worksheet does the hardest part first. Details on the 03.15.02 requirement page.
03.15.03 · Rules of Behavior
Before someone touches CUI, they read the rules for handling it and acknowledge them in a documented way — and the rules themselves get reviewed at an organization-defined frequency. The logic is not that a signature stops misuse; it is that expectations never stated cannot be enforced, and terminations, disputes, and insider-risk cases eventually turn on whether the person was told. Rev. 2 had no counterpart requirement; many organizations ran this informally under acceptable-use policies, which is close but not the same thing — the rules here are specific to CUI handling and system usage, short, and acknowledged before access is authorized.
Evidence is the current rules with version history and acknowledgments reconciled against everyone holding access — an access population larger than the signed population is the first thing an assessor reconciles, and non-employee access (contractors, vendor technicians, partner users) counts. The rules of behavior template carries starter language, the acknowledgment register, and the renewal wiring; completion records can also ride the onboarding rows of the security training matrix. Details on the 03.15.03 requirement page.
As the contractor, the Planning family rewards what you maintain, not what you once wrote. Every document in it needs an owner, a review date on a calendar, and a believable history — and each one is yours even if a provider drafted the first version.
- Treat the SSP as an operated document: a named owner, change-driven updates, and version history against the frequency you defined — the SSP development worksheet structures the build, and your boundary decision is the foundation everything else stands on.
- Right-size the policy set before polishing it: one family-aligned structure with named owners in the roles and responsibilities matrix beats a shelf of aspirational documents operations contradicts.
- Rules of behavior are the cheapest early win in the family: one CUI-specific page, acknowledged at onboarding and on change, with the signed population reconciled against the access population.
- Protect the SSP like the map it is — restrict who can read it, and keep the access decision written down.
As a service provider, you rarely own a Planning document — but your fingerprints are on all three. The clients who transition well are the ones whose providers contribute in writing, on a cadence, without quietly becoming the author of record.
- Contribute provider-supplied implementation descriptions for your services to each client's SSP, reviewed on a schedule — folklore about 'how the MSP does it' is the gap assessors find first.
- When you draft policy or plan language for a client, route it through their ratification: the decisions are theirs to own, and a document only you understand serves neither seat.
- Your technicians are 'individuals requiring access' under the client's rules of behavior — expect to have your staff acknowledge client rules, and build that into your onboarding for each engagement.
- Feed the client's SSP delta process: when you change their environment, the change record you produce should be usable as their plan-update trigger, not a ticket that dies in your PSA.
System and Services Acquisition (03.16): engineering, end-of-life, and other people's services
The SA family looks like three unrelated requirements and is really one idea: the security consequences of what you build, keep, and buy. Security engineering principles govern how the system changes, unsupported-component handling governs what you allow to age in place, and external system services governs the providers your CUI runs through. This is where technical-debt and third-party discipline get explicit requirement language — and where the technical-debt practice stops being hygiene advice and becomes directly relevant to an assessable requirement.
03.16.01 · Security Engineering Principles
This requirement asks the organization to apply systems security engineering principles — layered defense, least privilege by construction, minimized attack surface, fail-safe defaults — to the development and modification of the system and its components. It moved here from Rev. 2's communications-protection family (3.13.2) and was reframed in transit, and its reach is wider than 'we don't write software' assumes: a new SaaS integration, a network redesign, and a product-selection decision all embody engineering choices, whether anyone made them deliberately or not. Unlike most of its Rev. 3 neighbors, the judgment here is not a parameter value to select; it is naming the principles you actually work from — SP 800-160's catalog is the common reference — and building them into design review, so the claim has verifiable content. Be honest about retrofit: for legacy portions of the system, the principles govern modifications and compensating design, not a rebuild nobody will fund.
Evidence is design or architecture review records showing security considered before implementation, the stated principles or secure-design standard the organization works from, and a sampled change demonstrating the principles applied to something real. The configuration baseline worksheet and the network segmentation plan worksheet are where several of those engineering choices become written artifacts. Details on the 03.16.01 requirement page.
03.16.02 · Unsupported System Components
The end-of-life problem finally has a requirement number. An unsupported component is a permanent vulnerability — no patch will ever come — and this requirement's default answer is replacement; where a production constraint makes replacement genuinely impossible, the organization must still produce deliberate risk-mitigation options (isolation, restriction, extended support) rather than silence. There is no parameter to tune here; the organization-defined work is the decision record itself: which components are unsupported, which get replaced by when, and which stay with a documented mitigation, an owner, and a revisit date — so 'temporary' does not silently mean permanent. End-of-support is a date you can see coming years out, which makes this the most schedulable requirement in all three families.
Evidence is the unsupported-component register reconciled against the asset inventory with support-end dates, retirement records showing the register shrinking over time, and the documented mitigation decisions for what remains. The hardware and software asset inventory carries the support-status columns the register is built from, and the IT-03 practice guide is the campaign plan for working it down. In OT environments the same logic runs through vendor lifecycle reality — see the OT-09 practice guide for the plant-floor version. Details on the 03.16.02 requirement page.
03.16.03 · External System Services
When CUI runs through someone else's service, the organization still owns the outcome. This requirement makes the arrangement explicit: the providers of external services that process, store, or transmit CUI are required to conform to the organization's security requirements, and the organization defines and documents its oversight of those services and the user roles and responsibilities that go with them. The central organization-defined element is that set of imposed security requirements — you write what the provider must conform to, and a provider's marketing page is not a contractual obligation. 'The cloud provider handles security' is a sentence assessors hear weekly and accept never; a platform's federal authorization describes the provider's side, not your configuration and oversight on top of it.
Evidence is the external-service inventory with CUI relevance, provider obligations, and a named internal owner per service; agreements or terms showing the requirements actually imposed; and dated oversight records — attestation reviews, configuration checks, service reviews — proving somebody watches. Start with the cloud and SaaS inventory; the service count is nearly always higher than expected once file transfer, e-signature, and support tooling are included. Details on the 03.16.03 requirement page.
As the contractor, the SA family is a sequencing gift: all three requirements start from inventories you can build this quarter, and the hardest conversations — with your own legacy systems and your own providers — get easier the earlier the register exists.
- Stand up the end-of-life register now from the asset inventory: every unsupported component gets a replace-by date or a written mitigation with an owner and revisit date — 'we know about it' is neither.
- Inventory external services before negotiating anything: the cloud and SaaS inventory makes the sprawl visible, and each service needs a named internal owner, not a procurement checkbox.
- Put your security requirements to providers in the agreement at renewal — notification terms with a clock, data handling, evidence delivery — because an imposed requirement that lives only in an email thread is unenforceable.
- Name the engineering principles you actually apply and wire them into change review; a one-page secure-design standard you follow reads better than a borrowed framework you cannot demonstrate.
As a service provider, 03.16.03 is substantially about you: your clients are being asked to define requirements you must conform to, document the split of responsibilities, and oversee your performance. The providers who make that easy will keep the accounts.
- Author the responsibility split per service line yourself — 'we do / you do / we both do' — and review it with each client on a cadence; a client forced to reverse-engineer your service is a client an assessor will surprise.
- Make oversight a deliverable: periodic evidence packages (reports, exports, review notes) turn 'the client monitors the provider' from an awkward audit into a subscription feature.
- Your own stack has an end-of-life story, and 03.16.02 logic reaches your clients through you — aging components in your platform are risk your clients inherit and their assessors can ask about.
- Accept imposed security requirements you can actually evidence, and price them; a term you cannot demonstrate is worse for both seats than one you decline in writing.
Supply Chain Risk Management (03.17): the family with no ancestor
SR is the only Rev. 3 family with no Rev. 2 counterpart of any kind, and it is widely regarded as the hardest genuinely new ground in the revision. Its three requirements form a deliberate structure: a plan that governs (03.17.01), acquisition machinery that prevents (03.17.02), and running processes that detect and enforce (03.17.03). The reason it hurts is cultural, not technical — most contractors have treated supplier risk as a purchasing or quality concern, and this family asks for it as an assessable security program with owners and follow-through. NIST's C-SCRM practice guide, SP 800-161, is the deep reference behind the family's vocabulary.
03.17.01 · Supply Chain Risk Management Plan
The plan is a written answer to the question 'how does this organization decide what risk its suppliers bring, and what does it do about it' — covering supply chain risks across the system's full lifecycle, from development and acquisition through integration, operations, maintenance, and disposal. Like the SSP, it carries an organization-defined review frequency and must be protected from unauthorized disclosure — it evaluates the very suppliers it should be kept from. Scope it to the system that handles CUI rather than attempting an enterprise procurement rewrite, and build it from what already exists: vendor-vetting habits, purchasing rules, and contract templates are plan content already in operation. The plan's job is to connect and own them, not reinvent them.
Evidence is the plan itself with version history against its defined frequency, and — the part that separates a program from a binder — records showing the plan's processes exercised on a real acquisition or supplier event. A risk register that carries supplier entries with owners and dispositions is the natural spine. Tie the review cadence to supplier change (a new critical vendor, an acquisition, a discontinued product line), not only to the calendar. Details on the 03.17.01 requirement page.
03.17.02 · Acquisition Strategies, Tools, and Methods
Supply chain risk is cheapest to handle at purchase time, and this requirement moves security into the buying process itself: the questions asked before a product or supplier is chosen, the obligations the contract carries, and the sourcing choices — authorized channels, provenance expectations — that reduce the chance of counterfeit or compromised components ever arriving. There is no headline parameter here; the organization-shaped choices are structural: a procurement gate that scales with consequence (a component destined for the CUI environment earns scrutiny a printer cable does not) and contract language built once — security terms, vulnerability disclosure, incident notification, right to assess — then reused across purchases.
Evidence is the procurement checklist or gate showing security applied before purchase, the contract templates or clauses carrying supply chain obligations, and a sampled acquisition demonstrating the strategy operating end to end. The vendor risk assessment worksheet is the pre-purchase vetting instrument, and in OT procurement — where sole-source vendors often hold the leverage — the realistic version of this requirement runs through the OT-09 practice. Details on the 03.17.02 requirement page.
03.17.03 · Supply Chain Requirements and Processes
The operating half of the family: running processes that identify and address weaknesses in supply chain elements — a single-source component, a vendor with a poor patch history, an update channel with no integrity checking — and organization-defined security requirements enforced on suppliers to protect against supply chain risk and limit the harm when a supply-chain event lands anyway. Enforcement is the word that matters; requirements without consequences are requests. The parameter decision here is the requirement set itself: what suppliers must carry (secure development attestation, vulnerability notification, component provenance), tiered by consequence, checked at onboarding and on a cadence rather than once.
Evidence is the supplier-review process with records of weaknesses found and addressed, the defined supplier requirements and where each is imposed — contract, agreement, or terms — and escalation or enforcement records for a supplier that fell short. The supplier security questionnaire is the assessment instrument; keep it distinct from contractual flowdown, because a questionnaire is a question and a flowdown is an obligation, and presenting one as the other weakens both. Treat supplier weaknesses like vulnerabilities: recorded, risk-rated, assigned, and tracked to closure or formally accepted. Details on the 03.17.03 requirement page.
As the contractor, resist the urge to write the plan first. The SR family matures from the ground up: register, then requirements, then process, then the plan that describes what is by then actually happening.
- Build the supplier register before any prose: critical suppliers, integrators, and single-source components, risk-rated in the risk register and assessed with the vendor risk assessment worksheet.
- Define the supplier security requirements you will actually enforce, tiered by consequence — the vendor with remote access to production and the office-furniture vendor do not warrant the same process.
- Keep the plan short and true: a five-page plan naming the register, the cadence, the contract-terms approach, and the escalation path beats a fifty-page plan nobody follows.
- Keep the supplier security questionnaire and your contractual flowdown as separate instruments, and record at least one supplier escalation honestly — enforcement evidence is the family's scarcest artifact.
As a service provider, you live on both sides of this family: you are a line item in every client's supplier register, and your own subcontractors and tooling are part of your clients' supply chains whether anyone has written that down yet or not.
- Build one reusable supplier-assessment response — posture summary, personnel access model, notification terms, subcontractor list — because every Rev. 3-era client will ask, and answering fifty questionnaires from scratch is margin erosion.
- Map your own dependencies as your clients' supply chain: the RMM platform, the ticketing system, the offshore NOC — exactly the elements 03.17.03 wants identified and governed, one tier removed.
- Put incident-notification commitments in writing with timeframes that reconcile against each client's requirements; 'we would obviously tell you' is not a process, and a clause with a clock is.
- Where you run procurement or vendor management for clients, document which SR activities you perform and what evidence you hand over — a supplier register maintained silently earns the client nothing in an assessment.
Where to start
Across all nine requirements, the cheap-to-start, slow-to-mature artifacts are the same three: the supplier register (feeding all of 03.17), the end-of-life register (03.16.02), and the external-service inventory (03.16.03). All three are useful under either revision, none requires a policy decision to begin, and each makes the eventual plan or policy easier to write because it will describe something real. The long-lead items are the SSP's quality (03.15.02) and the enforcement habit (03.17.03) — documents and behaviors that cannot be backfilled in the month before an assessment.
Sequence matters more than speed, and the right sequence depends on where you honestly are — which is the subject of the next article in this series. And keep the seat distinction in view throughout: a provider can operate registers, draft plans, and deliver evidence, but the parameter choices, the imposed requirements, and the answers in the assessment room belong to the contractor.
The series overview, Fewer Requirements, More Work, maps where Rev. 3's whole workload concentrates beyond these three families. The prioritized remediation roadmap sequences this work for three honest starting points. Requirement pages for every identifier named here live in the site's Rev. 3 mapping, and the Rev. 2 to Rev. 3 crosswalk shows what moved where.
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-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.