Third-Party Risk Management Programme

The foundation of any TPRM programme is an accurate, current inventory of all third-party relationships. Many organisations discover, when they first build this inventory, that the actual number of active vendors is two to three times larger than what procurement or IT believes it to be. Shadow IT procurement, expired contracts that were never formally terminated, and inherited vendor relationships from acquisitions all inflate the hidden population. The inventory should capture the vendor's name, the services provided, the data types shared, the systems integrated, the contract status, and the assigned risk tier.

Tiering assigns each vendor a criticality level based on a defined set of criteria. A common three-tier model works as follows. Tier 1 applies to vendors that process sensitive personal data at scale, that have privileged access to internal systems, that provide services whose failure would halt core business operations, or that trigger specific regulatory obligations such as a business associate agreement under HIPAA or a data processing agreement under GDPR. These vendors receive full due diligence, the most demanding contract terms, and annual reassessment with continuous monitoring between cycles. Tier 2 covers vendors with moderate risk profiles: they handle limited personal data, have bounded system access, and their failure would be disruptive but recoverable. Tier 3 covers low-risk vendors with no data access and no system integration.

Tier assignments should be reviewed when the vendor's scope changes. A vendor that starts as a Tier 3 marketing supplier and later gains access to a customer database becomes a Tier 1 vendor the moment that access is granted, not at the next scheduled reassessment cycle. Change management processes should include a step that checks whether a scope change triggers a tier reclassification.

Due diligence is the investigation conducted before a vendor relationship begins. For Tier 1 vendors, this is a substantial exercise. The organisation sends a due diligence questionnaire covering the vendor's information security policy framework, access control practices, encryption standards, incident response capability, business continuity arrangements, and subprocessor relationships. The vendor's responses are reviewed against the organisation's minimum security baseline, and gaps are either remediated before onboarding proceeds or accepted as residual risk with documented rationale.

Evidence review supplements the DDQ. A vendor that claims ISO 27001 certification should produce a current certificate from an accredited certification body. A cloud provider claiming SOC 2 Type II should provide the full report, including the auditor's description of tests performed and any exceptions noted. Self-attestation without supporting evidence is a weaker assurance basis and should be noted in the risk assessment. For vendors handling payment card data, verification that they are listed in Visa's or Mastercard's registry of PCI-DSS compliant service providers is a baseline check.

For lower tiers, due diligence is proportionally lighter. A Tier 3 vendor may complete a brief self-attestation form confirming it has a security policy and that no data will be shared. The key principle is proportionality: the assessment effort should match the risk, and the rationale for the tier assignment should be documented in case it is later questioned.

The contract is the primary mechanism by which an organisation imposes security obligations on a vendor. A security-conscious contract does more than agree on price and deliverables; it allocates responsibility for data protection, specifies the controls the vendor must maintain, and creates mechanisms for the organisation to verify compliance. Regulatory frameworks explicitly require this. Under GDPR Article 28, a controller must have a written contract with any processor handling personal data. India's DPDP Act 2023 imposes analogous obligations on data fiduciaries contracting with data processors. HIPAA requires covered entities to have business associate agreements in place before sharing protected health information.

