03.17.02 Acquisition strategies, tools, and methods

What acquisition strategies must do for CUI supply chain risk under 03.17.02

Requirement 03.17.02 asks the organization to develop and implement acquisition strategies, contract tools and procurement methods that identify, protect against and mitigate supply chain risks to systems that handle CUI. It is new in Rev. 3 and traces to SR-5 in SP 800-53 Rev. 5. NIST's change analysis maps no Rev. 2 requirement to it, so CMMC Level 2, which assesses the 110 Rev. 2 requirements, has no matching requirement ID. Contracts that name Rev. 2 will not ask you to show 03.17.02 as a discrete item, but a contract that names Rev. 3, or a future FAR clause, may. As of this writing, DoD contracts still reference Rev. 2 under the revised DFARS clause, and the FAR overhaul rule proposing Rev. 3 is not final. Confirm the revision named in each contract, its modifications and any agency-specific parameter values before you scope the work.

In practice, the evidence sits in purchasing documents more than in technical settings. An assessor will look for an SCRM policy and procedures, the SCRM plan, system and services acquisition procedures and documented procedures for supply chain protection, then ask personnel with acquisition and SCRM responsibilities how tailored acquisition strategies are chosen. Expect the test to cover whether the organization actually uses defined contract tools, such as security clauses, incident notification terms, right-to-audit provisions, software bill of materials requirements and approved-vendor criteria, on purchases that touch CUI. A clean policy with no contract that reflects it will not pass.

Because the requirement governs how the organization buys, the work belongs to procurement, legal and security together. Procurement owns the sourcing and contract templates, legal owns the clauses and flow-down language, and security defines which risks each acquisition must address. A useful first step is to list the purchase types that reach CUI systems, such as cloud hosting, managed services and software licenses, and confirm who signs off on each. An implementation partner can help draft templates and evidence records, but the organization must own the decisions and the signed contracts that the assessor will review.

Which acquisitions and suppliers 03.17.02 reaches

Requirement 03.17.02 applies wherever the organization buys components, services or hosting that could affect systems handling CUI. The cards below set out the scoping decisions that determine how much contract language and review work follows, and why the organization's own acquisition process sets much of that scope.

Acquisitions that touch CUI systems

Start by listing every purchase that adds, changes or maintains a system that stores, processes or transmits CUI. This includes hardware, licensed software, development tools and infrastructure upgrades. Each one needs an acquisition strategy that states how supply chain risk is considered before the purchase. Purchases outside the CUI boundary, such as office supplies, usually fall outside 03.17.02, but confirm that boundary in the system security plan before relying on it. Ask procurement to flag CUI-relevant requests at intake so the review happens before a contract is signed.

Component suppliers inside the boundary

Hardware vendors, firmware sources and open-source software maintainers supply parts that run inside the CUI boundary. Their risk is often hidden because no contract covers a free component. Document which components are bought, which are downloaded, and who controls updates for each. Acquisition tools such as tailored contract clauses apply most directly to paid suppliers, while open-source components call for a defined selection and vetting method. Track both in the same inventory so the review covers the full supply path.

Managed and cloud service providers

A managed service provider or cloud platform that administers, hosts or backs up CUI becomes part of the supply chain for those systems. Contract terms usually determine what the provider must disclose, how it notifies the organization of changes, and how it handles incidents. Check whether the provider's administrators can reach CUI and whether that access is covered by the agreement. Ask for the provider's own supply chain practices in writing, and confirm the terms with counsel before signing, since the requirement is met through the contract and the review process.

Subcontractors that receive CUI

Any subcontractor that receives, generates or handles CUI extends the organization's supply chain exposure. The contract with that subcontractor should pass down the security expectations that apply to the prime, and the review should confirm that the subcontractor can meet them. The scope of this review grows with the number of tiers and the volume of CUI shared. Keep a current list of subcontractors that touch CUI, the data each one receives, and the date its terms were last reviewed. Confirm the flow-down language with your contracts team, since the wording depends on the prime contract.

