ISO 27001 Annex A 5.19 – Information Security in Supplier Relationships

Control 5.19 starts with a supplier-relationships policy, but that policy only counts if you can show, for any given supplier, that the right controls were chosen and applied before it could reach your information or systems. A common way an auditor tests this is by sampling: name a supplier, and demonstrate that its level of access, the risk it carries, and the safeguards around it were all decided deliberately rather than by default.

In practice the control asks you to know your supplier population, classify it by the sensitivity of what each supplier touches, and run a consistent, risk-proportionate process across the whole relationship — selection, onboarding, live operation, and exit. The companion control 5.21 then carries that thinking down the ICT supply chain, to the subcontractors and component suppliers behind the ICT products and services you buy.

Crucially, 5.19 is preventive. The safeguards are meant to be established up front, sized to the access being granted, not retrofitted after an incident exposes the gap.

A mature 5.19 implementation is visible in artefacts, not intentions. The strongest single signal is a live supplier inventory that records, per supplier, what data or systems it can reach, a criticality or risk tier, a named internal owner, and the current state of the relationship.

• A risk-tiered supplier register that is maintained rather than last touched at certification, with each entry tied to the access granted and a criticality rating.
• A documented supplier security policy that sets requirements by tier, so a high-risk data processor faces meaningfully more scrutiny than a low-risk stationery vendor.
• Risk-based due diligence on record before access is granted — the assessment, the evidence reviewed, and the decision, retained for each onboarding.
• Named ownership so every supplier has an accountable person inside the organisation, not a shared inbox.
• An offboarding routine that revokes access and confirms return or deletion of data when a relationship ends, with evidence it happened.
• A hand-off to 5.21 and 5.22 for the subprocessors and subcontractors behind each supplier, and a way to see when that list changes.

The through-line is evidence. For each of these an implementer should be able to produce a dated record that the step was performed for a specific supplier, not merely that a process exists on paper.

5.19 is the framing control for the supplier cluster; it sets the overall approach, and the controls around it operationalise specific parts of it. Reading them as a set avoids duplicated effort and, more importantly, avoids gaps between them.

• 5.19 defines the population and the rules — which suppliers exist, how they are tiered, and what secure means for each.
• 5.20 pushes those requirements into the agreement itself, so security expectations are contractually binding rather than assumed.
• 5.21 extends the discipline down the ICT supply chain, to the products, components, and services, and their upstream providers, that make up what you buy.
• 5.22 is the ongoing half of the relationship: monitoring supplier service delivery, reviewing it on a cadence, and managing change when a supplier's service or security posture shifts after signing.
• 5.23 handles the cloud-specific case, where much of the above still applies but the shared-responsibility model changes who does what.

The seam most programmes miss is between 5.19 and 5.22. 5.19 gets you a clean supplier inventory and a considered set of controls at the moment of onboarding; 5.22 requires you to keep watching, because a supplier that was low-risk at signing can quietly change its subprocessors, move data to a new region, or rewrite its data-processing terms. Detecting those supplier-side changes, and holding a dated record that you detected them, is one of the ways 5.22 evidence gets produced — alongside supplier service reports, assurance evidence and contractual notifications.

This is the narrow, honest place a tool like Venpo fits. It re-crawls a supplier's published legal documents on a schedule — privacy policy, DPA, cookie policy and subprocessor list — and produces a timestamped, linkable redline when any of them changes, with plain-English analysis of what moved. That is corroborating evidence that a supplier change was caught, feeding the 5.22 monitoring your 5.19 process relies on. It complements your own supplier reviews; it does not replace them, run your ISMS, or touch your internal records.

The common 5.19 failures are mostly about operation rather than documentation.

• A stale or incomplete register. Suppliers onboarded by individual teams — SaaS tools, contractors, niche processors — never make it onto the list, so the control covers a population that no longer matches reality.
• One-size-fits-all controls. Applying the same due diligence to every supplier either buries the team in low-value checks or gives a high-risk data processor no more scrutiny than a taxi account.
• Onboarding-only assurance. Due diligence is done once, at signing, and never revisited, so the relationship drifts for years with no review — a failure that surfaces under 5.22 but originates in a 5.19 process that never planned for the ongoing phase.
• No named owner. When accountability sits with procurement or security in the abstract, no one actually watches the supplier and reviews quietly lapse.
• No offboarding. Accounts, tokens, and data stay live long after a contract ends because nothing triggers revocation and confirmation of data return or deletion.
• Policy without evidence. A frequent audit finding is a well-written supplier policy with no dated records showing it was applied to specific suppliers. Existence is not operation.
• No hand-off for fourth parties. A 5.19 process that never feeds sub-suppliers into 5.21 and 5.22 leaves subprocessor changes unseen.