Every supplier with access to your systems is an extension of your attack surface. When a managed service provider gets compromised or a SaaS vendor misconfigures a database, the downstream impact lands on your organization — not theirs. ISO 27001 control 5.19 exists because procurement teams keep signing contracts that security teams never review, and the gap between onboarding a vendor and governing that relationship is where breaches take root.
What 5.19 Requires
ISO/IEC 27001:2022 Annex A 5.19 requires your organization to build and maintain a governance framework that identifies, assesses, and manages information security risks created by supplier relationships. This is not a one-time vendor checklist — it is a continuous process that covers the entire lifecycle of every third-party relationship, from initial due diligence through ongoing monitoring to secure offboarding.
In practical terms, you need to know which suppliers touch your information assets, how much access they have, and what happens if their security posture degrades. The control demands a documented policy, a risk-based approach to categorizing suppliers, and clear security requirements that are communicated before a contract is signed — not retrofitted after a breach. Understanding the full set of ISO 27001 third-party risk requirements is essential to scoping this work correctly.
The reasoning behind this requirement is straightforward. Organizations routinely grant suppliers access to production systems, customer data, and internal networks. Without a structured framework to govern those relationships, you are trusting that every third party protects your data as carefully as you do. That trust is the vulnerability 5.19 is designed to eliminate.
Why 5.19 Matters
In a common pattern, organizations discover that a supplier with broad network access was compromised weeks before the organization itself detected lateral movement. The attacker did not need to bypass your perimeter — they walked through a door your supplier left open. This is not a rare scenario — current data breach statistics confirm the trend. SecurityScorecard found that 35.5% of all data breaches in 2024 originated from third-party compromises, a figure that has climbed steadily year over year.
Third-party and supply chain risk is now classified as a high-severity threat category. A single supplier compromise can cascade across your entire organization, affecting data confidentiality, system integrity, and operational availability simultaneously.
What attackers exploit
- Unvetted supplier access to production systems with no pre-engagement security assessment
- Orphaned credentials from suppliers whose engagements ended months ago but whose accounts were never deprovisioned — a failure mode illustrated in common vendor risk management scenarios
- Missing right-to-audit clauses that prevent you from verifying a supplier’s actual security posture
- Flat supplier tiering — treating a cleaning company and a cloud infrastructure provider with the same level of scrutiny
- Shared or excessive permissions that violate least privilege, giving suppliers access far beyond what their role requires
- No contractual incident notification requirements, leaving you blind when a supplier is breached
- Unsegmented network access that allows an attacker who compromises one supplier to move laterally across your environment
- Over-reliance on self-attestation without independent verification of security claims — third-party risk statistics show how frequently this gap is exploited
How to Implement 5.19
Implementation splits into two perspectives: what you need to put in place internally and what you should demand from your suppliers. Both are required — governing your own processes without assessing your vendors, or vice versa, leaves gaps that auditors will flag and attackers will find.
For your organization (first-party)
Start with a supplier relationship policy that defines your organization’s risk appetite for third-party relationships, the scope of suppliers covered, and the minimum security requirements for each tier of supplier. This policy is the foundation everything else builds on.
Next, build a supplier register. This is a central inventory of every third party that accesses, processes, stores, or can affect your information assets. For each supplier, record their tier classification, what data or systems they can reach, contract start and end dates, and their current security status. If you cannot produce this register, you cannot manage supplier risk — you are just hoping nothing goes wrong.
Implement risk-based supplier tiering following vendor tiering best practices. Not every supplier needs the same scrutiny. A Tier 1 supplier — one that handles sensitive data or provides critical infrastructure — warrants annual security assessments, contractual audit rights, and continuous monitoring. A Tier 3 supplier with no access to sensitive systems might only need a basic questionnaire at onboarding.
For pre-engagement due diligence, use security questionnaires, verify certifications (check the scope and validity of any ISO 27001 certificate), and conduct on-site assessments for critical suppliers. Define access management rules rooted in least privilege: time-bound access, multi-factor authentication requirements, and dedicated accounts rather than shared credentials.
Embed security requirements into contracts before they are signed. This means right-to-audit clauses, incident notification SLAs (you need to know within hours, not weeks), data handling obligations, and clear terms for data return or destruction at contract end.
Establish an ongoing monitoring cadence as part of your broader vendor risk management workflow. Annual reviews for Tier 1 suppliers should include a reassessment of their security posture, a review of any incidents, and verification that certifications have not lapsed. Lower-tier suppliers can be reviewed less frequently, but never ignored entirely.
Finally, plan for supplier exit. When an engagement ends, revoke all access immediately. Confirm that your data has been returned or destroyed. Recover any organizational assets. This step is where most organizations fail — the contract ends, but the accounts stay active.
Common mistakes:
- Treating supplier security management as a one-time onboarding activity rather than a lifecycle process
- Applying identical scrutiny to every supplier regardless of risk, which wastes resources and delays onboarding
- Relying solely on supplier-completed questionnaires without any independent verification
- Failing to revoke supplier access when engagements end, leaving orphaned accounts as attack vectors
- Neglecting to include security requirements in contracts signed before the ISMS was implemented
For your vendors (third-party assessment)
When assessing a vendor’s security posture, structure your vendor risk assessment questionnaire around the areas that matter most: encryption practices (data at rest and in transit), access control policies, incident response capabilities, business continuity planning, and how they manage their own subprocessors.
Request concrete evidence, not just verbal assurances. An ISO 27001 certificate is useful — and an ISO 27001 vendor questionnaire template can help you verify scope — but only if the scope covers the services they provide to you — a certificate for a company’s HR department does not protect your data in their cloud platform. SOC 2 Type II reports demonstrate sustained control effectiveness. Penetration test summaries show whether they are testing regularly. Data flow diagrams reveal exactly where your data travels within their environment.
Red flags in vendor responses that should trigger deeper investigation:
- Refusal to share security documentation or audit reports
- No dedicated security function or named security owner
- Certifications that do not cover the specific services you are purchasing
- Vague or undefined incident response timelines (“we will notify you promptly” instead of “within 24 hours”)
- Inability to describe how they segregate customer data
To verify beyond self-attestation, look at independent audit reports, use automated security ratings platforms that continuously assess external-facing infrastructure, and exercise your right-to-audit clause for critical suppliers. Trust, in supplier security, is a vulnerability — verification is the control.
Audit Evidence for 5.19
Auditors assessing 5.19 expect both policy-level documentation and operational evidence showing those policies are followed in practice.
| Evidence Type | Example Artifact |
|---|---|
| Supplier Security Policy | Documented policy defining supplier risk assessment methodology, tiering criteria, and minimum security requirements for each tier |
| Supplier Register | Central inventory listing all suppliers with tier classification, data access scope, contract dates, and current security status |
| Due Diligence Records | Completed security questionnaires, certification verification records, and risk assessment outcomes for each supplier |
| Contractual Clauses | Supplier agreements containing right-to-audit clauses, incident notification SLAs, data protection terms, and access management requirements |
| Supplier Review Records | Minutes or reports from periodic supplier security reviews, including findings and corrective actions taken |
| Access Management Logs | Records showing supplier access provisioning, periodic access reviews, and deprovisioning upon engagement termination |
| Incident Response Evidence | Documented supplier-related security incidents with notification timelines and joint response activities |
Cross-Framework Mapping
Control 5.19 maps to equivalent requirements across major compliance frameworks. If you are pursuing multiple certifications, this overlap means the supplier governance work you do for ISO 27001 can satisfy requirements elsewhere.
| Framework | Equivalent Control(s) | Coverage |
|---|---|---|
| NIST 800-53 Rev. 5 | SR-01 (Supply Chain Risk Management Policy and Procedures) | Full |
| NIST 800-53 Rev. 5 | SR-02 (Supply Chain Risk Management Plan) | Full |
| NIST CSF 2.0 | GV.SC (Supply Chain Risk Management) | Full |
| SOC 2 (Trust Services Criteria) | CC9.2 (Risk Mitigation Related to Vendors and Business Partners) | Partial |
| CIS Controls v8.1 | Control 15 (Service Provider Management) | Full |
| DORA (EU) | Article 28 (ICT third-party risk management) | Partial |
| CPS 230 (APRA) | Outsourcing and third-party risk requirements | Partial |
Related ISO 27001 Controls
Control 5.19 does not operate in isolation. It connects to a network of controls that collectively govern how your organization manages external relationships and the risks they introduce.
| Control ID | Control Name | Relationship |
|---|---|---|
| 5.1 | Policies for Information Security | Supplier policy derives from and must align with the overarching information security policy framework |
| 5.2 | Information Security Roles and Responsibilities | Defines who owns supplier risk management and who is accountable for vendor security decisions |
| 5.10 | Acceptable Use of Information and Other Associated Assets | Sets boundaries for how suppliers may use organizational information and systems |
| 5.20 | Addressing Information Security Within Supplier Agreements | Translates 5.19 governance requirements into binding contractual terms |
| 5.21 | Managing Information Security in the ICT Supply Chain | Extends supplier governance specifically to technology and software supply chains |
| 5.22 | Monitoring, Review and Change Management of Supplier Services | Provides the ongoing assurance mechanism that supplier security commitments are maintained |
| 5.23 | Information Security for Use of Cloud Services | Applies supplier governance principles to cloud-specific risks and shared responsibility models |
| 5.31 | Legal, Statutory, Regulatory and Contractual Requirements | Ensures supplier agreements satisfy external legal and regulatory obligations |
| 8.1 | User Endpoint Devices | Governs how supplier-managed or supplier-accessed devices connect to organizational networks |
Frequently Asked Questions
What is ISO 27001 5.19?
ISO 27001 5.19 is an organizational control that requires you to establish a governance framework for managing information security risks in supplier relationships. It covers the full supplier lifecycle — from pre-engagement due diligence through ongoing monitoring to secure offboarding — ensuring that third-party access to your systems and data is governed, not assumed to be safe.
What happens if 5.19 is not implemented?
Without 5.19 controls in place, supplier relationships become unmanaged attack surfaces. Organizations face undetected third-party compromises, audit nonconformities that can block certification, regulatory penalties under frameworks like GDPR and DORA, and reputational damage when a supplier breach exposes customer data that your organization was responsible for protecting.
How do you audit 5.19?
Auditors verify 5.19 by requesting your supplier security policy, supplier register, completed risk assessments, and contractual evidence of security clauses. They typically select two or three suppliers and trace the full governance lifecycle — confirming that pre-engagement vetting, ongoing monitoring records, and access management evidence exist and align with your documented policy.
How UpGuard Helps
Automate Supplier Security Governance
UpGuard Vendor Risk continuously monitors your suppliers’ external security posture, automates risk assessments with industry-standard questionnaires, and generates the evidence trail auditors expect when verifying 5.19 compliance. Instead of managing supplier risk through spreadsheets and annual check-ins, you get real-time visibility into the risks your third parties introduce.