Third Party Risk Management
Third party risk management (TPRM) is the discipline of identifying, assessing, monitoring, and mitigating security risks introduced by vendors, service providers, cloud platforms, software suppliers, and other external parties that have access to an organisation's data, systems, or networks.
The modern enterprise is a network of dependencies. A typical financial services organisation manages 500-1,000 third party relationships, of which 50-100 have access to sensitive data or critical systems. Each third party extends the organisation's attack surface beyond its direct control. The 2020 SolarWinds compromise, the 2023 MOVEit exploitation, and the 2024 CrowdStrike incident demonstrated that third party risk is not theoretical — it is the primary vector for systemic compromise.
TPRM programmes fail for predictable reasons. Assessment is treated as a point-in-time checkbox during procurement rather than continuous monitoring. Questionnaire-based assessments (SIG, CAIQ, VSA) measure policy documentation rather than operational security. Risk tiering is based on contract value rather than data sensitivity and system criticality. Fourth party risk (your vendor's vendors) is invisible. Exit planning is deferred until the relationship is already in crisis.
This pattern defines a risk-proportionate TPRM architecture that addresses these failures. It covers the full vendor lifecycle from initial classification through due diligence, onboarding, continuous monitoring, incident response, and exit. The architecture is designed to be proportionate — a Tier 1 critical vendor with access to customer PII requires SOC 2 Type II, penetration test results, and cyber insurance verification; a Tier 4 office supplies vendor requires a basic questionnaire. Applying the same process to every vendor is how TPRM programmes collapse under their own weight.
The pattern maps to NIST 800-53 supply chain risk management (SR family), system and services acquisition (SA family), and planning controls, with additional mappings to assessment and authorisation controls that govern the ongoing assurance process.
Click any control badge to view its details. Download SVG
Key Control Areas
Third Party Classification and Risk Tiering
Classify all third parties by data sensitivity (PII, financial, health, IP), system criticality (business-critical, important, standard), access type (network, data, physical, none), and substitutability (single source, limited market, commodity). Assign risk tiers: Tier 1 (critical — access to sensitive data or critical systems, hard to replace), Tier 2 (significant — access to internal systems or moderate data), Tier 3 (standard — limited access, easily replaceable), Tier 4 (minimal — no data access, commodity services). Each tier maps to a proportionate assessment depth and monitoring frequency. Maintain a complete third party inventory with owner, tier, contract expiry, and last assessment date.
Due Diligence and Security Assessment
Tier 1 requires: SOC 2 Type II report (or ISO 27001 certificate with statement of applicability), annual penetration test results (application and infrastructure), evidence of vulnerability management programme, incident response plan, business continuity/disaster recovery test results, cyber insurance certificate of currency, and completed security questionnaire (SIG Lite or CAIQ). Tier 2 requires: SOC 2 Type II or ISO 27001 certificate, penetration test summary, and security questionnaire. Tier 3 requires: Self-attestation questionnaire and evidence of basic security controls. Tier 4 requires: Confirmation of standard terms only. Assess before onboarding and at intervals proportionate to tier (Tier 1 annually, Tier 2 every 18 months, Tier 3 every 2 years).
Contract Security Requirements
Embed security obligations in all vendor contracts proportionate to tier. Minimum clauses: data processing agreement (if personal data), security incident notification timeline (72 hours maximum for Tier 1, aligned with GDPR Article 33), right to audit (Tier 1 and 2), data return/destruction on termination, sub-processor notification and approval requirements, compliance with specified standards (SOC 2, ISO 27001, PCI DSS as applicable), insurance minimums, and liability allocation for security breaches. Use a standard security schedule that attaches to the commercial agreement rather than negotiating security terms ad-hoc per vendor.
Continuous Monitoring and Reassessment
Point-in-time assessment is necessary but insufficient. Implement continuous monitoring proportionate to tier: Tier 1 — real-time security rating monitoring (BitSight, SecurityScorecard, RiskRecon), SOC 2 Type II report refresh annually, automated alerts on rating changes, quarterly review meetings. Tier 2 — security rating monitoring, annual attestation refresh. Tier 3 — biennial questionnaire refresh. Monitor for: public breach disclosures, significant rating drops, regulatory actions, financial distress indicators, leadership changes in security function. Trigger reassessment when monitoring signals degrade below threshold.
Fourth Party and Sub-Processor Risk
Your vendor's vendors are your risk. Require Tier 1 vendors to disclose material sub-processors and notify before changes. Assess concentration risk — multiple critical vendors depending on the same cloud provider or infrastructure service creates correlated failure risk. Map critical fourth party dependencies: cloud hosting provider, identity provider, CDN, payment processor, key management service. Require contractual flow-down of security obligations to sub-processors. For SaaS vendors, assess whether they maintain SOC 2 coverage over their own sub-processor management.
Incident Response and Notification
Define incident notification requirements per tier. Tier 1: notification within 24 hours of confirmed incident affecting your data or services, with root cause analysis within 72 hours and remediation plan within 7 days. Tier 2: notification within 48 hours, RCA within 5 business days. Maintain pre-agreed incident communication channels and contacts (not just a generic support email). Include your third party incident playbook in your own IR plan — who to contact, escalation path, communication to your customers, regulatory notification obligations. Test third party incident scenarios in tabletop exercises.
Access Management and Data Controls
Third party access to your systems must follow least privilege. Dedicated accounts (never shared credentials), MFA required, just-in-time access for maintenance windows, VPN or zero trust network access for remote connections. Segregate third party network access from internal employee access. Monitor and log all third party access with alerts on anomalous patterns. For data sharing: encrypt in transit (TLS 1.2+) and at rest, use dedicated secure transfer mechanisms (not email), apply data loss prevention controls, and maintain data flow inventories showing what data goes where.
Cyber Insurance Verification
Require Tier 1 and Tier 2 vendors to maintain cyber insurance with coverage proportionate to the relationship risk. Verify: policy type (cyber liability, errors and omissions, professional indemnity), coverage limits (minimum aligned to potential exposure), policy currency (certificate of insurance annually), coverage scope (data breach response, business interruption, regulatory defence, third party liability). Note that cyber insurance is not a control — it is a risk transfer mechanism. It does not prevent incidents but ensures the vendor can fund response and remediation. A vendor without cyber insurance who suffers a major breach may not survive to fulfil their remediation obligations.
Exit Planning and Data Return
Plan exit before you need it. For Tier 1 vendors: document data return/destruction procedures, establish maximum data return timeline (30 days), verify data destruction certification, maintain alternative vendor shortlist, document migration runbook including data format and API compatibility. Test data portability before it becomes critical — extract a sample dataset and verify it imports to an alternative platform. For SaaS dependencies: ensure data export in standard formats (CSV, JSON, API), not proprietary. Contract should specify that the vendor will provide reasonable transition assistance at standard rates for a defined period after termination.
TPRM Programme Governance
Assign TPRM programme ownership — typically procurement or vendor management with security providing assessment and monitoring. Maintain TPRM policy defining tier criteria, assessment requirements per tier, exception process, and escalation path. Report TPRM metrics to leadership: total vendors by tier, percentage assessed within policy, overdue assessments, average vendor security rating trend, open remediation items, vendors with expired certifications. Conduct annual programme review including: tier classification accuracy, assessment process efficiency, monitoring effectiveness, and lessons from any third party incidents.
When to Use
Any organisation using cloud services, SaaS platforms, or outsourced IT services. Regulated industries with explicit supply chain risk requirements (financial services under DORA/PRA SS2/21, healthcare under HIPAA, government under FISMA). Organisations processing personal data under GDPR (data processor obligations). Organisations that have experienced a third party security incident. Any entity whose customers ask for SOC 2 Type II reports or completed security questionnaires.
When NOT to Use
Organisations with no external vendor dependencies (extremely rare). Very small teams where all services are built and operated internally with no cloud or SaaS usage.
Typical Challenges
Assessment fatigue — Tier 1 due diligence on every vendor regardless of risk. Questionnaire theatre — vendors provide policy documents that do not reflect operational reality. Point-in-time assessment treated as continuous assurance. Fourth party risk invisible because vendors will not disclose their sub-processors. Exit planning deferred because it implies the relationship will fail. TPRM team understaffed relative to vendor population (500+ vendors, 2-person team). Vendors resisting right-to-audit clauses. SOC 2 Type I presented as equivalent to Type II. Cyber insurance verification not part of standard onboarding. Shadow IT creating unmanaged third party relationships.
Threat Resistance
Addresses supply chain compromise by requiring security assessment before vendor onboarding and continuous monitoring during the relationship. Reduces fourth party concentration risk through sub-processor disclosure and dependency mapping. Ensures incident response capability through contractual notification obligations and tested playbooks. Provides financial resilience through cyber insurance verification. Enables clean exit through pre-planned data return and migration procedures.
Assumptions
The organisation uses external vendors, cloud services, and third party software. A procurement or vendor management function exists. The organisation has data classification and system criticality definitions. Regulatory requirements mandate supply chain risk management (financial services, healthcare, government, critical infrastructure).
Developing Areas
- Continuous third-party monitoring is displacing point-in-time assessment as the primary assurance mechanism, but the methodology is immature. External security rating services (BitSight, SecurityScorecard) provide observable signals but measure only internet-facing posture -- they cannot assess internal controls, incident response capability, or data handling practices. The gap between what continuous monitoring can see (exposed services, certificate hygiene, DNS configuration) and what matters (access controls, encryption, backup integrity) means ratings are directional indicators, not definitive risk measures.
- Nth-party (sub-contractor) risk visibility is the most significant blind spot in TPRM programmes. DORA and PRA SS2/21 mandate sub-processor visibility for critical ICT services, but practical enforcement is limited. Most Tier 1 vendors resist disclosing their full sub-processor chain, and the concentration risk from multiple critical vendors depending on the same cloud provider (AWS, Azure, GCP) or infrastructure service remains difficult to map and nearly impossible to mitigate without architectural diversity that increases cost and complexity.
- AI-assisted vendor risk assessment is emerging as a response to the scale problem -- hundreds of vendors requiring assessment with limited analyst capacity. LLM-powered tools can parse SOC 2 reports, extract control findings, compare against organisational requirements, and generate risk summaries, reducing initial assessment time by an estimated 60-70%. However, the accuracy of automated assessment is unvalidated at scale, and the risk of hallucinated compliance findings in AI-generated assessments creates a new category of assessment error.
- Software supply chain transparency through vendor-provided SBOMs is a regulatory requirement in progress (EU Cyber Resilience Act, US Executive Order 14028) but practical adoption is minimal. Fewer than 10% of commercial software vendors provide machine-readable SBOMs with their products, and those that do often deliver incomplete or inaccurate bills of materials. The tooling to consume, validate, and act on vendor SBOMs -- matching components to known vulnerabilities, detecting licence conflicts, verifying provenance -- is available but not integrated into standard TPRM workflows.
- Concentration risk measurement is gaining regulatory attention but lacks standardised methodology. Regulators want to know what happens if a major cloud provider or critical SaaS platform suffers a prolonged outage, but measuring concentration requires mapping dependency chains across hundreds of vendors, identifying single points of failure, and modelling correlated failure scenarios. No commercial TPRM platform provides automated concentration risk analysis, leaving organisations to build ad-hoc dependency maps that are outdated within months.
Related Patterns
Patterns that operate within or alongside this one. Click any to view.
SR: 5SA: 2CA: 2PM: 2CP: 1AC: 2SC: 3IR: 2PS: 1RA: 2PL: 1
SR-02 Supply Chain Risk Management Plan
SR-03 Supply Chain Controls and Processes
SR-05 Acquisition Strategies, Tools, and Methods
SR-06 Supplier Assessments and Reviews
SA-04 Acquisition Process
SA-09 External System Services
CA-07 Continuous Monitoring
CA-02 Control Assessments
PM-09 Risk Management Strategy
PM-14 Testing, Training, and Monitoring
CP-02 Contingency Planning
AC-03 Access Enforcement
AC-06 Least Privilege
SC-07 Boundary Protection
SC-08 Transmission Confidentiality and Integrity
SC-28 Protection of Information at Rest
IR-06 Incident Reporting
IR-08 Incident Response Plan
PS-07 External Personnel Security
RA-03 Risk Assessment
RA-05 Vulnerability Monitoring and Scanning
PL-02 System Security and Privacy Plans
SR-04 Provenance