ISO 27001:2022 Annex A 5.19 Information security in supplier relationships for AI Companies

ISO 27001 Annex A 5.19 for AI Companies

ISO 27001 Annex A 5.19 Information security in supplier relationships is a security control that requires organizations to establish, agree on, and verify security requirements for mitigating risks associated with supplier access. For AI companies, this control is essential to secure the software supply chain, ensuring that third-party data providers, cloud services, and API integrations do not introduce vulnerabilities into proprietary models or training pipelines.

In the world of artificial intelligence, your capacity for innovation is deeply connected to a complex network of third-party suppliers. From the providers that source your training data to the cloud platforms that host your models, your success is built on a digital supply chain. It’s a powerful ecosystem, but it comes with a critical warning: this supply chain is often the weakest link in an organisation’s information security.

Over half of all major incidents from the last five years have involved a third-party supplier, and these events rarely offer early warning – they erupt with costly speed, blindsiding even experienced security teams. A single vulnerability in a supplier’s environment can unravel months of your own security work. This is the reality of our hyperconnected world.

To address this challenge, the ISO 27001 standard provides ISO 27001 Annex A 5.19 Information security in supplier relationships, a control designed specifically for information security in supplier relationships. Its core purpose is “to manage the information security risks associated with the use of a supplier’s products or services.” It provides a clear framework for moving from reactive panic to proactive, structured oversight.

This guide is designed to help you, as an AI business, understand the unique supplier risks you face across your development lifecycle. More importantly, it provides a clear and practical path to implementing Annex A 5.19, turning a potential vulnerability into a source of competitive strength and resilience.

The “No-BS” Translation: Decoding the Requirement

Let’s strip away the consultant-speak. Annex A 5.19 isn’t about sending a 100-page questionnaire to your cleaner. It is about knowing which of your software vendors can kill your business.

The Auditor’s View (ISO 27001)The AI Company View (Reality)
“Information security requirements for mitigating the risks associated with supplier’s access to the organisation’s assets shall be agreed with the supplier and documented.”Don’t let them grade their own homework. 1. If you use OpenAI, AWS, or a data labelling firm in Kenya, you need a contract that says “If you get hacked, you must tell us within 24 hours.” 2. You need to verify their security claims (e.g., download their SOC 2 report) before you give them your data.

The Business Case: Why This Actually Matters for AI Companies

Why should a founder care about “Vendor Risk Management” (VRM)? Because your customers will audit your vendors through you.

The Sales Angle

Enterprise clients will ask: “Who are your sub-processors?” and “How do you vet them?”. If your answer is “We don’t know,” you lose the deal. If your answer is “We conduct annual security reviews of all critical sub-processors and bind them with DPAs (Data Processing Agreements),” you win the contract. Annex A 5.19 is your answer key for these questionnaires.

The Risk Angle

The “Supply Chain” Attack: Hackers know they can’t breach you, so they breach your data labelling vendor who has “Admin” access to your S3 bucket. If you don’t enforce MFA and IP whitelisting on that vendor (A 5.19), you are wide open.

DORA, NIS2 and AI Regulation: You Are Liable for Your Vendors

Regulators have stopped blaming the vendor. They now blame you for hiring them.

  • DORA (Article 28): Mandates that financial entities manage “ICT Third-Party Risk.” If you are a critical AI vendor to a bank, you must prove you are managing your own vendors (4th party risk).
  • NIS2 Directive: Requires supply chain security. You are responsible for the security of your direct suppliers. Ignorance is no longer a legal defence.
  • EU AI Act: Providers of High-Risk AI systems must ensure quality management. This extends to the quality and security of the data provided by third parties. If your vendor gives you poisoned data, you are liable for the output.

ISO 27001 Toolkit vs SaaS Platforms: The Vendor Management Trap

SaaS platforms love to sell “Automated Vendor Risk Management.” But software cannot negotiate a contract. Here is why the ISO 27001 Toolkit is superior.

