About this program
Most breaches reach you through someone else — a SaaS provider, a managed service, an integration partner. This assessment covers the full third-party lifecycle: due diligence before signing, contractual safeguards, ongoing monitoring, and exit planning. Aligned to ISO 27001 A.5.19–A.5.23, NIS2 Art 21.2(d), and SOC 2 vendor management controls.
Controls (14)
-
Do you maintain a complete inventory of third parties that access, process, or store your data?
MediumDo you maintain a complete inventory of third parties that access, process, or store your data?
How to test + evidence
Risk: You can't risk-manage what you can't see. Reconciling the register against finance and IDP catches the shadow-IT vendors that bypass procurement entirely.
Testing procedure: Pull the third-party register and reconcile to two independent sources: the AP/finance system (anyone you pay) and the IDP (any external user account or SSO connection). Investigate gaps in either direction.
Evidence to collect: Third-party / vendor register Procurement vendor master list IDP federation / SSO configurations Sample vendor entries with data classification + risk tier
-
Are vendors tiered by risk (data sensitivity, criticality, integration depth) so due diligence effort matches risk?
MediumAre vendors tiered by risk (data sensitivity, criticality, integration depth) so due diligence effort matches risk?
How to test + evidence
Risk: Without tiering you either over-burden low-risk vendors (procurement bottleneck) or under-scrutinise high-risk ones (audit finding). Risk-based effort is the only sustainable model.
Testing procedure: Review the tiering criteria. Sample 10 vendors and verify their tier matches the criteria (data classification, regulatory scope, business criticality). Check that Tier 1 vendors received deeper due diligence.
Evidence to collect: Vendor tiering policy with criteria Sample 10 tiered vendors with rationale documented Mapping of due-diligence depth to tier
-
Is security due diligence performed before contracting (not as an afterthought)?
MediumIs security due diligence performed before contracting (not as an afterthought)?
How to test + evidence
Risk: Post-signature due diligence is theatre — once you've committed, leverage to demand changes drops to near zero. Pre-contract is the only point of real influence.
Testing procedure: Sample 15 contracts signed in the audit period. For each, find the dated security review preceding signature. Verify the reviewer had appropriate authority.
Evidence to collect: Procurement workflow showing security gate Sample 15 contracts with pre-signature security reviews Sign-off authority matrix
-
Do you require a security questionnaire (SIG, CAIQ, custom) for Tier 1 / Tier 2 vendors?
MediumDo you require a security questionnaire (SIG, CAIQ, custom) for Tier 1 / Tier 2 vendors?
How to test + evidence
Risk: Questionnaires without evidence verification are self-attestation, which auditors discount. Verifying SOC 2 / ISO / pen test reports turns questionnaires into a real control.
Testing procedure: Sample Tier 1 vendors. Verify a completed questionnaire exists, was reviewed by a named owner, and supporting evidence (penetration test summaries, SOC 2 reports, ISO certificates) was inspected — not just received.
Evidence to collect: Standardised questionnaire (SIG Lite, CAIQ, or custom) Sample completed responses with reviewer name Linked supporting evidence per material claim
-
Do you collect and review certifications (ISO 27001, SOC 2, PCI DSS) before onboarding Tier 1 vendors?
MediumDo you collect and review certifications (ISO 27001, SOC 2, PCI DSS) before onboarding Tier 1 vendors?
How to test + evidence
Risk: Certifications are useful only when their reports are read. SOC 2 reports list complementary user entity controls (CUECs) — your team must implement them or the certification is moot.
Testing procedure: Sample 10 Tier 1 vendors. For each, find the most recent SOC 2 Type II report or ISO 27001 statement of applicability. Verify the audit period is current and that exceptions were reviewed by your team.
Evidence to collect: Vendor SOC 2 Type II reports (current period) Vendor ISO 27001 certificates + Statement of Applicability Internal review notes per report (exceptions, CUECs)
-
Do contracts include standard security clauses (right to audit, breach notification, data return/destruction, sub-processor controls)?
MediumDo contracts include standard security clauses (right to audit, breach notification, data return/destruction, sub-processor controls)?
How to test + evidence
Risk: These clauses are the only contractual leverage you have during a real incident. Breach-notification SLAs in particular are non-negotiable for GDPR/NIS2/SOC 2 compliance.
Testing procedure: Sample 10 contracts. Check for: breach notification SLA (typically 72 hours), audit rights, data return/deletion on termination, sub-processor disclosure, location of processing, security obligations referencing a standard (ISO 27001/SOC 2).
Evidence to collect: Standard security schedule template Sample 10 contracts containing the schedule Process for legal review of any deviation
-
Are Data Processing Agreements (DPAs) in place for vendors processing personal data?
MediumAre Data Processing Agreements (DPAs) in place for vendors processing personal data?
How to test + evidence
Risk: DPA absence is a per-incident regulatory finding under GDPR. The fines compound if you can't even point to the legal basis for the data flow.
Testing procedure: Identify all vendors processing personal data of EU/UK residents. For each, locate the executed DPA. Verify GDPR Art 28 elements: nature of processing, types of data, technical and organisational measures, sub-processor consent, transfer safeguards.
Evidence to collect: DPA template aligned to GDPR Art 28 Executed DPAs per personal-data processor Sub-processor lists + change-notification process Transfer mechanism documentation (SCCs / IDTAs)
-
Do contracts specify a breach notification SLA short enough to meet your own regulatory obligations?
MediumDo contracts specify a breach notification SLA short enough to meet your own regulatory obligations?
How to test + evidence
Risk: Under GDPR you have 72 hours to notify the regulator. If your vendor takes 7 days to tell you, you're already in breach of your own obligations.
Testing procedure: Sample 10 contracts. Confirm explicit notification timeline. Verify your own GDPR/NIS2 obligation (72 hours from awareness) can still be met given the vendor SLA + your investigation time.
Evidence to collect: Sample contracts with explicit notification clauses Map of vendor SLA → your regulatory clock Internal escalation playbook for vendor breach notifications
-
Are Tier 1 vendors reassessed at least annually (refreshed questionnaire, updated certs, security ratings)?
MediumAre Tier 1 vendors reassessed at least annually (refreshed questionnaire, updated certs, security ratings)?
How to test + evidence
Risk: Vendor security degrades silently — staff turn over, sub-processors change, certifications lapse. Annual reassessment is the minimum sustainable cadence for material vendors.
Testing procedure: Sample 10 Tier 1 vendors that have been onboarded for over a year. Verify a completed reassessment within the last 12 months — questionnaire, current certifications, change in sub-processors, breach history.
Evidence to collect: Reassessment schedule per tier Sample 10 completed reassessments within 12 months Trigger events that force out-of-cycle review
-
Do you monitor vendors for breach disclosures, security ratings drops, or threat-intel signals?
MediumDo you monitor vendors for breach disclosures, security ratings drops, or threat-intel signals?
How to test + evidence
Risk: Vendors' breach disclosures are rarely proactive. Independent monitoring catches issues earlier and gives you grounds to escalate before damage spreads.
Testing procedure: Inspect monitoring tooling (BitSight, SecurityScorecard, UpGuard, or manual feeds). Verify alerts trigger reviews. Sample 5 recent vendor events (CVE in vendor product, public breach) and trace the response.
Evidence to collect: Security-rating tool subscription + watchlist Breach-notification feed (e.g. HIBP for Business) Sample vendor incidents with documented response
-
Are vendor user accounts and integrations reviewed at the same cadence as employees?
MediumAre vendor user accounts and integrations reviewed at the same cadence as employees?
How to test + evidence
Risk: Forgotten vendor accounts (ex-MSP admins, decommissioned integration tokens) are a top initial-access vector for ransomware. Quarterly review catches them.
Testing procedure: Pull all federated/external accounts and integration tokens. For each, identify the responsible vendor and the last access review. Verify privileged vendor access (e.g. domain admin) is reviewed quarterly.
Evidence to collect: List of vendor user accounts + integration credentials Last-reviewed timestamp per account Sample reviews showing manager + system-owner sign-off
-
Do you have a documented exit plan for Tier 1 vendors (data return, transition timeline, alternate provider)?
MediumDo you have a documented exit plan for Tier 1 vendors (data return, transition timeline, alternate provider)?
How to test + evidence
Risk: Untested exit plans fail when actually needed. Even a tabletop walkthrough catches missing data formats and unrealistic timelines before they become a crisis.
Testing procedure: Sample 5 Tier 1 vendors. For each, request the exit plan. Inspect for: contractual termination assistance, data export format and retention, transition timeline, alternate-provider analysis.
Evidence to collect: Exit plan template Sample 5 Tier 1 vendor exit plans Last test/walkthrough of an exit plan
-
Do you assess and manage concentration risk (multiple critical functions in one vendor or one vendor's sub-processor)?
MediumDo you assess and manage concentration risk (multiple critical functions in one vendor or one vendor's sub-processor)?
How to test + evidence
Risk: A single-vendor failure (CrowdStrike July 2024, Okta repeated incidents) takes down everything that depends on it. Concentration analysis surfaces this risk before it lands.
Testing procedure: Inspect the vendor concentration analysis. Identify any vendor responsible for more than one of: identity, communications, billing, customer data, or critical infrastructure. Verify mitigation (e.g. failover, second supplier) for each concentration.
Evidence to collect: Concentration risk register Mitigation plans per concentrated vendor Sub-processor map showing 4th-party dependencies
-
Do you review and approve material sub-processors (vendor of your vendor) before they handle your data?
MediumDo you review and approve material sub-processors (vendor of your vendor) before they handle your data?
How to test + evidence
Risk: A breach in your vendor's vendor still hits you. GDPR and NIS2 expect you to know who's downstream — "the vendor handled it" is no defence.
Testing procedure: Sample 10 vendors processing personal or confidential data. Inspect their sub-processor list and confirm each is in scope of your DPA / contract. Check for change-notification process and your right of objection.
Evidence to collect: Sub-processor lists per material vendor DPA clauses giving change-notification + objection right Sample notifications received + reviewed