Third-Party / Vendor Risk

About this program

Controls (14)

1. Do you maintain a complete inventory of third parties that access, process, or store your data?

   Medium

   This control requires the organization to maintain a current, comprehensive inventory of all third-party vendors, service providers, contractors, and partners who have access to, process, transmit, or store organizational data. The inventory should include identifying details such as vendor name,…

   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

2. Are vendors tiered by risk (data sensitivity, criticality, integration depth) so due diligence effort matches risk?

   Medium

   Vendor risk tiering is a systematic classification of third-party vendors into risk categories (e.g., critical, high, medium, low) based on factors such as the sensitivity of data they access, the criticality of services they provide, and the depth of technical…

   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

3. Is security due diligence performed before contracting (not as an afterthought)?

   Medium

   Security due diligence is a structured evaluation process conducted during vendor selection and contract negotiation, before legal commitment, to assess third-party security posture, compliance status, regulatory alignment, and risk exposure. This process includes reviewing security questionnaires, certifications (SOC 2, ISO…

   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

4. Do you require a security questionnaire (SIG, CAIQ, custom) for Tier 1 / Tier 2 vendors?

   Medium

   This control mandates that organizations require third-party vendors classified as Tier 1 (critical/high-risk) or Tier 2 (moderate-risk) to complete standardized security questionnaires such as the Standardized Information Gathering (SIG) questionnaire, Consensus Assessments Initiative Questionnaire (CAIQ), or custom security assessments prior…

   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

5. Do you collect and review certifications (ISO 27001, SOC 2, PCI DSS) before onboarding Tier 1 vendors?

   Medium

   This control establishes a vendor risk management process requiring collection and review of relevant security certifications (ISO 27001, SOC 2, PCI DSS) prior to engaging Tier 1 vendors—those with access to critical systems, sensitive data, or who provide mission-critical services.…

   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)

6. Do contracts include standard security clauses (right to audit, breach notification, data return/destruction, sub-processor controls)?

   Medium

   This control ensures that all third-party vendor and service provider contracts include mandatory security clauses protecting organizational data and rights. Standard clauses must cover the right to audit security controls, mandatory breach notification timelines, procedures for secure data return or…

   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

7. Are Data Processing Agreements (DPAs) in place for vendors processing personal data?

   Medium

   Data Processing Agreements (DPAs) are legally binding contracts required under privacy regulations (GDPR, CCPA, etc.) that define the scope, purpose, and responsibilities when third-party vendors process personal data on behalf of the organization. These agreements establish data protection obligations, specify…

   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)

8. Do contracts specify a breach notification SLA short enough to meet your own regulatory obligations?

   Medium

   This control ensures that third-party contracts include explicit breach notification service level agreements (SLAs) that allow the organization to meet its own regulatory reporting obligations. For example, if GDPR requires 72-hour breach notification to supervisory authorities, vendor contracts must specify…

   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

9. Are Tier 1 vendors reassessed at least annually (refreshed questionnaire, updated certs, security ratings)?

   Medium

   This control ensures that vendors classified as Tier 1 (highest risk or criticality) undergo a comprehensive annual reassessment of their security posture. The reassessment includes requesting updated security questionnaires, collecting current compliance certifications (SOC 2, ISO 27001, etc.), and reviewing…

   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

10. Do you monitor vendors for breach disclosures, security ratings drops, or threat-intel signals?

    Medium

    This control establishes continuous monitoring of third-party vendors for security incidents, breach disclosures, deteriorating security posture, and threat intelligence indicators. Organizations subscribe to breach notification feeds, security rating services (e.g., SecurityScorecard, BitSight), and threat intelligence platforms that track vendor-related indicators…

    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

11. Are vendor user accounts and integrations reviewed at the same cadence as employees?

    Medium

    This control requires that vendor-owned user accounts, service accounts, API keys, and third-party integrations undergo periodic access reviews at the same frequency as internal employee accounts. Organizations often implement quarterly or semi-annual user access reviews for employees but neglect vendor…

    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

12. Do you have a documented exit plan for Tier 1 vendors (data return, transition timeline, alternate provider)?

    Medium

    This control requires documented exit plans for Tier 1 (critical/high-impact) vendors that specify data return procedures, transition timelines, and identification of alternate providers. Exit plans enable organizations to terminate vendor relationships without operational disruption, data loss, or vendor lock-in. These…

    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

13. Do you assess and manage concentration risk (multiple critical functions in one vendor or one vendor's sub-processor)?

    Medium

    This control requires organizations to identify, assess, and actively manage concentration risk arising from vendor relationships, particularly when multiple critical business functions or sensitive data processes depend on a single vendor or its sub-processors. Organizations must inventory all vendor dependencies,…

    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

14. Do you review and approve material sub-processors (vendor of your vendor) before they handle your data?

    Medium

    This control requires organizations to establish and enforce a formal review and approval process for material sub-processors—third parties engaged by primary vendors to handle, store, or process organizational data. Before a vendor may onboard a sub-processor with access to sensitive…

    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