# Vendor Compliance Review SOP — [Company name]

Template status: [Draft / In review / Approved] · Applies from: [date]

## Purpose

Decide, on evidence rather than familiarity, whether a supplier may be engaged
and what conditions attach, and make sure the same decision is revisited on a
schedule instead of being made once at purchase and never looked at again.

## Scope

New vendor requests and scheduled re-reviews for suppliers that process company
or customer data, hold system access, or are relied on for a service the
business cannot immediately replace.

Out of scope: one-off purchases below [amount] with no data access and no system
access, and the commercial negotiation itself ([Procurement SOP]).

## Owner

Accountable: [Vendor Risk Lead].
Supporting: [Requesting Manager] for business need, [Security Contact] for
technical review, [Legal Contact] for contract terms, [Finance] for onboarding
to the payment system.

## Trigger

Event: a vendor request is submitted by a [Requesting Manager], or an existing
vendor's scope changes to include data or system access.

Scheduled: the re-review date set at the last decision (see D4), plus an
immediate review on receipt of a breach notification from the vendor (→ E5).

## Inputs

| Input | System of record | Required |
| --- | --- | --- |
| Business case: what the vendor does and what breaks without them | [Request form] | Yes |
| Data the vendor will process, by category and volume | [Request form] | Yes |
| System access requested, by scope | [Request form] | Yes |
| Completed security questionnaire | [Vendor risk register] | Tier-dependent |
| Certifications and audit reports with expiry dates | Vendor-supplied | Tier-dependent |
| Insurance certificate | Vendor-supplied | If contract value ≥ [amount] |
| Subprocessor list and hosting locations | Vendor-supplied | If data is processed |
| Sanctions and denied-party screening result | [Screening source] | Yes |

## Prerequisites

- A written data classification scheme, so "what data will they touch" has a
  defined answer rather than a judgement call per request.
- A current register with every existing vendor, their tier and their next
  review date. A review process with no register only ever reviews new vendors.
- Named [Security Contact] and [Legal Contact] with capacity inside the SLA.
- The standard data processing agreement and the list of terms that may not be
  varied without [Legal Contact].

## Steps

1. **Check the register first.** The vendor may already be engaged by another
   team under different terms. Duplicate engagements are the most common finding
   in a first pass over a register.
2. **Validate the business case.** What is the vendor doing, who owns the
   relationship, and what happens to the business if they stop tomorrow. An
   answer of "we would be fine" changes the tier; an answer of "we would stop
   trading" changes the exit plan.
3. **Classify the data and access.** → Decision **D1**. This is the single input
   that drives the depth of everything after it.
4. **Assign the risk tier.** → Decision **D2**. Record the reason, because the
   tier is what a future auditor will question.
5. **Run sanctions and denied-party screening** on the legal entity and its
   stated ultimate parent. A positive hit stops the process (→ E4); it is not a
   condition to be negotiated.
6. **Collect the evidence for that tier.** Certifications with expiry dates,
   most recent audit report, penetration-test summary, insurance certificate,
   subprocessor list, hosting regions, incident-notification commitment.
7. **Check every certificate's validity date, not its existence.** An expired
   certificate is an exception (→ E1), not a tick.
8. **Review the subprocessor list against the data classification.** A
   subprocessor in a location or category the classification does not permit is
   a condition of engagement or a rejection, never a footnote.
9. **Review contract terms** against the standard set: notification window for
   incidents, audit rights, deletion on termination, liability cap, exit
   assistance. → Approval **A2** for any variation.
10. **Reach a decision.** → Decision **D3**: accept, accept with named
    conditions and owners, or reject. Conditions without an owner and a date are
    not conditions.
11. **Record the decision and set the next review date.** → Decision **D4**.
12. **Only then onboard to payment.** Bank details are verified by [Finance]
    against a source that is not the email containing them, and by a person who
    did not request the vendor.

## Decisions

