Control Definition
The organization must define and operate processes and procedures for managing the information security risks that come with using suppliers' products and services. In practice that means deciding which types of suppliers it deals with, what security requirements apply to each, how suppliers are evaluated and selected, and how every relationship is handled from onboarding through exit.
Control Objective
To maintain an agreed level of information security in supplier relationships by managing the risks suppliers introduce when they access, process, store, or support the organization's information and systems.
What This Really Means
Your real security perimeter is not your network — it is the full set of organizations you have handed access to. The payroll bureau holding employee data, the MSP with standing VPN access, the analytics SaaS ingesting customer events, the dev shop committing to your repos: each one extends your attack surface, and an attacker evaluates them as alternative doors into you. A.5.19 exists because that exposure has to be managed as a program, not as a series of one-off judgment calls.
The control asks for four things in practice. First, know your suppliers: a maintained register recording who they are, what service they provide, what information and systems they touch, and who owns the relationship. Second, tier them by risk — the classification of data accessed, the depth of access, and how badly their failure would hurt — so effort lands where the exposure is. Third, run due diligence proportionate to the tier before access is granted: evidence review and a risk write-up for critical suppliers, a lighter check for the rest. Fourth, manage the whole lifecycle, including the exits — access revoked, data returned or destroyed, register updated.
It helps to see how the four supplier controls divide the labor. A.5.19 builds the program: register, tiering, due diligence, lifecycle. A.5.20 converts the requirements into binding contract clauses. A.5.21 looks past direct suppliers into the ICT supply chain beneath them. A.5.22 keeps the assurance current through ongoing reviews, re-verification, and change management. Cloud providers get specialized treatment in A.5.23, but the program logic for every supplier starts here.
Auditors treat the register and the tiering logic as the heart of this control. Expect them to pick a supplier onboarded in the last year and trace it backwards: who assigned the risk tier, what diligence ran before credentials or data flowed, where the assessment record lives, and whether the contract reflects the requirements. If that chain holds for a sampled supplier, the control is working; if the register itself is incomplete, nothing downstream can save it.
Why It Matters
Third parties are now among the most reliable entry points into otherwise well-defended organizations. Attackers route around hardened perimeters by compromising a smaller supplier with trusted access, and many of the most damaging publicly reported breaches of recent years began in a vendor's environment rather than the victim's. Every supplier with credentials, an integration, or a copy of your data is part of your attack surface whether or not anyone is managing it.
Accountability, meanwhile, never outsources. Data protection regulators, enterprise customers, and certification auditors all hold you responsible for what your processors and service providers do with your information — "our vendor failed" has never excused a missed notification deadline or a lost dataset.
Weak supplier risk management exposes you to:
- •Inherited breaches – a compromise inside a supplier becomes your incident, your notification duty, and your customer conversation
- •Regulatory accountability – privacy and sector regulators hold the organization that collected the data responsible, regardless of which processor failed
- •Shadow suppliers – tools bought on corporate cards create data flows and access paths nobody assessed
- •Lingering access – ended relationships leaving live credentials, API keys, and integrations behind
- •Audit findings – an incomplete or stale supplier register is one of the most commonly written nonconformities in the organizational controls
Regional Compliance Context
Under India's DPDP Act 2023, a data fiduciary may hand personal data to a data processor only under a valid contract, and the fiduciary stays responsible for whatever processing happens on its behalf — with full compliance obligations landing 13 May 2027, the supplier register should already flag which suppliers act as data processors. For banks, NBFCs, and other regulated entities, RBI's master directions on outsourcing add sharper expectations: documented risk assessment of material service providers before onboarding, retained accountability for outsourced functions, and tested exit strategies.
In the Gulf, the Saudi PDPL and the UAE federal PDPL follow the same controller-processor logic — processors must offer adequate safeguards and be bound by contract — so a tiering model that identifies personal-data processors works across India and Gulf operations without modification.
Implementation Guidance
Define the Supplier Security Policy and Assign Ownership
Write a topic-specific policy covering what counts as a supplier, when security assessment is mandatory, who can grant exceptions, and what must happen at exit. Name an accountable owner for the program — in most organizations the CISO owns the framework while procurement owns day-to-day execution, and the policy should say so explicitly.
Build a Complete Supplier Register
Maintain one register with supplier name, service description, information accessed and its classification, access type (network, API, physical, data transfer), relationship owner, risk tier, assessment status and date, and contract reference. Seed it from accounts payable and your SSO/IdP application list rather than from memory — finance data surfaces the suppliers nobody mentioned.
Define Risk Tiers with Objective Criteria
Tier suppliers on what they can touch and how much you depend on them: highest classification of data accessed, depth of system or network access, and operational criticality. Three tiers are enough for most organizations. Write the criteria down so two people tiering the same supplier reach the same answer, and require security sign-off on every critical-tier assignment.
Run Due Diligence Proportionate to the Tier
For critical suppliers: a security questionnaire plus evidence review (ISO 27001 certificate and SoA scope, SOC 2 Type II report) and a short risk write-up. For medium tiers: certificate review and a focused questionnaire. For low tiers: a terms-and-security-page sanity check. Record the outcome and the reviewer every time — an unrecorded review does not exist at audit time.
Gate Access on Completed Assessment
Wire the assessment into procurement and onboarding so a supplier cannot receive credentials, API keys, or data feeds before due diligence closes. Define the security requirements per supplier type at this stage and hand them to the contracting process (A.5.20) so they become enforceable clauses rather than onboarding folklore.
Prepare the People Who Run Supplier Relationships
Give each significant supplier a named relationship owner who knows its risk tier, what to escalate, and how supplier incidents enter your incident process. Brief procurement and vendor managers on the program annually — they are this control's first line of defense, not the security team.
Manage Exits and Re-Assessment
Use an offboarding checklist for every ended relationship: revoke access in the identity provider, retrieve or destroy data with written confirmation, update the register. Set a re-assessment cadence by tier — annually for critical suppliers, every two to three years below that — and track completions; the continuous monitoring between re-assessments belongs to A.5.22.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.19:
Documentation
- Supplier security policy or procedure defining tiers, assessment requirements, and lifecycle steps
- Supplier register showing services, data accessed, risk tiers, owners, and assessment dates
- Completed due diligence packs for sampled suppliers — questionnaires, certificate reviews, risk write-ups
- Records showing assessment completed before access was granted for recently onboarded suppliers
- Offboarding records for ended relationships, including access revocation and data return or destruction confirmation
Interviews
- Procurement or vendor management lead about how a new supplier is onboarded and whether anyone can bypass the security gate
- CISO or security manager about the tiering criteria and how assessment depth scales with risk
- A business relationship owner about a specific critical supplier — its risks, incidents, and most recent assessment
Observations
- Live walkthrough of the supplier register, cross-checked against the accounts payable vendor list for completeness
- Trace of one recently onboarded supplier from request through assessment to access grant
- Check in the identity provider that a terminated supplier's accounts and integrations were actually disabled
Practitioner Insights
The fastest test of this control is putting the supplier register next to twelve months of accounts payable data — the gap between the two is the shadow supplier population, and it is rarely zero. The second failure pattern I keep meeting is tiering that exists on paper but converges in practice: criteria so loose that every supplier lands in the low tier and a full assessment never triggers. If your register shows fifty suppliers and zero critical ones, an experienced auditor will not believe the tiering, and honestly neither should your management.
Smaller organizations sink this control by over-engineering it — a 200-question questionnaire that no supplier answers, so assessments quietly stop happening. Proportionate beats comprehensive: for most SaaS vendors, reading their SOC 2 report or trust center page and filing a dated three-paragraph conclusion is genuinely sufficient diligence. The evidence mistake I see most is collecting a certificate and filing it unread; auditors ask what you concluded from it, not whether you possess the PDF. Write down who reviewed it, when, and what you decided.
Common Challenges & Solutions
Challenge
Nobody can produce a complete supplier list — business units buy SaaS tools on corporate cards and IT discovers them months later.
Solution
Reconcile the supplier register quarterly against three sources: accounts payable, expense reports, and the SSO/IdP application list. Add a procurement hook requiring security review before any new vendor payment is set up. SaaS discovery tooling helps, but the finance reconciliation catches most of the shadow population for free.
Challenge
Suppliers ignore or half-answer long security questionnaires, and deals close before assessments finish.
Solution
Cut the questionnaire to what you will actually act on, and accept existing evidence — a current ISO 27001 certificate with relevant scope or a SOC 2 Type II report — in place of questionnaire sections. Make the gate structural rather than heroic: procurement cannot issue a purchase order until the assessment task closes, which converts internal sales pressure into pressure on the supplier to respond.
Challenge
Risk tiering is so subjective that every supplier ends up rated low-risk and deep assessments never trigger.
Solution
Tie tiers to objective, checkable facts: highest classification of data accessed, type of access (standing network access ranks above one-off file exchange), and operational dependency if the supplier fails. Publish worked examples for common cases — payroll provider, marketing SaaS, facilities vendor. Require security sign-off on tier assignments so the incentive to under-tier has a counterweight.
Challenge
Due diligence ran once at onboarding years ago and was never repeated, so the register reflects suppliers as they were, not as they are.
Solution
Add a next-assessment date column to the register and drive it by tier — annual for critical suppliers, a two-to-three-year cycle below that. Treat overdue re-assessments like overdue internal audit actions: tracked, reported, escalated. The continuous layer between re-assessments — certificate re-verification and service reviews — is A.5.22's job.
Challenge
Hyperscalers and large SaaS vendors will not fill in questionnaires or accept custom requirements.
Solution
Stop asking them to. For providers of that scale, base the assessment on their published audit reports, certifications, and shared-responsibility documentation, and record a documented conclusion. Your real work with these providers sits on your side of the shared responsibility line — configuration, access, and monitoring — which A.5.23 addresses for cloud services specifically.
