ISO/IEC 27001:2022 · derived mapping target
A.5.19Information security in supplier relationships
Identify and manage the security risks that come with using suppliers who handle your information or systems. Your security is only as strong as the partners you rely on.
Mapping at a glance
A.5.19Information security in supplier relationshipsISO/IEC 27001:2022
A.5.19 is covered by 12 Sekit CSF controls. +7 more in the table below. Open in the full graph →
Mapped from the Sekit CSF
The Sekit controls that cover this requirement, lens by lens.
RCF-0025Third-party risk management · PolicysupportsSekit's Third-party risk management policy requires every supplier with data or system access to be risk-assessed before onboarding and re-assessed periodically, the written commitment behind A.5.19; running that assessment, mapped separately as the vendor due diligence process, is what performs the activity.RCF-0046Service inventory · PolicyenablesRecording every service the business depends on, with owner and criticality, gives supplier risk management something concrete to act on rather than an unlisted set of relationships.RCF-0047Service inventory · ProcessenablesKeeping the service dependency register current, and reviewing it for single points of failure, is what stops A.5.19's supplier risk view from going stale as vendors change.RCF-0295Supply chain continuity · PolicysupportsAssessing whether key suppliers could keep serving the company through a disruption is A.5.19's risk lens applied specifically to continuity of supply.RCF-0296Supply chain continuity · ProcesssupportsReviewing critical supplier continuity risk on a schedule, with a workable fallback in place, keeps A.5.19's supplier risk assessment from being a one-time exercise.RCF-0316Vendor due diligence · PolicysupportsRequiring a documented security check of every new supplier before the contract is signed supports A.5.19's due diligence requirement, though it does not cover the ongoing supplier risk management the control also demands.RCF-0317Vendor due diligence · ProcesssupportsRunning the security assessment at onboarding and repeating it on a cycle is what makes A.5.19's risk requirement operate rather than sit as a policy line.RCF-0318Vendor due diligence · TechnicalsupportsUsing questionnaire platforms or vendor risk feeds makes the supplier security check A.5.19 requires faster to run consistently across every in-scope vendor.RCF-0319Contractual security clauses · PolicysupportsBinding security and data protection clauses in supplier contracts give A.5.19's risk requirements legal weight once the relationship is signed.RCF-0322Ongoing monitoring · PolicysupportsCommitting to monitor key suppliers' security posture for the life of the relationship extends A.5.19's assessment past the onboarding moment, where most gaps open up over time.RCF-0325Offboarding vendors · PolicysupportsA formal supplier exit procedure that guarantees access removal and data return closes the loop A.5.19 opens at onboarding, covering the relationship end to end.RCF-0331Shared responsibility model · PolicysupportsDocumenting which security duties a cloud or SaaS provider covers, and which remain the company's, is A.5.19's supplier risk requirement applied to the specific case of cloud services.
NIST CSF 2.0 counterparts
Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.
ISO/IEC 42001:2023 — Annex A counterparts
Cyber Essentials counterparts
Evidence that proves this control
What an auditor, or Sekit's evidence engine, asks for.
Vendor due diligence and monitoring
How the company assesses a supplier's security before hiring and monitors it during the relationship, including the process when it ends.
From the Sekit evidence catalog
In practice
For most companies this means a short questionnaire sent to any new vendor that will touch company data, kept on file alongside the contract, plus a note on when to check again. Auditors ask for the vendor due diligence and monitoring records and pick a critical supplier, often the cloud host or payroll provider, to check whether the assessment on file is current or years stale. The gap that shows up most is a vendor list with assessments only for the largest suppliers, while smaller tools with real access to company data, an analytics plugin or a scheduling app, were never assessed at all.
Common gaps
Vendor due diligence was completed for major suppliers at onboarding but was never repeated, so assessments on file for long-standing vendors are years out of date.
Smaller tools with real access to company data, such as an analytics or scheduling plugin, were never included in the supplier risk process at all.
The supplier list itself is incomplete because it was built from memory rather than cross-checked against billing or integration records.
Questions your auditor will ask
How do you assess a new supplier's security before signing a contract?
Point to the vendor due diligence and monitoring records showing a documented security check completed and reviewed before the contract was signed.
How often is that assessment repeated during the relationship?
Reference the defined re-assessment cycle and show a critical supplier's most recent review date against that cycle.
How do you know which suppliers have access to company data or systems?
Show the service dependency register naming each supplier with its owner, criticality and what data or systems it touches.
Where regulation demands it
NIS2 art. 5.1 (Supply chain security policy) requires the same risk-based approach to supplier relationships A.5.19 asks organizations to maintain.
ENS op.ext.1 (Contratación y acuerdos de nivel de servicio) sets the equivalent baseline for managing supplier and service agreements.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.5.19?”
Also via MCP, free with account