ISO 27001:2022 Annex A 5.22 Monitoring, review and change management of supplier services for AI Companies

ISO 27001 Annex A 5.22 for AI Companies

ISO 27001 Annex A 5.22 Monitoring, review and change management of supplier services is a security control that requires organizations to regularly monitor and review supplier performance against agreed service levels. For AI companies, this control is critical to detect service degradation or security policy changes in cloud providers and LLM vendors, ensuring that model reliability and data protection standards are maintained over time.

Managing supplier risk is a cornerstone of any robust information security programme. For an AI company like yours, however, this challenge is not merely amplified; it is existential. Your supply chain of data providers, annotation services, model repositories, and cloud infrastructure is not just a support function, it is your factory floor. A disruption here is not just a security issue; it is a direct threat to your production line (model inference), your research and development (model training), and the integrity of your final product (the algorithm’s output).

The purpose of ISO 27001 Annex A 5.22 Monitoring, review and change management of supplier services is to ensure you maintain an agreed level of information security throughout your supplier relationships. In simple terms, it requires you to regularly monitor, review, and manage changes in your suppliers’ services to confirm they consistently meet your security standards. This is not about a single, once-a-year check. The standard demands a continuous cycle of oversight.

The “No-BS” Translation: Decoding the Requirement

Let’s strip away the consultant-speak. Annex A 5.22 isn’t about re-reading the contract every year. It is about catching your vendors when they quietly change the rules.

The Auditor’s View (ISO 27001)The AI Company View (Reality)
“Organisations shall regularly monitor, review and audit supplier service delivery.”Did they break the SLA? You pay for 99.9% uptime on the vector database. Did they hit it? If not, do you have a credit note? If you aren’t checking, you are just donating money.
“Managing changes to the provision of services… including maintaining and improving existing information security policies.”Did they change the Terms of Service? OpenAI just updated their terms. Did they remove the clause about not training on your API data? If you didn’t notice, you might be leaking IP right now.

The Business Case: Why This Actually Matters for AI Companies

Why should a founder care about “supplier reviews”? Because your product is likely a wrapper around 5 other APIs. If they change, you break.

The Sales Angle

Enterprise clients will ask: “How do you ensure your sub-processors remain compliant over time?” If your answer is “We checked them when we signed the contract 3 years ago,” you lose the deal. If your answer is “We conduct quarterly performance reviews and real-time monitoring of sub-processor security bulletins,” you win the contract. Annex A 5.22 is your proof of ongoing vigilance.

The Risk Angle

The “Silent Deprecation” Risk: Your cloud provider deprecates a specific security feature or encryption standard you rely on. They sent an email about it 6 months ago, but nobody read it because you don’t have a “Supplier Review” process. Suddenly, your production environment is non-compliant or offline.

DORA, NIS2 and AI Regulation: Continuous Monitoring

Regulators demand that you watch your supply chain like a hawk.

  • DORA (Article 28): Financial entities must monitor the performance of ICT third-party providers. You must track key performance indicators (KPIs) regarding security. If your AI service degrades, you must tell the bank immediately.
  • NIS2 Directive: Requires you to address security vulnerabilities in your suppliers. If a supplier releases a patch, you must know about it and ensure it is applied. A 5.22 provides the monitoring framework for this.
  • EU AI Act: Requires post-market monitoring. If a change in a third-party base model (e.g., GPT-4 update) causes your system to become unsafe or biased, you are liable. You must monitor upstream changes to ensure downstream safety.

ISO 27001 Toolkit vs SaaS Platforms: The Monitoring Trap

SaaS platforms automate “questionnaires,” but they don’t automate “relationships.” Here is why the ISO 27001 Toolkit is superior.

FeatureISO 27001 Toolkit (Hightable.io)Online SaaS Platform
FlexibilityReal Conversations. Our templates guide you to have a quarterly call with your critical vendor. You can’t automate a relationship.Spam Bots. Platforms send automated emails asking “Are you still secure?” Vendors ignore them. You get no data.
OwnershipYour Records. You keep the meeting minutes and performance reports in your own system.Data Silo. Review data is locked in the platform. If you switch GRC tools, you lose the history of your supplier oversight.
SimplicitySLA Tracking. Simple spreadsheets to track uptime vs. promise.Alert Fatigue. Platforms pull in every RSS feed from every vendor, burying you in noise about minor incidents that don’t affect you.
CostOne-off fee. Pay once. Monitor forever.Subscription. You pay monthly for a tool that essentially just reminds you to check a website.

The Unique Supplier Risks AI Companies Face

To effectively manage your AI supply chain, you must first identify the specific ways in which supplier relationships can introduce risk into your unique workflows.

Exposure of Sensitive Training Datasets

A supplier’s quiet change in process could lead to a catastrophic breach. For example, if your data annotation provider changes their workflow to use a cheaper, less secure sub-processor without telling you, your PII is now exposed. Annex A 5.22 requires you to monitor for these sub-processor changes.

Disruption of Algorithmic Processes

A subtle, undocumented change in a cloud provider’s GPU driver or a core machine learning library could silently degrade your model’s performance. These issues are insidious because they may not be caught by basic uptime monitoring. You need to review release notes and changelogs.

Vulnerabilities in the AI Supply Chain

The modern AI supply chain is intricate. A vulnerability in your data annotation supplier’s platform could allow an attacker to introduce subtle, malicious labels into your training data (data poisoning). Continuous monitoring of your supplier’s security posture is the only defence.

Your Practical Steps to Comply with Annex A 5.22