Policy and process ownership

The organization's own acquisition process sets much of the scope for 03.17.02. Procurement, legal, security and the system owner each decide what gets reviewed, which contract tools apply and who signs off. Written procedures for these steps are what an assessor examines and what interviews test. Map each acquisition path to a named owner before the assessment, and confirm that staff who buy technology know when to involve security. Where the process is informal, expect the assessment to find gaps that need documented fixes.

How an assessor tests 03.17.02 with six determination statements

This table breaks down how SP 800-171A Rev. 3 tests 03.17.02, showing which examine, interview and test methods apply and which objects an assessor reviews for each determination. Read it as a map of the evidence trail: an assessor needs documents, people who run the process, and proof that the tailored acquisition steps were actually carried out. Documented intent alone rarely satisfies the requirement.

Assessment focus	Methods and objects reviewed	Typical finding when the paperwork exists but practice does not
Acquisition strategies defined and tailored to supply chain risk	Examine: SCRM policy and procedures, SCRM plan, system and services acquisition policy and procedures. Test: process for defining tailored acquisition strategies.	The plan names acquisition strategies, but no record shows they were tailored for a specific system or purchase.
Contract tools selected and defined for supply chain protection	Examine: procedures for supply chain protection. Test: mechanisms for defining contract tools used in procurement.	Standard contract templates are used unchanged for high-risk components, with no supply chain clauses added.
Procurement methods defined and applied	Examine: SCRM plan and acquisition procedures. Interview: personnel with acquisition responsibilities. Test: procurement methods as defined.	Staff describe the method from memory, but purchase files show different steps were followed.
Implementation of tailored strategies, tools and methods	Test: mechanisms for implementing tailored acquisition strategies, contract tools and procurement methods.	Tailored requirements are written into the plan but absent from purchase orders, statements of work or vendor onboarding.
Responsibility for supply chain acquisition work	Interview: personnel with acquisition responsibilities and personnel with SCRM responsibilities.	Procurement and security teams cannot describe who approves tailored terms or who checks them.
Consistency between plan, procedures and practice	Examine and interview together: whether SCRM and acquisition documents agree with how people describe and perform the work.	Documents are current, but interviews and sampled purchases show the process has not been followed since the plan was approved.

How to build an acquisition strategy that covers supply chain risk

This sequence turns the 03.17.02 requirement into a working acquisition process, from the supply chain policy and plan that govern it through tiered strategies, contract terms, approval gates and tests that buyers follow them. Each step closes with a record an assessor can examine, interview against and test.

