DCC Evidence Requirements: What Defence Suppliers Need to Prove

One of the biggest mistakes organisations can make when preparing for Defence Cyber Certification is assuming that having the right policies and security tools will automatically be enough.

They may not be.

DCC is about demonstrating that the required controls are actually being met in practice.

IASME's current applicant guidance is explicit: organisations need to answer the relevant assessment questions, explain how each control is met and provide supporting evidence that demonstrates compliance in practice.

For Defence suppliers, that creates an important distinction:

Having a control is one thing. Being able to evidence that the control exists, operates effectively and applies to the correct scope is another.

This guide explains what organisations should be preparing.

What is DCC trying to evidence?

The Defence Cyber Certification scheme provides independent assurance against the cyber-security requirements of the Ministry of Defence's Cyber Security Model.

Under CSMv4, an MOD risk assessment determines the applicable Cyber Risk Profile, from Level 0 through to Level 3. Defence Standard 05-138 then defines the controls suppliers are expected to meet for that level.

DCC provides a mechanism for independently evidencing that compliance.

That means an assessor is not simply looking for a collection of documents.

They need enough information to understand:

• what the organisation does;

• what systems and services are within scope;

• how each applicable control has been implemented;

• who is responsible;

• whether the control is operating in practice; and

• whether the evidence supports what the organisation says.

The stronger the relationship between the requirement, implementation and evidence, the easier the assessment becomes.

What counts as evidence?

There is no single evidence format that applies to every DCC control.

The appropriate evidence depends on what the particular requirement is trying to demonstrate.

Evidence could include things such as:

• policies;

• procedures;

• screenshots;

• configuration exports;

• audit logs;

• security reports;

• meeting records;

• training records;

• asset registers;

• access-control reviews;

• risk assessments;

• vulnerability reports;

• backup-test results;

• incident-response exercises;

• supplier-assurance records; and

• examples showing that a process is actually being followed.

The important point is that the evidence should directly support the answer being given.

IASME advises applicants to make sure supporting evidence gives the assessor a clear understanding of how the control is being met and that it is readily available when requested.

1. Policies need evidence behind them

A policy is useful.

But a policy saying:

All users must use multi-factor authentication.

does not, by itself, prove that MFA is actually enforced.

Evidence might instead include:

• the organisation's access-control policy;

• configuration showing MFA requirements;

• Conditional Access policies;

• privileged-role configuration; and

• evidence that exceptions are controlled.

The documentation explains what should happen.

The technical evidence helps demonstrate what actually happens.

Strong DCC preparation normally requires both.

2. Identity and privileged-access evidence

Identity controls are likely to involve some of the clearest technical evidence in a modern cloud environment.

For an organisation using Microsoft 365, for example, evidence could include:

• Entra ID authentication settings;

• Conditional Access policies;

• administrator-role assignments;

• separate privileged accounts;

• MFA configuration;

• joiner, mover and leaver records;

• access reviews; and

• evidence showing stale or unnecessary accounts are removed.

The assessor needs to understand not simply that identity security exists, but how the organisation controls access in practice.

3. Device and endpoint evidence

An organisation should be able to demonstrate that devices within the relevant scope are understood and appropriately managed.

Typical evidence might include:

• an asset inventory;

• Intune or other device-management records;

• device compliance policies;

• endpoint-protection status;

• encryption settings;

• operating-system versions;

• security-update status;

• evidence of local administrator controls; and

• vulnerability-management reports.

This is where organisations with mature endpoint management often have an advantage.

Much of the necessary evidence may already exist inside the tools they operate every day.

The task becomes organising it against the correct control.

4. Patching and vulnerability management

Saying that systems are "patched regularly" is not particularly strong evidence.

A stronger position would demonstrate:

• what the patching policy requires;

• which systems are covered;

• who is responsible;

• when updates were deployed;

• how exceptions are handled;

• whether unsupported software exists; and

• how vulnerabilities are identified and remediated.

Evidence might therefore include RMM reports, Microsoft Intune records, vulnerability scans or change-management records.

The aim is to demonstrate a repeatable process rather than a one-off activity.

5. Security monitoring evidence

Where controls require security events to be identified or monitored, the evidence should demonstrate that monitoring actually takes place.

That could include:

• Defender alerts;

• Sentinel incidents;

• SIEM reports;

• SOC tickets;

