About this program
Where the Third-Party / Vendor Risk assessment looks at controls, this one looks at the programme — governance, ownership, automation, KPIs, and how TPRM integrates with procurement, legal, and security. Aligned to ISO 27036, NIST SP 800-161, and the Shared Assessments TPRM Framework.
Controls (12)
-
Is there a single accountable owner for the TPRM programme with executive sponsorship?
MediumIs there a single accountable owner for the TPRM programme with executive sponsorship?
How to test + evidence
Risk: Without single-owner accountability, TPRM diffuses across functions and ends up belonging to no one. Charters with executive sponsorship are what give the programme teeth.
Testing procedure: Inspect the TPRM programme charter, organisation chart, and most recent steering committee minutes. Verify the named owner is empowered to block onboarding and trigger off-boarding.
Evidence to collect: TPRM programme charter signed by executive sponsor Org chart showing the TPRM owner role Steering committee minutes showing decisions made Documented authority to block onboardings
-
Is the TPRM policy approved at board or executive level and reviewed annually?
MediumIs the TPRM policy approved at board or executive level and reviewed annually?
How to test + evidence
Risk: Board-level approval signals to vendors and regulators that TPRM has organisational weight. Annual review keeps it current as the vendor estate evolves.
Testing procedure: Inspect the TPRM policy. Verify board/executive approval signature, effective date within the audit period, and most recent annual review.
Evidence to collect: TPRM policy with version history Board / executive minutes approving the policy Annual review log with reviewer + outcome
-
Is there a documented risk appetite for third-party risk (e.g. acceptable concentration, residual risk thresholds)?
MediumIs there a documented risk appetite for third-party risk (e.g. acceptable concentration, residual risk thresholds)?
How to test + evidence
Risk: Without a quantified appetite the programme cannot say "no" credibly. Auditors look for explicit thresholds, not "we know it when we see it".
Testing procedure: Inspect the risk appetite statement. Check for explicit thresholds (e.g. "no single vendor responsible for more than X% of critical services"). Trace one breach of appetite to documented escalation.
Evidence to collect: Risk appetite statement signed by the board KRIs with thresholds tied to appetite Sample escalation when threshold breached
-
Is TPRM integrated into procurement workflow as a hard gate (cannot sign without TPRM sign-off)?
MediumIs TPRM integrated into procurement workflow as a hard gate (cannot sign without TPRM sign-off)?
How to test + evidence
Risk: Workflow enforcement is the only sustainable way to prevent bypasses under deal-pressure. Policy-only enforcement degrades within 6 months.
Testing procedure: Walkthrough the procurement workflow with Procurement and IT. Verify that the system technically prevents signature without TPRM approval. Sample 15 contracts and confirm no bypasses.
Evidence to collect: Procurement workflow showing mandatory TPRM gate Sample 15 contracts each with TPRM sign-off date Bypass log (should be empty or fully justified)
-
Is Legal integrated into TPRM (DPAs, security schedule, breach notification clauses standardised)?
MediumIs Legal integrated into TPRM (DPAs, security schedule, breach notification clauses standardised)?
How to test + evidence
Risk: Legal-owned templates ensure breach notification SLAs, audit rights, and data return clauses are non-negotiable defaults rather than per-deal struggles.
Testing procedure: Inspect the security schedule template and the contract review playbook. Sample 10 contracts and confirm the schedule is attached unmodified.
Evidence to collect: Standard security schedule template (versioned) Sample 10 contracts with the schedule attached Contract review playbook covering security clauses
-
Is the TPRM lifecycle documented end-to-end (intake, due diligence, contracting, monitoring, exit) with role assignments?
MediumIs the TPRM lifecycle documented end-to-end (intake, due diligence, contracting, monitoring, exit) with role assignments?
How to test + evidence
Risk: Lifecycle documentation is auditor table-stakes. Without it, the programme cannot scale with vendor count or onboard new TPRM staff efficiently.
Testing procedure: Request the TPRM lifecycle process document. Verify RACI per phase, escalation paths, and SLAs per stage.
Evidence to collect: TPRM lifecycle process document RACI per phase SLAs and escalation paths
-
Do you use a TPRM/GRC platform (or fit-for-purpose system) rather than spreadsheets?
MediumDo you use a TPRM/GRC platform (or fit-for-purpose system) rather than spreadsheets?
How to test + evidence
Risk: Spreadsheet-based TPRM stops scaling around 100 vendors. Tooling enables KPIs, automated reassessment cadence, and audit-ready evidence on demand.
Testing procedure: Inspect the system of record for TPRM. Verify it tracks vendor, tier, status, last reassessment, exception, contract end date — and that data is current.
Evidence to collect: Tool / system of record screenshot Sample 10 vendors with up-to-date records Reporting capabilities (sample dashboard)
-
Are due-diligence questionnaires sent and tracked automatically (rather than via email)?
MediumAre due-diligence questionnaires sent and tracked automatically (rather than via email)?
How to test + evidence
Risk: Email-based questionnaires lose evidence, fail to standardise scoring, and prevent year-on-year comparison. Tooling fixes all three.
Testing procedure: Inspect the questionnaire workflow tool. Verify completed questionnaires include reviewer name, date, and linked evidence files.
Evidence to collect: Vendor portal / questionnaire tool Sample completed questionnaires with reviewer + evidence Audit trail of versions and reviews
-
Do you use a continuous security-rating service (BitSight, SecurityScorecard, UpGuard) for Tier 1 vendors?
MediumDo you use a continuous security-rating service (BitSight, SecurityScorecard, UpGuard) for Tier 1 vendors?
How to test + evidence
Risk: Continuous monitoring catches vendor degradation between annual reviews — the period when most breaches actually develop.
Testing procedure: Inspect the rating service subscription and watchlist. Sample 5 recent rating drops and trace the response (review, escalation, dialogue with vendor).
Evidence to collect: Rating service subscription + Tier 1 watchlist Alert configuration Sample 5 drops with documented response
-
Do you have defined KPIs for TPRM (cycle time, exception rate, reassessment compliance, finding remediation)?
MediumDo you have defined KPIs for TPRM (cycle time, exception rate, reassessment compliance, finding remediation)?
How to test + evidence
Risk: KPIs without targets are vanity metrics. The programme is only credible to leadership when there are stated thresholds and reported trends.
Testing procedure: Inspect the KPI dashboard. Verify metrics include onboarding cycle time, % vendors reassessed on time, open findings by age, exceptions in force.
Evidence to collect: KPI dashboard screenshot Quarterly TPRM metrics report Targets vs actuals trend
-
Does TPRM report to the board (or audit committee) at least annually with material risk findings?
MediumDoes TPRM report to the board (or audit committee) at least annually with material risk findings?
How to test + evidence
Risk: Board visibility creates the budget and authority TPRM needs to operate. NIS2 in particular requires management body accountability for supplier risk.
Testing procedure: Inspect board / audit committee minutes for TPRM agenda items in the last 12 months. Verify topics included material findings, concentration risk, and remediation status.
Evidence to collect: Board / audit committee minutes referencing TPRM Sample TPRM board pack Action log showing follow-up on board questions
-
Are vendor security incidents (breaches, outages, contract violations) logged, root-caused, and used to refine the programme?
MediumAre vendor security incidents (breaches, outages, contract violations) logged, root-caused, and used to refine the programme?
How to test + evidence
Risk: Without learning loops, the programme repeats the same gaps. Auditors specifically look for evidence that incidents drove control changes.
Testing procedure: Inspect the vendor incident register. For 3 incidents, trace the root-cause analysis and any programme changes (questionnaire updates, contract clause changes, tier reassessments).
Evidence to collect: Vendor incident register Sample 3 incidents with root-cause + programme change linked Lessons-learned log