Federal customers do not evaluate a prime contractor in isolation. They evaluate the whole delivery team, including subcontractors, teaming partners, software and cloud providers, and anyone else who touches contract data or the systems that hold it. This article lays out a practical, lifecycle-based approach to third-party risk management (TPRM) for federal contractors and teaming partners, grounded in public guidance from NIST, the FAR and DFARS, and DoD.
Why Third-Party Risk Matters on Federal Work
A prime contractor remains accountable to the government for what its team does. When a subcontractor handles federal contract information (FCI) or controlled unclassified information (CUI), a weakness at that company becomes the prime contractor's problem: a reportable incident, a failed assessment, a stalled award, or a damaged past-performance record. Risk also travels in both directions. Small businesses that join teams are routinely asked to prove their own security posture before they are added to a proposal.
Good TPRM is therefore not just a defensive control. It is a competitive capability: a team that can show disciplined partner selection, clear flow-downs, and evidence-based oversight is easier for a contracting officer to trust.
Vendor Selection and Risk Tiering
Not every third party deserves the same scrutiny. Tiering matches effort to exposure so that your limited review capacity goes where the risk is.
Factors that drive a tier
- The type of information the party will handle (none, FCI, CUI, or other sensitive data).
- Whether the party connects to or administers your systems or the customer's systems.
- How critical the service is to contract performance and how hard it is to replace.
- The party's own supply chain, including cloud and software dependencies.
- The contract clauses in play, such as DFARS cyber requirements.
Document the tiering logic once, apply it consistently, and record the tier in your vendor register so that questionnaires, clauses, and review cadence all follow from it.
Due-Diligence Questionnaires and Evidence
A questionnaire is only as useful as the evidence behind the answers. Keep it short for lower tiers and ask for artifacts at higher tiers.
- Ownership and eligibility: legal entity, ownership, and registration status in SAM.gov.
- Security program: a system security plan or equivalent, policies, and a named security point of contact.
- Control status: for CUI work, a current NIST SP 800-171 assessment and the plan of action for any open items.
- Incident readiness: an incident response plan and how and how quickly the party will notify you.
- Supply chain: critical software, cloud, and hardware suppliers, and confirmation about covered telecommunications equipment under Section 889.
- Personnel: screening practices and security awareness training.
Treat answers as claims until you have seen evidence. Self attestation, a third-party assessment, or a score in the appropriate government system each carry different weight, so record which kind you received.
Contract Flow-Downs That Matter
Flow-down clauses are how obligations in your prime contract become obligations for your subcontractors. Always confirm applicability against the actual solicitation and contract text and with counsel; the list below is a starting map, not legal advice.
- FAR 52.204-21 (Basic Safeguarding of Covered Contractor Information Systems) sets baseline safeguarding requirements for systems that process, store, or transmit FCI and is flowed down to subcontractors that may have FCI on their systems.
- DFARS 252.204-7012 (Safeguarding Covered Defense Information and Cyber Incident Reporting) requires adequate security aligned to NIST SP 800-171 for covered defense information, cyber incident reporting, and flow-down to subcontractors whose performance involves that information.
- DFARS 252.204-7019 and 252.204-7020 concern the NIST SP 800-171 DoD Assessment, including the requirement to have a current assessment posted in the Supplier Performance Risk System (SPRS) and the obligation to verify subcontractors' assessments where the clause applies.
- DFARS 252.204-7021 addresses Cybersecurity Maturity Model Certification (CMMC) requirements, including ensuring subcontractors hold the required CMMC level before award where the clause is included. See the DoD CIO CMMC program page for current status.
- FAR 52.204-25 implements Section 889 of the FY2019 NDAA, prohibiting certain covered telecommunications and video surveillance equipment and services, and carries its own representation, flow-down, and reporting obligations.
Beyond the regulatory clauses, add commercial terms that make them workable: incident-notification timelines that let you meet your own reporting duties, a right to request evidence, a duty to notify you of material changes (ownership, hosting location, key subcontractors), and clear data return and destruction obligations.
Using NIST SP 800-161 for C-SCRM
NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, is NIST's reference for cybersecurity supply chain risk management (C-SCRM). Two ideas are especially useful for contractors:
- C-SCRM should be integrated into enterprise, mission and business process, and operational levels rather than handled as a one-time purchasing check.
- Supply chain risk management belongs inside the acquisition lifecycle, from requirements and sourcing through operations and disposal.
Even a small company can borrow its structure: assign an owner, define tiers, document requirements in contracts, assess suppliers proportionate to risk, and review the program periodically. NIST SP 800-171 remains the control baseline for CUI on contractor systems, while SP 800-161 supplies the supply-chain management practices around it.
Writing Risk-Based Security Requirements into Acquisition Documents
Customers and primes alike get better outcomes when security requirements are written into the acquisition documents rather than added after award.
SOW and SOO
In a statement of work, state specific security tasks and deliverables, such as reporting, evidence submissions, and incident notification. In a statement of objectives, state the security outcomes and let offerors propose how to achieve them. Either way, tie requirements to the sensitivity of the data and the tier of the supplier.
Evaluation factors
Where supply chain security matters to the mission, consider a factor or subfactor that evaluates the offeror's approach to managing its subcontractors and suppliers, with a clear definition of what evidence will be assessed.
Total cost of ownership
Cheapest-at-award can be most expensive over the contract life. Total cost of ownership (TCO) should include assessment and monitoring effort, remediation of findings, switching costs if a supplier fails, and the cost of incidents. Making these visible during acquisition planning supports better trade-offs.
Service levels
Pair security requirements with measurable service levels: incident notification and update timelines, vulnerability remediation windows by severity, evidence delivery dates, and availability or recovery objectives where relevant. Specify remedies so the terms can be enforced.
Ongoing Monitoring and Reassessment Triggers
A point-in-time review goes stale quickly. Set a review cadence by tier (for example, annual for the highest tier) and add event-driven triggers that prompt an earlier reassessment:
- A security incident or breach at the supplier or one of its own suppliers.
- A change of ownership, key personnel, hosting provider, or data location.
- A significant change in scope, such as access to new or more sensitive data.
- Expiry of an assessment, certification, or plan of action milestone.
- Public vulnerability or advisory affecting a product the supplier provides, such as notices from CISA.
- Missed deliverables or service levels.
Offboarding Without Loose Ends
Relationships end, and that is when access is most likely to be forgotten. Maintain an offboarding checklist:
- Revoke accounts, credentials, tokens, and network paths.
- Recover or require certified destruction of contract data, following the contract's requirements and any records obligations.
- Retrieve equipment and badges.
- Confirm surviving confidentiality and incident-reporting obligations.
- Update the vendor register, system access lists, and any security plan that named the supplier.
Procurement Lifecycle and Cost-Benefit
Map TPRM activities to the procurement lifecycle: define requirements and tier, screen and select, contract with the right clauses, onboard with least-privilege access, monitor and reassess, then offboard. Early steps are cheap and late corrections are expensive. Rejecting an unsuitable partner during selection costs a few hours of review; discovering the same gap after award can mean remediation under deadline, a reportable incident, or replacing a team member mid-performance.
Right-size the effort. Concentrate deep reviews on the few suppliers that touch CUI or privileged systems, and use lighter checks for the rest. Reuse evidence you already hold, and where a supplier supplies the same evidence to many customers, ask for it once rather than building a bespoke questionnaire.
Metrics for Reporting Third-Party Risk to Leadership
Leaders need a small set of trend-able measures tied to decisions. Examples that avoid vanity counts:
- Percentage of third parties tiered, and of each tier with current evidence on file.
- Percentage of subcontracts containing the required flow-down clauses.
- Number of open findings and plan-of-action items by tier, and their age.
- Overdue reassessments.
- Time from incident notice to triage for third-party events.
- Concentration risk: critical services dependent on a single supplier.
- Offboarding completion, measured as access revoked within the target window.
Pair each metric with an owner and a threshold that triggers a decision, otherwise the dashboard becomes decoration.
Key Takeaways
- Prime contractors remain accountable for their teams, so treat subcontractors as part of your security boundary.
- Tier third parties by data sensitivity, access, and criticality, and scale diligence to match.
- Ask for evidence, not just answers, and record the type of assurance received.
- Verify which FAR and DFARS clauses apply and flow them down, with incident-notification terms that fit your own reporting duties.
- Use NIST SP 800-161 as a structure for the program and SP 800-171 as the CUI control baseline.
- Reassess on events as well as on a schedule, and offboard deliberately.
- Report a few actionable metrics to leadership.
References
- FAR 52.204-21, Basic Safeguarding of Covered Contractor Information Systems, acquisition.gov.
- FAR 52.204-25, Prohibition on Contracting for Certain Telecommunications and Video Surveillance Services or Equipment, acquisition.gov.
- DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting, acquisition.gov. DFARS 252.204-7019, 7020, and 7021 are available from the DFARS index.
- NIST, SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations.
- NIST, SP 800-171 Rev. 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations.
- U.S. Department of Defense CIO, Cybersecurity Maturity Model Certification (CMMC) program.
This article is general information, not legal advice. Confirm clause applicability against your specific solicitation and contract.
Conclusion
Third-party risk management works best as a lifecycle: choose carefully, contract clearly, verify with evidence, watch for change, and exit cleanly. The same discipline that protects a prime contractor also makes small-business partners easier to team with, because expectations are clear from the start.
If you are building or refining a teaming or subcontractor oversight process, contact us to start a conversation.
