SecureLayer
Your security perimeter no longer ends at your network boundary. It extends through every vendor with access to your data, every SaaS platform your employees use, every API integration connecting your systems to third parties, and every contractor with credentials to your environment.
The average enterprise relies on hundreds of third-party vendors, and each one represents a potential entry point for attackers. Supply chain attacks have moved from theoretical to routine: attackers compromise a trusted vendor and use that trust to reach the vendor's customers. The SolarWinds attack demonstrated this at scale. MOVEit, 3CX, and dozens of others followed. The attacker doesn't need to breach your defenses if they can breach your vendor's.
Third-party risk management (TPRM) is the systematic process of identifying, assessing, monitoring, and mitigating the cybersecurity risks that third-party vendors, suppliers, and partners introduce to your organisation. It answers the question every board now asks: "Are we secure from risks introduced by the companies we depend on?"
This guide covers how to build a TPRM programme from assessment through ongoing monitoring, the framework for tiering and evaluating vendors, where penetration testing fits into third-party risk, compliance requirements driving TPRM, and how to make the programme operational rather than aspirational.
For supply chain attack patterns and defensive strategies, see our supply chain security guide.
What Is Third-Party Risk Management?
TPRM is the structured discipline of managing cybersecurity risk introduced by organisations outside your direct control: software vendors, cloud providers, managed service providers, SaaS platforms, consultants, contractors, payment processors, and any entity with access to your data, systems, or network.
Why TPRM Matters Now
Attack surface multiplication. Each vendor with access to your environment extends your attack surface. A vendor with VPN access to your network is as much an entry point as your public-facing web application. See our attack surface management guide.
Supply chain attacks are increasing. Attackers target vendors specifically because compromising one vendor grants access to all that vendor's customers. One breach, hundreds of victims.
Regulatory pressure. Every major compliance framework now includes third-party risk requirements. SOC 2, ISO 27001, PCI DSS, HIPAA, GDPR, DORA, and NIST CSF all require vendor risk management.
Breach liability. When a vendor breach exposes your customer data, your customers hold you accountable. Regulatory penalties apply to you, not your vendor. The contractual relationship doesn't transfer the reputational or regulatory liability.
The TPRM Framework: Five Stages
Stage 1: Vendor Inventory and Classification
You can't manage risk you don't know about. Start with a complete inventory of every third party with access to your data, systems, or network.
What to inventory:
Every SaaS platform your organisation uses (including shadow IT adopted without security approval). Every vendor with network access (VPN, direct connections, API integrations). Every vendor processing your data (cloud providers, payment processors, analytics platforms). Every vendor with physical access (facility management, hardware maintenance). Every contractor or consultant with system credentials.
Classification by risk tier:
Classification determines assessment depth. Not every vendor needs the same level of scrutiny. A vendor hosting your production database receives a fundamentally different assessment than a vendor supplying office furniture.
Stage 2: Vendor Security Assessment
Assess each vendor's security posture proportionate to their risk tier.
Assessment methods by tier:
Critical vendors: Detailed security questionnaire (SIG, CAIQ, or custom). Review of SOC 2 Type II report. Review of ISO 27001 certification. Review of penetration testing reports. Architectural review for data handling. Right-to-audit clause exercised. Independent penetration testing of the vendor's product (where contractually permitted).
High vendors: Security questionnaire. SOC 2 or equivalent compliance evidence. Penetration testing report review. Insurance verification. Business continuity documentation.
Medium vendors: Abbreviated security questionnaire. Compliance certification verification. Basic security controls confirmation (MFA, encryption, access management).
Low vendors: Minimal or no security assessment.
What the Assessment Should Evaluate
Security governance. Does the vendor have a security programme? Dedicated security leadership? Policies, training, risk management?
Technical controls. Encryption (at rest and in transit). Access management (MFA, least privilege). Patch management. Network security. Endpoint protection. For comprehensive assessment coverage, see our IT security audit guide.
Data handling. How does the vendor store, process, and transmit your data? Data classification? Retention and deletion policies? Data residency? Encryption? Who has access?
Incident response. Does the vendor have an incident response plan? Tested within the past year? Notification procedures and timelines for customer-affecting incidents?
Business continuity. Backup strategy. Disaster recovery plan. Tested recovery capabilities. Geographic redundancy.
Compliance. Which frameworks does the vendor maintain? SOC 2 Type II, ISO 27001, PCI DSS, HITRUST? Are certifications current? Outstanding audit findings?
Subcontractor management. Does the vendor use fourth parties (subcontractors) to process your data? How does the vendor assess its own third parties?
Stage 3: Risk Rating and Decision
Based on assessment results, assign a risk rating and make a business decision.
Risk rating scale:
Risk acceptance documentation. When business needs require working with a vendor that has identified risks, document the accepted risks, compensating controls implemented, responsible executive who accepts the risk, and review timeline for reassessment.
Stage 4: Contractual Controls
Security requirements must be contractually enforceable, not just assessed.
Essential contract clauses:
Security requirements. Define minimum security controls the vendor must maintain. Reference specific standards (SOC 2, ISO 27001, encryption requirements, access control standards).
Data handling. Define how the vendor may use, store, process, and delete your data. Geographic restrictions. Encryption requirements. Return and deletion upon contract termination.
Breach notification. Require the vendor to notify you within a defined timeframe (72 hours or less) of any security incident affecting your data.
Right to audit. Reserve the right to assess the vendor's security controls, either directly or through an independent third party. This enables penetration testing of vendor systems when warranted.
Compliance maintenance. Require the vendor to maintain specified certifications and provide updated evidence annually.
Subcontractor approval. Require notification or approval before the vendor engages subcontractors to process your data.
Liability and indemnification. Allocate responsibility for breach costs and regulatory penalties.
Stage 5: Ongoing Monitoring
Vendor security isn't static. A vendor that passed assessment last year may have a breach this year.
Continuous monitoring activities:
Annual reassessment. Repeat the security assessment annually for critical and high vendors. Review updated SOC 2 reports, penetration testing reports, and compliance certifications.
Breach monitoring. Monitor for vendor breaches through dark web monitoring, news alerts, and threat intelligence. Services like SecurityScorecard, BitSight, or UpGuard provide continuous external security ratings.
Compliance monitoring. Track vendor certification expiration. Alert when SOC 2 reports, ISO 27001 certificates, or PCI DSS attestations approach expiration.
Performance monitoring. Track vendor security incidents, SLA compliance, and responsiveness to security queries.
Change monitoring. Major changes at the vendor (acquisition, leadership change, infrastructure migration, new subcontractors) trigger reassessment.
Where Penetration Testing Fits in TPRM
Testing Your Own Third-Party Integrations
Your integration points with vendors are attack surface. API security testing of vendor integration endpoints validates that authentication, authorisation, data handling, and error handling are secure. Web application testing of vendor-facing portals ensures your systems don't leak data through vendor interfaces.
Testing Vendor Products
For critical vendors, exercise your right-to-audit clause to conduct independent penetration testing of the vendor's product or platform. This validates the vendor's security claims with independent evidence rather than relying on the vendor's self-assessment.
Reviewing Vendor Pentest Reports
When reviewing vendor-provided penetration testing reports, evaluate scope (did testing cover the systems processing your data?), methodology (was industry-standard methodology used? See our CREST guide), findings (what was found and was it remediated?), provider quality (who conducted the test?), and recency (was testing within the past 12 months?). For evaluating report quality, see our penetration testing reports guide and quality evaluation guide.
M&A and Vendor Acquisition
When a vendor is acquired, the acquiring company's security posture may differ significantly. Trigger reassessment when vendors undergo ownership changes. See our M&A pentesting guide.
TPRM for Compliance
SOC 2
Trust Services Criteria CC9.2 specifically addresses risk from business partners and vendors. SOC 2 auditors evaluate whether the organisation has a process for assessing and monitoring vendor security. TPRM is a direct audit requirement.
ISO 27001
Annex A.5.19 (Information Security in Supplier Relationships), A.5.20 (Addressing Information Security Within Supplier Agreements), A.5.21 (Managing Information Security in the ICT Supply Chain), and A.5.22 (Monitoring, Review and Change Management of Supplier Services) establish comprehensive supplier security management requirements.
PCI DSS
Requirement 12.8 mandates maintaining a list of service providers, written agreements with security requirements, due diligence before engagement, and annual monitoring of service provider compliance status.
HIPAA
The HIPAA Security Rule requires Business Associate Agreements (BAAs) with vendors processing ePHI. TPRM ensures BAAs are in place and vendors maintain adequate security.
GDPR
Article 28 requires data processors to implement appropriate security measures. Article 32 requires controller and processor to ensure security. TPRM ensures processors meet GDPR requirements.
NIST CSF
The Govern function (GV.SC) explicitly addresses Cybersecurity Supply Chain Risk Management. See our NIST CSF implementation guide.
DORA
DORA requires financial entities to manage ICT third-party risk through risk assessment, contractual controls, and ongoing monitoring. DORA requirements include specific obligations for critical ICT service providers.
For comprehensive compliance mapping, see our penetration testing compliance guide.
TPRM by Vendor Type
Cloud Service Providers (AWS, Azure, GCP)
Shared responsibility. Cloud providers secure the infrastructure. You secure your configuration, access, and data. The cloud security testing you conduct validates your side. The provider's SOC 2/ISO 27001 validates theirs.
What to assess: Shared responsibility model documentation. Compliance certifications. Incident notification procedures. Data residency options. Encryption key management options. See our cloud security assessment guide.
SaaS Platforms
What to assess: Multi-tenant isolation. Data encryption. Authentication options (SSO, MFA). API security. Compliance certifications. Data portability. Breach notification SLA. See our SaaS compliance guide.
Managed Security Service Providers
What to assess: SOC capabilities. Staff qualifications. Data handling for your security telemetry. Incident escalation procedures. Technology stack security. Their own security posture (who watches the watchers?).
Payment Processors
What to assess: PCI DSS compliance level. Transaction security. PCI DSS scope impact on your environment. Integration security. Fraud detection capabilities.
Software Vendors
What to assess: Secure development practices. Vulnerability management programme. Patch release cadence. Security testing programme. Open-source dependency management. See our supply chain security guide.
Building the TPRM Programme
Programme Components
Policy. Third-party risk management policy defining scope, roles, assessment requirements, and risk acceptance authority.
Inventory. Centralised vendor register with classification, assessment status, contract details, and risk rating.
Assessment process. Standardised questionnaires, evidence review procedures, and risk rating methodology.
Contractual templates. Standard security clauses for vendor agreements. Tiered templates matching vendor risk classification.
Monitoring programme. Scheduled reassessment cadence. Continuous external monitoring. Breach notification tracking.
Reporting. Regular reporting to leadership on TPRM programme status, vendor risk distribution, and emerging concerns.
Roles and Responsibilities
TPRM programme owner. Security team member responsible for the programme's operation and improvement.
Business relationship owners. Each vendor should have an internal business owner responsible for the vendor relationship and accountable for managing identified risks.
Procurement. Integrate security assessment into the procurement process. No vendor onboarded without security assessment.
Legal. Ensure security clauses are included in all vendor contracts.
Security team. Conduct assessments, review evidence, rate risk, monitor vendors, and provide guidance.
Implementation Roadmap
Month 1 to 2: Foundation. Create TPRM policy. Build vendor inventory. Define risk tiers and assessment criteria.
Month 3 to 4: Critical vendors. Assess all critical (Tier 1) vendors. Review existing contracts for security clause gaps. Establish right-to-audit where missing.
Month 5 to 8: High vendors. Assess all high (Tier 2) vendors. Implement continuous monitoring for critical and high vendors.
Month 9 to 12: Programme maturity. Assess medium vendors. Integrate TPRM into procurement workflow. Implement vendor risk dashboard. Establish annual reassessment cycle.
Ongoing. Continuous monitoring. Annual reassessment. Programme improvement based on incidents and lessons learned. Regular reporting to leadership.
TPRM Assessment Checklist
Vendor Inventory
- Complete vendor inventory maintained
- Every vendor classified by risk tier (critical, high, medium, low)
- Shadow IT / unapproved vendors identified and classified
- Vendor business owners assigned for every critical and high vendor
- Vendor inventory reviewed and updated quarterly
Assessment Process
- Standardised questionnaire for each risk tier
- SOC 2 Type II reports reviewed for critical vendors
- ISO 27001 certificates verified for applicable vendors
- Penetration testing reports reviewed for critical vendors
- Compliance certification currency verified
- Data handling practices evaluated
- Incident response capability assessed
- Business continuity documentation reviewed
- Subcontractor (fourth-party) management assessed
Contractual Controls
- Security requirements clause in all vendor contracts
- Data handling and privacy clause included
- Breach notification clause with defined timeline (72 hours or less)
- Right-to-audit clause for critical vendors
- Compliance maintenance requirement clause
- Subcontractor approval clause
- Data return and deletion clause for contract termination
- Liability and indemnification for security incidents
Ongoing Monitoring
- Annual reassessment for critical and high vendors
- Breach monitoring active (dark web, news, threat intel)
- Compliance certification expiration tracked
- External security rating monitored (SecurityScorecard, BitSight)
- Vendor change triggers reassessment (acquisition, leadership, infrastructure)
- Vendor incident tracking operational
- TPRM dashboard reporting to leadership quarterly
Integration Testing
- API security testing of vendor integration endpoints
- Authentication security at integration boundaries validated
- Data flow between systems tested for exposure
- Error handling at integration points tested
- Vendor-facing portals tested through web application testing
Common TPRM Mistakes
Mistake 1: Assessing once, never again. Vendor security changes. Annual reassessment for critical vendors is the minimum. Without ongoing monitoring, you're relying on a point-in-time snapshot that degrades immediately.
Mistake 2: Treating all vendors equally. Risk-tiered assessment focuses resources where they matter most. Applying the same deep assessment to 500 vendors is neither feasible nor necessary.
Mistake 3: No contractual enforcement. Assessment without contractual requirements is advisory. If the vendor has no contractual obligation to maintain security controls, your assessment findings are suggestions, not requirements.
Mistake 4: Ignoring fourth parties. Your vendor's vendors process your data too. A critical vendor using an insecure subcontractor introduces risk you didn't assess.
Mistake 5: No integration testing. Assessing the vendor's security doesn't validate your integration's security. Your API connections, data exchanges, and authentication at integration boundaries need testing independently.
How AppSecure Supports TPRM
AppSecure provides the security testing that strengthens every stage of your TPRM programme.
Vendor Integration Testing. API penetration testing of vendor integration endpoints validates that your connections to third parties are secure. Authentication, authorisation, data handling, and error handling tested at every integration boundary.
Independent Vendor Assessment. When exercising right-to-audit clauses, AppSecure conducts independent penetration testing of vendor products, validating security claims with technical evidence.
Your Own Security Posture. Comprehensive testing of your systems: web application, API, cloud, network (external and internal), and mobile. Your vendors assess your security just as you assess theirs. Strong testing results strengthen your position.
Application security assessment and offensive security testing for comprehensive coverage. Compliance-mapped reports serving SOC 2, ISO 27001, PCI DSS, and other frameworks.
Zero False Positives. 3-Week Delivery. 90-day support. Complimentary retesting. Continuous testing and PTaaS for ongoing validation.
Contact AppSecure:
Frequently Asked Questions
1. What is third-party risk management (TPRM)?
Third-party risk management is the systematic process of identifying, assessing, monitoring, and mitigating cybersecurity risks introduced by vendors, suppliers, and partners. TPRM covers every third party with access to your data, systems, or network. It includes vendor inventory and classification, security assessment, contractual security requirements, ongoing monitoring, and risk-based decision-making about vendor relationships. TPRM is a regulatory requirement across most compliance frameworks.
2. Why is TPRM important for cybersecurity?
Each vendor with access to your data or systems extends your attack surface. Supply chain attacks compromise trusted vendors to reach their customers. When a vendor breach exposes your customer data, regulatory penalties and reputational damage apply to you, not the vendor. The average enterprise depends on hundreds of third parties. Without TPRM, you have unmanaged attack surface through every vendor relationship.
3. How do you assess third-party security risk?
Use a risk-tiered approach. Critical vendors (sensitive data access, production systems) receive full assessment: detailed questionnaire, SOC 2 report review, pentest report review, and potentially independent testing. High vendors receive questionnaire and compliance evidence. Medium vendors receive abbreviated assessment. Low vendors receive minimal or no assessment. Assessment evaluates governance, technical controls, data handling, incident response, business continuity, and compliance.
4. What is vendor risk tiering?
Vendor risk tiering classifies vendors by the risk they introduce to your organisation. Factors include data sensitivity (does the vendor access sensitive data?), system access (does the vendor connect to your network or systems?), business criticality (would vendor failure disrupt your operations?), and replaceability (can you switch vendors quickly?). Tiering determines assessment depth: critical vendors receive the most thorough evaluation. Not all vendors need the same scrutiny.
5. What should vendor contracts include for security?
Essential clauses include minimum security control requirements, data handling and privacy obligations, breach notification timeline (72 hours or less), right to audit the vendor's security, compliance certification maintenance, subcontractor notification or approval, data return and deletion on termination, and liability allocation for security incidents. Without contractual requirements, security expectations are unenforceable.
6. How does penetration testing support TPRM?
Penetration testing supports TPRM in three ways: testing your own integration endpoints with vendors (validating that API connections, data exchanges, and authentication boundaries are secure), conducting independent testing of vendor products under right-to-audit clauses (validating vendor security claims with technical evidence), and reviewing vendor-provided penetration testing reports (evaluating whether the vendor's own testing was adequate in scope, methodology, and findings remediation).
7. Which compliance frameworks require TPRM?
SOC 2 (CC9.2 vendor risk management), ISO 27001 (Annex A.5.19-5.22 supplier security), PCI DSS (Requirement 12.8 service provider management), HIPAA (Business Associate Agreement requirements), GDPR (Article 28 processor requirements), NIST CSF (GV.SC supply chain risk management), and DORA (ICT third-party risk management). Virtually every compliance framework now includes third-party risk management requirements.
8. How often should vendors be reassessed?
Critical vendors: annually at minimum, with continuous external monitoring. High vendors: annually. Medium vendors: every two years or when changes occur. All vendors: immediately upon breach notification, acquisition, significant leadership change, or major infrastructure modification. The reassessment cadence should match the risk tier. Continuous monitoring tools (SecurityScorecard, BitSight) supplement periodic reassessment with ongoing external visibility.
9. What is fourth-party risk?
Fourth-party risk comes from your vendors' vendors. Your critical SaaS vendor may use a cloud hosting provider (fourth party) that has security weaknesses. A breach of the fourth party can expose your data through your vendor. TPRM programmes should require critical vendors to disclose their significant subcontractors, demonstrate they assess subcontractor security, and notify you when subcontractors change. Fourth-party visibility is increasingly expected by auditors.
10. How do I start building a TPRM programme?
Start with vendor inventory: list every third party with access to data or systems. Classify by risk tier. Assess critical vendors first (SOC 2 review, questionnaire, pentest report review). Add security clauses to vendor contracts during renewal cycles. Implement breach monitoring for critical vendors. Build the programme outward from critical vendors over 6 to 12 months. Integrate security assessment into procurement so new vendors are assessed before onboarding. Report programme status to leadership quarterly.