What 03.17.01 asks for and why a new Rev. 3 plan is hard to inherit
If a contract now requires Rev. 3, 03.17.01 is the requirement with no predecessor to reuse. NIST maps no Rev. 2 requirement to it, so CMMC Level 2, which still assesses the 110 Rev. 2 requirements, has no matching requirement ID. Teams that already passed a Rev. 2 review cannot point to an existing practice and claim credit for it. They need to write a supply chain risk management plan from the start and show that it works. The requirement asks for a plan covering research and development, design, manufacturing, acquisition, delivery, integration, operations, maintenance and disposal of the system, its components or its services. The scope runs the full life cycle, not only the purchasing step that many procurement teams already document.
The plan also needs two decisions that NIST does not make for you. The first is the review and update frequency, which is the single organization-defined parameter for 03.17.01. NIST does not assign ODP values, and a nonfederal organization must assign them when the federal agency does not. Confirm with the contracting agency whether it has published a value, and if it has not, document your chosen frequency and the reason for it. The second is protection: the plan must be safeguarded from unauthorized disclosure, so decide who can read it, where it is stored and how changes are recorded. Assessors look for a plan that exists, has an owner, has a set review date and has been reviewed on that date.
Three things make this hard to inherit. The plan is new, so most organizations have no template that already meets the wording. SR-2 from SP 800-53 Rev. 5 is the source control, so it is a design basis rather than a checklist, and the plan must show how the organization applies it to its own systems. The examine, interview and test steps in SP 800-171A Rev. 3 also expect evidence from people with acquisition and supply chain responsibilities, not only from documents. Before you start, ask your contracting officer which Rev. 3 ODP values apply and confirm which revision your contract cites, because the answer changes the review schedule you must write into the plan.
Which systems, suppliers and teams the SCRM plan must cover
The 03.17.01 plan only works if its scope matches the CUI boundary. The cards below cover the decisions that change the work: which systems and components are in scope, which teams own which parts, and how suppliers and cloud providers are brought under the plan.
Systems inside the CUI boundary
Start from the system security plan's boundary, not from the asset inventory. Every system that stores, processes or transmits CUI, and every system that can affect those systems' security, belongs under the plan's life cycle coverage. Ask the team to confirm which shared services, identity providers and build pipelines sit inside or connect to the boundary, because those connections are where supply chain risk usually enters an enclave.
Components and open-source dependencies
The plan reaches the components that make up each system, including open-source packages, container base images and firmware. Record where each component comes from, who maintains it and how it gets updated. A software bill of materials gives the assessor a traceable list to test against, and it should be kept current as the platform changes.
Acquisition and procurement ownership
Procurement, legal and the system owner each control part of the supply chain decisions. The plan should name who approves a new supplier, who negotiates security terms and who signs off on a component change. Confirm that these roles are written down, because an assessor interviewing acquisition staff will test whether they know their responsibilities under the plan.
Operations and maintenance teams
Operations, maintenance and disposal are life cycle phases the plan must cover, not only the purchase. Engineers who patch, replace or retire components, and those who sanitize hardware at end of life, need defined steps and handoffs. Check that maintenance vendors with remote access are named, since their tooling and sessions reach the same systems.
External suppliers and service providers
Each external supplier that touches CUI systems, or supplies components to them, should be listed with the scope of its access and the security terms in its contract. Ask for evidence of how each supplier is assessed before onboarding and how its access is reviewed afterward. Suppliers that cannot meet the plan's requirements need a documented decision, not an exception made in a meeting.
Cloud providers and hosting
Cloud accounts, managed services and data center operators hold the infrastructure beneath the CUI boundary. The plan should record which provider controls which layer, which responsibilities the organization keeps, and how it obtains the provider's assurance documents. Confirm these terms with the provider and your contracting team, since shared responsibility boundaries differ by service.
How an assessor tests the SCRM plan under SP 800-171A
Examination is the document review step. The assessor reads the written artifacts and checks that they exist, cover the required topics and are current. For 03.17.01, SP 800-171A Rev. 3 names examine objects that include the supply chain risk management policy and procedures, the supply chain risk management plan itself, the system and services acquisition policy and procedures, and the acquisition procedures. The assessor checks each determination statement against these documents, so a plan that is missing a life cycle phase will fail even if the organization can describe that phase verbally.
- Policy and procedures: Confirm a supply chain risk management policy exists and that procedures describe how the plan is applied.
- The SCRM plan: Check that it covers research and development, design, manufacturing, acquisition, delivery, integration, operations, maintenance and disposal.
- Acquisition procedures: Look for steps that bring supply chain risk into purchasing decisions.
- Review record: Find the revision history showing the plan was reviewed at the frequency the organization defined.
- Protection marking: Confirm the plan is stored with access restrictions that prevent unauthorized disclosure.
Before the assessment, read the plan the way an assessor would, checking each life cycle phase against its own text.
Interviews test whether people know and follow the documented plan. SP 800-171A Rev. 3 lists personnel with acquisition responsibilities and personnel with supply chain risk management responsibilities as interview objects for 03.17.01. The assessor asks them how they apply the plan to a real purchase, a vendor onboarding or a component replacement, and compares their answers with the written procedures. Gaps usually appear when the plan assigns responsibilities to a role that nobody in practice holds.
- Acquisition staff: Ask how supply chain risk is considered before a contract is signed and who approves exceptions.
- SCRM owners: Ask who reviews the plan, when the last review happened and what triggered it.
- Plan awareness: Ask whether staff can locate the current version of the plan.
- Role clarity: Check that named roles match the people who do the work.
- Escalation path: Confirm staff know whom to contact when a supplier raises a security concern.
Before the assessment, brief the interviewees on the plan and confirm that their answers match the written responsibilities.
Testing checks that the organization's processes operate as described. For 03.17.01, the test objects in SP 800-171A Rev. 3 include the organizational processes for defining and documenting the system development life cycle and the processes for identifying life cycle roles and responsibilities. The assessor looks for evidence that these processes ran, not only that they are written down. A life cycle definition that no project ever used is a common finding.
- SDLC definition: Confirm the organization defines and documents the life cycle that the supply chain plan references.
- Role identification: Check that life cycle roles and responsibilities are identified for real projects.
- Applied records: Sample recent acquisitions or system changes and trace them back to the plan.
- Consistent phases: Confirm the same life cycle phases appear in the SDLC, the plan and the acquisition records.
- Recorded outcomes: Look for decisions that show supply chain risk was assessed and acted upon.
Before the assessment, pick two or three recent projects and prepare the records that show the plan was applied to each.
SP 800-171A Rev. 3 assesses 03.17.01 with 13 determination statements plus one additional check that the organization-defined parameter is defined. The ODP for this requirement is the frequency at which the plan is reviewed and updated. NIST does not set that value. If a federal agency does not specify it, the nonfederal organization must assign it to complete the requirement. An assessor will not accept a plan that says it is reviewed periodically without a defined frequency, because the determination for the ODP cannot be met.
- Thirteen statements: Map each statement to a document, a person or a process record so none goes untested.
- ODP check: Write a specific review frequency into the plan and confirm the contracting agency has not already specified one.
- Traceability: Keep a matrix linking each determination to its evidence.
- Consistency: Make sure the frequency in the plan matches the frequency in the procedures and the calendar.
- Scope confirmation: Agree with the agency which systems and suppliers the plan covers.
Before the assessment, confirm the ODP value in writing and verify that every determination has a named piece of evidence.
The most frequent problem is a plan that exists but has never been reviewed. An assessor will compare the revision date with the defined frequency and the organization's own change history. Other findings include a plan that names a life cycle phase the organization does not perform, interview answers that contradict the written roles, and an SDLC that was documented but never applied to a project. Because 03.17.01 is new in Rev. 3 and has no matching CMMC Level 2 requirement ID, teams often have no prior evidence to reuse.
- Stale plan: The review date is older than the defined frequency, or no review is recorded.
- Missing phases: The plan omits disposal, maintenance or another phase named in the requirement.
- Unprotected plan: The plan is shared without access controls or protection from unauthorized disclosure.
- Paper-only process: The procedures are not reflected in any acquisition or project record.
- Undefined ODP: The review frequency is described as periodic or as needed.
Before the assessment, check the plan against each finding above and fix the gaps your records can prove.
How to build the SCRM plan in the order an assessor expects
The sequence below builds the 03.17.01 plan from scope and review frequency outward, so each later step rests on a documented decision. An assessor can then trace every life-cycle phase back to an owner, a risk and a control, and the plan itself is protected and version-controlled.
Confirm scope and the review frequency
Start by fixing the system boundary the plan covers, including the CUI environment, the components and the external services it depends on. Then set the review frequency, which is the one organization-defined parameter (ODP) for 03.17.01. If a federal agency or contract specifies the value, record that source. If it does not, the organization assigns the value itself, and the assessor will check that a value is defined. The output is a scope statement and a signed-off frequency that the plan will quote.
Assign owners to each life-cycle phase
Map the phases named in the requirement to accountable roles: research and development, design, manufacturing, acquisition, delivery, integration, operations, maintenance and disposal. Each phase needs a named owner, usually drawn from engineering, procurement, operations and security, so that the people interviewed during assessment can describe their part. The output is a RACI-style table that lists the phase, the owner, the deputy and the artifacts each owner produces.
Document risks and mitigations per phase
For each phase, record the supply chain risks that apply to your system, such as unvetted component sources, unsupported software, vendor access to CUI, or disposal of media that still hold data. Pair each risk with a mitigation and the control or procedure that carries it out, and cross-reference related requirements such as 03.11 risk assessment and 03.16 system and services acquisition. The output is a phase-by-phase risk register that an assessor can compare against the plan text.
Write, review and approve the plan
Draft the plan from the scope, owner map and risk register, using clear section headings that follow the life-cycle order. Route it to the people who hold the phase ownership and to the senior leader who accepts residual risk, and record their review. The output is an approved plan with an approval date, an approver name and a list of the reviewers, so the assessor can confirm the plan was reviewed before it was adopted.
Version the plan and its change history
Give the approved plan a version number and keep every revision under version control, recording what changed, when and by whom. A wiki or document system with page history can do this, but confirm that it keeps prior versions and supports comparison and rollback before relying on it. The output is a versioned record that shows the plan in force on any given date, which supports the assessor's review of whether the plan was updated at the defined frequency.
Protect the plan with access controls
The requirement expects the plan to be protected from unauthorized disclosure, because it describes weaknesses in your supply chain. Restrict read and edit rights to the roles that need them, log access where the tool supports it, and mark the document according to your CUI handling rules. The output is a documented access list and a storage location that the assessor can inspect, together with evidence that the access list is reviewed.
Schedule and record the periodic review
Put the review on the calendar at the frequency confirmed in the first step, and assign the owner who will run it. Each review should check the risk register against changes in suppliers, components, contracts and incidents, then either update the plan or record why no change was needed. The output is a review log with dates, reviewers and outcomes, which is the evidence an assessor uses to test that the plan is reviewed and updated as defined.
Evidence that satisfies 03.17.01 and how to keep it current
An assessor testing 03.17.01 looks for a plan that exists, is reviewed at the frequency the organization defined, is protected, and is owned by named people. The cards below cover the artifacts that show each of those points and how to keep them accurate between assessments.
Approved SCRM plan with version history
The supply chain risk management plan is the central artifact. It should name the system, the life cycle phases it covers (research and development, design, manufacturing, acquisition, delivery, integration, operations, maintenance and disposal), and the approver. Keep every revision so an assessor can see what changed and when. Store the plan in a wiki or document system that records edits, authors and rollbacks. Confirm that the approved version in use matches the version referenced in the system security plan.
SCRM policy and procedures
The policy states why the organization manages supply chain risk and who is accountable. The procedures describe how the plan is written, reviewed, approved and communicated to acquisition and operations staff. Assessors examine both documents, so they must agree with the plan and with each other. Check that the procedures name the review trigger, such as a major system change or a supplier incident, and that the policy has an owner and a review date of its own.
Defined review frequency record
03.17.01 has one organization-defined parameter: how often the plan is reviewed and updated. NIST does not set this value, so the organization must choose it and record it. Write the chosen frequency in the plan and in the procedures, then keep a calendar or ticket that shows the next review date. An assessor checks that the defined value exists and that the review actually happened at that interval. If a federal agency specifies a value in the contract, use that value instead.
Review minutes showing updates
Each review should leave a record: attendees, the sections checked, supplier and component changes found, decisions taken and the resulting plan revision. Minutes that show no change are still useful if they show the plan was checked against current suppliers and system changes. Link each review to the version it produced. Between formal assessments, schedule reviews after significant acquisitions or supplier changes, and keep the minutes in the same repository as the plan.
Named owners for interview readiness
Assessors interview personnel with acquisition responsibilities and personnel with supply chain risk management responsibilities. Each person should be able to explain the plan, their part of it and the last review. Keep a current roles record that names the plan owner, the acquisition lead, the system owner and the deputies who cover absences. Update it whenever staff change roles, and brief each owner on the sections they answer for before an assessment.
Access restrictions on the plan
03.17.01 requires the plan to be protected from unauthorized disclosure, because it describes supplier dependencies and weak points. Restrict read and edit rights to the people named in the roles record, and log access to the repository. Review those permissions at each plan review and when staff leave. Confirm that copies sent to suppliers or auditors are controlled and that the access list itself is kept as evidence.
What meeting 03.17.01 costs in money and effort
This table lists each cost component of building and maintaining the supply chain risk management plan, who typically pays for it, whether it is one-time or recurring, and what moves it up or down. Use it to structure a quote request, since no price or duration is published for this requirement.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it, and what to ask for in a quote |
|---|---|---|---|
| Drafting the plan | Internal acquisition and security staff, or an implementation partner preparing the document | One-time, then revised | Life-cycle complexity and the number of system types covered. Ask for the named deliverables, who drafts each section, and what review rounds are included. |
| Acquisition and security staff time | Internal procurement, contracting and security personnel | Recurring | How many acquisitions run per year and how many teams buy technology. Ask the partner to state which internal roles it expects to be involved and for how long, in writing. |
| Review and update cycles | Plan owners, reviewers and approvers | Recurring | The review frequency the organization sets for the ODP value in 03.17.01. More frequent reviews raise staff time. Ask how review and update effort is scoped after the first delivery. |
| Documentation and version control tooling | Software licensing or self-hosted tooling, plus administration time | Mostly one-time setup, recurring hosting and upkeep | Choice of tool and whether it is self-hosted. XWiki keeps page history with who changed what and when, which supports review evidence. Ask what hosting, backup and upgrade work is included. |
| Supplier information gathering | Procurement staff, supplier contacts and sometimes a tool that inventories components | Recurring per supplier cycle | Number of suppliers and components in scope. Dependency-Track and Trivy can reduce manual inventory work for software, but they do not replace supplier questionnaires. Ask how supplier data collection is priced. |
| Protecting the plan from disclosure | Security team and records or access administrators | One-time setup, recurring access reviews | How widely the plan is shared and how sensitive supplier details are. Ask how access controls and storage protection are included in scope. |
| External review or independent assessment | Independent assessor or consultant, selected by the organization | Recurring at each assessment cycle | Which assessment the contract requires and who performs it. Only an independent assessor issues assessment results. Ask whether the partner's work is preparation only and what the assessor will need from you. |
| Contract and flow-down obligations | Contracts staff and legal review | Recurring with contract renewals | Number of prime and subcontract agreements that reference the requirement. Ask which contract documents the plan must match before work begins. |
Who owns the SCRM plan, who helps, and what the auditor checks
Your organization owns requirement 03.17.01 in full. That means it owns the supply chain risk management plan, the decisions recorded in it, and the organization-defined parameter for how often the plan is reviewed and updated. NIST states that application and implementation of SP 800-171, and any compliance issues, are the responsibility of the federal agency that holds the contract or agreement with the nonfederal organization, so the contracting agency is also a party to what the plan must cover. Internally, someone with acquisition and security authority must approve the plan, and named staff must be able to explain it in an interview, because SP 800-171A Rev. 3 tests interviews with personnel who hold acquisition and SCRM responsibilities.
- Plan ownership: A named executive or security owner signs off on the plan and each revision.
- ODP decision: Your organization sets the review frequency, or confirms the value your contracting agency specifies, and records it in the plan.
- Interview readiness: Acquisition and security staff can describe how supplier risk is assessed across the life cycle.
- Lifecycle scope: The plan covers research and development, design, acquisition, delivery, integration, operations, maintenance and disposal.
- Protection of the plan: Access to the plan is limited, since it describes weaknesses in your supply chain.
Before starting any work, confirm with your contracting officer which ODP value applies to your contract.
An implementation partner such as DeployOpen can prepare the working material behind 03.17.01: a draft plan, the software bill of materials (SBOM) and vulnerability records for the self-hosted platforms in scope, and the procedures that show how the plan is applied. The partner does not decide the risk tolerance, approve the plan, or sign anything on the organization's behalf. Its deliverables should be agreed in writing as a fixed scope before work begins, with each artifact named, along with the systems it covers and who reviews it.
- Draft plan: The partner drafts the plan for your review, mapped to the life-cycle stages your systems actually go through.
- SBOM and component records: Tools such as Trivy can generate SBOMs, and OWASP Dependency-Track can track components, vulnerabilities and license risk over time.
- Versioned evidence: Policy and plan revisions can be kept under version control in a wiki such as XWiki, which records what changed, when and by whom.
- Procedure walkthroughs: The partner documents how review and update cycles run so staff can answer interview questions.
- Handover: Your team receives the artifacts, access and runbooks needed to operate the process without the partner.
Ask for a written list of deliverables, the responsible owner for each, and what happens if the review frequency changes.
Only an independent assessor issues assessment results. For DoD contractors, that role is played by DCMA DIBCAC for Medium and High assessments, and by the organization itself for a Basic Assessment, which it reports through SPRS. Assessors examine documents, interview personnel and test processes against the determination statements in SP 800-171A Rev. 3, which for 03.17.01 number 13 plus one check that the ODP value is defined. An implementation partner that also performs the assessment would not be independent, so the same firm should not write the plan and then judge it.
- Examine: The assessor reviews the SCRM policy, the plan, and the acquisition and SDLC procedures.
- Interview: The assessor speaks with acquisition and SCRM personnel to confirm they know the plan.
- Test: The assessor checks that organizational processes for defining the SDLC and its roles actually operate.
- Independence line: Assessors do not design the controls they test, and partners do not issue results.
- Reporting: Results and any SPRS score come from the assessor or the organization, not from the partner.
Confirm with the assessor which evidence they expect and which assessment method applies to your contract before preparing the package.
Where organizations fall short on the SCRM plan
Most gaps in the supply chain risk management plan come from treating it as a document rather than a living control. The cards below cover the gaps assessors most often find when they test 03.17.01, each paired with the step that closes it.
No review frequency defined
03.17.01 has one organization-defined parameter: how often the plan is reviewed and updated. Many organizations leave it blank or write "as needed," which an assessor cannot test. Set a specific frequency, record it in the plan, and confirm that the assessment procedure's check that the ODP value is defined passes. Ask your contracting agency whether it has published an ODP value, since NIST leaves assignment to the organization when none is specified.
Plan covers acquisition only
A plan that addresses purchasing decisions but ignores operations, maintenance and disposal misses most of the life cycle the requirement names. Risks often arise after go-live, such as a vendor ending support, a maintainer change, or a component that needs replacing. Extend the plan's scope to every phase from research and design through disposal, and assign a risk owner for each phase.
No evidence of review
An assessor will ask for proof that the plan was reviewed on the defined schedule and updated when conditions changed. A plan with a creation date and nothing after it signals that the review never happened. Keep dated revision history, meeting minutes or sign-off records for each review, and record what changed and why. A wiki with version control keeps this trail without extra tooling.
Plan left unprotected
The requirement expects the plan itself to be protected from unauthorized disclosure. Plans that name critical suppliers, single points of failure and known weak components are sensitive. Many organizations store them in a shared drive with broad read access. Restrict the plan to named roles, apply the same access controls used for CUI-related documentation, and log access to the document.
Suppliers not mapped to life-cycle phases
A supplier list without phase context does not show which risks apply when. Map each system component and supplier to the phase where it matters, such as design, integration, operation or disposal, and note the risk for each. Software bills of materials can supply the component inventory. Dependency-Track can track vulnerable and license-risk components against that inventory, giving the plan current data rather than a snapshot.
Plan not linked to the SSP
The supply chain plan should connect to the system security plan, the risk assessment and the 03.17.02 and 03.17.03 processes. When these documents drift apart, an assessor cannot trace how a supplier risk led to a control decision. Cross-reference the plan from the system security plan, and update both documents in the same review cycle so the assessor sees one consistent picture.
How much work is an SCRM plan, and can we write it ourselves?
Is a Rev. 2 compliance program enough for now, or do we need a 03.17.01 plan?
For a current DoD contract, the answer depends on which clause your contracting officer has put in the contract. DoW Class Deviation 2026-O0025, Revision 3, signed 3 September 2026, has contracting officers use a revised DFARS 252.204-7012 that names SP 800-171 Revision 2 explicitly, and it cites a 13 July 2026 DoW CIO memorandum requiring baseline compliance with Rev. 2 while CMMC Phase 2 is suspended. A proposed FAR overhaul rule published 23 June 2026 would move contractors handling CUI to Rev. 3, but it was not final as of October 2026. Because 03.17.01 has no Rev. 2 equivalent, a Rev. 2 assessment will not test it. Confirm the clause and the assessment timing with your contracting officer and keep a 03.17.01 plan in draft so you are ready if the requirement changes.
Who sets the review frequency for the supply chain risk management plan?
The organization sets it. 03.17.01 has one organization-defined parameter, the frequency at which the plan is reviewed and updated. NIST does not assign the value, and if a federal agency does not specify it in the contract, the nonfederal organization must define it to complete the requirement. Choose a frequency your leadership will commit to, document it in the plan, and make sure the assessor can see the approved value. An undefined parameter is a gap an assessor can test for on its own, so treat the decision as a governance item with a named owner rather than a drafting detail. If the contract names a value, use that value.
How long does it take to draft an SCRM plan?
No supplied figure gives a reliable duration, so the honest answer is that it depends on the size and complexity of your supply chain and on how many people must review the draft. Drafting time is driven by the number of systems and suppliers in scope, how much of your acquisition and development lifecycle is already documented, and how quickly the owners of acquisition, engineering and operations can agree on responsibilities. Ask any provider for a written scope that lists the systems, suppliers and review cycles covered, and ask for the stages and dependencies in the schedule before you commit.
Do we need an outside partner to write the plan?
You do not need one to write the document, but you may want one to prepare the evidence. The plan must cover research and development, design, manufacturing, acquisition, delivery, integration, operations, maintenance and disposal, and it must be reviewed on your defined schedule and protected from unauthorized disclosure. An implementation partner can help structure the plan, map roles, and set up the systems that produce the records an assessor will examine. Only an independent assessor or certification body can issue an assessment result, and the organization still owns its controls and its plan.
What does the work need from our team?
The plan is a cross-functional document, so it needs people who own each stage of the system life cycle. In practice, you will need:
- Acquisition or procurement staff who manage supplier contracts and purchase decisions
- Engineering and architecture owners who understand design, integration and component selection
- Operations and maintenance leads who manage patching, support and disposal
- A security or compliance owner who sets the review cycle and approves the final plan
- Legal or contracts staff who can confirm how supplier obligations are written
Agree in advance who signs the plan and who keeps it current. Without a named owner, the review cycle tends to lapse.
How do we show that the plan is reviewed on schedule?
Keep a version history and a review record that an assessor can examine. Store the plan in a system that records every change, what changed, when and by whom, and that lets reviewers compare versions and restore earlier ones. Each review should produce a dated entry showing who reviewed the plan, what they checked, and what they changed or approved. Self-hosted tools such as XWiki provide page version control of this kind, which you should confirm against your own configuration. Also record the review frequency you set so the assessor can match the recorded reviews against the defined value.
How DeployOpen prepares SCRM plan evidence for 03.17.01
DeployOpen starts this work with a written scope that names the systems, components and services covered by the supply chain risk management plan, the people who own each part of it, and the deliverables the organization will receive. The organization keeps ownership of the plan, the risk decisions and the acceptance of residual risk. DeployOpen helps draft the plan so that it addresses the life cycle stages named in 03.17.01, from research and design through acquisition, integration, operations, maintenance and disposal, and it sets up the evidence trail an assessor will examine: the plan itself, the SCRM policy and procedures that point to it, and records showing who reviewed it and when. The review frequency is the one organization-defined parameter for this requirement, so the first decision to confirm is the value the organization will assign and document. DeployOpen does not choose that value for the client, and an assessor will check that it is defined.
For the technical side of the plan, DeployOpen can deploy self-hosted tools inside the client's own cloud accounts, data center or air-gapped network. OWASP Dependency-Track (Apache-2.0) consumes and produces CycloneDX SBOMs and VEX, flags components with known vulnerabilities, outdated or modified components and license risk, and records license use by SPDX license ID, which gives the organization a dated component record to point to during review. Trivy (Apache-2.0) can generate SBOMs for the OS packages and software dependencies in a target and scan existing SBOMs supplied by vendors. XWiki (LGPL-2.1-or-later) keeps every change to the plan under version control, so the reader can see what changed, when and by whom. Confirm with your assessor which artifacts they expect, since an SBOM alone does not show the plan was reviewed or protected from unauthorized disclosure.
DeployOpen prepares the systems, documents and evidence described above, and it does not issue assessment results, attestations or certifications. Those decisions rest with the independent assessor or certification body that the contracting agency or organization engages, and with the organization's own leadership. Ask any partner to show which evidence they will produce, who will hold each artifact after the engagement and how the plan will be reviewed once the fixed-scope work ends. Ongoing support and continuous component monitoring are available as separate retainers if the organization wants them after the initial implementation.
