ISO 27001 Annex A 5.19: supplier security across the full lifecycle

The enterprise security questionnaire arrives with one line you dread: "Provide your supplier risk register." You have a spreadsheet of subscriptions, a hosting provider nobody has assessed, and a deal waiting on the answer.

This guide covers ISO 27001 Annex A 5.19 from the first tiering decision to the last deprovisioned account. It is written for CTOs, COOs and security managers at 25–250 person firms heading into a Stage 1 or Stage 2 audit, and it keeps the effort proportionate to the risk.

What does A.5.19 information security in supplier relationships require?

A.5.19 information security in supplier relationships requires you to manage every vendor as a lifecycle, not a signing-day formality. That means identifying which suppliers touch your data or keep your service running, building security into selection, limiting access, monitoring performance, planning for failure, and taking data back at exit. It heads the supplier family, A.5.20 to A.5.23.

Think of the control as the decision layer for supply chain security. It does not dictate contract clauses or cloud settings. It decides which suppliers matter, how hard to look at each one, and what must happen when the relationship starts, changes and ends. Contract wording belongs to A.5.20, and cloud specifics to A.5.23.

The lifecycle looks smaller once you see it is mostly what a well-run firm already does. You already choose vendors, issue logins and cancel subscriptions. A.5.19 asks you to do those three things deliberately, in writing, and in an order an auditor can follow.

The control is classed as preventive, and it touches confidentiality, integrity and availability together. A supplier can leak your data, corrupt it or take your service down with them. Tiering and vetting exist to stop that before the vendor holds anything sensitive.

What changed in ISO 27001:2022 Annex A 5.19 supplier relationships?

Annex A 5.19 ISO 27001:2022 widens the 2013 supplier control. It expects vendor categorisation, explicitly reaches cloud providers, and covers the whole lifecycle through to offboarding rather than stopping at onboarding. Annex A 5.19 information security in supplier relationships now sits in the organizational theme, beside A.5.23, the new 2022 control for cloud services.

Three shifts change your paperwork:

• Categorisation. Suppliers are no longer one flat list. You group them by what they can reach and what breaks if they fail.
• Cloud reach. Hosting, SaaS and platform vendors sit inside the supplier scope, and that is where most of a modern firm's data lives.
• Offboarding. Exit is part of the control, so access removal and data return need evidence just as onboarding does.

If you are moving across from the earlier edition, test your register against those three points first. Is every vendor tiered? Are the cloud platforms listed? Does an exit record exist for a vendor you have already dropped?

Why does accountability not transfer when a supplier handles your data?

Under UK GDPR, a controller stays accountable for personal data even when a processor holds it, and must use only processors that give sufficient guarantees under written contracts (Article 28). Enterprise buyers also treat a supplier risk process as a due-diligence staple, so a missing register slows deals exactly where trust should speed them.

The Information Commissioner's Office UK GDPR guidance on controller-processor contracts sets out the test: appropriate technical and organisational guarantees, backed by a written agreement carrying mandatory processing terms. If a payroll processor loses your client data, the regulatory exposure and the client conversation are yours, whatever the contract says about fault.

The exposure is larger than it looks. A 25–250 person firm runs largely on other people's platforms, such as payroll, hosting, CRM and the support desk, so much of its real attack surface sits inside its vendors.

Buyers know this. Enterprise clients, including those passing down their own DORA or NIS2 obligations, put "show us your supplier risk process" on every serious questionnaire. A firm that cannot produce a register at that moment looks unmanaged.

How do you implement ISO 27001 Annex A 5.19 without enterprise bureaucracy?

Start with one short supplier security policy and one register that tiers every vendor as Critical, High or Low by data access, operational impact and service continuity. The tier sets the effort: critical vendors get a questionnaire plus a current, in-scope assurance check, mid-tier gets the certificate check, and low-tier gets contract basics.

The NCSC supply chain risk grouping guidance suggests grouping suppliers into risk profiles based on operational impact, the nature of the service and data sensitivity. Three tiers are enough at this size.

The supplier security policy is a topic-specific policy, and a few pages is plenty. It names the owner, defines each tier and its criteria, sets the diligence and contract minimums per tier, and fixes the review cadence and exit steps. The register then records how each vendor was tiered and what was done.

Build the rest of the control in this order:

1. Set proportionate vetting. The NCSC 12 principles of supply chain security ask for minimum requirements that are justified, proportionate and achievable. For a critical vendor, check that the ISO 27001 certificate or SOC 2 report is current and covers the service you actually buy.
2. Limit supplier access. Define which systems, data and premises each supplier may reach, grant it on least privilege with MFA, and sweep supplier accounts in your regular access reviews. Orphaned vendor logins are a classic audit find.
3. Push expectations into signed terms. Cover notification duties, handling rules, subcontracting conditions and exit obligations. This control decides who needs which terms; A.5.20 holds the clause detail.
4. Wire suppliers into incident handling. Know who to call at each critical vendor, what they have committed to tell you and how fast, and where responsibility splits if something fails on their side.
5. Plan continuity for critical vendors. Ask what happens if they suffer an outage, get acquired or disappear. At this scale, a named alternative or an exportable copy of your data is usually enough.
6. Brief the people who work with supplier staff. Give them ground rules on what can be shared, through which channels, and what needs escalating.

The pitfall is flat-tier diligence. A 50-page questionnaire sent to the stationery supplier burns goodwill and hours, while a one-page form goes to the platform holding all your client data.

The policy and register take one to two weeks. Backfilling diligence on existing critical vendors is the longer tail, so run it tier-first and the audit-sensitive gaps close before the rest.