Achieving compliance is not about creating bureaucracy; it is about implementing a robust oversight programme.

Create a Dynamic Supplier Map

Your first step is to maintain the supplier register created in A 5.19. Add columns for “Last Review Date” and “Next Review Date.” This transforms a static list into a management tool.

Implement Continuous, Risk-Based Monitoring

In the fast-paced AI industry, “annual-only” reviews are insufficient. You must monitor triggers:

  • Service Level Drops: If API latency increases, trigger a review.
  • Security Incidents: If they appear in the news for a breach, trigger a review.
  • Terms Changes: If they update their Privacy Policy, trigger a review.

Formalise Your Change Management Process

When a supplier changes their service (e.g., API deprecation), you must assess the impact on your security. Document this impact assessment. “Will this change break our encryption? Will it force us to move data to a non-compliant region?”

The Evidence Locker: What the Auditor Needs to See

Auditors want proof of activity, not just a policy. Prepare these artifacts:

  • Supplier Review Meeting Minutes (PDF): Notes from your quarterly business review (QBR) with your cloud provider or major SaaS vendor.
  • Performance Dashboards (Screenshots): Evidence that you track uptime/availability for critical AI APIs.
  • Incident Tickets (Linear/Jira): A ticket where you logged a supplier issue (e.g., “GitHub Actions outage”) and tracked it to resolution.
  • Audit Reports (PDF): The latest SOC 2 / ISO 27001 certificate you collected from your Critical suppliers.

Common Pitfalls & Auditor Traps

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

  • The “Auto-Renew” Trap: You renew a contract automatically without checking if the vendor is still compliant. The auditor checks the renewal date vs. the last review date. If renewal > review, you fail.
  • The “Status Page” Fallacy: You claim to monitor suppliers, but you just look at their status page when things break. You have no logs of proactive monitoring.
  • The “Sub-Processor” Blind Spot: Your vendor changes their hosting provider from AWS to Alibaba Cloud. You didn’t notice. Now your data is in a different jurisdiction, violating your own client contracts.

Handling Exceptions: The “Break Glass” Protocol

What if a critical supplier fails or changes terms overnight, and you have no choice but to accept it temporarily?

The Forced Change Workflow:

  • Trigger: Supplier pushes a mandatory update that degrades security (e.g., removing MFA for a week).
  • Risk Acceptance: CTO signs a risk waiver acknowledging the temporary gap.
  • Mitigation: Implement compensatory controls (e.g., restrict access to that tool to only 2 admins via VPN).
  • Exit Plan: Initiate a project to migrate to a new vendor if the issue isn’t resolved in 30 days.

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

How to operationalise A 5.22 using your existing stack (Linear, Google Calendar).

  • Step 1: Schedule (Automated). Set a recurring task in Linear/Jira: “Quarterly Supplier Review – Tier 1.”
  • Step 2: Gather Data (Manual). Engineering Lead pulls uptime logs. Compliance Lead pulls the latest SOC 2 report from the vendor’s portal.
  • Step 3: Review (Manual). A 30-minute meeting to discuss: “Are they delivering? Are they secure? Have they changed terms?”
  • Step 4: Action (Manual). If issues are found, raise a support ticket with the vendor or log a risk in your Risk Register.
  • Step 5: Record (Manual). Save the meeting notes and the downloaded SOC 2 report in the “Supplier Evidence” folder in Google Drive.

By using the High Table ISO 27001 Toolkit, you can implement a robust supplier management programme without the overhead of complex software. The templates provide the structure you need to monitor, review, and manage changes effectively.

ISO 27001 Annex A 5.22 for AI Companies FAQ

What is ISO 27001 Annex A 5.22 for AI companies?

ISO 27001 Annex A 5.22 requires AI companies to monitor, review, and manage changes in supplier services. This ensures 100% oversight of LLM API providers, cloud infrastructure, and data-labelling vendors to maintain security and performance standards throughout the AI development and deployment lifecycle.

   

Why is monitoring AI suppliers critical for compliance?

   

Monitoring is critical because 72% of AI-related security incidents involve third-party vulnerabilities or service degradation. By actively reviewing supplier performance, AI firms can detect unauthorised changes in data handling or API security protocols, preventing model poisoning and proprietary data leaks before they impact production environments.

   

What are the key monitoring activities for AI vendors?

   

AI organisations must implement a continuous oversight framework for all critical ICT and data suppliers. Key activities include:

   
           
  • Performance Tracking: Monitoring LLM API latency, availability, and error rates to ensure model reliability.
  •        
  • Security Certification Reviews: Conducting quarterly reviews of supplier ISO 27001, SOC 2, or ISO 42001 certifications.
  •        
  • Data Residency Verification: Auditing 100% of training datasets to ensure compliance with geographic data sovereignty requirements.
  •        
  • Vendor Site Audits: Performing periodic security assessments of third-party data-labelling facilities and remote worker protocols.
  •        
   

How should AI firms manage changes in supplier services?

   

Change management under Annex A 5.22 involves formal impact assessments for vendor updates, such as model deprecations or API version shifts. Organisations must document 100% of major vendor changes to ensure that new features do not bypass established security guardrails or introduce unwanted algorithmic bias.

   

What evidence is required for Annex A 5.22 audits?

   

Auditors require proof of active supplier oversight and formal change logs. Essential evidence includes vendor performance dashboards, minutes from quarterly security review meetings, documented impact assessments for supplier updates, and updated risk registers reflecting the current status of the AI supply chain.

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