What 03.17.03 asks an organization to prove about its supply chain
If you are preparing for a Rev. 3 assessment, 03.17.03 has no Rev. 2 equivalent, so your existing Rev. 2 evidence will not answer it. The requirement has two halves. First, you need a working process to identify and address weaknesses or deficiencies in your supply chain elements and processes. Second, you need to enforce security requirements that you define yourself to protect against supply chain risks to your systems, system components and system services, and to limit the harm when a supply chain event occurs. An assessor will look for both halves: a process that finds problems, and proof that the process leads to enforced requirements in contracts, onboarding and operations. NIST maps the requirement to SR-3 in SP 800-53 Rev. 5 as its source control, which explains its origin but does not change what you must show.
The hard part is that the requirement is partly undefined by design. Its one organization-defined parameter is the set of security requirements you apply against supply chain risk. NIST does not assign that value. If the federal agency you contract with does not specify it, you must assign it yourself, and the assessor will check that the value is defined and used. Confirm with your contracting officer or prime contractor whether they will supply ODP values for 03.17.03 before you start, because the answer changes how much of this work you must design from scratch. Also confirm which deviation or rule governs your contract, since recent federal documents point to Rev. 2 and to Rev. 3 in different ways.
Expect the assessor to test 03.17.03 against your 03.17.01 and 03.17.02 work, not in isolation. The supply chain risk management plan (03.17.01) should name the elements and processes you consider critical, and the acquisition strategies and contract tools (03.17.02) should carry your chosen security requirements into supplier agreements. Gather an inventory of critical system components and services, a record of any deficiencies found in suppliers or your own procurement process, the action taken on each, and a sample of contract language that enforces your requirements. Interview the people who own acquisition, information security and SCRM work, since the assessment procedure includes interviews as well as document review.
Which systems, suppliers and teams fall under 03.17.03
Requirement 03.17.03 applies to the systems and suppliers that touch controlled unclassified information, so scope starts with the CUI system boundary. The cards below cover the decisions that change the work: which components are in scope, which suppliers feed them, and which teams must agree on the security requirements the organization enforces.
Systems and components inside the CUI boundary
Start with the system security plan boundary and list every system, component and service that stores, processes or transmits CUI, plus the administrative tools that can reach them. Components outside that boundary usually fall outside 03.17.03, but a shared identity provider, backup service or build pipeline that touches CUI systems may not. Document the reasoning so an assessor can follow why each item is in or out.
Commercial software and hardware suppliers
Map each product vendor that supplies operating systems, network devices, endpoint agents and firmware used inside the boundary. For each one, record who can push updates, where they are delivered from and what support commitments exist. Ask vendors for their secure development and vulnerability disclosure practices, and note where the organization cannot obtain that information.
Managed and cloud service providers
Identify every managed service, hosting provider, SaaS tool and support contractor with administrative or data access to CUI systems. Their staff, subprocessors and remote access paths become part of the supply chain you must control. Confirm which security requirements each contract imposes on them and how the organization verifies those requirements are met.
Open-source dependencies and build inputs
Inventory the open-source libraries, container base images, package repositories and build tools that compile or deploy software running in scope. A dependency pulled into a CUI system is a supplier relationship even though no contract exists. Generate a software bill of materials for each in-scope application and decide who reviews new or updated components before they reach production.
Acquisition and contracting team
The acquisition team sets the contract terms that carry security requirements down to suppliers, so it must know which ones to enforce. Confirm with this team who signs off on new suppliers, who tracks renewals and who can add security clauses to purchase orders. Gaps here usually show up as suppliers who were never asked to meet the requirements the organization has defined.
Security and engineering owners
Security owns the defined security requirements and the process for finding weaknesses in suppliers and their processes. Engineering owns the components and deployment pipelines where those findings must be fixed. Name one owner for each supplier record and agree on how findings move from security review to engineering work, with dates and escalation paths written down.
How an SP 800-171A assessor tests 03.17.03
This table maps each determination statement and the ODP check for 03.17.03 to the examine, interview and test methods an assessor uses under SP 800-171A Rev. 3. Read it as a checklist of what to prepare: the documents to examine, the people to interview and the deficiency process that must be shown working.
| Assessment element | What the assessor does | Evidence to prepare |
|---|---|---|
| Determination statement 1: supply chain deficiency process | Examines whether the organization has a process for identifying weaknesses or deficiencies in supply chain elements and processes, and tests whether that process runs | Written SCRM procedure, a register of identified supply chain deficiencies, and records of how each was addressed |
| Determination statement 2: security requirements enforced | Examines the organization-defined security requirements for supply chain risk and checks they are enforced against suppliers and internal supply chain elements | Defined supply chain security requirements, contract clauses or supplier terms that reference them, and enforcement records |
| Determination statement 3: limiting harm from supply chain events | Interviews personnel to confirm how supply chain events are contained and how their consequences are limited | Incident or event records showing containment steps, and a description of how impact is limited for each event type |
| ODP check: security requirements defined | Confirms the organization-defined parameter for security requirements and the harm-limiting scope has an assigned value | A written ODP assignment stating the supply chain security requirements, signed off by the system owner or the federal agency |
| Examine objects | Reviews SCRM policy and procedures, the SCRM strategy and plan, the system and critical component inventory, and system and services acquisition policy | Current versions with approval dates, a component inventory that covers critical elements, and a plan that links to this requirement |
| Interview objects | Speaks with personnel holding acquisition, information security and SCRM responsibilities | Named roles, role descriptions and staff who can explain the deficiency process from their own work |
| Test object: deficiency process | Tests whether the process for identifying and addressing supply chain element and process deficiencies operates as described | Sample deficiency records showing identification, assigned owner, corrective action and closure |
| Common finding: undefined ODP | The ODP check fails when no value is assigned, which leaves the requirement without a measurable standard | Confirm the value with the federal agency or the DoW rule in effect, then document it in the SSP |
| Common finding: paper-only process | A process exists in a document but no deficiencies were recorded, followed up or closed, so the test method cannot be satisfied | Run the process on real supply chain elements and keep records, even where findings are minor |
| Common finding: no link to the SCRM plan | The assessor cannot trace how the deficiency process fits the SCRM plan under 03.17.01 | A cross-reference from the process to the plan, with the same roles and review cycle |
Implementing 03.17.03 in the order an assessor will check it
This sequence builds the supply chain requirements and processes that 03.17.03 asks for, one artifact at a time, so each step leaves evidence an assessor can examine, interview against and test. The order matters because the ODP values set the bar that the process, the register and the periodic review are measured against.
Define and approve the ODP values
Start by assigning values to the one organization-defined parameter in 03.17.03: the security requirements that protect against supply chain risks to systems, system components and system services, and that limit the harm from supply chain events. NIST does not assign these values, and if the federal agency with your contract has not specified them, your organization must. Have the system owner and information security lead draft the requirements, then obtain sign-off from a named executive. The output is an approved requirements statement that the rest of the sequence refers to. Confirm with your contracting officer whether any agency-specified values apply before you finalize.
Document the supply chain weakness identification process
Write the procedure that finds weaknesses and deficiencies in supply chain elements (suppliers, components, services) and in the processes that govern them. It should name the inputs you review, such as the system component inventory, vendor security documentation and vulnerability notices, who reviews them, how often, and how a finding is escalated. Pair it with your supply chain risk management policy and plan so the assessor can trace the process back to the policy. The output is an approved, versioned procedure that personnel with acquisition, security and SCRM responsibilities can be interviewed about.
Open a deficiency register with owners
Record every identified weakness in a single register. Each entry needs a description, the affected element or process, a risk rating, a named owner, a remediation action, a target and status, and a closure record that shows what was verified. Tools such as DefectDojo can import and track findings, but the register itself is the evidence, so confirm the tool's fit with your environment before adopting it. The output is a register that shows deficiencies moving from identified to closed, which is what an assessor will test by sampling entries.
Enforce requirements through contracts and onboarding
Put the approved ODP requirements into supplier contracts, purchase terms and onboarding checklists so that new suppliers and components must meet them before they join the system. Existing suppliers should be reviewed against the same requirements, and gaps logged in the register. Software component visibility can support this step: an SBOM generated with Trivy and tracked in OWASP Dependency-Track can show which components and vulnerabilities enter the system. The output is signed contract language, completed onboarding records and a list of suppliers reviewed against the requirements.
Run and record a periodic review of the process
Review the process itself on a schedule you define in the procedure, not only the suppliers. Check whether the weakness identification process ran as written, whether register entries were owned and closed on time, whether onboarding enforcement held for new suppliers, and whether the ODP requirements still match current supply chain risks. Record the review's date, participants, findings and any changes to the procedure or requirements. The output is a dated review record with action items, which shows an assessor that the process is tested rather than assumed.
Evidence that passes 03.17.03 and how to keep it current
The assessment procedure for 03.17.03 asks an assessor to examine supply chain risk management policy and procedures, the SCRM strategy and plan, and the system and services acquisition policy. These documents show that the organization defined how it identifies and addresses weaknesses in supply chain elements and processes, and which security requirements it enforces. An assessor reads them for specificity: named roles, defined review triggers, and a stated link between the procedure and the systems in scope.
- Policy with named owners: Record who approves the SCRM policy, who maintains the procedure and who is accountable for each step.
- Procedure with triggers: Define the events that start a supplier review, such as a new component, a contract renewal or a disclosed vulnerability in a vendor product.
- Plan tied to the system boundary: Reference the systems and critical components the plan covers so an assessor can trace the plan to the inventory.
- Version history and review dates: Keep dated revisions and records of the annual review, so the assessor can see the documents were maintained.
Between assessments, schedule a documented review of each document, record changes in a change log, and reconcile the plan against the current system boundary after major architecture changes. Confirm the review cadence with your assessor before the assessment begins.
The assessment asks for documentation of systems and critical system components. For supply chain purposes, this inventory should show which software, firmware and services make up the system, where each came from, and which suppliers provide them. A software bill of materials in CycloneDX or SPDX form is the usual way to capture component detail, and it gives the assessor something concrete to sample against the boundary.
- Component list per system: Generate SBOMs from build pipelines or container images, for example with Trivy, and store them with the release record.
- Supplier register: List each supplier, the components or services it provides, and the contract or onboarding record that governs it.
- Vulnerability and license tracking: Import SBOMs into Dependency-Track to track known vulnerabilities, outdated or modified components and license risk over time.
- Dated snapshots: Keep point-in-time exports so the assessor can see what the system contained on the assessment date.
Between assessments, regenerate SBOMs on each release and reconcile the supplier register against procurement records each quarter. Confirm with your assessor which inventory format and granularity they expect for the system boundary.
The requirement asks for a process that identifies and addresses weaknesses or deficiencies in supply chain elements and processes. The test method examines whether that process works in practice, so the assessor looks for a trail from finding to fix. Records of supplier weaknesses, component vulnerabilities and process gaps, along with how each was resolved, show the process operating rather than only described.
- Intake log: Record each supply chain finding with its source, such as a vendor advisory, a scan result or an audit observation.
- Triage and decision: Document the decision to accept, mitigate, transfer or replace, with the approver and date.
- Remediation tracking: Link each finding to the change, contract amendment or plan of action that closed it.
- Deduplicated findings: Tools such as DefectDojo can import scanner output and deduplicate findings, which keeps the log readable across several reporting sources.
Between assessments, review open findings on a set schedule and close the loop on each one with evidence. Ask your assessor how they want closed items retained and for what period.
The requirement calls for enforcing organization-defined security requirements against supply chain risks. Enforcement is visible in the contract, the onboarding checklist and the acceptance criteria that gate a new supplier or component. An assessor wants to see that these requirements exist, that they apply to the suppliers in scope, and that someone checked them before the relationship began or the component entered production.
- Defined security requirements: Write the requirements the organization enforces, and fill the organization-defined parameter with values the organization chose and can justify.
- Clauses in contracts: Confirm that supplier agreements contain the agreed security terms, including incident notification and component disclosure where applicable.
- Onboarding gate records: Keep completed checklists showing the review performed before a supplier or component was approved.
- Exceptions with approval: Record each waiver with the risk owner's sign-off and an expiry date.
Between assessments, audit a sample of recent contracts and onboarding records against the defined requirements, and track waivers to expiry. Confirm with counsel and procurement which clauses your contracts already carry.
The assessment includes interviews with personnel who have acquisition responsibilities, information security responsibilities and SCRM responsibilities. An assessor uses these conversations to test whether staff know the process and can describe it consistently with the written documents. Interview readiness depends on records that show who runs the process, what training they received and how responsibilities were assigned.
- Role assignments: Maintain a current responsibility matrix that names the people for acquisition, security review and SCRM decisions.
- Training records: Keep evidence that role holders completed supply chain and secure acquisition training.
- Meeting minutes: Record SCRM review meetings, attendees and decisions, which give the assessor concrete examples of the process running.
- Consistent answers: Brief each interviewee on the documented process so their description matches the records.
Between assessments, update the responsibility matrix after every staffing change and run a short internal walkthrough with each role holder. Confirm with your assessor whether they will interview specific roles and prepare those people accordingly.
How SBOM and dependency tooling produces evidence for the process
Self-hosted SBOM and dependency tools can generate evidence that the identification step of 03.17.03 is running, but they do not show on their own that the process works. The assessment asks whether the organization identifies weaknesses and deficiencies in supply chain elements and processes. For software components, the most direct evidence is an inventory that is generated, stored and refreshed. Trivy, an Apache-2.0 scanner, can identify OS packages and software dependencies in a target and produce them as a software bill of materials, and it can also scan an SBOM that a supplier or build pipeline already produced. OWASP Dependency-Track, also Apache-2.0, consumes and produces CycloneDX SBOMs and VEX, flags components with known vulnerabilities, outdated or modified components and license risk, and tracks license use by component using SPDX license IDs. Exports from both tools, with dates and the system each one covers, give an assessor artifacts to examine rather than descriptions.
The part an assessor will test most closely is what happens after a finding. Dependency-Track and similar tools record deficiencies, but the organization must show that someone reviewed them, decided how to address them and followed the decision through. Keep the triage decisions, VEX statements and tickets that link a finding to a supplier action, a replacement or a documented risk acceptance. Interview evidence matters here too, because the assessment includes interviews with personnel who hold acquisition, security and SCRM responsibilities. Confirm with your own environment which systems and supplier components each tool can reach, how often ingestion runs, and whether the license terms of Trivy and Dependency-Track fit your distribution and internal use. Their license terms should be checked with your legal team before deployment, and the NIST SP 800-171 Rev. 3 publication is the reference for what the requirement asks.
What meeting 03.17.03 costs in money and effort
Meeting 03.17.03 is mostly a matter of people's time: writing the process, agreeing the organization-defined parameter, and keeping supplier records current. Cards below separate one-time work from recurring work and variable assessment fees, so you can ask a partner or auditor for a quote that matches your environment.
Policy and process design
This is the one-time work of writing the process that finds and fixes weaknesses in supply chain elements and processes, and linking it to your existing SCRM policy, procedures and acquisition practice. Most of the cost is staff time from security, procurement and engineering, plus review by legal or contracting staff. It gets cheaper if you already have a supplier risk process to extend, and costs more if the requirement has to be built from nothing. Ask a quote to state which existing documents are reused and who signs off.
ODP definition and approval
Rev. 3 leaves the value of the organization-defined parameter for 03.17.03 to you when your federal agency does not supply one. The parameter names the security requirements that protect against supply chain risks and limit the harm from supply chain events, so the cost is the decision time for leaders who can accept those requirements. Expect a short, one-time workshop and written approval. Ask whether the contracting agency has published values, since that removes this work.
Supplier and component inventory upkeep
Processes that identify weaknesses in supply chain elements depend on a current list of suppliers, systems, critical components and services. Keeping that list accurate is recurring work that grows with the number of vendors and the rate of change in your environment. Open-source tools such as Trivy can generate software bill of materials data, but someone still has to review, correct and assign owners to the output. Ask how often the inventory is refreshed and who is accountable for it.
Deficiency tracking and review
Once a weakness is found, it has to be logged, owned, fixed or accepted, and reviewed on a schedule. This recurring cost is analyst and engineer time for triage, vendor follow-up and reporting. Tooling can reduce duplicate work, since DefectDojo deduplicates findings using per-tool hashcode fields, but triage decisions remain human work. Ask a quote to show the review cadence, the ticket volume assumed and the escalation path to management.
External assessment support and sampling fees
An independent assessor or auditor tests 03.17.03 by examining documents, interviewing staff and testing whether the process works. Their fees vary with scope, the number of samples they select, and how much evidence is ready when they arrive. Preparation support from an implementation partner is a separate line item from the assessor's fee, and the assessor issues any report. Ask for the sample sizes the assessor expects and whether re-testing after findings is included.
Open-source licenses and engineering time
Self-hosted open-source platforms such as Dependency-Track, Trivy, CISO Assistant and DefectDojo have no license fee under their open-source licenses, so spend moves to implementation, integration and operations. Those engineering hours are the main cost, and they recur as tools are upgraded and scans are maintained. Ask any partner to separate license spend, implementation hours and ongoing support in the written scope, so the total cost is visible.
Open-source tools that support 03.17.03 evidence
This table compares four open-source tools by the 03.17.03 evidence each can help produce, such as component inventories, scanner findings and assessment records. Read each row as a supporting role: the tool produces inputs for the organization's supply chain process, while the organization still defines the security requirements, enforces them with suppliers and decides what counts as a deficiency. No single tool satisfies the requirement alone.
| Tool | Evidence it can help produce for 03.17.03 | Caveat and license check |
|---|---|---|
| Dependency-Track | CycloneDX SBOM and VEX records for system components, plus findings on known-vulnerable, outdated or modified components and license risk | Apache-2.0. It shows component risk, but the organization must still set supplier security requirements and record how weaknesses are addressed. |
| Trivy | OS package and software dependency inventories that can be exported as an SBOM, and scans of existing SBOMs for component weaknesses | Apache-2.0. Inventory covers what is scanned, so confirm the target scope matches the systems and components named in the SCRM plan. |
| CISO Assistant | Mapping of 03.17.03 to the organization's requirement set, assessment records, and tracking of the determination statements and ODP value | AGPL-3.0-only. Confirm license obligations for your use, including whether hosting it for others or modifying it triggers source disclosure. |
| DefectDojo | Imported and deduplicated findings from supply chain and component scanners, and a record of follow-up on deficiencies in supply chain elements | BSD-3-Clause. It tracks remediation of findings but does not decide which supplier weaknesses matter or enforce contract terms. |
| What none of them provides | Supplier security requirements in contracts, documented processes for identifying and addressing weaknesses, and interview evidence from acquisition and security staff | Assessors look for organizational process and records. Confirm with your assessor which artifacts they will examine before relying on tool output. |
Who owns 03.17.03, what partners can take, and where the auditor stops
Your organization owns the requirement. 03.17.03 asks for a process that identifies and addresses weaknesses in supply chain elements and processes, and enforces the security requirements you define to protect against supply chain risks. Those definitions are yours: the organization-defined parameter values, the risk decisions on which suppliers and components are acceptable, and the terms you hold suppliers to. Under NIST's FAQ, the federal agency that holds the contract is responsible for how SP 800-171 is applied and for any compliance issues, so your contracting officer or prime contractor will expect a clear answer from you.
- Process ownership: Name an accountable owner for the deficiency identification and remediation process, and record who approves exceptions.
- ODP values: Assign the value for the security requirements parameter in writing, since NIST does not assign values and a nonfederal organization must assign them when the agency does not.
- Risk decisions: Document which supplier weaknesses you accept, mitigate or reject, and who signed off.
- Supplier relationships: Own the contract language, notification expectations and escalation paths with each supplier.
- Evidence records: Keep the SCRM policy, strategy, plan and inventory documentation that the assessment procedure examines.
Before any outside party starts work, confirm in writing which of these items you have already decided.
An implementation partner such as DeployOpen can prepare the systems and records that make the process testable. Work of this kind is scoped in writing before it starts, and the partner's role ends at preparation. A partner does not issue an assessment result, a score or a certificate, and it does not decide your ODP values or accept your supplier risks on your behalf.
- Component inventory: Build the system and critical component inventory that examiners will ask for, using tools such as Trivy to list software in use and produce SBOMs.
- Supplier tracking: Set up Dependency-Track to monitor CycloneDX SBOMs and VEX data for known vulnerabilities and license risk in delivered components.
- Evidence workflows: Configure how findings, remediation decisions and supplier responses are recorded, for example in DefectDojo, so each deficiency has a traceable history.
- Process testing: Run internal tests of the identification and remediation process, and report the gaps to your owner for decision.
- Documentation support: Draft procedures and assessment-ready evidence packages for your review and approval.
Ask any partner to name each deliverable, the person who approves it, and the evidence it produces.
The independent assessor or DCMA DIBCAC examines and tests the requirement against the SP 800-171A Rev. 3 procedure, then reports findings. For 03.17.03 the procedure uses three determination statements plus one check that the ODP value is defined, applying the examine, interview and test methods. Assessors question your personnel, read your documents and observe whether the process runs. Only the assessing body issues findings or scores. Which assessment applies depends on your contract, so confirm the required assessment type with the agency or prime contractor.
- Examine: Reviews the SCRM policy, strategy, plan, inventory and acquisition policy you provide.
- Interview: Speaks with acquisition, information security and SCRM personnel to confirm they know their responsibilities.
- Test: Checks whether the process for identifying and addressing deficiencies actually operates on real cases.
- ODP check: Confirms that the organization-defined security requirements value is defined and recorded.
- Findings: Issues the results of the assessment, which only the assessing body can do.
Ask the assessor, before the engagement, which evidence it will request for 03.17.03 and in what form.
Where organizations usually fall short on 03.17.03
03.17.03 asks for a working process that finds weaknesses in supply chain elements and enforces security requirements against supply chain risk. Assessors test whether that process exists, runs, and leaves records, so the gaps below tend to surface as missing evidence rather than missing policy. Each card names one gap and the action that closes it.
ODP values left undefined
03.17.03 has one organization-defined parameter: the security requirements that protect against supply chain risks and limit the harm from supply chain events. NIST does not assign that value, and when a federal agency has not specified it, the nonfederal organization must. Many organizations write a process but never fill in the parameter, so the requirement has no stated content to test against. Check that the defined requirements are written down, approved, and referenced in the SCRM plan. Action: define the ODP value in writing before the assessment, and confirm with the contracting agency whether it has already set one.
Process with no recorded deficiencies
The requirement asks for a process that identifies and addresses weaknesses in supply chain elements and processes. An assessor will look for the records a working process produces: findings about suppliers or components, the decisions made about them, and the follow-up. A process that has never recorded a deficiency in its life is hard to distinguish from a process that never ran. Check whether supplier reviews, component findings and corrective actions are logged with owners and closure dates. Action: run one documented review cycle and keep its findings, even when the result is a clean bill for a supplier.
SBOMs generated once and never refreshed
A software bill of materials captured at procurement or at one release tells you little about what runs today. Dependencies change, and newly disclosed vulnerabilities affect components that were clean when the first SBOM was produced. Dependency-Track consumes and produces CycloneDX SBOMs and VEX and flags components with known vulnerabilities, outdated or modified components and license risk, which makes refreshing them a routine task. Check when each system's SBOM was last regenerated and whether the findings reach a named owner. Action: schedule SBOM regeneration per release and feed it into a tracked review.
SCRM plan not tied to contract terms
03.17.01 covers the supply chain risk management plan, and 03.17.02 covers acquisition strategies and contract tools. 03.17.03 then requires the defined security requirements to be enforced. Organizations often write a plan that says suppliers must meet certain requirements, while the purchase orders and contracts carry none of them. Trace each requirement in the plan to a clause, a questionnaire, or a verification step in the acquisition file. Action: map every SCRM plan requirement to the contract term or check that enforces it, and record gaps as findings.
Interviewed staff who never run the process
Assessors interview personnel with acquisition, information security and SCRM responsibilities, and they ask them to describe their work. When the answers do not match the written procedure, or the people named have never seen it, the process fails in practice even if the documents are complete. This gap is usually about ownership and training rather than policy text. Check that the named roles are filled, that staff can describe the steps and records they own, and that the procedure reflects how work is actually done. Action: brief the named roles on the procedure and capture a short walkthrough record before the assessor arrives.
Questions buyers ask about 03.17.03
Is 03.17.03 part of CMMC Level 2 assessments?
No Rev. 2 requirement maps to 03.17.03, so the CMMC Level 2 assessment, which covers the 110 Rev. 2 requirements, has no matching requirement ID to test it directly. That does not make the work optional for every buyer. The DoW's Class Deviation 2026-O0025, Revision 3 names SP 800-171 Revision 2 in its revised DFARS 252.204-7012, and a proposed FAR overhaul would move contractors to Rev. 3 with ODP values published by the DoW CIO. Because these instruments are changing, confirm with your contracting officer which revision and which ODP values your contract currently requires before you plan scope around this requirement.
What does a 03.17.03 engagement need from our team?
The work needs people and documents more than new tooling. Expect to provide access to the current supply chain risk management policy and procedures, any SCRM strategy or plan, inventories of systems and critical components, and system and services acquisition procedures. You will also need named owners for acquisition, information security and supply chain risk decisions who can answer interview questions and approve changes. Someone must be able to describe how supplier weaknesses are found today, including vendor security reviews, incident notices and vulnerability reports from component suppliers.
How long does it take to implement 03.17.03?
Duration depends on scope, and it cannot be estimated responsibly without a written scope. The main drivers are how many systems and suppliers are in the boundary, whether a supply chain risk management plan already exists, how mature your component inventory is, and whether the process must be built or only documented and tested. A fixed-scope agreement sets deliverables and timelines in writing before work starts, so ask for the schedule as part of the scoped proposal rather than a general estimate.
Can our internal team implement 03.17.03 without outside help?
Often yes, if you already have a documented acquisition process, a component inventory and a security review step for new suppliers. Internal teams commonly struggle to produce evidence that the process runs repeatedly, not just that it exists on paper. Outside help is most useful for designing the process against the examine, interview and test methods in SP 800-171A Rev. 3, building the SBOM and vulnerability tracking that supports it, and preparing evidence packages for an assessor. Your organization keeps ownership of the controls, and an independent assessor, not a consultant, issues any report.
What is an organization-defined parameter for 03.17.03, and who sets it?
An organization-defined parameter (ODP) is a value that the requirement leaves open so that it can be set for a specific environment. For 03.17.03, the ODP covers the security requirements that protect against supply chain risks to systems, components and services, and the limits on harm from supply chain events. NIST does not assign ODP values. If the federal agency you contract with does not specify them, the nonfederal organization must define them to complete the requirement. Under the proposed FAR overhaul, ODP values would instead be published by the DoW CIO, so confirm the source that governs your contract.
What should we ask a partner to include in a fixed-scope quote for 03.17.03?
Ask for a written scope that names the systems, suppliers and business units in the boundary, and the deliverables for each step. Useful items to request include:
- A list of the policies, plans, inventories and procedures the partner will review or draft, and who approves them.
- Confirmation of which ODP values will be used and who confirmed them with the contracting agency.
- The tools proposed for SBOM generation, component vulnerability tracking and findings management, and whether they run inside your environment.
- The evidence package format, the interview plan and the testing approach.
- Assumptions about your access, staffing and review cycles, plus any work the partner expects you to perform.
- Whether ongoing support or retesting is priced separately as a retainer.
How DeployOpen scopes 03.17.03 work
DeployOpen scopes 03.17.03 work as a fixed-scope engagement agreed in writing before any work starts. The first step is a review of the one organization-defined parameter for this requirement, which sets the security requirements the organization enforces against supply chain risks to its systems, components and services and the limits it places on the harm from supply chain events. Because NIST does not assign ODP values, the organization must choose them, and that choice should be written down, approved by the people accountable for acquisition and security, and traced to the supply chain risk management policy and plan from 03.17.01 and the acquisition terms from 03.17.02. The scope also covers the existing process for finding and fixing weaknesses in suppliers and their delivery processes, including who receives supplier findings, how they are tracked and how overdue items are escalated. Confirm with your assessor which examine, interview and test objects they will request, since the process evidence must be readable by someone outside your team.
DeployOpen then sets up tooling inside your own cloud accounts, data centers or air-gapped network. Typical components include an SBOM generator such as Trivy, which can produce software bills of materials from targets and scan existing SBOMs, and a component analysis platform such as OWASP Dependency-Track, which consumes and produces CycloneDX SBOMs and VEX and flags components with known vulnerabilities, outdated or modified components and license risk. Findings from these tools can be consolidated in DefectDojo, which imports reports from many security tools and deduplicates findings. Each tool is configured to write records the assessor can inspect, such as dated SBOM versions, triage decisions and exception approvals. Client ownership of the tools, credentials and retention settings is agreed at the outset, and the scope states which tool versions and licenses are in use. Ask for these details in any written proposal.
Before the assessor arrives, DeployOpen prepares the evidence and runs a rehearsal of the supply chain process with your staff. The rehearsal follows a sample supplier or component through identification of a weakness, enforcement of the defined requirement, escalation and closure, so that gaps appear in your records rather than during the assessment. The evidence package covers the supply chain risk management policy and procedures, the plan, the component inventory and the acquisition records. DeployOpen does not issue assessment results, scores or certifications. Only the independent assessor or certification body issues findings, and the organization owns its controls and its decision on whether to submit a score. Ask any implementation partner to name the deliverables in writing, including the evidence index and rehearsal results, and to state what remains the organization's responsibility.
How DeployOpen prepares 03.17.03 evidence
DeployOpen helps organizations prepare the systems, records and test evidence that show how supply chain weaknesses are identified, addressed and enforced under 03.17.03. The organization owns its supply chain process and decisions, and only an independent assessor can issue an assessment result.
How we scope
- Engagements are fixed-scope, with the 03.17.03 boundary, systems and suppliers agreed in writing before work starts.
- We confirm which organization-defined security requirements your federal agency or contract sets for supply chain risk.
- Scope covers the SCRM policy, plan references and the inventory of critical components that the examine objects depend on.
How we build
- We configure open-source tooling such as Dependency-Track to track component weaknesses across the systems in scope.
- We set up SBOM generation with Trivy so software inventories feed the supplier deficiency review process.
- We document the workflow for triaging supply chain findings, assigning owners and enforcing the agreed security requirements.
How we hand over
- You receive documented procedures, configuration records and sample outputs mapped to the three determination statements and the ODP check.
- Test results show how identified deficiencies were tracked to closure, ready for an assessor to examine and test.
- Handover includes a walkthrough with the personnel who hold acquisition, security and SCRM responsibilities, so interview answers match the records.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can retest supply chain workflows and tooling after changes to suppliers, platforms or the SBOM process.
- Independent assessors and certification bodies, not DeployOpen, decide whether the 03.17.03 evidence meets the requirement.