Confirm the supply chain policy and plan
Start by checking that the supply chain risk management policy and plan exist, are approved, and name who owns acquisition decisions. The acquisition strategy has to follow them, so every later step cites them. Owners are usually the CISO or security governance lead with procurement. The output is an approved policy, a current SCRM plan, and a short list of acquisition roles that an assessor can match against the procedures in SP 800-171A Rev. 3, which lists the SCRM policy and plan as examine objects for 03.17.02.
Inventory acquisitions and suppliers that touch CUI
Build a register of every purchase, subscription, service and supplier that can access, store, process or transmit CUI or support systems that do. Include cloud and managed service providers, software vendors with remote maintenance access, and subcontractors. Pull data from procurement records, asset inventories and system security plan boundaries rather than relying on memory. The output is a dated register with a named owner for each entry, reviewed against the system boundary, which gives the assessor a population to sample from.
Define tailored acquisition strategies by risk tier
Group the register into risk tiers based on the CUI exposure, criticality of the function, and how hard the supplier would be to replace. For each tier, document the acquisition strategy: the due diligence expected, the security evidence to request, and the conditions for approval. The organization sets the tiers and their criteria, since NIST does not prescribe them. The output is a written tiered strategy approved by the SCRM function, which an assessor will check against the processes for defining tailored acquisition strategies named in SP 800-171A Rev. 3.
Select contract tools and security clauses
For each tier, choose the contract tools that carry the strategy into agreements: security requirements, incident notification duties, flow-down terms for subcontractors handling CUI, assessment and audit rights, and conditions for disposal or return of data. Procurement and legal draft the terms, and the security team confirms they match the tier. Where a federal contract already prescribes flow-down language, reuse it. The output is a clause library mapped to tiers, plus a checklist showing which clauses each new or renewed contract must carry.
Set procurement methods and approval gates
Document the procurement methods buyers use, such as competitive bids, sole-source justification, purchasing through approved catalogs, and renewals, and attach a security approval gate to each. The gate states who must sign off before a supplier of a given tier is onboarded, what evidence is required (for example, reviewed security documentation or completed questionnaires), and what happens when a supplier cannot meet the terms. The output is a procurement procedure with a documented gate for each tier and a record of exceptions and their approvers.
Track supplier evidence and assessment results
Use an inventory or compliance tool to record each supplier's tier, contract clauses, evidence received, review dates and open findings. Open-source options such as CISO Assistant can hold assessments and map them to frameworks, and Dependency-Track can ingest CycloneDX SBOMs and VEX from software suppliers to flag vulnerable or license-risk components. Confirm each tool's capabilities against your environment before relying on it. The output is a current supplier record set that links every acquisition to its tier, evidence and review status.
Test that buyers follow the strategy
Sample recent acquisitions across tiers and check that the tier was assigned correctly, the required clauses appear in the signed contract, the approval gate was passed and the evidence is on file. Interview procurement and SCRM personnel to confirm they know the procedure, which mirrors the interview and test objects in SP 800-171A Rev. 3 for 03.17.02. Record each exception and its remediation. The output is a test record with sample selection, results and tracked findings, which supports the organization's own assessment under the 03.12 requirements.

Evidence that passes 03.17.02 and how to keep it current

An assessor testing 03.17.02 looks for documents that show acquisition strategies, contract tools and procurement methods were defined, applied and reviewed. The six cards below cover the records most often examined, with the refresh trigger and signer to confirm for each. Your organization sets the cadence and approvers, and the dates and signatures must match what your team actually does.

SCRM policy and procedures

The top-level policy states why acquisition decisions consider supply chain risk and who is accountable for them. Its procedures describe how a buyer selects an acquisition strategy, which contract tools apply and when escalation to security is required. Assessors use it as the baseline for every other card. Confirm the policy names an accountable executive as approver, carries a version number and a next review date, and that the procedures match what acquisition staff actually do. Refresh on the review date or after a significant change to acquisition practice, and record each review in the document history.

SCRM plan

The supply chain risk management plan sets the methods your organization uses to identify and mitigate supply chain risk across the system life cycle. For 03.17.02 it should name the acquisition strategies, contract tools and procurement methods in use and the roles that apply them. It is also the document that links to the 03.17.01 plan requirement. Confirm it has a named owner, an approver with authority over procurement, and a review cycle set in the plan itself. Refresh when suppliers, system boundaries or contract vehicles change, and keep prior versions so an assessor can see how the plan evolved.

Tailored acquisition strategy records

Each tailored acquisition strategy shows how a specific purchase, system or service was matched to its supply chain risk. A record should state the risk identified, the strategy chosen, the contract tool used and the procurement method selected. Assessors test whether these records exist for real acquisitions and whether the tailoring reflects the risk, rather than applying one template to every buy. Confirm each record is dated, names the requesting and approving staff, and references the risk assessment that drove it. Refresh the record when scope, supplier or contract terms change during the acquisition.

Contract templates with security clauses

Contract templates carry the security and supply chain clauses your organization expects in its agreements, such as notification duties, component disclosure and access restrictions. A clause in a template shows intent, but it is weaker evidence than a signed contract that uses it. Assessors will ask for an executed contract that carries the clause. Confirm the template has a version and owner, that legal or security approved its current wording, and that the clauses reflect the tailored strategies. Review templates when regulations or the SCRM plan change, and keep each signed contract tied to the template version it used.