The security clauses an auditor expects to find in a Tier 1 vendor contract include: a data protection annex specifying the categories of data processed, the permitted purposes, and the technical and organisational measures required; a breach notification obligation requiring the vendor to notify the organisation within a defined period (24 to 72 hours is typical, aligned with GDPR's 72-hour supervisory authority notification window); a right-to-audit provision; a requirement to maintain specified certifications or security standards throughout the contract term; a subprocessor approval requirement obliging the vendor to obtain written consent before engaging subprocessors that will handle the organisation's data; and data return and destruction obligations on termination.

The right-to-audit clause deserves specific attention. In practice, organisations rarely exercise the right directly because on-site audits of large vendors are expensive and disruptive. Many vendors instead offer their SOC 2 Type II report or ISO 27001 certificate as a substitute. The contract should specify which accepted substitutes satisfy the audit right and should preserve the organisation's right to conduct a direct assessment in high-risk scenarios, such as following a security incident at the vendor.

A vendor's security posture at onboarding is not a permanent state. Staff change, controls degrade, new vulnerabilities emerge, and vendors undergo their own organisational changes such as acquisitions, financial stress, or technology migrations that alter their risk profile. A TPRM programme addresses this through two complementary mechanisms: periodic formal reassessment on a defined schedule, and continuous monitoring between cycles.

Periodic reassessment for Tier 1 vendors typically runs annually. The organisation sends an updated DDQ or a delta questionnaire asking only about changes since the last assessment, reviews any updated certifications or audit reports, and checks for public security incidents involving the vendor. The reassessment produces a refreshed risk rating and a decision on whether to continue, renegotiate, or exit the relationship. Tier 2 vendors may be reassessed every two years. Tier 3 vendors are typically reviewed only at contract renewal.

Continuous monitoring fills the gap between formal reassessments. External attack surface monitoring tools scan vendor-owned domains and IP ranges for exposed services, unpatched vulnerabilities, and misconfigurations. Threat intelligence feeds report on vendor-related security incidents in near real-time. Security ratings services produce numerical scores based on observable signals from outside the vendor's network. These tools do not replace formal assessment, but they allow the organisation to detect a meaningful deterioration in a vendor's posture between reassessment cycles and trigger an earlier review if warranted.

Trigger-based reassessment should occur independently of the scheduled cycle when specific events occur: a security incident at the vendor that may have affected the organisation's data, a significant change to the vendor's ownership or management, a material change to the services provided or the data accessed, a regulatory action against the vendor, or a publicly disclosed vulnerability in software the vendor operates on the organisation's behalf.

Offboarding is the stage most frequently neglected in TPRM programmes. When a vendor relationship ends, either by non-renewal, termination, or replacement, the organisation must systematically close off every point of access and account for every piece of shared data. Failure to do so leaves credentials active that are no longer monitored, data in vendor systems with no contractual protection, and network connections that exist outside the organisation's current vendor inventory.

A structured offboarding checklist for a Tier 1 vendor should include: revoking all user accounts and service accounts provisioned to the vendor, rotating any shared API keys or secrets, terminating VPN tunnels or other dedicated network connections, notifying the vendor in writing to return or destroy all organisation data within a specified period (typically 30 days), obtaining written confirmation from the vendor that destruction is complete (or receiving the returned data), recovering or inventorying any organisation-owned equipment at the vendor's site, and archiving all offboarding records for the required retention period.

Data destruction verification is a contractual and regulatory obligation under GDPR Article 28(3)(g), the DPDP Act 2023, and HIPAA. The organisation must retain evidence that destruction occurred. A vendor's written confirmation letter, a certificate of destruction from a destruction service, or an audit log showing file deletion are acceptable forms of evidence. Verbal confirmation is not.

When an information security auditor reviews a TPRM programme, they work through a standard set of documentation checks at each lifecycle stage. The auditor is not simply verifying that processes exist on paper; they are checking whether the processes are operating and producing current evidence. A policy that has never been executed, a vendor inventory last updated eighteen months ago, or a due diligence file with no reassessment record after the initial onboarding are all findings, even if the underlying documents look comprehensive.

Key documentation the auditor will request includes: a current vendor inventory with tier assignments, a TPRM policy and procedure document approved at appropriate governance level, completed due diligence questionnaires for Tier 1 and Tier 2 vendors with evidence reviewed (certificates, SOC reports), signed contracts for all active vendors with security clauses and data processing agreements as applicable, records of periodic reassessments with dates and outcomes, evidence of continuous monitoring activity (reports, alerts reviewed, actions taken), and offboarding records for recently terminated vendors showing access revocation and data destruction.

The most frequently cited findings in TPRM audits fall into consistent categories. Incomplete vendor inventory: vendors in active use that do not appear in the formal inventory. Missing or expired certifications: vendors whose ISO 27001 certificate has lapsed or whose SOC 2 report is more than twelve months old. Contracts without security clauses: legacy contracts predating the TPRM programme that were never updated. Overdue reassessments: Tier 1 vendors whose last formal assessment was more than two years ago. No offboarding records: terminated vendors with no documented access revocation.