FeatureISO 27001 Toolkit (Hightable.io)Online SaaS Platform
FlexibilityAny Vendor. Works for AWS, the freelance cleaner, and the lawyer.SaaS Only. Most platforms only track software vendors. They fail to track physical security providers or consultants.
OwnershipYour Register. You keep the Supplier Register in Excel. You own the relationship history.Platform Lock-in. If you cancel the subscription, you lose your record of due diligence. You have to start vetting everyone from scratch.
SimplicityTiers. A simple logic: Tier 1 (Critical) gets a full review. Tier 3 (Low) gets a basic check.Overkill. Platforms often force you to send 100-question surveys to tiny vendors who will never reply, stalling your procurement.
CostOne-off fee. Pay once. Manage 1,000 vendors.Per-Vendor Cost. Some platforms charge you for every vendor you track. You are punished for growing your supply chain.

The AI Challenge: Unique Supplier Risks in Your Workflow

While supplier risk management is a universal business challenge, AI companies face a unique and heightened set of threats. Your intellectual property – the data, models, and algorithms that define your value – is frequently handled by third parties.

Risks in Data Sourcing and Processing

Your AI models are only as good as the data they are trained on. This creates significant risks:

  • Data Poisoning: A vulnerability within a supplier’s systems could allow an attacker to subtly corrupt your training data, leading to a model that produces biased outputs.
  • IP Loss: If a data labelling service mishandles your proprietary dataset, it can result in the theft of valuable intellectual property.

Risks in Model Development and Training

The process of building AI models relies heavily on third-party infrastructure:

  • Disruption: Your reliance on a third-party MLOps platform is a critical dependency. Their downtime halts your development pipeline.
  • Model Theft: A supplier with access to your development environment could gain unauthorised access to your model weights.

Risks in the AI Supply Chain and Inference

Once deployed, your AI service integrates with a broader supply chain:

  • API Vulnerabilities: A security flaw in a supplier’s API (e.g., payment processing) can become an exploitable vulnerability in your product.
  • Inference Compromise: A compromise of your cloud hosting provider could allow an attacker to tamper with your model’s real-time results.

Your Compliance Roadmap: Practical Steps to Implement Annex A 5.19

Complying with ISO 27001 Annex A 5.19 isn’t about creating bureaucracy; it’s about implementing a clear, risk-based process.

Establish Your Supplier Security Policy

Define the rules of engagement. What security standards must a vendor meet before you sign a contract?

Create a Centralised Supplier Register

You cannot manage what you cannot see. Track the following:

Supplier NameService ProvidedRisk TierData AccessedContract Review Date
Example CorpCloud HostingTier 1PII, Model Data2024-12-31
Data Label Inc.Image AnnotationTier 2Training Images2025-03-15
Office Supply Co.StationeryTier 3None2026-06-30

Assess Risk and Tier Your Suppliers

Focus your energy. Tier 1 (Critical) requires deep due diligence (SOC 2 review). Tier 3 (Low) requires a basic check.

Enforce Security Through Clear Agreements

Your contract is your sword. Ensure it includes:

  • Right to Audit: You can check their security.
  • Breach Notification: They must tell you within 24-72 hours.
  • Data Destruction: They must delete your data when the contract ends.

Implement Ongoing Monitoring and Review

Don’t just sign and forget. Review Tier 1 suppliers annually. Did they renew their ISO 27001 certificate?

The Evidence Locker: What the Auditor Needs to See

When the audit comes, show me the proof:

  • Supplier Register (Excel): The master list.
  • Due Diligence Records (Folder): Copies of the SOC 2 reports or security questionnaires you collected for Tier 1 vendors.
  • Contracts/DPAs (PDF): Signed agreements with security clauses highlighted.
  • Review Logs (Email/Ticket): Evidence that you checked if AWS was still compliant this year.

Common Pitfalls & Auditor Traps

