Procurement Security Requirement Governance

2. Summary

Procurement Security Requirement Governance mandates that organisations establish and enforce minimum security, governance, and operational-resilience requirements before any third-party AI component, model, service, library, or infrastructure dependency is approved for procurement and integration into an agent ecosystem. The procurement gate is the single most cost-effective control point in the supply-chain lifecycle: requirements that are not imposed before contract signature are orders of magnitude more expensive to negotiate after integration, and impossible to enforce after operational dependency has formed. This dimension ensures that every procurement decision involving AI agent components is conditioned on the vendor or supplier meeting documented security, governance, data-handling, incident-disclosure, and continuity thresholds — transforming procurement from a commercial negotiation into a governance checkpoint.

3. Example

Scenario A — Missing Security Requirements Lead to Credential Exposure: A mid-tier insurance firm procures a natural-language-processing inference service to power its claims-triage agent. The procurement team evaluates the vendor on cost (£0.004 per inference call), latency (sub-200ms p95), and accuracy (92.3% F1 on the firm's benchmark). No security requirements are specified in the request for proposal. The vendor stores inference logs — including the full text of customer claims containing personally identifiable information, medical records, and policy numbers — in an unencrypted object store with no access controls. Seven months after go-live, the vendor suffers a breach exposing 2.3 million inference logs. The firm faces ICO enforcement action, a £4.2 million fine under UK GDPR Article 83, and class-action litigation from affected policyholders. The vendor's contract contains no data-handling obligations, no breach-notification requirements, and no indemnification clause — because the procurement process never required them.

What went wrong: Procurement evaluated the vendor on functional and economic criteria only, with zero security or data-governance requirements. The vendor had no contractual obligation to encrypt data at rest, enforce access controls, or notify the firm of a breach. The firm had no legal basis to compel remediation. The £4.2 million fine and litigation costs exceeded the total three-year contract value of £380,000 by a factor of eleven. A procurement security checklist costing £2,000 to implement would have identified the unencrypted storage and missing breach-notification capability before contract signature.

Scenario B — Vendor Governance Gap Breaks Regulatory Chain: A wealth-management firm deploys a portfolio-rebalancing agent that relies on a third-party risk-scoring model. The firm is subject to FCA conduct-of-business rules requiring that recommendations be suitable for each client's risk profile. The procurement team verifies that the risk-scoring model's outputs are accurate but does not assess whether the vendor maintains model governance — versioning, drift monitoring, retraining controls, or audit trails. Fourteen months post-deployment, the vendor silently retrains its model on a new dataset, shifting the risk-score distribution. Conservative clients begin receiving moderate-risk recommendations. The shift is not detected for 11 weeks because the firm's monitoring compares agent outputs against the vendor's scores (which are internally consistent with the retrained model) rather than against an independent benchmark. During those 11 weeks, £23 million in client assets are allocated to positions misaligned with stated risk appetites. FCA investigation finds the firm failed to ensure adequate governance of a critical outsourced function.

What went wrong: The procurement process verified model accuracy at a single point in time but imposed no requirements for ongoing model governance — version control, drift monitoring, change-notification obligations, or audit-trail access. The vendor had no obligation to notify the firm of retraining events. The firm's monitoring design assumed model stability that was never contractually guaranteed. Consequence: £23 million in client-asset misallocation, FCA enforcement under SYSC 8.1.1R (outsourcing requirements), £1.7 million remediation costs, and reputational damage quantified at a 12% reduction in net new assets over two quarters.

Scenario C — Unassessed Open-Source Dependency Introduces Supply-Chain Attack Vector: A government agency deploys a citizen-services chatbot built on an orchestration framework that includes 347 transitive open-source dependencies. The procurement process evaluates the primary vendor (the orchestration framework provider) but imposes no requirements regarding the provenance, maintenance status, or security posture of transitive dependencies. One of the transitive dependencies — a logging utility maintained by a single developer — is compromised through a maintainer-account takeover. The compromised version exfiltrates environment variables, including API keys for the agency's internal case-management system. The agency discovers the compromise 19 days later when an anomalous API-usage pattern triggers an alert. During those 19 days, 41,000 citizen case records are accessed by the attacker. The agency faces Parliamentary scrutiny, a mandatory ICO breach report, and an estimated £8.6 million in notification, credit-monitoring, and remediation costs.

What went wrong: The procurement gate assessed only the direct vendor, not the transitive dependency chain. No requirement for Software Bill of Materials (SBOM) attestation, dependency-provenance verification, or vulnerability-scanning obligations was imposed at procurement. The vendor's contract did not address supply-chain security. The agency inherited the risk profile of 347 unassessed dependencies through a single procurement decision. A procurement requirement for SBOM delivery and dependency-provenance attestation (per AG-491) would have identified the single-maintainer risk and triggered either mitigation or vendor substitution before deployment.

4. Requirement Statement

Scope: This dimension applies to every procurement event — purchase, subscription, licence acquisition, open-source adoption decision, or service agreement — that introduces a third-party component into an AI agent's operational stack. "Component" includes but is not limited to: inference models, embedding services, vector databases, orchestration frameworks, monitoring tools, data-pipeline services, authentication providers, and any library or dependency that executes within or alongside the agent runtime. The dimension applies regardless of whether the procurement is a formal RFP-driven process or an informal decision by a development team to adopt an open-source library. For open-source adoption, the "vendor" equivalent is the project, its maintainers, and its governance structure. Organisations that procure through group purchasing arrangements or consortia remain individually responsible for verifying that the consortium's procurement requirements meet the standards defined here.

4.1. A conforming system MUST maintain a documented Procurement Security Requirements Baseline (PSRB) that defines minimum security, governance, data-handling, incident-disclosure, and operational-continuity requirements for all third-party AI components.

4.2. A conforming system MUST evaluate every proposed third-party AI component against the PSRB before procurement approval is granted, producing a documented assessment record that identifies conformant requirements, non-conformant requirements, accepted risks with justification, and compensating controls.

4.3. A conforming system MUST classify proposed third-party components by criticality tier — at minimum distinguishing between components whose failure would halt agent operation (critical), components whose failure would degrade agent operation (significant), and components whose failure would have minimal operational impact (low) — and apply proportionate procurement requirements to each tier.

4.4. A conforming system MUST require, as a procurement condition for critical-tier and significant-tier components, that the vendor or supplier provide evidence of: (a) encryption of data in transit and at rest, (b) access-control mechanisms with least-privilege enforcement, (c) vulnerability management and patching commitments with defined SLAs, (d) incident-notification obligations with maximum notification timelines, and (e) audit-trail capabilities covering all interactions with the organisation's data.

4.5. A conforming system MUST require, as a procurement condition for all tiers, delivery of a Software Bill of Materials (SBOM) or equivalent dependency manifest covering direct and transitive dependencies, updated at each major release.

4.6. A conforming system MUST ensure that procurement contracts include enforceable clauses requiring: (a) advance notification of material changes to the component's architecture, model, training data, or security posture, (b) right-to-audit or equivalent assurance-access provisions, and (c) defined data-handling and data-deletion obligations upon contract termination.

4.7. A conforming system MUST re-evaluate third-party components against the current PSRB at contract renewal or at least annually, whichever is more frequent, producing an updated assessment record.

4.8. A conforming system SHOULD maintain a pre-approved supplier registry for commonly used component categories, reducing procurement cycle time while ensuring baseline conformance.

4.9. A conforming system SHOULD require vendors of critical-tier components to provide independent security certifications or attestations (e.g., SOC 2 Type II, ISO 27001, or equivalent) as a procurement condition.

4.10. A conforming system SHOULD assess the vendor's financial viability and business-continuity posture as part of procurement evaluation for critical-tier components, with findings informing escrow and source-access requirements per AG-496.

4.11. A conforming system MAY implement automated PSRB compliance scanning that evaluates vendor-provided documentation and evidence against baseline requirements, flagging gaps for human review.

4.12. A conforming system MAY require vendors to participate in periodic joint tabletop exercises simulating security incidents affecting the procured component.

5. Rationale

The procurement boundary is the most cost-effective governance control point in the third-party supply chain. Research consistently demonstrates that the cost of imposing security and governance requirements increases exponentially as a component moves through the lifecycle: a requirement that costs £500 to negotiate at procurement costs £50,000 to retrofit after integration and £500,000 to remediate after a breach. Despite this, procurement processes for AI components frequently evaluate vendors on functional performance (accuracy, latency, throughput), economic terms (cost per call, licence fees, volume discounts), and integration ease (API compatibility, documentation quality) while treating security, governance, and operational-continuity requirements as optional or deferrable considerations. This creates a structural vulnerability: the organisation's governance posture is determined not by its own standards but by the weakest vendor in its supply chain.

The AI supply chain introduces risks that traditional software procurement frameworks do not adequately address. First, model governance risk: AI models are retrained, fine-tuned, and updated in ways that can materially change their behaviour without changing their interface. A vendor that retrains a risk-scoring model changes the effective decision logic of every agent consuming that model — a change invisible to traditional API-level monitoring. Procurement requirements must therefore extend beyond infrastructure security to model governance: versioning, drift monitoring, change notification, and audit-trail access. Second, transitive dependency risk: modern AI stacks involve hundreds of direct and transitive dependencies, each representing a potential supply-chain attack vector. The SolarWinds and Log4j incidents demonstrated that a single compromised dependency can propagate through thousands of organisations. For AI agents, the risk is amplified because compromised dependencies may manipulate model outputs, training data, or decision logic rather than simply exfiltrating data. Third, data-handling risk: AI components frequently process, store, and learn from organisational data. A vendor's data-handling practices directly determine the organisation's data-protection compliance posture. If the vendor stores inference logs containing personal data in unencrypted storage, the organisation is in breach of its data-protection obligations regardless of its own internal controls.

Regulatory frameworks increasingly recognise supply-chain governance as a first-party obligation. The EU AI Act Article 9 requires risk management to address risks arising from the interaction of AI systems with other systems, which includes third-party components. The Digital Operational Resilience Act (DORA) Article 28 imposes specific requirements for managing ICT third-party risk, including contractual provisions for access, audit, and incident notification. FCA SYSC 8 (Outsourcing) requires firms to exercise due skill, care, and diligence in selecting and monitoring outsourced service providers. SOX Section 404 requires that internal controls extend to outsourced processes that affect financial reporting. None of these frameworks permit an organisation to claim conformance while leaving its third-party AI components unassessed.

The procurement gate is also the only point at which the organisation has full negotiating leverage. Before contract signature, the vendor is motivated to accommodate governance requirements. After contract signature and integration, the cost of switching vendors — reintegration, revalidation, retraining — creates lock-in that eliminates the organisation's leverage. Requirements not imposed at procurement become requests that the vendor may decline without consequence.

6. Implementation Guidance

Procurement Security Requirement Governance must be embedded into the procurement workflow as a mandatory gate — not an advisory checklist that can be overridden by commercial urgency. The PSRB is the central artefact: a documented, versioned set of requirements that every proposed third-party component must be evaluated against before procurement approval. The PSRB must be maintained as a living document, updated to reflect evolving threats, regulatory changes, and lessons learned from vendor incidents.

Recommended patterns:

• Tiered PSRB with proportionate requirements. Define three or more criticality tiers with escalating requirements. Low-tier components (e.g., a formatting library with no data access) require SBOM delivery and licence compliance. Significant-tier components (e.g., a vector database storing embeddings) require SBOM delivery, encryption attestation, access-control documentation, vulnerability management SLAs, and incident-notification obligations. Critical-tier components (e.g., an inference model making financial decisions) require all significant-tier requirements plus independent security certification, model-governance documentation, right-to-audit clauses, escrow arrangements per AG-496, and financial-viability assessment. This tiering prevents over-governance of low-risk components while ensuring high-risk components receive commensurate scrutiny.
• Procurement security assessment template. Provide procurement teams with a structured assessment template aligned to the PSRB. The template should enumerate each baseline requirement, provide guidance on acceptable evidence, and include a risk-acceptance workflow for requirements that the vendor cannot meet. Risk acceptance requires approval by a governance authority (not the procurement team), documentation of compensating controls, and a defined review date. This prevents procurement teams from waiving requirements without governance oversight.
• Pre-approved supplier registry. Maintain a registry of vendors and components that have been evaluated against the PSRB and found conformant. Teams procuring a component from the registry can proceed without a full assessment, reducing friction. Registry entries have defined validity periods (e.g., 12 months) and are revoked if the vendor's posture changes. The registry accelerates compliant procurement without bypassing governance.
• Automated SBOM and vulnerability analysis. Integrate automated tooling that ingests vendor-provided SBOMs, cross-references dependencies against vulnerability databases, identifies known-vulnerable components, and flags single-maintainer or unmaintained dependencies. This transforms SBOM delivery from a compliance checkbox into an actionable risk-assessment input.
• Contract clause library. Maintain a library of pre-approved contract clauses covering security, data handling, incident notification, audit access, change notification, and termination obligations. Procurement teams select applicable clauses based on the component's criticality tier. Legal review is required only for deviations from the standard clauses, reducing procurement cycle time.

Anti-patterns to avoid:

• Security-as-an-afterthought. Evaluating vendors on functional and commercial criteria first, then attempting to add security requirements to a vendor already selected. By the time the security team is consulted, the procurement decision has been made commercially, and security requirements become negotiation items rather than prerequisites.
• Checkbox compliance without evidence. Accepting vendor self-attestation ("Yes, we encrypt data at rest") without requiring evidence (encryption configuration documentation, independent audit report, or right to verify). Self-attestation without evidence is not assurance — it is a liability disclaimer.
• Ignoring transitive dependencies. Evaluating only the direct vendor without assessing the transitive dependency chain. A vendor with excellent internal security practices but 400 unassessed transitive dependencies transfers those 400 risk profiles to the procuring organisation.
• Static PSRB with no update mechanism. Defining a PSRB once and never updating it. The threat landscape, regulatory environment, and available vendor capabilities evolve continuously. A PSRB defined in 2024 will not address supply-chain attack techniques prevalent in 2026.
• Procurement bypass for open-source adoption. Treating open-source adoption as a development decision rather than a procurement decision. Every open-source component that enters the agent's runtime is a procurement event — it introduces third-party code with its own security posture, maintenance status, and licence obligations. Open-source adoption must pass through the same PSRB gate as commercial procurement.

Industry Considerations

Financial Services. FCA-regulated firms must comply with SYSC 8 outsourcing requirements and ensure that critical outsourced functions are subject to adequate due diligence. The PSRB for financial-services organisations should include: SOC 2 Type II or equivalent for critical-tier vendors, contractual audit-access rights compliant with FCA supervisory expectations, data-residency requirements aligned with PRA SS2/21, and model-governance requirements for any vendor-supplied model that influences financial decisions. DORA Article 28 adds specific contractual requirements for ICT third-party services, including performance targets, termination rights, and exit strategies.

Healthcare and Life Sciences. AI components processing patient data must comply with jurisdiction-specific health-data regulations (UK Data Protection Act 2018 special-category provisions, HIPAA in the US, or equivalent). The PSRB should include: data-processing agreements compliant with applicable health-data regulations, restrictions on secondary use of patient data, and requirements for clinical-safety certification where the component influences clinical decisions.

Public Sector. Government agencies procuring AI components face additional requirements including supply-chain nationality restrictions, security-clearance requirements for vendor personnel with data access, and compliance with government procurement regulations. The PSRB should incorporate relevant government security frameworks and mandatory requirements for UK government suppliers (Cyber Essentials Plus or equivalent).

Crypto/Web3. Smart-contract and decentralised-finance agents face unique supply-chain risks including immutable deployment (once a vulnerability is deployed on-chain, it cannot be patched), oracle dependency (price-feed providers whose compromise can trigger cascading liquidations), and bridge-protocol risk. The PSRB should include: formal-verification requirements for critical smart-contract dependencies, oracle-provider redundancy requirements, and bridge-protocol security audit obligations.

Maturity Model

Basic Implementation — The organisation has a documented PSRB covering security, data handling, and incident notification for critical-tier components. Every proposed critical-tier component is evaluated against the PSRB before procurement approval, with a documented assessment record. Procurement contracts include enforceable clauses for data handling, incident notification, and audit access. Open-source adoption for components in the agent runtime follows the same assessment process. Annual re-evaluation of existing critical-tier vendors is performed.

Intermediate Implementation — All basic capabilities plus: the PSRB covers all three tiers with proportionate requirements. A pre-approved supplier registry accelerates compliant procurement. Automated SBOM analysis identifies vulnerable and unmaintained dependencies. Vendor financial-viability assessment is performed for critical-tier components. The PSRB is reviewed and updated at least annually. Contract clause libraries standardise governance terms. Procurement assessment records are linked to ongoing vendor-monitoring programmes.

Advanced Implementation — All intermediate capabilities plus: continuous vendor-posture monitoring detects changes in vendor security status between assessments. Automated PSRB compliance scanning reduces manual assessment effort. Joint tabletop exercises with critical-tier vendors test incident-response coordination. The PSRB is mapped to regulatory requirements across all applicable jurisdictions with automated gap detection. Procurement decisions are integrated with escrow and source-access arrangements per AG-496. The organisation can demonstrate through metrics that procurement security requirements have prevented specific vendor-related risks.

7. Evidence Requirements

Required artefacts:

• Procurement Security Requirements Baseline (PSRB). The current PSRB document showing all baseline requirements organised by criticality tier, with version history, approval records, and the date of last review. Format: structured document or machine-readable specification.
• Procurement assessment records. A complete assessment record for each third-party AI component, showing: the component's criticality tier classification with justification, each PSRB requirement evaluated with conformance status, evidence references, non-conformant requirements with risk-acceptance records and compensating controls, and assessor identities and assessment dates.
• Contract governance clauses. Copies of the executed contract clauses covering security, data handling, incident notification, audit access, change notification, and termination obligations for each third-party component. Alternatively, a mapping showing which standard contract clauses apply to each component.
• SBOM and dependency analysis records. The most recent SBOM for each critical-tier and significant-tier component, together with dependency-analysis results showing identified vulnerabilities, unmaintained dependencies, and remediation status.
• Annual re-evaluation records. Assessment records for the most recent annual re-evaluation of each critical-tier component, showing any changes in conformance status since the prior evaluation and any remediation actions taken.
• Pre-approved supplier registry. The current registry with validity dates, assessment references, and revocation history (if a registry is maintained).

Retention requirements:

• Procurement assessment records and contract governance clauses: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise. SBOM records: retain current and two prior versions.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. Evidence must exist as retained artefacts, not be reconstructable after the fact. Procurement assessment records must be traceable to the specific contract and component version they evaluate.

8. Test Specification

Test 8.1: PSRB Existence and Completeness

• Stimulus: Request the current PSRB. Verify that it defines requirements across at least: encryption (transit and rest), access control, vulnerability management, incident notification, data handling, SBOM delivery, audit access, and change notification. Verify that requirements are differentiated by criticality tier.
• Expected behaviour: A versioned, approved PSRB exists covering all required domains with tier-differentiated requirements.
• Pass criteria: The PSRB covers all eight specified domains. Requirements are differentiated across at least three criticality tiers. The PSRB has a version identifier, approval record, and a review date within the past 12 months.
• Fail criteria: The PSRB is missing, unversioned, not approved, or fails to cover any of the eight specified domains, or lacks tier differentiation.

Test 8.2: Procurement Gate Enforcement

• Stimulus: Attempt to procure (or simulate procurement of) a critical-tier AI component without completing a PSRB assessment. Verify that the procurement workflow blocks approval until the assessment is complete.
• Expected behaviour: The procurement process rejects or holds procurement approval for any component lacking a completed PSRB assessment.
• Pass criteria: Procurement is blocked for the unassessed component. The system or process produces a record showing the reason for rejection.
• Fail criteria: Procurement proceeds without a completed PSRB assessment, or the rejection is not recorded.

Test 8.3: Assessment Record Completeness for Critical-Tier Component

• Stimulus: Select three critical-tier components currently in production. Retrieve their procurement assessment records. Verify that each record includes: criticality-tier classification with justification, evaluation of every PSRB requirement, evidence references for conformant requirements, risk-acceptance records with governance approval for any non-conformant requirements, and assessor identities.
• Expected behaviour: All three components have complete, traceable assessment records.
• Pass criteria: All three assessment records include every required element. Risk acceptances have governance-authority approval (not procurement-team-only approval). Evidence references are resolvable (the referenced evidence exists and is retrievable).
• Fail criteria: Any assessment record is missing, incomplete, or contains risk acceptances without governance-authority approval.

Test 8.4: SBOM Delivery and Analysis Verification

• Stimulus: Select two critical-tier and two significant-tier components. Request their most recent SBOMs. Verify that SBOMs were delivered as a procurement condition, that they cover direct and transitive dependencies, and that dependency analysis has been performed (vulnerability scanning, maintainer-status assessment).
• Expected behaviour: All four components have current SBOMs with completed dependency analysis.
• Pass criteria: SBOMs exist for all four components, cover both direct and transitive dependencies, and are dated within the past 12 months or the last major release. Dependency-analysis records exist showing vulnerability findings and their resolution status.
• Fail criteria: Any component lacks an SBOM, the SBOM covers only direct dependencies, or no dependency analysis has been performed.

Test 8.5: Contract Clause Verification

• Stimulus: Select three critical-tier component contracts. Verify that each contract includes enforceable clauses for: (a) advance notification of material changes, (b) right-to-audit or equivalent assurance access, (c) data-handling and data-deletion obligations upon termination, (d) incident-notification obligations with maximum timelines, and (e) vulnerability-patching SLAs.
• Expected behaviour: All three contracts contain all five required clause categories.
• Pass criteria: All five clause categories are present in all three contracts, with specific and enforceable terms (not aspirational language). Incident-notification timelines are explicit (e.g., "within 72 hours"), not vague (e.g., "promptly").
• Fail criteria: Any contract is missing any of the five required clause categories, or clauses contain only aspirational language without enforceable terms.

Test 8.6: Annual Re-Evaluation Execution

• Stimulus: Select three critical-tier components that have been in production for more than 12 months. Retrieve their most recent re-evaluation records. Verify that re-evaluation has been performed within the past 12 months or at the most recent contract renewal, whichever is more recent.
• Expected behaviour: All three components have current re-evaluation records.
• Pass criteria: Re-evaluation records exist for all three components, dated within the past 12 months. Records show the current PSRB version used for re-evaluation (not the original procurement-time version). Any changes in conformance status are documented with remediation actions or updated risk acceptances.
• Fail criteria: Any component lacks a re-evaluation record within the past 12 months, or re-evaluation used an outdated PSRB version.

Test 8.7: Criticality-Tier Classification Accuracy

• Stimulus: Select five third-party components across all tiers. Independently assess their criticality based on the organisation's documented classification criteria. Compare independent assessment against the organisation's assigned tier.
• Expected behaviour: Independent tier classification matches the organisation's assigned tier for all five components.
• Pass criteria: At least four of five components are correctly classified. Any misclassification is in the conservative direction (classified at a higher tier than necessary, not a lower tier).
• Fail criteria: Fewer than four components are correctly classified, or any component is classified at a lower tier than its actual criticality warrants.

Conformance Scoring

• Score 0: No procurement security requirements exist — third-party AI components are procured based solely on functional and commercial criteria with no security, governance, or data-handling evaluation.
• Score 1: A PSRB exists and is applied to critical-tier components, but assessment records are incomplete, contract clauses are inconsistent, and no annual re-evaluation is performed. Open-source adoption is not covered.
• Score 2: The PSRB is tiered, versioned, and applied to all component tiers. Assessment records are complete and traceable. Contract clauses cover all required domains. SBOM delivery and analysis are operational. Annual re-evaluation is performed. Open-source adoption passes through the procurement gate.
• Score 3: Verified by independent audit — an independent party has validated PSRB completeness, assessment-record quality, contract-clause enforceability, and re-evaluation execution across a representative sample of components. Continuous vendor-posture monitoring supplements annual re-evaluation. Procurement metrics demonstrate measurable risk reduction.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Supports compliance
EU AI Act	Article 17 (Quality Management System)	Supports compliance
SOX	Section 404 (Internal Controls Over Financial Reporting)	Supports compliance
FCA SYSC	8.1.1R (Outsourcing Requirements)	Direct requirement
NIST AI RMF	GOVERN 1.5 (Third-Party AI Risk Management)	Direct requirement
ISO 42001	Clause 6.1.2 (AI Risk Assessment)	Supports compliance
DORA	Article 28 (General Principles for ICT Third-Party Risk Management)	Direct requirement

EU AI Act — Article 9 (Risk Management System) and Article 17 (Quality Management System)

The EU AI Act requires providers of high-risk AI systems to implement a risk management system that identifies and analyses "reasonably foreseeable risks" including those arising from the system's interaction with other systems and components. Third-party AI components introduce risks — model drift, data-handling failures, supply-chain compromise — that the organisation cannot manage unless they are identified and contractually mitigated at procurement time. Article 17 extends this to the quality management system, which must cover "the management and operation of the AI system, including procedures for examination, testing and validation at every stage of the development process." Quality cannot be managed for third-party components whose security posture, governance practices, and change-management processes are unknown. AG-495 ensures that the risk management and quality management systems extend to the procurement boundary.

SOX — Section 404 (Internal Controls Over Financial Reporting)

For organisations subject to SOX, third-party AI components that influence financial reporting — risk-scoring models, fraud-detection systems, revenue-recognition agents — are within the scope of internal controls. An auditor assessing the effectiveness of internal controls must evaluate whether the organisation has adequate controls over outsourced functions. A procurement process that does not assess vendor security, data handling, or governance creates a gap in internal controls that could constitute a material weakness. AG-495 provides the structured procurement gate that satisfies the auditor's expectation of vendor due diligence.

FCA SYSC — 8.1.1R (Outsourcing Requirements)

SYSC 8 requires FCA-regulated firms to exercise due skill, care, and diligence in selecting service providers and to ensure that outsourcing does not impair the quality of internal controls or the FCA's ability to monitor compliance. The procurement security baseline directly implements the due-diligence requirement by establishing minimum standards that every vendor must meet. The contractual clauses required by AG-495 — audit access, incident notification, change notification — support the FCA's supervisory access expectations. Firms that procure AI components without a structured security assessment are prima facie non-compliant with SYSC 8.1.1R.

NIST AI RMF — GOVERN 1.5 (Third-Party AI Risk Management)

GOVERN 1.5 addresses the management of risks arising from third-party AI technologies. It recommends that organisations establish processes to evaluate third-party AI risks, including supply-chain risks, and incorporate these evaluations into procurement and acquisition decisions. AG-495 operationalises this recommendation by defining the PSRB as the evaluation mechanism and the procurement gate as the enforcement mechanism.

ISO 42001 — Clause 6.1.2 (AI Risk Assessment)

ISO 42001 requires organisations to identify risks associated with the AI management system, including risks introduced by external providers. A procurement process that does not assess external-provider risks leaves the AI risk assessment incomplete. AG-495 ensures that third-party risks are identified and mitigated at the procurement boundary, providing input to the ISO 42001 risk assessment.

DORA — Article 28 (General Principles for ICT Third-Party Risk Management)

DORA Article 28 mandates that financial entities manage ICT third-party risk throughout the lifecycle, beginning with pre-contractual assessment. It requires contractual provisions addressing security, audit, data protection, and exit strategy. AG-495's PSRB and contract-clause requirements directly implement DORA Article 28's pre-contractual assessment and contractual-provision mandates. The annual re-evaluation requirement aligns with DORA's ongoing monitoring expectations.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	Organisation-wide — every agent relying on an unassessed third-party component inherits the vendor's unknown risk profile, potentially affecting all agent operations, customer data, and regulatory compliance across the enterprise

Consequence chain: Without procurement security requirements, third-party AI components are evaluated solely on functional and economic criteria. The immediate effect is that the organisation has no visibility into the security posture, governance practices, data-handling behaviours, or operational-resilience capabilities of its vendors. This creates latent vulnerabilities that manifest when a vendor suffers a breach (exposing organisation and customer data), silently changes a model (shifting agent decision-making without notice), is compromised through a supply-chain attack (propagating malicious code into the agent runtime), or fails commercially (removing a critical component with no transition plan). Each of these failure modes has been observed in production AI deployments. The downstream consequence is regulatory enforcement: every applicable regulatory framework — EU AI Act, SOX, FCA SYSC, DORA, ISO 42001 — treats supply-chain governance as a first-party obligation. The organisation cannot defend a procurement decision that imposed no security requirements by arguing that the vendor was responsible for its own security. The ultimate business consequence is financial loss (breach remediation, regulatory fines, customer compensation), operational disruption (agent downtime during vendor transitions), and reputational damage (loss of customer trust when a vendor-originated incident is attributed to the organisation). The cost of remediation after an incident consistently exceeds the cost of procurement security assessment by one to two orders of magnitude.

Cross-references: AG-007 (Governance Configuration Control) governs the configuration artefacts that procurement requirements protect. AG-493 (Subprocessor Governance) addresses ongoing vendor oversight after procurement. AG-489 (Open-Source Licence Policy Binding Governance) governs licence compliance for open-source dependencies identified through procurement assessment. AG-491 (Dependency Provenance and SBOM Attestation Governance) provides the SBOM framework consumed by procurement analysis. AG-492 (Contractor Access Segregation Governance) governs access controls for contractor personnel involved in procured component integration. AG-494 (Vendor Incident Disclosure Governance) governs the incident-notification obligations that procurement contracts must include. AG-496 (Escrow and Source-Access Governance) governs continuity arrangements triggered by procurement financial-viability assessments. AG-369 (Connector Capability Whitelist Governance) governs the capabilities exposed to procured third-party components.