Def Stan 05-138 Explained

A reference to Def Stan 05-138 often appears at an awkward point in a defence opportunity. A supplier has reached tender stage, received contractual security information or started preparing for assurance activity, and suddenly needs to understand how a broad defence standard translates into the technology, processes and people involved in day-to-day delivery.

The first instinct is usually to look for a checklist. That is understandable, but it can lead to the wrong kind of preparation. Def Stan 05-138 is not concerned only with whether an organisation has multi-factor authentication, endpoint protection or a set of approved policies. It looks at whether cyber security is operating as a coherent part of the business: whether systems are understood, access is managed, vulnerabilities are addressed, suppliers are governed, incidents can be handled and recovery arrangements have been tested.

For MOD suppliers, the practical challenge is therefore less about finding a single “compliance solution” and more about being able to explain how the business works securely. The standard provides the control model. The real work lies in applying those controls to the people, technology and third-party dependencies that support a defence contract.

Understanding Def Stan 05-138

Def Stan 05-138 sits within a wider defence cyber assurance landscape, but this page deliberately focuses on the standard itself: the controls it expects organisations to operate and the evidence that supports them.

For the broader picture—including CSMv4, Cyber Risk Profiles, DEFCON 658, Defence Cyber Certification, supply-chain flow-down and contract mobilisation—read Logiq’s Defence Supply Chain Cyber Security Guide. For suppliers working through a particular MOD assurance process, the relevant CSMv4 guidance remains the appropriate next step.

The purpose here is narrower and more practical. It is to help security, IT, delivery and commercial teams understand what Def Stan 05-138 looks like once it leaves the contract pack and reaches the operating environment.

What Def Stan 05-138 is designed to establish

Def Stan 05-138 Issue 4 sets out the cyber security controls expected of defence suppliers at the applicable level of assurance. The standard is structured around a risk-based model, but its underlying purpose is consistent across organisations of different sizes: suppliers should be able to protect the systems and operations that support defence delivery, and demonstrate that the controls they rely on are working.

That does not mean every supplier needs the operating model, budget or specialist capability of a major prime contractor. A small engineering firm, a software supplier and a large managed-service provider will all have different environments, different dependencies and different technical risks. The standard recognises that. What it does not allow is a purely theoretical approach to cyber security, where policies describe an idealised business while the actual environment has evolved around them.

A useful reading of the standard is that it turns broad security claims into testable questions. When an organisation says it controls access, can it show who has privileged access and how it is reviewed? When it says systems are patched, can it demonstrate the process, exceptions and remediation decisions? When it relies on a third party, does it understand how that dependency is governed and what would happen if the service became unavailable?

Those are the questions that separate a control that exists on paper from a control that can be relied upon in delivery.

The standard reaches beyond a project folder

One of the most persistent misunderstandings in defence cyber assurance is the idea that requirements can be contained within a single project workspace, shared drive or cloud tenant. This may appear workable at first, particularly where a programme has a defined information set and a relatively small delivery team. In reality, defence work rarely operates in such a clean boundary.

A team working on a contract may depend on corporate identity services, managed laptops, email, engineering tools, cloud platforms, outsourced IT support, backup services, software suppliers and specialist subcontractors. Even where a system does not hold defence information directly, it may still support a business-critical activity required to deliver the contract. If a compromise, outage or access-control failure in that system would interrupt delivery, it deserves consideration within the wider cyber model.

This is where Def Stan 05-138 becomes useful. It encourages suppliers to look beyond the immediate information asset and understand the environment that protects, processes, moves and supports it. The result should not be an artificially expanded scope that tries to include every application the business owns. It should be an honest view of the operations that matter, the dependencies they rely on and the controls needed to protect them.

Governance has to be visible in the operating model

Cyber security governance can become abstract very quickly. Most organisations have a policy, an accountable executive and some form of risk register. Those are important foundations, but Def Stan 05-138 requires suppliers to go further by showing how responsibility works when decisions need to be made.

