Implementing a Supplier Risk Management Program

Build a tiered supplier risk program — due diligence proportional to risk, contractual security clauses that mean something, ongoing monitoring, and a secure offboarding process.

Medium 55m 3 tasks

Prerequisites: Implementing a Secure Development Lifecycle

Learning Objectives

→ Tier suppliers by risk rather than treating them all identically
→ List the due diligence steps proportional to a high-risk supplier
→ Identify essential contractual security clauses
→ Explain what secure supplier offboarding requires beyond ending the contract

Foundation's supplier controls (5.19-5.23) covered what's expected. Implementation means building a program that scales — not every supplier deserves the same scrutiny, and a program that treats the office snack vendor identically to the cloud hosting provider either wastes effort on low-risk suppliers or, more dangerously, under-scrutinizes a high-risk one.

Tiering suppliers by risk, not alphabetically

A practical program starts by tiering suppliers based on what they actually touch:

Tier	Example	Due diligence depth
Critical	Cloud hosting provider, payment processor	Full security questionnaire, certification review, contractual audit rights, ongoing monitoring
Significant	SaaS tool processing customer data	Security questionnaire, certification review, standard contract clauses
Low	Office supplies vendor, marketing tool with no customer data access	Minimal — standard terms, no deep security review needed

The tiering criteria should trace back to the risk register (this roadmap, lesson 3): what data or access does this supplier have, and what's the impact if that access were misused or compromised? A supplier with no access to customer data or production systems simply doesn't warrant the same due diligence as one that does — treating them identically wastes scrutiny that should go toward genuinely higher-risk relationships.

Due diligence before onboarding

For Critical and Significant tier suppliers, due diligence typically includes:

A security questionnaire covering their own controls (often mapped loosely to Annex A themes)
Reviewing their relevant certifications (ISO/IEC 27001, SOC 2, or similar) — and, per Foundation's SoA lesson, actually verifying the certificate rather than just accepting a claim of certification
Assessing what happens to your data if their sub-suppliers (fourth-party risk) are compromised — a supplier's own supply chain is part of the risk picture too (Foundation, Annex A 5.21)

Contractual clauses that actually matter

A vendor contract with no security-specific language leaves the relationship governed only by general commercial terms. Essential clauses for Critical/Significant suppliers include:

Right to audit — the ability to review the supplier's security posture, directly or via accepted certifications, on an ongoing basis
Breach notification obligations — a specific timeframe (e.g., "within 72 hours of becoming aware") the supplier must notify you of an incident affecting your data
Data handling and return/destruction terms — what happens to your data during the relationship and, critically, when it ends
Sub-processor disclosure — the supplier must disclose (and ideally seek approval for) any fourth parties they share your data with

Ongoing monitoring, not a one-time check

Foundation's 5.22 explicitly requires monitoring supplier services over time, not just at onboarding. In practice this means: re-reviewing certifications at renewal (certifications expire), tracking the supplier's own security incident history, and reassessing the tier if the relationship's scope changes (e.g., a previously "Significant" supplier is given access to a new, more sensitive dataset).

Secure offboarding

When a supplier relationship ends, the risk doesn't automatically end with it. Secure offboarding requires: revoking the supplier's access to your systems (same discipline as the leaver stage from this roadmap's access control lesson), confirming — with evidence, not just a verbal assurance — that your data has been returned or securely destroyed per the contract's terms, and updating the risk register and SoA to reflect that this specific supplier risk no longer applies. An offboarded supplier who still has active credentials or an unreturned data copy six months later is a real, common finding — the relationship ending on paper doesn't mean the risk ended in practice.

A company uses: (a) a cloud hosting provider running its entire production environment, (b) a payroll processing SaaS tool with access to employee bank details, (c) a company that supplies office plants. Assign each to Critical, Significant, or Low tier, and justify each based on data/access exposure, not company size or contract value.

✦ Answer the questions to complete this task

Which tier does the payroll processing SaaS tool belong to, and why?

A company's contract with a Critical-tier cloud storage supplier includes pricing, service-level uptime guarantees, and a standard confidentiality clause — but nothing about what happens to the company's data if the contract is terminated. Six months after switching providers, the old provider still has a full copy of the data with no documented destruction. Identify the missing clause and its consequence.

✦ Answer the questions to complete this task

What specific contractual clause was missing that led to this outcome?

A supplier relationship formally ends per the contract's termination date. The supplier's system access credentials, however, are never explicitly revoked — they simply remain valid because no one specifically owns the task of disabling them. Explain why 'the contract ended' is not the same as 'the risk ended.'

✦ Answer the questions to complete this task

Why doesn't a contract ending automatically mean the associated security risk has ended too?