Skip to content

Defence Standard 05-138

Status: In flight (Plan 100). WI-0 (foundation work) currently under way.

Scope

Defence Standard 05-138 Issue 4 (July 2024) is the UK MoD cyber security standard that contractors must meet when delivering systems to the Ministry of Defence. Although 05-138 predates the AI-specific guidance, its control set is what defence-supply-chain customers are contractually held to, so the Secruna pack treats it as a first-class framework rather than a sub-set of the AI Playbook.

05-138 is a profile-based standard: every system is assigned a Cyber Risk Profile based on the sensitivity of the data it handles and the consequence of compromise, and the control set the system must meet flows from the profile.

Profiles

Profile Description
Very Low Public information; minimal consequence of compromise.
Low Internal information; limited consequence of compromise.
Moderate Sensitive information; significant consequence of compromise.
High Highly sensitive information; severe consequence of compromise.

The profile is set at AI-system-creation time and drives which controls apply. Higher profiles inherit the controls of every lower profile.

Categories

Each control evaluates to one of three categories:

  • mandatory_control — the control is required at this profile level. Failure to meet it is a contractual breach.
  • recommended_control — the control is best practice at this profile but not contractually required. Customers typically meet these for defence-in-depth.
  • not_applicable — the control does not apply to this AI system at this profile.

Why it matters for AI

05-138 is not an AI standard, but every AI system in a defence context is also a software system, and software systems in a defence context fall under 05-138. The pack lets a defence-supplier customer maintain a single inventory of AI systems mapped against both the Defence AI Playbook (AI-specific obligations) and 05-138 (cyber security obligations) without double-entry.

Reference

UK Ministry of Defence, Defence Standard 05-138 Issue 4 (July 2024).

Plan references

  • Plan 100 WI-0 — Foundation: profile model on ai_systems, control taxonomy, 05-138 framework registration. In flight.
  • Plan 100 WI-1+ — Per-profile control YAML pack and matchers against the Plan 96 WI-3 category taxonomy. Scheduled after WI-0.

What's not in this pack

The cyber security controls 05-138 specifies are evaluated against the same artifact_metadata surface as the AI rule books. Where 05-138 controls require evidence outside Secruna's reach (e.g. physical security of a facility) the verdict is not_applicable_to_secruna and the control is flagged for the customer to evidence externally.

Analysis

Scope

Defence Standard 05-138 Issue 4 (July 2024) is the UK MoD's cyber security standard for contractors delivering systems into defence. It applies to every supplier — prime, sub, integrator, or service-provider — whose contract references the standard, which in practice means most MoD contracts touching networked systems. Geographic scope is UK MoD operational reach but propagates through the supply chain to non-UK suppliers via contract clauses. In scope: any system handling MoD information assets, including AI systems whose training data, model weights, or inference outputs classify as MoD information. The standard is profile-based: each system is assigned a Cyber Risk Profile (Very Low / Low / Moderate / High) based on data sensitivity and consequence of compromise, and the applicable control set follows from the profile. Out of scope: systems handling no MoD information (internal supplier R&D, public-domain reference systems); operator physical security; non-cyber operational security. 05-138 complements but does not replace the Defence AI Playbook: AI systems in defence fall under both, with the Playbook handling AI-specific obligations and 05-138 handling the cyber overlay.

Key obligations

  1. Profile assignment — every system must be assigned a Cyber Risk Profile at creation, justified by data classification and consequence-of-compromise analysis.
  2. Profile-driven control adherence — the controls applicable to the assigned profile must be evidenced; higher profiles inherit lower-profile controls.
  3. Mandatory controls — a subset of controls per profile are contractually required; failure is a breach.
  4. Recommended controls — best-practice controls that are not contractually required but expected for defence-in-depth.
  5. Supply chain propagation — primes must flow 05-138 obligations down to sub-contractors handling MoD information.
  6. Evidence retention — control evidence must be retained and producible on request through the contract lifetime.
  7. Change management — material changes to the system or its data flows trigger profile re-assessment and control re-evaluation.

Our coverage approach

The pack adds a cyber_risk_profile column on the ai_systems inventory entity (Plan 100 WI-0 in flight) so every AI system carries its profile alongside its framework subscriptions. The control taxonomy uses three categories (mandatory_control, recommended_control, not_applicable) consistent with the Plan 96 WI-3 cross-framework category enum work. Controls are evaluated against the same artifact_metadata surface the AI rule books use, so an AI system inventory item gets a single verdict view spanning 05-138 cyber controls and Defence AI Playbook AI obligations without double-entry. Mandatory controls map to verdicts that block deployment until cleared; recommended controls produce informational verdicts for defence-in-depth. The change-management obligation is served by the platform's audit log: any artifact change that affects profile-relevant attributes triggers re-evaluation of the applicable control set. Supply-chain propagation reuses the mechanism from the Defence AI Playbook pack — supplier-origin artifacts surface contract-clause guidance to the customer.

Gaps

Per-profile control YAML pack (Plan 100 WI-1) is scheduled after WI-0 lands; until then the control set is scaffolded but not fired against customer artifacts. Physical-security controls (facility access, secure-area handling) are explicitly outside Secruna's reach — verdicts return not_applicable_to_secruna and flag the control for the customer to evidence externally. Cryptographic-control evidence — 05-138 specifies key-management and crypto requirements that we partially evidence via connector artifacts but cannot fully evidence without integration with the customer's HSM or KMS; partial coverage is documented in the verdict copy. Profile-recalculation tooling — when a customer changes a system's data classification, the platform re-evaluates the control set, but the customer-facing migration UX (how to walk through the new gaps) is on the Plan 100 WI-2+ backlog. Counsel-reviewed contract clauses for supply-chain propagation are pending the UK defence-law specialist counsel hire.

Customer impact

05-138 enforcement is contractual rather than regulatory. The practical consequences for a non-compliant supplier are sharp. Bid disqualification: MoD invitations to tender increasingly require evidence of 05-138 capability before the technical evaluation; inability to evidence the standard fails the bid gate. Contract breach: an existing supplier failing a 05-138 audit faces remedies that range from corrective-action plans through fee withholding to contract termination, depending on control criticality. Supply-chain reach-back: a sub-contractor failure becomes the prime's problem — primes have been known to terminate sub-contracts to protect the head contract. Reputational and incident exposure: a cyber incident on a 05-138-non-compliant defence system has parliamentary-scrutiny consequences and meaningfully damages the supplier's standing in future MoD competitions. For AI systems specifically, 05-138 overlays the Defence AI Playbook obligations — a customer in scope of both faces compounded contractual exposure if either pack fails.