DEFSTAN 05-138 cybersecurity: what the evidence standard actually requires
Sienna VanceApril 29, 2026
Key takeaways
DEFSTAN 05-138 supplier assurance requirements cannot be satisfied by self-attestation questionnaires alone — MoD assessors request independent verification evidence, and suppliers who rely only on completed questionnaires have no audit-ready response when challenged.
The framework's incident response requirements specify demonstrable capability, not documented policy. An organization with a 24-hour reporting SLA in its policy document that takes 48 hours to begin an investigation is non-compliant on the evidence standard, not the documentation standard.
Configuration baseline gaps under Part 3 Section 3 most commonly appear on network devices and embedded systems, not operating systems — the assets that endpoint management tools cover are not the ones where configuration drift creates exploitable exposure.
DEFSTAN 05-138 Part 4 Section 3 information risk management evidence must cover internal network segmentation, not just perimeter controls — auditors who find perimeter evidence without segmentation validation treat the gap as a finding, not an oversight.
Suppliers in the MoD supply chain face cascading contractual exposure when a prime contractor's assurance program cannot verify sub-supplier security posture — the evidence liability travels up the chain, not down.
TL;DR
DEFSTAN 05-138 is a framework where the evidence standard matters more than the control list. Most MoD suppliers can produce documentation. Fewer can produce audit-ready evidence that demonstrates controls operating under realistic conditions — incident timelines that match stated SLAs, configuration baselines that cover network devices and not just endpoints, supplier assurance files that contain independent verification rather than completed questionnaires. The gap between documentation and demonstrable evidence is where compliance breaks down, and where regulatory exposure concentrates.
The evidence package that did not survive the audit
A tier-two defense supplier in the UK spent four months preparing documentation for a DEFSTAN 05-138 assessment. Security policies were written, reviewed, and approved at board level. An incident response procedure was documented in detail, including escalation paths, reporting timelines, and accountable executives. Configuration standards were recorded for all production servers. The evidence package was substantial.
The assessor asked for the incident timeline from the most recent security event. The documented procedure specified a 24-hour detection-to-report window. The actual timeline, reconstructed from system logs, showed 72 hours between first indicator and internal notification, and a further 48 hours before the accountable executive was informed. The policy was correct. The evidence contradicted it. The assessment finding was not a documentation gap — it was a demonstrable failure of the control the documentation described. That distinction is the central compliance risk in DEFSTAN 05-138, and most suppliers do not understand it until an assessor makes it explicit.
Why DEFSTAN 05-138 evidence requirements are stricter than they appear
DEFSTAN 05-138 is structured around four parts covering supplier assurance, secure development, system assurance, and information risk management. Each part specifies controls. What the framework does not make explicit in its control language — but what MoD assessors apply in practice — is that evidence must demonstrate operational effectiveness, not just policy existence.
This distinction matters in a specific way. A documented incident response procedure satisfies the policy requirement. An incident timeline showing the procedure was followed satisfies the evidence requirement. These are not the same thing, and the evidence requirement is the one that matters during an assessment. Organizations that prepare for DEFSTAN 05-138 audits by producing documentation packages without behavioral evidence — logs, timelines, configuration change records, exception handling records — are preparing for the wrong test.
The framework's information risk management requirements under Part 4 Section 3 are where this gap is most consequential. The section requires that risk be managed to limit the impact of security incidents. Auditors interpret this as requiring evidence that containment controls — specifically internal network segmentation — actually function, not merely that firewall rules exist. A perimeter that appears well-configured in submitted evidence but sits in front of a flat internal network does not satisfy Part 4 Section 3 on its evidence standard. It satisfies a superficial reading of the documentation requirement.
From a regulatory evidence standpoint, the question an MoD assessor is answering is: if an incident occurred, would the controls described in this documentation have limited its impact? The evidence must support an affirmative answer. Policy documents alone cannot.
Example
A first-tier MoD contractor produced evidence of firewall rules for their external perimeter as part of a system assurance package under Part 3. The rules were correctly configured and the documentation was clean. The assessor requested evidence of internal segmentation between the development environment and the production network handling classified data. No such evidence existed because the segmentation had not been implemented — the development and production environments shared a network segment. The external perimeter evidence was accurate. It was also irrelevant to the finding. The framework's blast radius limitation requirement was unmet, and the perimeter evidence did not speak to it.
Configuration baseline requirements under Part 3 Section 3 extend to network devices, embedded systems, and operational technology components — not just operating systems and application servers. Endpoint management platforms that report clean configuration compliance across managed workstations produce evidence that satisfies a subset of the baseline requirement. Unmanaged network infrastructure and embedded components that are outside the endpoint management tool's scope contribute to the same evidence obligation and are routinely absent from submitted configuration baseline documentation.
What DEFSTAN-related assessments surface
Assessment base: Vulnox framework assessments including DEFSTAN 05-138 and related UK defense and supply chain security requirements, 2023-2025
Incident response SLA evidence contradicted by log reconstruction
In assessments where we reconstructed incident timelines from system logs and compared them to documented SLA commitments, the documented timeline and the log-derived timeline matched in a minority of cases. The most common discrepancy was between stated detection windows and actual time from first indicator to internal acknowledgment. Organizations with 24-hour response commitments in policy regularly showed 48 to 96 hours between first indicator and any documented internal action. The policy was accurate as a statement of intent. The logs showed what actually happened.
DEFSTAN 05-138 assessors request incident timelines specifically because the gap between policy intent and operational reality is predictable and well-known. An organization that has not tested its incident response procedure against a realistic scenario — not a tabletop exercise, but a log reconstruction against an actual event — does not know whether its evidence will survive an audit. The assessment finding in these cases is not remediated by revising the policy. It is remediated by demonstrating that the procedure operates as documented.
Supplier assurance files built entirely on self-attestation
Across assessments involving supplier assurance review, the majority of supplier files consisted of completed questionnaires without accompanying independent verification evidence. Penetration test reports from sub-suppliers were absent. Configuration audit results were absent. The questionnaire responses stated security controls were in place. Nothing in the file demonstrated they were. In several cases, questionnaire responses described controls that a basic external reconnaissance of the supplier's domain contradicted — publicly exposed services running outdated software, subdomains serving error pages that revealed internal system architecture.
DEFSTAN 05-138 Part 2 Section 3 supplier assurance requirements are not satisfied by a completed questionnaire. MoD assessors reviewing a supplier assurance program expect evidence that the prime contractor has verified, not merely collected, supplier security posture claims. An assurance file that contains only questionnaire responses gives an assessor no basis for confidence in the sub-supplier's controls. The regulatory exposure for the prime contractor when a sub-supplier experiences a breach and the assurance file is reviewed is significant — the file demonstrates that assurance was delegated to self-attestation, which is not assurance.
Configuration baselines covering endpoints but not network infrastructure
Configuration baseline documentation submitted for DEFSTAN Part 3 compliance consistently covered operating system builds and application configurations. Network device configurations — switches, routers, firewalls, VPN concentrators — were absent from baseline documentation in the majority of cases reviewed. Where network device configurations existed, they had not been reviewed against a current baseline within the preceding 12 months. Embedded systems and OT-adjacent components were absent from baseline documentation in every case where they were present in the environment.
The configuration baseline requirement does not have a carve-out for network infrastructure. An assessor reviewing a configuration management program that covers endpoints but not network devices has a finding. The more consequential issue is that network device configuration drift is how lateral movement becomes possible after a perimeter breach — the same gap that produces a compliance finding also produces an exploitable internal network. The finding and the risk are the same problem.
The part of DEFSTAN 05-138 that trips up the most prepared suppliers
Common belief
Organizations approaching DEFSTAN 05-138 compliance for the first time assume the documentation-heavy controls are the difficult ones — incident response plans, information risk management policies, supplier assurance procedures. They invest in writing comprehensive policies and believe the operational controls will be easier to evidence because they are more concrete.
What we found
In assessments involving both documentation review and log-based evidence reconstruction, organizations with the most detailed policy documentation did not perform better on evidence-based findings than organizations with lighter documentation. The correlation was effectively zero. Detailed policies predicted nothing about whether the controls described in them were actually operating.
The reality is the opposite. Documentation-heavy controls are satisfied by documentation. The assessor reviews the policy, confirms it covers the required elements, and moves on. The difficult controls are the ones where evidence must demonstrate operational reality, not stated intent.
Supplier assurance is the clearest example. A supplier assurance policy is straightforward to write. A supplier assurance file that demonstrates actual verification of sub-supplier security posture is hard to produce because it requires having done the verification — engaging sub-suppliers for penetration test reports, conducting configuration audits, or running independent external reconnaissance. Most prime contractors have done none of this. They have collected questionnaires and filed them. The policy describes an assurance program. The file demonstrates a questionnaire collection program. These are not the same thing, and the evidence standard distinguishes between them.
The same pattern applies to incident response. A detailed incident response plan with clear escalation paths and reporting timelines satisfies the documentation requirement completely. What it does not do is demonstrate that the plan works. Assessors who request incident timelines from recent events are applying the evidence standard, not the documentation standard. Organizations that have invested in policy writing without investing in testing do not have a compliance problem with their documentation — they have a compliance problem with their evidence.
What DEFSTAN 05-138 suppliers say before an assessment — and what it reveals
'We have CrowdStrike deployed across all our endpoints. That covers our system assurance requirements.'
Root cause:EDR deployment is a detection and response control. DEFSTAN 05-138 system assurance requirements under Part 3 cover configuration management, secure development practices, and validation of system security throughout the lifecycle — not endpoint detection coverage. CrowdStrike on all endpoints does not produce configuration baseline evidence, does not address network device configuration management, and does not speak to secure development practices for systems in scope. The belief that EDR deployment satisfies system assurance reflects a misreading of what Part 3 requires and what EDR does.
'Our suppliers have all completed our security questionnaire, so our supplier assurance program is in place.'
Root cause:Completed questionnaires are inputs to a supplier assurance program. They are not the program. The DEFSTAN 05-138 supplier assurance obligation under Part 2 Section 3 is to manage security risks associated with third-party suppliers — which requires having a basis for confidence in the accuracy of supplier claims. A questionnaire that asks a supplier whether they have MFA enforced and accepts their answer without verification provides no basis for that confidence. The questionnaire collection is an administrative activity. Assurance requires evidence that the claimed controls exist.
'We passed the last DEFSTAN audit with no major findings. We just need to confirm nothing has changed.'
Root cause:Point-in-time assessments do not capture configuration drift, staff changes affecting incident response capability, supplier relationship changes affecting assurance files, or new system introductions that fall outside previously assessed scope. 'Nothing has changed' is rarely accurate at the evidence level over a 12 to 18 month period in an active development and procurement environment. A previous clean audit confirms the controls were satisfactory at the time of assessment. It predicts nothing about current state.
What DEFSTAN 05-138 compliance programs miss
Sub-supplier digital footprint outside assurance scope
Supplier assurance programs that rely on questionnaires do not include external reconnaissance of supplier domains. A sub-supplier can accurately complete a questionnaire describing their internal security controls while running publicly accessible services on forgotten subdomains with outdated software, exposed configuration panels, or service banners revealing internal system architecture. This information is available to anyone running passive reconnaissance. It is not available to a prime contractor whose assurance program consists of filed questionnaires. The assurance gap is not in the questionnaire design — it is in the decision to accept self-reported claims without external verification.
Incident response capability degradation between audits
Incident response plans are documents. The capability they describe depends on the people, tools, and processes referenced in them. Staff changes, tool procurement changes, and process modifications that occur between audits can degrade the capability without triggering a policy update. An organization whose incident response plan names a specific security lead who left the company six months ago has an evidence problem — the accountable executive named in the plan is not the person who would receive the notification. This is not a theoretical concern. It is a routine finding in environments where IR plans are treated as static documents.
Data residency implications of cloud service use in classified data environments
DEFSTAN 05-138 information risk management requirements under Part 4 do not provide explicit cloud-specific guidance, but the data protection and sovereignty obligations that apply to MoD contract data create evidence obligations for cloud service use that most supplier compliance programs have not mapped. Organizations using cloud services for any part of their DEFSTAN-scoped environment need evidence that data residency, access controls, and provider security posture satisfy the information risk management standard. Most have not produced this evidence because the question has not been asked during previous assessments. It will be.
Evidence validity periods for configuration baselines
Configuration baseline evidence submitted for DEFSTAN assessments is point-in-time. A configuration screenshot proves the setting existed when the screenshot was taken. An automated configuration audit report covers the state at report generation. Neither proves the configuration is still in place. DEFSTAN's continuous monitoring requirements imply that configuration evidence should reflect current state, but the evidence standard for what 'current' means is not precisely defined. Organizations that prepare evidence packages for audit cycles without continuous configuration monitoring are producing accurate historical records, not current compliance evidence.
Where DEFSTAN 05-138 enforcement is heading
Within 3 years, MoD supplier assurance requirements will be updated to require independent verification evidence for sub-suppliers above a defined contract value threshold, making self-attestation questionnaires insufficient as a standalone assurance mechanism for prime contractors.
The supply chain attack surface in UK defense contracting is well understood and publicly documented following several high-profile incidents in allied defense supply chains. The current self-attestation model creates a structural gap that is visible to anyone who reviews a supplier assurance file. Regulatory pressure to close this gap is predictable. The mechanism most likely to be adopted is an independent verification requirement with tiering by contract sensitivity or value, because it is the least operationally disruptive way to materially improve assurance quality.
Confidence: highDEFSTAN 05-138 revisions or supplementary guidance published by MoD CESO between 2025 and 2028. If updated guidance does not address independent verification requirements for sub-suppliers, this prediction is wrong.A prime contractor will face contractual liability following a breach traced to a sub-supplier whose assurance file consisted only of a completed questionnaire, and the resulting enforcement action will establish that questionnaire-only assurance programs do not satisfy Part 2 Section 3.
The structural conditions for this outcome already exist. Questionnaire-based assurance programs are the norm. Sub-suppliers with inaccurate or outdated questionnaire responses are not rare. A breach that traverses a supply chain relationship where the prime contractor's assurance file cannot demonstrate actual verification will produce a regulatory finding about the adequacy of the assurance program, not just the breach itself. This is the pattern that has emerged in GDPR enforcement involving third-party processors, and the regulatory logic applies equally to defense supply chain assurance.
Confidence: mediumNo publicly documented enforcement action or contractual dispute involving questionnaire-based DEFSTAN supplier assurance programs by May 2028. This would suggest either the structural conditions are less prevalent than assessment data indicates, or enforcement focus remains elsewhere.
The honest problem with how suppliers read DEFSTAN 05-138
DEFSTAN 05-138 is read by most suppliers as a documentation exercise with an audit at the end. The documentation is produced. The audit is prepared for. The controls that documentation describes may or may not operate as documented, and the preparation process does not force that question to be answered.
The framework's actual evidence standard — particularly for incident response, supplier assurance, and configuration management — requires behavioral evidence. It requires that organizations know what happened, can demonstrate what happened, and can show that the controls described in their policies operated during the events in question. This is a materially harder standard than producing a compliant policy document, and it is the standard that matters during a real assessment or a real incident investigation.
The gap between what most DEFSTAN suppliers prepare and what the evidence standard actually requires is not a misunderstanding of the framework's control requirements. It is a rational response to the incentive structure of point-in-time audits. If producing documentation has historically been sufficient to pass, the investment in behavioral evidence is hard to justify to management. The problem is that this calculus changes the moment an incident occurs and the evidence standard is applied to real events rather than prepared packages.
Counterargument
The counterargument is that behavioral evidence requirements are impractical at scale for smaller defense suppliers who lack the logging infrastructure and security operations capability to produce log-based incident timelines on demand. This is a real constraint. The response is not that the evidence standard should be lower — it is that smaller suppliers need to understand which evidence requirements they cannot currently satisfy and remediate that gap before an assessment, rather than discovering it during one. Documenting a control you cannot evidence is not a compliance strategy. It is a liability.
Building a DEFSTAN 05-138 evidence program that survives an audit
Step 1 — timeline reconstruction from logs rather than from the incident report. Organizations test their incident response plan by reviewing the plan, not by checking whether the plan matches what actually happened during a real event. The log reconstruction reveals the evidence problem that a documentation review cannot.
- 1Compliance lead or security manager
Reconstruct the incident timeline for the most recent security event from system logs, not from the incident report. Compare the log-derived timeline to the documented SLA commitments in the incident response plan. Any discrepancy between the two is an evidence finding — not a documentation gap, but a demonstrated failure of the control the documentation describes. This reconstruction takes a day and reveals more about actual incident response capability than any tabletop exercise.
Expected outcomeA clear picture of whether incident response SLA commitments are achievable under current logging and alerting infrastructure, and a specific list of discrepancies to remediate before an external assessment.
- 2Supplier relationship manager or security lead
Pull the supplier assurance file for each sub-supplier and identify every claim that is supported only by a completed questionnaire. For each such claim, identify what independent verification would look like — a penetration test report, a configuration audit result, or an external reconnaissance finding. Prioritize sub-suppliers with access to systems in scope for classified or sensitive data. Request independent verification evidence from those suppliers before the next assessment cycle.
Expected outcomeA supplier assurance file that contains verification evidence for high-priority sub-suppliers, and a documented process for obtaining and reviewing that evidence on a defined cycle.
- 3IT or security team
Run external reconnaissance against your organization's primary domain and against the domains of sub-suppliers in your assurance program. Use certificate transparency log queries, passive DNS enumeration, and service fingerprinting to build an external asset inventory. Compare the result to your internal asset register and to the assets described in sub-supplier questionnaire responses. Any externally discoverable asset not in scope for your configuration baseline or patching program is a gap. Any sub-supplier asset that contradicts their questionnaire responses is an assurance finding.
Expected outcomeAn accurate external asset inventory and a list of sub-supplier assurance discrepancies that can be raised with sub-suppliers before they become assessment findings.
- 4IT or infrastructure team
Extend configuration baseline documentation to cover network devices, VPN infrastructure, and any embedded or OT-adjacent systems in scope. For each device class, document the baseline configuration, the process by which drift is detected, and the review cycle. If no review cycle exists, establish one with a defined frequency before the next assessment. The configuration baseline requirement under Part 3 Section 3 does not exclude network infrastructure.
Expected outcomeA configuration baseline program that covers the full scope of assets in the DEFSTAN-assessed environment, with documented review cycles that produce current-state evidence rather than point-in-time snapshots.
One thing to do this week
Take the most recent security event your organization handled — anything from a phishing attempt that required investigation to a system availability incident — and reconstruct what happened from system logs alone, without referring to any incident report or internal communication. Note the time of first indicator, the time of internal acknowledgment, the time the accountable executive was informed, and the time of any external notification if required. Compare each timestamp against your documented SLA commitments.
If the log-derived timeline matches your documented commitments, your incident response evidence will survive an audit. If it does not match, you have identified the evidence gap before an assessor does. That gap is remediable — but only if you find it first.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisEMEA compliance frameworks: the complete guide to GDPR, NIS2, DORA, and 40+ regional mandates
DEFSTAN 05-138 cybersecurity evidence requirements for MoD suppliersNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionOWASP Web Security Testing Guide
OWASP testing methodologies
Frequently Asked Questions
What does DEFSTAN 05-138 cybersecurity require for incident response evidence?
DEFSTAN 05-138 requires demonstrable incident response capability, not just documented procedures. MoD assessors request actual incident timelines — reconstructed from system logs — and compare them against the SLA commitments stated in the organization's incident response plan. An organization with a 24-hour response commitment in its policy that takes 72 hours to acknowledge an incident in practice has a compliance finding on the evidence standard, not the documentation standard. Preparing for this requires testing IR procedures against real events, not just maintaining a current policy document.
Does completing supplier questionnaires satisfy DEFSTAN 05-138 supplier assurance requirements?
No. DEFSTAN 05-138 Part 2 Section 3 requires management of security risks associated with third-party suppliers, which requires a basis for confidence in supplier security claims. Completed questionnaires are inputs to a supplier assurance program, not evidence of assurance. MoD assessors reviewing a supplier assurance file expect independent verification evidence — penetration test reports, configuration audit results, or external reconnaissance findings — for sub-suppliers with access to sensitive systems. Organizations whose assurance files contain only questionnaire responses have documented an administrative process, not an assurance program.
What configuration management evidence does DEFSTAN 05-138 Part 3 require?
Part 3 Section 3 requires secure configuration management across the full scope of systems in the assessed environment, including network devices, VPN infrastructure, and embedded systems — not just operating systems and application servers. Endpoint management tools that report clean configuration compliance for managed workstations satisfy a subset of this requirement. Network infrastructure and OT-adjacent components that fall outside endpoint management tool scope contribute to the same evidence obligation and are routinely absent from submitted baseline documentation, producing assessment findings.
What is the difference between DEFSTAN 05-138 perimeter security requirements and internal segmentation requirements?
DEFSTAN 05-138 Part 4 Section 3 information risk management requirements cover limiting the impact of security incidents, which assessors interpret as requiring internal network segmentation evidence, not just perimeter control documentation. An organization that submits perimeter firewall evidence without demonstrating internal segmentation between sensitive and non-sensitive network zones has not satisfied the blast radius limitation implied by Part 4. Perimeter evidence is necessary but not sufficient. Internal segmentation must be evidenced separately.
How often should DEFSTAN 05-138 supplier assurance files be updated?
Supplier assurance files should reflect current verification evidence, not evidence collected at initial onboarding. At minimum, independent verification should be requested annually for sub-suppliers with access to systems handling classified or sensitive data. Questionnaire-based assurance without a defined review cycle produces stale files that accurately describe what a supplier claimed at a point in time — not what their security posture is today. Configuration drift, staff changes, and new system introductions at sub-suppliers occur continuously and are not captured by one-time questionnaire collection.
What does DEFSTAN 05-138 gap analysis typically find that organizations miss?
DEFSTAN 05-138 gap analysis most commonly surfaces three categories of findings organizations did not anticipate: incident timeline evidence that contradicts documented SLA commitments when reconstructed from logs; supplier assurance files built entirely on self-attestation without independent verification; and configuration baseline documentation that covers endpoints but not network devices or embedded systems. Organizations preparing for assessment by producing documentation packages frequently pass the documentation review and fail the evidence-based portions of the assessment.
What are the regulatory consequences of DEFSTAN 05-138 supplier assurance failures?
A prime contractor whose supplier assurance program cannot demonstrate actual verification of sub-supplier security posture faces contractual exposure when a sub-supplier breach occurs. The assurance file is reviewed as part of any post-incident investigation, and a file consisting only of questionnaire responses demonstrates that assurance was delegated to self-attestation. This is the same pattern that has produced liability findings in GDPR enforcement involving third-party data processors. The regulatory logic — that collecting claims is not the same as verifying them — applies equally to defense supply chain assurance.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.