Procurement approval records

Procurement approval records show that a security or risk reviewer examined an acquisition before it was approved. For 03.17.02 they should reflect the acquisition strategy and contract tools chosen, with the reviewer's findings and any conditions attached to approval. Assessors interview the people who approve purchases to confirm they understand the process. Confirm each approval names the approver, the date, the scope and the outcome, and that approvals are not granted without the review step. Records are created per acquisition, so the refresh is the approval itself, plus a re-approval when scope or supplier changes materially.

Supplier review records

Supplier review records document the assessment of each supplier against the acquisition strategy and the risks identified for it. Typical content includes the supplier's security posture, its component sources and any known weaknesses, along with the decision reached. These records feed the supplier and component inventory that Dependency-Track or similar tools can help populate when software components are involved. Confirm each review is dated, signed by the reviewer and approver, and linked to the contract it supports. Refresh on a schedule set in the SCRM plan and whenever a supplier incident, ownership change or scope change occurs.

How open-source tools produce supplier and component evidence

Tools do not satisfy 03.17.02, but they can produce much of the evidence an assessor will ask for. The requirement is mostly procedural: the organization must develop and implement acquisition strategies, contract tools and procurement methods that identify, protect against and mitigate supply chain risks. SP 800-171A Rev. 3 looks for a written SCRM policy and plan, acquisition procedures, and records showing those procedures were applied. Software can show what sits inside the systems you buy or build, which gives the acquisition records something concrete to reference.

*OWASP Dependency-Track* (Apache-2.0) is the most direct fit. It consumes and produces CycloneDX SBOMs and VEX, flags components with known vulnerabilities, outdated or modified components and license risk, and tracks license use by SPDX license ID. Before a supplier review or renewal, export the component inventory for the product in scope and record which findings were triaged, accepted or remediated. Trivy (Apache-2.0) complements it: it identifies OS packages and software dependencies in a target, can generate an SBOM, and can scan SBOMs that suppliers provide. Confirm with each supplier that the SBOM format and scope they deliver are compatible with what your tooling expects, and keep the files with the contract record.

*CISO Assistant* (AGPL-3.0-only) can run assessments against frameworks including NIST CSF and track evidence against requirement records, so the supplier review, contract clause and SCRM plan references sit in one place. Because the license is AGPL-3.0-only, confirm with counsel how its terms apply if you modify the software, host it for users outside your organization, or embed it in a service you provide. Treat the tool as a register for evidence, not as the assessment itself: an independent assessor or the contracting federal agency decides whether the evidence is sufficient.

What meeting 03.17.02 costs in money and effort

This table lists the cost components of building and keeping up the 03.17.02 acquisition strategy, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written quote, since no price or duration is published for this work.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Policy and SCRM plan drafting	Internal staff or implementation partner	One-time, then periodic review	Number of existing procurement policies to reconcile with the SCRM plan
Legal and contract template revision	Internal counsel or outside contract lawyers	One-time, then on each template change	Number of standard templates and flow-down clauses that need supplier security terms
Procurement staff time	Internal procurement and acquisition staff	Recurring with each new supplier or renewal	Contract volume and how many purchases pass through a formal security review
SBOM and supplier review tooling	Software vendor license or self-hosted open source with internal hosting costs	One-time setup, recurring hosting and upkeep	Number of software products ingested and whether commercial licenses are required
Supplier assessment effort	Internal security staff, supplier questionnaires, third-party assessors	Recurring per supplier and per reassessment cycle	Number of suppliers with access to the CUI boundary and their criticality
Evidence upkeep	Internal compliance or security engineering staff	Recurring	Frequency of supplier changes and how well evidence is stored in one system
External review	Independent assessor or consultant	Periodic, tied to assessment cycle	Scope of the CUI boundary and the assessment level the contract requires
Auditor sampling	Independent assessor, paid by the organization	Periodic, per assessment	Number of acquisitions sampled and completeness of records for each one

