What MOD's Cyber Security Model requires from AI suppliers

CSMv4 does not ask whether a supplier's technology is AI. It asks whether the supplier can meet the controls required for its assigned risk level, and whether it can prove it. An AI supplier that expects a lighter touch because the technology is newer, or a harder one because it sounds unfamiliar, is reading the model wrong either way.

How the model actually works

The Ministry of Defence's Cyber Security Model (CSM) is how defence builds cyber security into its supply chain, and version 4 (CSMv4) is the current live version, using the controls specified in Defence Standard 05-138 Issue 4. The process runs in a fixed sequence. At the earliest market engagement for a new opportunity, the MOD delivery team provides a Risk Assessment Reference and the required Cyber Risk Profile level, one of four: Level 0, Level 1, Level 2 or Level 3. A supplier intending to bid completes a Supplier Assurance Questionnaire (SAQ) through the Supplier Cyber Protection Service, self-assessing against that profile. The SAQ is scored automatically, and the supplier is told immediately whether it is compliant.

Defence condition 658 (DEFCON 658) is the contractual mechanism that makes this binding. It lays out the contractual terms for the Cyber Security Model and, critically, contains the obligations that a supplier must place on its own subcontractors. Where a prime contractor brings in a subcontractor, and that subcontractor brings in another, the same Risk Assessment and SAQ process repeats down every tier, each generating its own Cyber Risk Profile for that link in the chain.

An AI system used in a defence contract goes through the identical Risk Assessment, SAQ and flow-down process as a hardware or software vendor. The model does not have a separate track for it.

What happens when a supplier falls short

A non-compliant SAQ does not automatically end a bid. The supplier submits a Cyber Improvement Plan (CIP), setting out when and how it will reach the required level of compliance, with timescales or reasons for any gap. The CIP becomes part of the contract document itself, and the authority weighs compliance, or a credible CIP, in supplier selection. Annually, on the anniversary of contract award, the supplier completes a new SAQ to confirm it remains compliant with its Cyber Risk Profile; a lapse there triggers the same CIP process.

A newer layer sits alongside this: Defence Cyber Certification (DCC), developed with IASME as the scheme's Certification Authority, gives suppliers a way to independently evidence CSM compliance rather than self-assess alone. MOD guidance is clear that suppliers should expect increasing requirements to hold valid DCC certification. It is equally clear that a DCC certificate does not yet replace the SAQ: completing the full questionnaire through the Supplier Cyber Protection Service remains mandatory for the contractual risk assessment, whatever certification a supplier already holds.

Where an AI supplier specifically struggles

Def Stan 05-138's control set covers governance, asset and identity management, secure configuration, vulnerability management, monitoring and incident response, and the security of a supplier's own third-party dependencies. None of it is AI-specific, and that is exactly the point: an AI supplier has to answer the same questions as anyone else, with evidence, not a policy document describing an idealised system.

Two of those questions are genuinely harder to answer when the technology is an AI system rather than a conventional application. Asset and identity management asks which systems support delivery and who has access to them; an AI system whose behaviour or training data provenance a supplier cannot fully account for makes that question harder to answer with confidence. Supplier dependency assessment asks whether an organisation understands what a third party does with the access or information it receives; an AI vendor whose own infrastructure depends on further model or hosting providers the prime contractor has no visibility into extends that dependency chain further than a conventional software supplier typically would.

An AI system that runs on infrastructure the supplier or the MOD controls, and that produces a verifiable record of what it actually did, gives a supplier something concrete to point to when a Risk Assessment or an incident review asks these questions, rather than a description of intended behaviour that cannot be checked.

What this means in practice

A supplier bringing AI into a defence contract, as a prime or anywhere down the flow-down chain, should treat the Risk Assessment and SAQ exactly as it would for any other critical dependency: confirm the assigned Cyber Risk Profile, map the actual controls in Def Stan 05-138 against the AI system's real operating environment rather than an idealised one, and be ready to produce evidence, not a policy statement, if a control is questioned. Where a gap exists, a credible Cyber Improvement Plan is the honest route, not a claim of compliance the evidence cannot support.