That means identifying who owns critical systems, who has authority to accept a risk, who reviews security exceptions, who coordinates an incident and who can make a decision when a supplier’s service no longer provides the assurance expected. In a smaller organisation, some of those roles may sit with the same individual. In a larger business, responsibilities may be distributed across security, IT, operations, delivery, procurement and commercial teams. Either way, the arrangement needs to be explicit.

The strength of the model is revealed when something changes. A new cloud service is introduced, a key subcontractor is brought into the programme, an administrator leaves, a serious vulnerability is identified or a recovery test fails. Organisations with clear governance can identify the right decision-maker, understand the exposure and act without spending days establishing who owns the issue. Organisations without it tend to fall back on informal knowledge, delayed escalation and assumptions that are difficult to defend later.

Assets, identities and configuration form the practical security baseline

Def Stan 05-138 expects suppliers to understand the technology they rely on. That sounds obvious, but asset visibility is often incomplete in environments that have grown through acquisitions, rapid cloud adoption, remote working or outsourced IT provision.

A useful asset view is more than a spreadsheet of laptops. It should make clear which systems support critical operations, who owns them, where information is held, which services depend on third parties and how those services connect. The level of detail should be proportionate, but it must be sufficient for the organisation to answer practical questions when an incident, audit or change request occurs.

Identity and access management sits alongside this. Access should reflect a person’s role and current need, particularly where privileged administration, sensitive information or externally managed services are involved. Suppliers should be able to show how accounts are created, reviewed and removed; how privileged access is controlled; how shared accounts are avoided or tightly governed; and how service accounts are assigned an accountable owner.

Configuration matters for the same reason. Secure settings, encryption, endpoint controls, cloud configurations and administrative permissions are not one-off decisions. They need to be managed as the environment changes. A secure design at deployment can drift over time as teams introduce exceptions, add integrations or make urgent changes under delivery pressure.

Control area	The question that matters	Useful evidence
Asset management	Do we know which systems and services support delivery?	Asset records, service ownership, system diagrams and dependency maps
Access management	Can we show who has access and why?	Access reviews, MFA reporting, privileged-account records and leaver processes
Secure configuration	Are security settings controlled as the environment changes?	Configuration standards, compliance reports, change records and exception approvals
Vulnerability management	Can we identify, prioritise and resolve weaknesses consistently?	Scan results, remediation records, patch reports and risk decisions
Supplier assurance	Do we understand the controls and limitations of critical third parties?	Due diligence, contracts, assurance evidence and service reviews

Vulnerability management is a business process

Most organisations can produce evidence that they run vulnerability scans or apply software updates. The harder question is whether the process gives them a reliable view of exposure.

A mature vulnerability-management approach connects the inventory of systems, the tools used to identify weaknesses, the people responsible for remediation and the decisions made when a fix cannot be applied immediately. It should distinguish between a routine update on a low-risk device and a serious vulnerability affecting a system that supports delivery, sensitive information or remote access. It should also retain the evidence of what was found, what action was taken and why any exception was accepted.

This is particularly important where IT is outsourced. A managed-service provider may carry out patching, endpoint management or vulnerability scanning on behalf of the supplier. That can be a sensible delivery model. It does not remove the supplier’s need to understand what the service covers, how performance is measured, how exceptions are reported and where the evidence is retained.

The same principle applies to cloud services. Shared-responsibility models can be useful, but they do not eliminate accountability. A supplier still needs to know which controls are provided by the platform, which remain its responsibility and whether the operating model has been configured to meet the needs of the contract.

Monitoring, incident response and recovery need to work together

Security monitoring is often discussed as a technology purchase: centralised logging, detection tools, a security operations centre or endpoint telemetry. Those capabilities matter, particularly in more complex environments. Their value depends on the response process around them.

A supplier should understand what events are monitored, who receives alerts, how incidents are triaged, how serious events are escalated and how relevant evidence is retained. The answer may involve an internal team, a managed security provider or a combination of both. What matters is that the organisation can show how the arrangement works when it needs to.

Incident response should also connect to delivery reality. A ransomware event, compromised account or service outage can affect more than a particular device or data set. It can interrupt access to designs, prevent communication with subcontractors, delay programme milestones or compromise a critical shared service. Plans that concentrate only on technical containment, without considering delivery decisions and customer communication, often leave teams unprepared for the wider consequences.

