CF03-004: SSRM Implementation & Review

AI Control Library / CF-03: AI Supply Chain & Third-Party Risk

Designation: Core | Control types represented: Operational

Control requirement

Implement and periodically review the agreed shared responsibility model, verifying that assigned parties perform their duties and that changes, incidents and evidence expose gaps requiring correction.

Why this matters

A signed responsibility matrix can drift away from actual operations. New tools, changed service terms or staff turnover may leave a previously assigned safeguard unsupported without anyone noticing.

How the control types work together

Operational controls establish the supplier assessment, ownership, agreement and review processes described here. They work when the assigned parties perform the required activities and use evidence to guide decisions.

When it applies

Active AI services with shared internal or supplier responsibilities, including changes in deployment architecture and operating arrangements.

Tailor review depth to information sensitivity, granted authority and business dependence. Record what the organization can test directly, what relies on provider evidence and how material visibility gaps affect the acceptance decision.

Ownership

The AI service owner maintains the model; control owners provide evidence and supplier management coordinates unresolved provider issues.

Implementation guidance

  1. Translate assignments into procedures, configured controls, access rights and evidence schedules with named operational contacts.
  2. Verify representative safeguards and handoffs before consequential release; test the customer-owned parts directly where feasible.
  3. Review performance, incidents and missed evidence at a risk-based interval and after material service, contract or architecture changes.
  4. Reconcile the matrix with actual practice, assign corrective actions and verify closure rather than updating ownership labels alone.

How to verify it

Use representative deployment records and authorized controlled tests. Establish the assessed service, artifact version and acceptance conditions before interpreting results; do not extend evidence beyond the boundary it covers.

Test Expected result
Sample an assigned safeguard The named party performs it and can supply relevant evidence.
Exercise a shared incident or recovery handoff Receiving teams act within the agreed conditions.
Change a tool or provider feature Responsibilities are reassessed and implemented before the expanded use.

Record a finding when a required result cannot be demonstrated or actual practice differs materially from the accepted conditions. Assign corrective action and verify the affected boundary before closing the issue.

Evidence to retain

  • Current responsibility model
  • Implemented-control and evidence records
  • Handoff exercises
  • Review findings and corrective actions

Protect supplier-confidential information, credentials and personal data in these records. Preserve enough version and scope information to establish which service or artifact the evidence supports.

If the control fails

Escalate nonperformance or recurring handoff failure to service and supplier authorities. Restrict affected capabilities while required responsibilities remain unfulfilled.

Example in practice

Hypothetical example: A provider adds customer-managed connector credentials. The review updates secret rotation and revocation duties, verifies the customer’s procedure and tests revocation rather than simply revising the diagram.

Related controls

Framework mappings

  • CSA AICM (STA-06, STA-07)
  • NIST AI RMF (MANAGE 2.2)
  • EU AI Act (Art. 9(2))
  • ISO 42001 (Cl. 9.2, A9.1)

Review and maintenance

Review at the interval approved by the control owner and after relevant supplier, component, contract, access or deployment changes. Reassess material incidents and new evidence, updating acceptance conditions and verifying corrective actions where required.

Back to AI Supply Chain & Third-Party Risk

Version 1.0

Scroll to Top