# Vendor / Sub-processor Due-Diligence Checklist

_The questionnaire Cyntech uses to assess third parties before they touch client data._
_Shared under CC BY 4.0 — adapt freely for your own programme._

---

## 1. Vendor profile

- Legal entity name and registered office
- Primary contact (commercial) and primary contact (security)
- Years in operation, ownership, recent funding events
- Public references / case studies in our sector

## 2. Service scope

- What data categories will the vendor process for us? (PII / financial / health / OT telemetry / client confidential)
- What volumes (records, GB) and frequencies?
- What is the processing purpose, and is it documented in the contract?
- Will the vendor act as a processor, sub-processor, or independent controller?

## 3. Certifications & attestations

Tick those held and attach evidence (audit letter, certificate, SOC report):

- [ ] ISO 27001:2022
- [ ] ISO 27017 (cloud)
- [ ] ISO 27018 (PII in public cloud)
- [ ] ISO 27701 (privacy)
- [ ] SOC 2 Type II (current period)
- [ ] PCI DSS Level 1 (if handling card data)
- [ ] HIPAA / HITRUST (if applicable)
- [ ] Cyber Essentials / Cyber Essentials Plus

## 4. Data protection

- Privacy policy URL and last-updated date
- DPA available before contract signature?
- Standard Contractual Clauses 2021 + UK Addendum in place?
- Transfer Impact Assessment provided?
- Named DPO / Information Officer and contact details
- Breach-notification SLA to controllers (target: ≤72h)

## 5. Sub-processors

- Public, dated sub-processor list with locations and transfer mechanisms?
- Change-notification mechanism with right to object?
- Flow-down of controller obligations to sub-processors?

## 6. Security controls

- Encryption: in transit (TLS version), at rest (algorithm, key management)
- Identity & access: SSO, MFA, RBAC, least privilege, JIT access
- Network: segmentation, WAF, DDoS, egress restrictions
- Application: SDLC, code review, dependency scanning, SAST/DAST/SCA
- Vulnerability mgmt: patch SLAs by severity, public vulnerability disclosure policy
- Endpoint: MDM, EDR, full-disk encryption on workstations
- Logging & monitoring: centralised logs, retention, SOC coverage hours
- Backup & DR: RPO/RTO targets, last successful DR test date

## 7. Incident response

- Documented IR runbook, last tested date
- Public incident history (any reportable breach in the last 3 years?)
- Customer notification template available?
- Contractual cooperation with our IR and our regulator notifications?

## 8. Personnel

- Background checks on staff with data access?
- Mandatory security & privacy training, frequency?
- Joiners-movers-leavers process documented?
- Access reviews cadence?

## 9. Resilience

- Hosting region(s) — confirm match to our data-residency commitments
- Multi-AZ / multi-region failover?
- Published SLA and historical uptime?
- Insurance: cyber liability and professional indemnity cover and limits?

## 10. Exit & deletion

- Data deletion SLA on termination (target: ≤30 days)
- Certificate / attestation of deletion?
- Data export format and assistance during transition?

## 11. AI use

- Does the vendor train models on our data? (Required answer: no)
- Where are inference endpoints hosted?
- Logging and retention of prompts and completions?
- Sub-processor AI providers disclosed?

## 12. Scoring & decision

| Section | Score (1–5) | Notes |
| --- | --- | --- |
| Profile | | |
| Data protection | | |
| Security controls | | |
| Incident response | | |
| Resilience | | |
| Exit | | |
| **Overall** | | |

**Approver:** _________________________  **Date:** _________________

**Decision:** Approve / Approve with conditions / Reject

**Review interval:** Annually / On material change / On regulator advisory