Your team, an implementation partner and the auditor for 03.17.02

Your organization owns the requirement. Leadership, procurement, legal and the security team decide how acquisitions are structured, which contract clauses apply to suppliers that touch CUI or the systems that process it, and which suppliers are accepted or rejected. Those decisions belong to you because they carry the business and contractual risk, and an assessor will expect to see that people with real authority made them.

Acquisition policy: Approve the rules for how supplier risk is considered before a purchase, including who signs off on high-risk acquisitions.
Contract tools: Decide which security terms, notification duties, audit rights and data handling clauses go into standard and negotiated contracts.
Supplier decisions: Accept, condition or reject suppliers based on the risk findings, and record the reasoning.
Named owners: Assign people to the acquisition and SCRM responsibilities that assessors will interview.
Ongoing review: Keep the procurement methods current as contracts renew and as the CUI scope changes.

Before engaging anyone else, confirm that your procurement and legal teams can name the people who make these decisions and show records of them.

Where organizations fall short on supply chain acquisition

Most gaps under 03.17.02 are not missing policies. They are places where the acquisition strategy written in the SCRM plan never reaches the contracts, purchase records and supplier files that an assessor will examine. The cards below cover the gaps we see most often, with the fix for each.

SCRM plan procurement never follows

The supply chain risk management plan describes tiered suppliers and review steps, but buyers place orders through a process that never references it. An assessor will compare the plan against purchase requests and vendor onboarding records. Fix: add a required SCRM check to the purchase request and vendor onboarding workflow, so the plan is applied at the point of purchase.

Contract templates without security flow-down

Standard purchase terms often omit security obligations such as incident notification, access limits for CUI, and rights to review a supplier's controls. Each new contract then starts from a weaker position than the plan requires. Fix: maintain approved clause sets for each supplier tier and require legal sign-off before a template is used without them.

No record of tailored strategies by tier

Organizations often apply one acquisition approach to every supplier, from cloud hosting providers to office printer vendors. NIST expects strategies, contract tools and procurement methods to be tailored, and the examine and test steps look for records showing how each was chosen. Fix: document a tailored acquisition strategy for each supplier tier, with the reason for each contract tool selected.

SBOMs not refreshed after supplier changes

A software bill of materials captured at purchase can go out of date when a supplier changes a component, releases a new version or is acquired. Tools such as OWASP Dependency-Track consume CycloneDX SBOMs and VEX data and track components with known vulnerabilities, but only if the inventory is kept current. Fix: require updated SBOMs at each release or renewal and load them into a tool that alerts on changes.

No evidence buyers were trained

Assessors interview personnel with acquisition and SCRM responsibilities. If buyers cannot describe the tailored strategies or show a training record, the interview and examine steps tend to fail even when the policy is sound. Fix: deliver role-based training to purchasing and contract staff and keep attendance and completion records with the procurement files.

What buyers ask about 03.17.02 cost, timing and outside help

How much extra effort does 03.17.02 add beyond the supply chain risk management plan?

In most programs, 03.17.02 adds the work of turning the plan into contract practice. The plan under 03.17.01 says what the organization considers a supply chain risk. 03.17.02 asks for the acquisition strategies, contract clauses and procurement methods that act on that view, and it asks you to show they are used. Assessors look for six determination statements covering SCRM policy, the SCRM plan, acquisition procedures, the people who buy, and tested mechanisms. The effort depends on how many suppliers, contract templates and purchasing routes you have, and on whether procurement already has supplier security terms in place. Confirm with your assessor which artifacts they will sample before estimating the work.

Is 03.17.02 required under Rev. 2 contracts?

