Third-Party Risk Management (TPRM) is the discipline of assessing and monitoring the risk your vendors and suppliers create for you. When you depend on third parties for critical services or data, their failures become yours — operationally, contractually and, increasingly, legally.
This guide covers building a TPRM programme: tiering, questionnaires, due diligence, continuous monitoring, and the concentration and exit questions regulators now ask.
Why TPRM Matters
- Operational — a key supplier fails, is acquired, or degrades, and a process you own stops working.
- Security and compliance — a vendor breach exposes your data or your customers'. Their control failure appears in your incident report.
- Regulatory — supervisors expect demonstrable oversight. DORA mandates a Register of Information covering every ICT contractual arrangement; NIS2 makes supply-chain security an explicit duty; GDPR requires Article 28 terms and processor due diligence.
- Reputational — a supplier's labour or environmental practices become your headline, and increasingly your ESG disclosure.
Building the Programme
1. Build the Inventory First
You cannot manage what you have not listed, and most organisations underestimate their vendor count substantially — procurement records miss anything bought on a card, and shadow IT misses more.
Reconcile procurement, accounts payable, and system integration lists. The output is one record per third party, with the services they provide and the business processes and data they touch.
2. Tier by Criticality
Not all vendors warrant the same scrutiny. Tier by the impact of their failure:
- Critical — core to operations, or handling sensitive data at scale, or hard to replace quickly. Full due diligence, annual reassessment, continuous monitoring, exit plan.
- High — significant but recoverable. Full questionnaire, periodic reassessment.
- Medium — limited exposure. Lightweight assessment.
- Low — minimal. Inventory record and contract terms.
Tier on inherent criticality — what happens if they fail — rather than on spend. The cheapest vendor can support the most critical process, and frequently does.
3. Assessment Questionnaires
Use standardised questionnaires so responses are comparable across vendors and across time. Industry templates (SIG, CAIQ) save design effort and vendors answer them faster because they have answered them before.
Two efficiencies matter. Accept evidence in lieu of answers — a current ISO 27001 certificate with a relevant scope, or a SOC 2 Type II report, should short-circuit the corresponding sections. And check scope: a certificate covering a subsidiary or a different product does not cover the service you are buying, and this is the single most common thing organisations fail to verify.
Score responses, flag gaps, and track them as findings with owners rather than filing the questionnaire.
4. Due Diligence
Before onboarding a critical vendor, and periodically after: financial stability, certifications with scope checked, insurance, sub-processor disclosure, data location and transfer mechanisms, and contract terms — security requirements, audit rights, breach notification deadlines, service levels, and termination assistance.
Document all of it. Oversight you cannot evidence does not exist as far as an auditor or regulator is concerned.
5. Continuous Monitoring
TPRM does not end at onboarding, and this is where most programmes are weakest. Monitor for certificate and attestation expiry, breach disclosures and news, financial distress signals, service-level performance, and changes in sub-processors.
Reassess on a schedule proportionate to tier, and on trigger events — a breach, an acquisition, a material service change, or a certificate lapsing.
6. Concentration Risk and Exit
Two questions regulators now ask that most programmes cannot answer.
Concentration. How many critical processes depend on the same provider, or on the same underlying infrastructure? Four vendors on the same cloud region is one failure, not four. Answering this requires vendor records linked to the processes they support.
Exit. For each critical vendor, could you actually leave? A documented exit strategy covers the trigger, the alternative, data extraction in a usable format, transition duration, and who does the work. DORA requires this explicitly; it is good practice regardless.
7. Link to the Risk Register
Vendor risk belongs in the enterprise risk register, not in a parallel vendor system. Where a third party is critical to a process, "failure of vendor X" should be an assessed risk linked to its controls — the contract, the assessment, the monitoring, the exit plan — and to any audit work covering it.
This also resolves a conflict that siloed programmes produce constantly: sustainability rates a supplier compliant on a returned questionnaire while procurement's risk assessment flags them high-risk, and nobody can say which is correct.
Where the RTO Chain Breaks
A point worth stating explicitly because it invalidates continuity plans quietly: a supplier with a 72-hour recovery commitment caps every process depending on them at 72 hours, whatever your own business continuity plan claims. Third-party recovery commitments must be reconciled against the RTOs in your BIA, and the mismatches treated as findings.
Metrics
| Metric | What it reveals |
|---|---|
| Inventory completeness | Whether shadow vendors are being found |
| Assessments current by tier | Whether the cadence is real |
| Open findings by vendor and age | Whether gaps get closed |
| Critical vendors with tested exit plans | Whether exit is documented or theoretical |
| Concentration by provider and process | Where single points of failure hide |
How ActiveERM Supports TPRM
An integrated GRC platform holds the vendor inventory, runs and scores assessments, tracks findings to closure, and links third-party risk to the risk register and control library — so security, procurement and sustainability assessments resolve to one supplier record with one composite view.
Because vendors are linked to the processes they support, concentration and RTO-chain conflicts surface as reports rather than as discoveries during an incident. See GRC Cloud and Risk OS, or request a demo.