Recovery is the other half of the equation. Backups matter, but a backup report does not prove that a business can recover a critical service. Suppliers should understand which systems need to be restored first, how long recovery would realistically take, whether restore processes have been tested and what dependencies could prevent the plan from working. The most useful evidence is usually generated by testing: restore exercises, incident simulations, documented decisions and tracked improvement actions.

Supplier dependencies should be understood before they become a problem

Defence delivery is rarely self-contained. Suppliers depend on hosting providers, managed-service providers, software vendors, external consultants, specialist engineering partners and subcontractors. Some relationships are straightforward; others are critical to the delivery model. Def Stan 05-138 expects organisations to recognise the difference.

The key question is not whether a third party has a recognised certification or a reassuring security statement. Those may be relevant inputs. The more important question is whether the supplier understands what that third party does, what business-critical service it supports, what information or access it receives, how assurance is maintained and what would happen if the relationship failed.

This applies equally to group services. A subsidiary may rely on a parent company for identity management, HR systems, IT support or network services. Those arrangements can be entirely appropriate, but they should not become invisible simply because they sit inside the same wider corporate structure. The operational dependency still exists, and the supplier needs a clear view of the controls that support it.

Evidence should show that controls are operating

Evidence gathering often becomes a last-minute scramble because organisations treat it as an assessment activity rather than an operational discipline. A request arrives, people search shared folders for policy documents and screenshots, and the resulting pack gives a fragmented view of the environment at a particular moment in time.

Def Stan 05-138 is better approached through evidence that is generated as part of normal management. Access reviews should produce records. Vulnerability remediation should produce tickets and decisions. Incident exercises should create actions and lessons learned. Supplier reviews should leave an auditable trail. Leadership oversight should be visible in risk discussions, approvals and exception management.

The strongest evidence also explains its own relevance. A policy may show what the organisation intends to do. A system report may show that a setting is enabled. A service review may show how a dependency is governed. Taken together, those items can support a credible conclusion that a control is designed appropriately and operating consistently.

The question to keep asking is simple: could an informed person understand how this control works without relying on the memory of the person presenting it?

Common weaknesses that undermine otherwise capable suppliers

The most common gaps are rarely dramatic technical failures. They tend to emerge at the points where responsibility crosses teams, systems or organisations.

A supplier may have strong endpoint protection but no reliable record of which devices support a critical service. It may have a capable managed-service provider but no evidence of how security performance is reviewed. It may run annual access reviews but overlook administrator accounts, service accounts or access provided to temporary specialists. It may have a well-written incident plan that has never been tested with the people who would make delivery and customer decisions during a serious event.

These issues are addressable. The difficulty comes when they are discovered only after an assurance request, a tender deadline or an incident. A structured review against the standard gives organisations an opportunity to find the joins early and assign ownership before those weaknesses become commercially significant.

A practical way to begin

Start by taking a small number of business-critical delivery activities and tracing how they work. Identify the people involved, the systems they use, the services they depend on, the access required and the likely impact if any part of that chain fails. This creates a more useful foundation than beginning with a generic spreadsheet of security tools.

From there, map the relevant controls to named owners and existing evidence. Where the organisation already has a strong process, record it clearly. Where the control depends on an external service, document the relationship and the assurance mechanism. Where a gap exists, define the remediation activity, the accountable owner and the decision needed to move it forward.

The purpose is not to create a parallel compliance bureaucracy. It is to make cyber security part of the way the business plans, delivers and sustains defence work. Done well, the result is a clearer operating model, better evidence and fewer surprises when a customer, assessor or internal leader asks how the organisation knows its controls are actually working.

---

---

---

Important note: This guide is intended as an overview to help organisations understand the principles and practical considerations of this topic. It is not a substitute for official guidance, contractual requirements or professional advice. Always refer to the latest official guidance and the specific requirements of your organisation, customer or contract before making implementation or compliance decisions. Last reviewed: 13 July 2026.