| ID | Decision | Criteria | Default |
| --- | --- | --- | --- |
| D1 | Data class | None / internal-only / customer personal data / special category or regulated data | Assume customer personal data until evidenced otherwise |
| D2 | Risk tier | Tier 1: special category data, or production system access, or no viable replacement. Tier 2: customer personal data or limited system access. Tier 3: no data, no access, replaceable. | Tier 2 |
| D3 | Engagement decision | Evidence complete for tier, no unresolved high finding, terms acceptable | Accept with conditions |
| D4 | Re-review interval | Tier 1: [12] months. Tier 2: [24] months. Tier 3: on renewal. Any tier: immediately on breach notification or scope change. | Tier interval |
| D5 | Conditions may be waived | Never for Tier 1 findings; Tier 2 and 3 only with approval **A3** and a stated end date | No waiver |

## Exceptions

- **E1 — Certificate expired or expiring within [60] days.** Accept only with a
  condition naming the renewal date and an owner who will check it. Record the
  gap; do not treat the previous year's certificate as current evidence.
- **E2 — Vendor declines to complete the questionnaire.** Escalate to
  [Requesting Manager] and [Vendor Risk Lead]. For Tier 1 and 2 this is a
  rejection unless an equivalent audit report covers the same ground.
- **E3 — Sole-source vendor with material findings.** Do not silently accept.
  Document the dependency, agree compensating controls with [Security Contact],
  set a shorter re-review, and obtain approval **A4** at executive level.
- **E4 — Sanctions or denied-party hit.** Stop. Escalate to [Legal Contact]
  immediately. No engagement, no payment, and no further correspondence without
  legal direction.
- **E5 — Breach notification received from an engaged vendor.** Trigger an
  immediate re-review, notify [Security Contact] and [Legal Contact] within [24]
  hours, and assess whether your own notification obligations are engaged.
- **E6 — Vendor changes its subprocessors or hosting region after engagement.**
  Treat as a scope change: re-run steps 8 to 11, do not wait for the scheduled
  review.
- **E7 — Bank detail change request mid-engagement.** Never actioned from an
  email or a portal message alone. Verify out of band with a known contact using
  details already on file.

## Approvals

| ID | What is approved | Who approves | Why it stays with a person |
| --- | --- | --- | --- |
| A1 | Engagement of a Tier 1 vendor | [Vendor Risk Lead] with [Security Contact] | Highest exposure to data and continuity risk |
| A2 | Variation to standard contract terms | [Legal Contact] | Contractual liability |
| A3 | Waiver of a condition | [Vendor Risk Lead] with a stated end date | A waiver with no end date becomes a permanent gap |
| A4 | Accepting a sole-source vendor with material findings | [Executive sponsor] | Accepting residual risk on behalf of the business |
| A5 | Adding vendor bank details to the payment system | [Finance] second person, out-of-band verified | Payment fraud is committed at exactly this step |

## Output

- A register entry per vendor: tier, decision, evidence with expiry dates,
  conditions with owners and dates, and the next review date.
- A decision record naming who approved what and on what evidence.
- A conditions worklist that is reviewed [monthly], not at renewal.
- Payment-system onboarding only after A5.

## SLA / KPI

- Decision within [10] business days of a complete submission: target [90%].
- Vendors past their re-review date: target zero.
- Open conditions past their due date: target zero, reported [monthly].
- Percentage of Tier 1 vendors with in-date evidence on file: [100%].

## Audit record

Retain for the engagement term plus [6] years: the request, the classification
and tier with reasons, all evidence documents with their validity dates, the
screening result, the decision record and its approvals, every condition with
its owner, due date and closure evidence, and every scope change or breach
notification with the resulting re-review.

> Simulated example data
>
> Vendor [Kestrel Analytics BV] · requested by [Marketing] · D1 → customer
> personal data, no special category · system access: [read-only API], so
> D2 → **Tier 2** · questionnaire complete, [ISO 27001] certificate valid to
> [2027-01-31], subprocessor list shows one processor in a region not covered by
> the current transfer mechanism → D3 = accept with conditions: transfer
> mechanism confirmed by [Legal Contact], owner [Vendor Risk Lead], due
> [2026-08-15]. Next review [2028-07]. A5 bank verification completed by
> [Finance] by phone to a number already on file.

## Revision log

| Version | Date | Author | Change |
| --- | --- | --- | --- |
| v1.0 | 2026-07-24 | [Your name] | initial draft |