Module 4 · Third-Party Risk Management

Last updated: April 29, 2026

Third-party risk management (TPRM) is the discipline of identifying, assessing, and continuously monitoring the security risks introduced by your vendors and partners. Most modern breaches involve a third party — either as the source of compromise or as the path to it. This module covers the operating model, assessment workflow, ongoing monitoring, and the contractual provisions that matter.

Why TPRM is hard

• You don’t control vendor systems — only your relationship with them
• Vendors range from huge (AWS, Azure) to tiny (a 3-person SaaS that does one critical thing)
• One-time assessments age quickly; vendor security posture changes
• The risk is often invisible — you cannot see your vendor’s controls daily
• Regulatory expectations are rising fast (DPDP, EU DORA, RBI third-party risk guidance)

Vendor classification — tier by inherent risk

Not every vendor needs the same scrutiny. Tier vendors by:

• Data sensitivity: do they hold our customer data? PII? Financial? Source code?
• Access level: direct system access? Reads only? Privileged?
• Operational dependence: would loss of this vendor halt our business?
• Regulatory implications: are they subject to obligations we’re then liable for?

A common 3-tier model:

• Tier 1 (Critical): handles regulated/sensitive data or critical operations. Heavy assessment. Annual reassessment. Real-time monitoring
• Tier 2 (Important): some data access or operational dependence. Light assessment. Biennial reassessment
• Tier 3 (Routine): minimal data, limited operational impact. Self-attestation only. Triennial reassessment

Assessment workflow — pre-contract

1. Inherent risk scoring by data + access + dependency. Determines tier
2. Security questionnaire aligned to tier — SIG, CAIQ, or custom
3. Evidence collection — request SOC 2, ISO 27001:2022 cert, pentest summary, security policies
4. Review and risk identification — gaps in vendor controls vs your requirements
5. Risk treatment — accept, require remediation before contract, walk away
6. Contract clauses — security addendum, breach notification, audit rights, data processing agreement
7. Sign-off by appropriate authority (Tier 1 = CISO; Tier 3 = procurement)

Standard questionnaires

• SIG (Standardized Information Gathering) — Shared Assessments. Comprehensive (~1000 questions); subset SIG-Lite (~250 questions) for smaller engagements
• CAIQ (Consensus Assessment Initiative Questionnaire) — Cloud Security Alliance. ~300 questions focused on cloud providers
• VSAQ (Vendor Security Assessment Questionnaire) — Google’s open-source; lighter
• Custom subsets — many enterprises start from SIG and trim 60% as not applicable

What to actually verify (versus check-box)

Vendors fill in questionnaires aspirationally. The work is verification:

• SOC 2 / ISO 27001 reports — read the auditor opinion, exceptions, and CUECs (controls you must implement)
• Sample evidence — for high-risk vendors, request specific evidence (e.g., recent access review)
• Penetration test summaries — recency (within last 12 months), scope (relevant to your use case), severity of findings, remediation status
• Public security signals — Bitsight / SecurityScorecard ratings, breach history, public CVE disclosures
• Reference customers — for Tier 1, talk to existing customers about their experience

Contractual security provisions

For Tier 1 vendors, the contract should cover:

• Data Processing Agreement (DPA) — required by GDPR/DPDP if PII involved
• Breach notification — within X hours of confirmed breach affecting your data
• Audit rights — annual SOC 2 sharing; right to perform on-site audit (often capped or substituted with SOC 2)
• Subprocessor controls — vendor’s vendors who touch your data; notification of changes
• Data location — geographic constraints if required for regulatory reasons
• Encryption — required for data at rest and in transit
• Return / destruction of data at contract end
• Security incident liability — financial cap and exclusions
• Insurance — cyber liability minimums
• Termination triggers — material breach of security provisions

Continuous monitoring

Annual assessments are insufficient. Continuous signals:

• External attack surface — Bitsight, SecurityScorecard, RiskRecon score the vendor’s exposed posture daily
• Breach intel feeds — alert when a vendor appears in breach reports
• Certification expiry — track SOC 2 / ISO renewal dates
• Public CVE monitoring — when vendor’s product has critical CVE, you have a window of risk
• Subprocessor changes — vendors must notify; verify compliance

Fourth-party and beyond

Your vendor’s vendors (fourth parties) are also your risk. Practically:

• Require vendors to disclose subprocessors
• Track concentration risk — multiple critical vendors all depend on AWS us-east-1, an outage cascades
• For Tier 1 vendors, request their TPRM program details — how do they assess their vendors?

The vendor offboarding playbook

Often overlooked. When a vendor relationship ends:

1. Confirm data return or destruction; obtain certificate of destruction
2. Revoke all access — federation accounts, API keys, IP allowlists
3. Update internal documentation
4. Notify customers if vendor was material
5. Verify with monitoring tools that the vendor no longer has signals into your environment

Operating model — who runs TPRM?

• Procurement-led: common in mid-size; security provides templates and reviews. Procurement owns vendor lifecycle
• Security-led: common in regulated industries; procurement defers to security on risk decisions
• Joint: dedicated TPRM team reporting to a TPRM committee with security and procurement seats

Whichever model, security has the final veto on Tier 1 onboarding. Without that, business velocity wins every assessment dispute.

Tools that help

• Vendor risk platforms: OneTrust, Prevalent, Whistic, ProcessUnity, CyberGRX, Vanta Trust Center
• Continuous monitoring: Bitsight, SecurityScorecard, UpGuard, RiskRecon
• Trust Centers: tools like Drata Trust Center, SafeBase let vendors host their security info; assessors can fetch SOC 2 + policies + questionnaire responses without back-and-forth
• SIG Manager / CAIQ tools — questionnaire automation

India-specific considerations

• RBI Outsourcing Guidelines — for banks: detailed third-party risk management requirements; outsourcing committee approvals
• DPDP Act: Data Fiduciaries are accountable for processors (vendors); contracts must include specified provisions
• SEBI cybersecurity framework — third-party risk requirements for capital market entities
• Cross-border data transfer: some sectors restrict; document data residency in vendor selection

Common failure patterns

• Onboarding 100 vendors a year, reassessing 5 — backlog grows; risk posture declines
• Contracts have security clauses but nobody monitors compliance
• SOC 2 reports collected but not read — exceptions and CUECs ignored
• Critical vendor dependencies undocumented; loss of vendor reveals unknown unknowns
• No offboarding rigour — old vendors retain access for years
• Procurement bypasses security review for “small” purchases that turn out to handle critical data

What the last module covers

Module 5 covers internal audits — running them effectively, scope, sampling, follow-through. The discipline that catches issues before external auditors do, and that demonstrates continuous improvement to certification bodies.