Not as a numbered requirement. 03.17.02 is new in Rev. 3, and NIST maps no Rev. 2 requirement to it. CMMC Level 2 assesses the 110 Rev. 2 requirements, so it has no matching requirement ID. Contracts that still reference Rev. 2 are assessed against those 110 requirements. The DoW class deviation dated 3 September 2026 names Revision 2 explicitly, and the proposed FAR overhaul would move contractors to Rev. 3 with ODP values published by the DoW CIO, but that rule was not final as of October 2026. Confirm which revision your contract cites and whether a later modification changes it.

What does 03.17.02 need from procurement and legal teams?

It needs procurement and legal to own the contract side of supply chain risk. Procurement typically maintains the acquisition routes, supplier onboarding steps and the templates that carry security terms. Legal reviews the clauses that set security expectations, notification duties and the rights to assess suppliers. Both teams also need to identify the personnel with acquisition responsibilities, because assessors interview them. Expect to document which contract tools are used for which supplier types and to keep records showing the process ran. Ask your counsel whether existing terms already satisfy this, since that answer changes the work.

Can our organization complete 03.17.02 without outside help?

Often yes, if you have procurement, legal and security staff who can write the strategies and keep records. Outside help is useful when the work crosses many contract types, when no one owns supplier security terms, or when you need an independent view before an assessment. Your organization owns the controls and the decisions. An implementation partner such as DeployOpen can prepare systems, procedures and evidence under a written scope. Only an independent assessor or certification body issues a report or certificate. Decide early which part you will do in-house and which you will buy.

How long does readiness take, and what drives that timeline?

No supplied fact gives a duration for 03.17.02 readiness, so confirm the timeline with your assessor and with any partner before you commit. The main drivers are the number of contract templates, how many supplier categories you buy from, whether a current SCRM plan exists to build on, and how quickly legal and procurement can review changes. Timelines also depend on how many people must be interviewed and how far existing contracts reach back. Ask for a milestone plan that separates policy drafting, contract updates and evidence collection.

What should we request in a DeployOpen quote for this work?

Ask for a written scope that names the systems, contract types and deliverables in play, because quotes follow from scope and DeployOpen does not publish a price list. Request the list of artifacts to be produced, such as acquisition strategy documents, contract tool guidance and procurement records. Ask which tasks are one-time, such as drafting strategies, and which recur, such as supplier reviews and evidence refresh. Confirm who attends interviews, what assessor support is excluded, and what happens if the assessment basis changes from Rev. 2 to Rev. 3. Agree on acceptance criteria in writing before work begins.

How DeployOpen prepares 03.17.02 evidence for your assessment

DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside your own infrastructure. For 03.17.02 Acquisition strategies, tools, and methods, we prepare the systems, procurement records and evidence your organization needs, while your organization owns the controls and an independent assessor reaches the conclusions.

How we scope

We agree the written scope for 03.17.02 before work starts, listing the acquisition processes and contracts in the CUI boundary.
We confirm which SCRM policy, SCRM plan and acquisition procedures already exist and which must be written or revised.
We identify the personnel with acquisition and SCRM responsibilities who will be interviewed, and record their roles in the scope.

How we build

We set up open-source tooling that can hold the SBOM inventory of acquired software that supports supplier selection and contract tool decisions.
We configure Dependency-Track to track component vulnerabilities, outdated components and SPDX license risk for acquired products.
We help define the procurement mechanisms and contract tool templates your organization would use to set supplier security requirements.

How we hand over

We deliver the documented acquisition procedures, configuration records and tool outputs mapped to the six 03.17.02 determination statements.
We walk your assessment team through how each examine, interview and test object is evidenced, so they can verify it themselves.
We record open items, owners and dates in a handover register, so your organization can close any gaps before the assessor arrives.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work is complete.
We can keep SBOM and component data current so acquisition decisions are based on the latest supplier inventory.
Confirm with us in writing which retainer tasks cover re-running tooling evidence before each assessment cycle.