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?
MediumThis control ensures the Third-Party Risk Management (TPRM) programme has a designated executive-level owner with defined accountability and active sponsorship from senior leadership. The owner is responsible for programme strategy, resource allocation, governance oversight, and escalation of critical vendor risks.…
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?
MediumThis control ensures the Third-Party Risk Management (TPRM) policy receives formal approval from the board of directors or executive leadership committee and undergoes mandatory annual review. The approval process establishes accountability at the highest organizational level for vendor risk decisions…
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)?
MediumThis control requires the organization to formally define and document acceptable risk thresholds for third-party relationships. It establishes measurable limits such as maximum vendor concentration (percentage of critical vendors in a single industry or geography), residual risk scores that require…
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)?
MediumThis control mandates that Third-Party Risk Management (TPRM) approval acts as a blocking requirement in the procurement workflow, preventing contract execution or purchase order issuance until a formal TPRM assessment is completed and approved. Implementation typically involves workflow automation in…
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)?
MediumThis control ensures that the legal department is formally embedded within the Third-Party Risk Management (TPRM) process, particularly for vendor contracts involving data processing. Legal reviews and standardizes Data Processing Agreements (DPAs), contractual security schedules (defining technical and organizational measures),…
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?
MediumThis control ensures the organization maintains a formally documented Third-Party Risk Management (TPRM) lifecycle that spans intake (vendor request and initial triage), due diligence (security assessments, questionnaires, and risk scoring), contracting (legal review and security clauses), ongoing monitoring (periodic reassessments…
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?
MediumThis control requires organizations to manage third-party risk using a dedicated TPRM (Third-Party Risk Management) or GRC (Governance, Risk, and Compliance) platform rather than relying on spreadsheets or ad-hoc tools. Dedicated platforms provide centralized vendor inventories, automated risk scoring, workflow…
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)?
MediumThis control ensures that vendor and third-party due-diligence questionnaires (DDQs) are managed through a dedicated platform or workflow automation system rather than manual email exchanges. Automated tracking provides centralized visibility into questionnaire distribution, completion status, follow-up requirements, and version control.…
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?
MediumThis control requires the organization to subscribe to and actively utilize a third-party continuous security rating service (such as BitSight, SecurityScorecard, UpGuard, or similar) to monitor the cybersecurity posture of Tier 1 vendors—those critical to business operations or handling sensitive…
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)?
MediumThis control requires organizations to establish and monitor quantitative Key Performance Indicators (KPIs) for their Third-Party Risk Management (TPRM) program, specifically tracking cycle time (duration from initiation to completion of assessments), exception rate (frequency of approved deviations from standard requirements),…
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?
MediumThis control requires the Third-Party Risk Management (TPRM) function to provide formal reporting to the board of directors or its audit committee at minimum annually, specifically addressing material risks identified through vendor assessments, ongoing monitoring, and incidents. The report typically…
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?
MediumThis control ensures that security incidents involving third-party vendors—including data breaches, service outages, and contractual security violations—are formally documented in an incident tracking system, subjected to root cause analysis, and systematically reviewed to improve vendor risk management processes. The control…
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