• alerting rules;

• investigation records;

• escalation procedures; and

• examples of alerts being reviewed.

Simply purchasing Microsoft Defender or another security product does not necessarily demonstrate an operational monitoring capability.

Someone must be responsible for responding to what the technology identifies.

6. Incident-response evidence

Incident response is another area where documentation alone can become misleading.

An organisation may have an incident-response plan sitting in SharePoint.

The stronger question is:

Has anyone tested it?

Evidence could include:

• the incident-response policy;

• defined roles and responsibilities;

• contact lists;

• reporting processes;

• tabletop-exercise records;

• lessons learned;

• actual incident records;

• escalation evidence; and

• remediation actions.

The objective is to demonstrate that the organisation can respond when an incident occurs, rather than simply possessing a document describing how it intends to respond.

7. Backup and recovery evidence

Backup evidence should go beyond showing that a backup product has been purchased.

An assessor may need to understand:

• what is backed up;

• how frequently;

• where backups are stored;

• who can access them;

• whether backups are protected from alteration or deletion;

• how long information is retained; and

• whether restoration has been tested.

A screenshot saying Backup successful is useful.

A documented restoration test showing that the organisation has actually recovered a critical system is significantly stronger evidence of resilience.

8. Governance and risk-management evidence

Not every DCC control is purely technical.

Evidence of organisational governance might include:

• risk registers;

• management-review minutes;

• security responsibilities;

• board or leadership reporting;

• cyber-risk assessments;

• documented exceptions;

• remediation plans; and

• evidence that security decisions are reviewed periodically.

One of the major changes under CSMv4 is the move towards organisational security and resilience, rather than focusing only on individual items of MOD information.

That makes governance evidence increasingly important.

9. Supplier and subcontractor evidence

Your own controls are only part of the picture.

Where Defence work is subcontracted, CSMv4 includes a formal flow-down process. A supplier carries out a risk assessment for the subcontracted activity, which determines the Cyber Risk Profile that the subcontractor must address.

Evidence might therefore include:

• supplier registers;

• subcontractor assessments;

• security requirements in contracts;

• Supplier Assurance Questionnaire results;

• Cyber Risk Profile information;

• assurance reviews; and

• agreed Cyber Improvement Plans where necessary.

This matters particularly for SMEs that depend heavily on third-party IT, software and cloud providers.

10. People and training evidence

Cyber resilience depends on people as well as technology.

Evidence might include:

• induction training;

• annual cyber-awareness records;

• phishing simulations;

• specialist administrator training;

• policy acknowledgements;

• role descriptions; and

• records showing completion rates.

Again, the important distinction is between having a policy requiring training and being able to demonstrate that people have actually completed it.

Can existing ISO 27001 or other evidence be reused?

Potentially, yes.

This is particularly relevant for organisations that already maintain formal standards such as ISO 27001.

The MOD publishes a mapping between Defence Standard 05-138 Issue 4 and a number of recognised frameworks, including:

• ISO 27001:2022;

• NIST Cybersecurity Framework;

• NIST SP 800-171;

• Cyber Essentials;

• CAF;

• ISO 22301; and

• ISO 27701.

The stated purpose is partly to help organisations identify alignment and reuse existing compliance evidence where appropriate.

That can make DCC preparation considerably more efficient.

For example, an ISO 27001-certified organisation may already have:

• risk-management evidence;

• information-security policies;

• internal audits;

• management reviews;

• asset management;

• supplier-management procedures;

• incident processes; and

• access-control evidence.

The important word is appropriate.

Holding ISO 27001 does not automatically demonstrate compliance with every DCC requirement.

The organisation still needs to map what it already has against the applicable Defence controls.

What about Cyber Essentials?

Cyber Essentials remains an important part of the DCC framework.

All DCC levels begin with Cyber Essentials, while Levels 2 and 3 require Cyber Essentials Plus.

This means some technical evidence may already have been assembled through the Cyber Essentials process.

But Cyber Essentials and DCC have different scopes and purposes.

Cyber Essentials should therefore be treated as a useful foundation rather than the complete evidence package.

Does DCC Level 0 require the same evidence as higher levels?

No.

The assessment burden grows significantly as the DCC level increases.

IASME currently states that no Assessment Submission Record is required for Level 0, whereas applicants for Levels 1–3 use an Assessment Submission Record as part of preparing their submission.

