AICM AtlasCSA AI Controls Matrix
STA · Supply Chain Management, Transparency, and Accountability
STA-09Cloud & AI Related

Supply Chain Risk Management

Specification

Periodically review risk factors associated with supply chain relationships.

Threat coverage

Model manipulation
Data poisoning
Sensitive data disclosure
Model theft
Model/Service Failure
Insecure supply chain
Insecure apps/plugins
Denial of Service
Loss of governance

Architectural relevance

Physical infrastructure
Network
Compute
Storage
Application
Data

Lifecycle

Preparation

Data collection, Data curation, Data storage, Resource provisioning, Team and expertise

Development

Supply Chain

Evaluation

Re-evaluation, Validation/Red Teaming, Evaluation

Deployment

Orchestration, AI Services supply chain, AI applications

Delivery

Operations, Maintenance, Continuous monitoring, Continuous improvement

Retirement

Data deletion

Ownership / SSRM

PI

Owned by the Cloud Service Provider (CSP)

The Cloud Service Provider (CSP) is responsible for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with cloud computing (processing, storage, and networking) technologies in the context of the services or products they develop and offer. The CSP is responsible and accountable for implementing the control within its own infrastructure/environment. The CSP is responsible for enabling the customer and/or upstream partner to implement/configure the control within their risk management approach. The CSP is accountable for ensuring that its providers upstream implement the control related to the service/product developed and offered by the CSP.

Model

Owned by the Model Provider (MP)

The model provider (MP) designs, develops, and implements the control as part of their services or products to mitigate security, privacy, or compliance risks associated with the Large Language Model (LLM). Model Providers are entities that develop, train, and distribute foundational and fine-tuned AI models for various applications. They create the underlying AI capabilities that other actors build upon. Model Providers are responsible for model architecture, training methodologies, performance characteristics, and documentation of capabilities and limitations. They operate at the foundation layer of the AI stack and may provide direct API access to their models. Examples: OpenAI (GPT, DALL-E, Whisper), Anthropic(Claude), Google(Gemini), Meta(Llama), as well as any customized model.

Orchestrated

Shared Model Provider-Orchestrated Service Provider (Shared MP-OSP)

The MP and OSP are jointly responsible and accountable for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with Large Language Model (LLM)/GenAI technologies in the context of the services or products they develop and offer.

Application

Owned by the Application Provider (AP)

The Application Provider (AP) is responsible for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with Large Language Model (LLM)/GenAI technologies in the context of the services or products they develop and offer. The AP is responsible and accountable for the implementation of the control within its own infrastructure/environment. If the control has downstream implications on the users/customers, the AP is responsible for enabling the customer and/or upstream partner in the implementation/configuration of the control within their risk management approach. The AP is accountable for carrying out the due diligence on its upstream providers (e.g MPs, Orchestrated Services) to verify that they implement the control as it relates to the service/product develop and offered by the AP. These providers build and offer end-user applications that leverage generative AI models for specific tasks such as content creation, chatbots, code generation, and enterprise automation. These applications are often delivered as software-as-a-service (SaaS) solutions. These providers focus on user interfaces, application logic, domain-specific functionality, and overall user experience rather than underlying model development. Example: OpenAI (GPTs,Assistants), Zapier, CustomGPT, Microsoft Copilot (integrated into Office products), Jasper (AI-driven content generation), Notion AI (AI-enhanced productivity tools), Adobe Firefly (AI-generated media), and AI-powered customer service solutions like Amazon Rufus, as well as any organization that develops its AI-based application internally.

Implementation guidelines

[All Actors]
1. Establish a structured process to identify and assess risks associated with third-party AI tools, datasets, models, libraries, infrastructure, and service providers.

2. Periodically review supply chain relationships to evaluate exposure to vulnerabilities, data poisoning, model manipulation, licensing issues, and trustworthiness of upstream sources.

3. Maintain an up-to-date inventory of third-party AI dependencies and their associated risk classification.

4. Integrate threat intelligence, software composition analysis, and vendor assessments into the risk management process.

5. Define and test contingency plans for third-party failures, deprecations, or integrity violations that may impact AI system availability or performance.

[Shared between the MP, AP, OSP, CSP]
1. Implement incident response protocols for AI models, services, and cloud platforms to address security breaches or vulnerabilities in the supply chain.

2. Ensure all stakeholders are trained on incident response procedures and that these procedures are regularly tested.

Auditing guidelines

1. Verify the CSP conducts regular reviews of supply chain risks at least annually or after significant changes addressing operational, security, compliance, and reputational risks, such as onboarding a new infrastructure vendor or changes in data residency laws.

2. Confirm risk assessments are documented, kept up to date, and informed by indicators like SLA violations, security incidents, or audit findings (e.g., repeated downtime from a storage provider or failure to meet encryption standards while involving relevant internal teams).

3. Ensure that identified risks lead to mitigation actions such as revising third-party agreements, enhancing monitoring controls, or replacing non-compliant vendors and that these actions are tracked and supported by audit-ready documentation, especially when risks impact service availability or regulatory compliance.

Standards mappings

ISO 42001No Gap
42001: A.2.3 Alignment with other organizational policies
42001: A.10.3 Suppliers
27001: A.5.19 Information security in supplier relationships
27001: A.5.21 Managing information security in the information and communication technology (ICT) supply chain
27001: A.5.23 Information security for use of cloud services
27002: 5.19 Information security in supplier relationships
27002: 5.21 Managing information security in the information and communication technology (ICT) supply chain
27002: 5.23 Information security for use of cloud services
Addendum

N/A

EU AI ActPartial Gap
Article 9
Addendum

The EU AI Act does not explicitly state the requirement to "periodically review risk factors associated with the supply chain."

NIST AI 600-1No Gap
GV-6.1-005
RM-1.2-002
Addendum

N/A

BSI AIC4No Gap
C4 SR-03
C4 SR-04
C5 SSO-02
C5 SSO-04
Addendum

N/A

AI-CAIQ questions (1)

STA-09.1

Are risk factors associated with the supply chain relationships periodically reviewed?