The Target breach in 2013 came through an HVAC vendor. SolarWinds compromised thousands of organizations through a trusted software update. Third-party risk isn’t a theoretical concern — it’s one of the most consistent sources of real-world incidents, and it’s the category of risk that most security programs address last and least thoroughly.
The reason it gets deprioritized is that it’s organizationally difficult. Managing your own environment is hard enough. Managing the security posture of every vendor, supplier, and service provider that touches your data requires cross-functional cooperation, executive backing, and a structured process that most organizations haven’t built. Third-Party Risk Management is that process.
Why You Can’t Opt Out
Beyond the operational risk, TPRM is a compliance obligation in most regulated environments. GDPR Article 28 requires written contracts — Data Processing Agreements — with every processor that handles personal data on your behalf. HIPAA extends your security and privacy obligations to business associates through the Business Associate Agreement. PCI DSS Requirement 12.8 requires that you maintain a list of third-party service providers, monitor their PCI DSS compliance status, and ensure appropriate contractual obligations exist.
The legal principle is consistent across frameworks: you can outsource a function, but you cannot outsource the liability. If a vendor breaches your customer data, the regulatory obligation to notify, remediate, and potentially pay fines belongs to you — not them. The contract is how you claw back some of that exposure, but only if it was structured correctly before the incident.
The Process
A functioning TPRM program moves through five steps. They need to happen in order because each step depends on the output of the one before it.
Discovery — Build the Supplier Inventory
You cannot manage what you haven’t found. Discovery means pulling supplier lists from procurement, getting the critical application inventory from IT, and validating both with department heads who know which vendors actually have access to sensitive systems or data. No single team has the complete picture — procurement knows about contracted vendors, IT knows about technical integrations, and business units know about the SaaS tools they signed up for independently. All three lists need to be consolidated and cross-referenced.
Classification — Assign Tiers Based on Risk
Once you have the inventory, classify each supplier by the risk they represent. The classification should reflect the sensitivity of the data they access, the criticality of the systems they touch, and the operational dependency the organization has on them. A tiered model — typically three levels — determines how much assessment depth each vendor receives. You don’t send a 200-question questionnaire to your office supply vendor.
Assessment — Questionnaire Mapped to a Framework
Assess suppliers with a questionnaire calibrated to their tier. The questions should be mapped to a framework relevant to your industry — HIPAA technical safeguards if you’re in healthcare, PCI DSS Requirement 12 if cardholder data is involved, NIST SP 800-53 or ISO 27001 controls for general enterprise environments. A generic questionnaire produces answers you cannot evaluate against anything. A mapped questionnaire produces findings you can score, document, and defend.
Review — Inspect Answers, Produce Findings
Questionnaire responses are claims, not evidence. Review answers critically, identify gaps, and produce a findings report with a risk rating per vendor. The output isn’t a pass/fail — it’s a documented risk posture that upper management can evaluate. Findings should be traceable back to the specific control gaps that produced them.
Decision — Management Accepts or Exits
The findings go to upper management, who decide whether to accept the residual risk and continue the relationship, require remediation before continuing, or exit the relationship entirely. This decision belongs to management — not the security team. Security assesses. Management accepts or doesn’t. If security is making the final call on vendor relationships, the governance structure isn’t right.
Supplier Tiers
The classification step is where you make the program manageable. Applying the same depth of scrutiny to every vendor wastes resources and produces assessment fatigue. Tiering focuses effort where the risk is highest.
Critical
Direct access to sensitive data or critical systems. A breach or outage at this vendor directly impacts your operations or compliance posture. Deepest assessment, contractual controls, ongoing monitoring.
Significant
Indirect access or less sensitive data. Operational dependency exists but impact of a breach is bounded. Standard assessment questionnaire, annual review cycle.
Standard
Low risk. No sensitive data access, minimal operational dependency. Lightweight assessment or attestation-based review. Periodic spot checks.
The classification isn’t permanent. A Tier 3 vendor that expands its scope of access — through a new integration, a contract amendment, or an M&A event — moves up. The inventory and classifications need to be reviewed at least annually and whenever a material change in the relationship occurs.
Where Most Programs Break Down
The discovery gap
The supplier inventory is never complete. Shadow IT, departmental SaaS purchases, and vendors brought in through acquisitions consistently fall outside formal procurement processes. A vendor your organization has never officially onboarded still has access to your data if a business unit is using their product. Discovery is a continuous process, not a one-time project — and it requires a culture where business units report new vendor relationships rather than treating security as an obstacle to getting work done.
The questionnaire problem
Sending a questionnaire and accepting the answers at face value isn’t assessment — it’s documentation theater. Vendors have strong incentives to answer optimistically. The questionnaire is a starting point for a conversation, not a closing document. For Tier 1 vendors, questionnaire responses should be backed by evidence: audit reports (SOC 2 Type II, ISO 27001 certification), penetration test summaries, or right-to-audit clauses that give you the ability to verify independently.
The contract gap
Most TPRM programs focus on the assessment and forget the contract. The questionnaire tells you what the vendor claims. The contract is what you can enforce. Right-to-audit clauses, breach notification timelines, data handling and disposal obligations, and subprocessor restrictions need to be in the agreement before the relationship starts. Negotiating these after something goes wrong is both more expensive and less effective.
The offboarding gap
When a vendor relationship ends, what happens to your data? Most programs have no formal answer. GDPR Article 28(3)(g) requires that processors delete or return all personal data at the end of services. Getting that obligation into the contract and verifying that it was carried out is the close of the loop that most TPRM programs never complete. An offboarded vendor who still holds a copy of your customer data is still a risk — one you’re no longer monitoring.
Annual assessments tell you the vendor’s security posture as of the date they filled out the questionnaire. A vendor that passes in January can have a major breach in March and you won’t know until next year’s cycle unless you have ongoing monitoring in place — news feeds, breach disclosure tracking, and security ratings services. NIST SP 800-53 SR-6 enhancement (1) specifically requires ongoing monitoring of supplier security posture. An annual questionnaire satisfies the documentation requirement. It does not satisfy the intent.
Control Mapping
NIST SP 800-53 SR-2 (Supply Chain Risk Management Plan) requires that a formal SCRM plan exists, addresses known threats and vulnerabilities in the supply chain, and is reviewed and updated regularly. The discovery and classification steps above are the operational implementation of SR-2.
NIST SP 800-53 SR-6 (Supplier Assessments and Reviews) requires assessing suppliers and third-party providers using formal assessments or audits. SR-6(1) adds ongoing monitoring. The questionnaire process mapped to a framework is SR-6. Annual-only assessment without monitoring is SR-6 without the enhancement — technically compliant, operationally insufficient.
NIST SP 800-53 SR-8 (Notification Agreements) requires that agreements with suppliers include notification requirements for security incidents and breaches. This is the contractual control that most programs leave out — the questionnaire gets built, the contract doesn’t get updated to require breach notification within a defined window.
NIST CSF ID.SC (Supply Chain Risk Management) is the Identify function’s supply chain category. ID.SC-2 requires identifying, prioritizing, and assessing suppliers — which maps directly to the discovery, classification, and assessment steps. ID.SC-4 requires that response plans include third parties.
ISO 27001 A.5.19 and A.5.20 cover information security in supplier relationships and addressing security within supplier agreements respectively. A.5.19 is the program-level control — policies for supplier relationships. A.5.20 is the contract-level control — what must be in the agreement. Both are required for ISO 27001 certification.
GDPR Article 28 requires that controllers only use processors providing sufficient guarantees about technical and organizational security measures, and that processing is governed by a binding Data Processing Agreement. The DPA must include the subject matter and duration of processing, the nature and purpose of processing, the type of personal data and categories of data subjects, and the obligations and rights of the controller. Every cloud vendor, SaaS platform, and contractor that processes personal data on your behalf requires a compliant DPA.
TPRM is one of those program areas where the gap between what organizations document and what they actually practice is wide. The process isn’t complicated — discovery, classification, assessment, review, decision. What makes it hard is that it requires organizational cooperation that doesn’t happen without executive mandate, contractual discipline that most procurement teams aren’t focused on, and continuous monitoring that most security teams haven’t resourced. Getting those three things right is what separates a TPRM program from a TPRM checklist.