Here are the top 3 ways AI companies fail this control:

  • The “Credit Card” Vendor: A developer put a monthly subscription for a new AI tool on the corporate card. It isn’t in the Supplier Register. It has access to your data. Instant failure.
  • The “Expired” Certificate: You collected a vendor’s ISO 27001 certificate during onboarding 3 years ago. You never checked if they renewed it.
  • The “Missing” Offboarding: You fired a marketing agency but forgot to revoke their access to your Google Analytics and social media accounts.

Handling Exceptions: The “Break Glass” Protocol

Sometimes you need a vendor now to fix a critical issue, and you can’t wait 2 weeks for legal review.

The Emergency Procurement Workflow:

  • Trigger: Critical incident requiring specialized external help.
  • Approval: CTO/CISO approves “At Risk” onboarding.
  • Constraint: Vendor is given limited, monitored access (e.g., screen share only, or sandbox environment).
  • Review: Full due diligence is completed retroactively within 10 days.

The Process Layer: “The Standard Operating Procedure (SOP)”

How to operationalise A 5.19 using your existing stack (Linear, Google Drive).

  • Step 1: Request (Manual). Employee requests new tool via Linear ticket.
  • Step 2: Triage (Manual). Security Lead assigns Risk Tier (1, 2, or 3).
  • Step 3: Assessment (Manual).
    • Tier 3: Check website for security page. Approve.
    • Tier 1: Request SOC 2 report. Legal review of DPA.
  • Step 4: Onboarding (Manual). Add to Supplier Register (Excel). Sign Contract.
  • Step 5: Review (Automated). Calendar reminder set for 11 months later: “Review [Vendor] Security.”

For an AI company, managing supplier security is not just a compliance exercise – it is an act of survival. By implementing the processes outlined in ISO 27001 Annex A 5.19, you turn your biggest blind spot into a strategic advantage.

ISO 27001 Annex A 5.19 for AI Companies FAQ

What is ISO 27001 Annex A 5.19 for AI companies?

ISO 27001 Annex A 5.19 requires AI companies to establish and maintain information security requirements for supplier relationships. For AI firms, this involves ensuring that 100% of third-party vendors—including cloud providers (CSP), LLM API providers, and data labelling services—adhere to strict data protection and model integrity standards.

   

Why is supplier security critical for AI firms?

   

Supplier security is critical because approximately 70% of AI-related security breaches originate within the supply chain, such as through compromised API integrations or third-party datasets. Implementing Annex A 5.19 ensures that external dependencies do not introduce vulnerabilities that could lead to model poisoning or proprietary data leakage.

   

What are the supplier requirements for AI compliance?

   

AI organisations must enforce specific security mandates within their supplier contracts to remain compliant. Key requirements include:

   
           
  • Right to Audit: Contractual clauses allowing for the inspection of the supplier’s security controls and AI governance frameworks.
  •        
  • Data Sovereignty: Ensuring 100% of training data remains within approved geographic regions to satisfy GDPR and the EU AI Act.
  •        
  • Incident Notification: Mandatory 24-hour reporting windows for any breach affecting the AI firm’s models or training pipelines.
  •        
  • Model IP Protection: Explicit agreements that suppliers will not use the firm’s proprietary data to train their own foundation models.
  •        
   

What evidence is required for Annex A 5.19 audits?

   

Auditors require documented proof of active supplier management. Essential evidence includes a Supplier Security Policy, a risk-rated Supplier Register, signed Non-Disclosure Agreements (NDAs), and recent SOC2 or ISO 27001 certificates from 100% of critical vendors involved in the ML Ops lifecycle.

About the author

Stuart Barker
🎓 MSc Security 🛡️ Lead Auditor 30+ Years Exp 🏢 Ex-GE Leader

Stuart Barker

ISO 27001 Ninja

Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management. Holding an MSc in Software and Systems Security, he combines academic rigor with extensive operational experience, including a decade leading Data Governance for General Electric (GE).

As a qualified ISO 27001 Lead Auditor, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. His toolkits represent an auditor-verified methodology designed to minimise operational friction while guaranteeing compliance.

Shopping Basket
Scroll to Top