How do you handle AWS, Google and Microsoft when they won't negotiate?

Accept that hyperscalers will not renegotiate for you. Review their standard terms, collect their published assurance such as ISO certificates or SOC reports, and where a gap remains, record a compensating control or an accepted risk with a named owner. Auditors credit the documented judgement, not a pretence of negotiating leverage.

Three records make that judgement defensible:

• The terms review. Note what the standard agreement commits the vendor to on breach notification, subprocessors and data return.
• The assurance on file. Keep the certificate or report with its date, and confirm its scope covers the services you use.
• The gap decision. Where terms fall short, record the compensating control, such as limiting what data enters the service or keeping your own backups, or record the accepted risk. Add an owner and a review date.

How you configure the cloud service itself is the job of A.5.23. This control only needs proof that someone looked at the terms and made a decision.

Even a non-negotiable contract is a written set of terms you can review and file. Where the vendor processes personal data, its standard data processing addendum belongs in that file too.

A vendor engaged on a click-through is a purchase, not a managed relationship.

How do you monitor suppliers and offboard them without orphaned accounts?

Run a light annual review of critical suppliers: assurance in date, scope still right, incidents and subcontractor changes logged, conclusion recorded. Then script the ending before you need it: an offboarding checklist that pulls access the day the contract ends and secures written confirmation that your data was returned or destroyed.

For each critical supplier, the annual review answers five questions:

• Is the certificate or report still in date, and does it cover the service you use?
• Has your use of the service grown beyond the scope you assessed?
• Have there been incidents since the last review, theirs or yours?
• Has the supplier changed subcontractors or been acquired?
• What did you conclude: keep, remediate or exit?

A certificate on file proves the supplier was assessed once, not that it is safe today.

The register that says "annual" and shows nothing in the last twelve months is a typical audit gap. A dated review note per critical supplier closes it in minutes.

Offboarding is the same discipline in reverse. Script it as four steps:

1. Trigger on the contract date. The end date or termination notice starts the checklist, not someone's memory.
2. Pull access the same day. Remove accounts, API keys, integrations and shared credentials.
3. Request return or destruction in writing. State which data, in which format, by when.
4. File the proof. Store the checklist, the access-removal record and the confirmation against the register entry.

Offboarding fails by never finishing. Accounts stay live months after the contract ended, and nobody confirms the data was destroyed. A dated sign-off on the register entry is what closes it.

What audit evidence does ISO 27001 A.5.19 need?

Auditors expect to see the supplier policy, a current tiered register, completed vetting records for sampled critical suppliers, signed contracts with security terms, scoped and MFA-protected access records, and proof the annual review ran. Offboarding artefacts for a departed vendor complete the set: checklist, access-removal record and destruction or return confirmation.

The detail inside each artefact is what separates a pass from a query:

• Register. Current, tiered, and covering the vendors the auditor has already noticed, such as your hosting provider and payroll platform.
• Vetting records. Questionnaires, assurance reports with dates and scope checked, and a sign-off showing someone weighed the answers.
• Contracts. The same sampled suppliers, with security terms present.
• Access records. Supplier accounts scoped to need, MFA-protected, and visible in review cycles.
• Review proof. Refreshed certificates, review notes and tracked actions.

These are by-products of the process in the earlier sections, not a separate documentation project. If the process runs, the evidence file assembles as you go.

What will the auditor ask, and how are A.5.19 findings graded?

Expect the auditor to sample two or three suppliers, usually the most critical plus a recent joiner, and trace each from tiering rationale through vetting, contract, assurance and access. No supplier process, or a critical vendor onboarded without assessment or terms, grades major. A lapsed certificate or missed review grades minor, aggregating to major as a pattern.

The questions in the room tend to follow that trace:

• "Show me your supplier register. How did you decide which vendors are critical?"
• "This processor holds client data. What did you check before onboarding, and what assurance is on file now?"
• "What does this contract oblige the supplier to tell you after a breach, and in what timeframe?"
• "Who at your firm can this vendor's staff log in as, and when was that access last reviewed?"
• "You stopped using this platform in January. How was access closed, and where did your data go?"

Recently exited vendors are a favourite trace for the offboarding path. Expired certificates on file are the easiest find in the room, because the auditor needs only a date to spot one.

Our grading guidance follows certification-body practice: a single slip stays minor, and the same slip across several sampled suppliers reads as a system failure. Three minors are the ones to watch for repeating:

• An assurance report or certificate that has lapsed.
• A missed annual review.
• A stale register entry, such as a vendor you no longer use or one that was never tiered.

How do you automate A.5.19 with GRC engineering?

Treat supplier management as data and workflow. Hold the register as structured records, trigger certificate chasing from expiry dates, gate new vendors until tier, vetting and terms are complete, and fire deprovisioning from contract end-dates. Each step runs without a human remembering it, and each leaves evidence behind as a by-product.

Once each vendor record carries tier, owner, assurance type and expiry, contract status and review date, "which critical suppliers have lapsed assurance" becomes a query instead of quarterly archaeology. Gated onboarding makes the control structurally unskippable. Contract-end triggers close the orphaned-account gap that manual processes always leave.

Judgement stays with people. Designing the tiering model, setting the diligence bar per tier and making the accept-or-walk call on a risky vendor is Fractional CISO work, while GRC engineering builds the register, the chasing and the gated flows around those decisions.

In an enterprise review, the register is then an export and the evidence is already filed. That is the commercial upside: the question that used to stall a deal becomes proof that you are managed.

Frequently asked questions