That makes Level 0 comparatively lightweight.

However, organisations should still avoid treating it as a simple box-ticking exercise.

The wider objective remains demonstrating that the required baseline controls are genuinely in place.

And if an organisation later needs Level 1, Level 2 or Level 3, establishing good evidence-management practices at Level 0 makes that progression much easier.

What is a good DCC evidence structure?

A practical way of preparing is to create a simple evidence register.

For every applicable requirement, record:

Control

What requirement are we addressing?

Owner

Who inside the organisation is responsible?

Implementation

How do we meet the requirement?

Evidence

What proves that statement?

Location

Where is the evidence stored?

Status

Compliant, partially compliant or gap?

Remediation

What needs to happen if there is a gap?

This creates traceability.

Instead of hunting through SharePoint, email, security portals and IT systems during an assessment, the organisation knows exactly where the supporting evidence lives.

Avoid the "assessment scramble"

A common risk is only beginning to assemble evidence when the assessor requests it.

That creates several problems.

Documents are difficult to find.

People disagree about who owns a control.

Screenshots are taken at the last minute.

Policies have not been reviewed.

Processes described on paper turn out not to happen consistently.

None of that necessarily means the organisation has poor security.

It means it has poor assurance readiness.

The better approach is to build evidence collection into normal IT and security operations.

For example:

Monthly: privileged-access review
Quarterly: restore test
Quarterly: vulnerability review
Annually: incident-response exercise
Ongoing: security-alert records
Ongoing: joiner/leaver evidence
Ongoing: patching and compliance reports

Then DCC evidence becomes a by-product of running the environment properly rather than a one-off certification project.

What if the evidence reveals a gap?

That is exactly why readiness reviews are useful.

Under CSMv4, where a supplier cannot meet applicable requirements — including where it does not hold the required DCC certification — a Cyber Improvement Plan (CIP) may be required detailing how compliance will be achieved and the associated timescales.

Finding a weakness before assessment gives the organisation time to:

1. document the gap;

2. understand the associated risk;

3. agree ownership;

4. implement remediation;

5. gather evidence; and

6. verify that the fix actually works.

The objective should not be to manufacture evidence for an assessment.

It should be to fix the underlying issue and allow the resulting evidence to demonstrate that improvement.

DCC evidence is really about operational maturity

There is a broader lesson here.

A business with well-managed IT and cyber-security operations will often already generate much of the evidence it needs.

Asset inventories exist.

Devices are centrally managed.

Access reviews happen.

Security alerts generate tickets.

Backups are tested.

Policies are reviewed.

Incidents are recorded.

Suppliers are assessed.

The DCC exercise then becomes primarily one of mapping and organising evidence against the Defence requirements.

An organisation where those practices do not happen consistently has a different challenge.

It first needs to improve the underlying cyber-security operating model.

That is why DCC readiness should not be treated purely as a documentation project.

How Symposium IT can help

Symposium IT helps UK Defence suppliers establish whether they can actually evidence the cyber-security controls they claim to have in place.

Through Symposium Defence, we can assess the technical and operational environment supporting the organisation, including:

• Microsoft 365;

• Entra ID;

• Intune;

• Microsoft Defender;

• endpoint security;

• identity and privileged access;

• patching;

• vulnerability management;

• backup and recovery;

• security monitoring;

• policies and governance; and

• wider DCC readiness.

For organisations that already hold certifications such as ISO 27001 and Cyber Essentials, we can also help identify where existing controls and evidence can support the DCC journey rather than unnecessarily recreating work already completed.

The aim is simple:

know what controls apply, know how you meet them, and know where the evidence is before an assessor asks for it.

Could you prove your controls today?

That is probably the most useful DCC-readiness question a Defence supplier can ask.

Not:

"Do we have MFA?"

but:

"Could we prove how MFA is enforced, who it applies to, how exceptions are controlled and who reviews it?"

Not:

"Do we take backups?"

but:

"Could we demonstrate that our critical systems can actually be recovered?"

That shift from having security to being able to evidence security is at the heart of assurance.

If you supply the MOD, a Defence prime or another organisation in the Defence supply chain, preparing that evidence early can make the eventual DCC assessment considerably more straightforward.

Explore Symposium Defence to learn more about DCC readiness and how we can help identify, remediate and evidence your organisation's cyber-security controls.