Preparing Evidence for DCC Level 0: What Assessors Actually Look For

Evidence is the currency of DCC Level 0. Every answer in your self-assessment must be supported by something an assessor can inspect. Weak evidence generates clarification cycles; fabricated evidence generates findings and sometimes outright refusal. This guide covers what the assessor is actually looking for, control by control, with specific examples of strong and weak evidence.

For the broader process context, see the DCC L0 process walkthrough. For the underlying controls being evidenced, see the DCC L0 five controls guide.

The fundamental principle: operational, not performative

The single most important idea in DCC evidence is that assessors want to see that your controls are operating in the normal course of business, not that you produced documentation for the assessment.

A policy written last week and signed the day before submission is weaker evidence than a policy that has been in place for two years with three documented reviews. A patch report generated this morning for the assessment is weaker than a monthly patch report series showing the same process running for twelve months.

The assessor's test: could this organisation produce the same evidence tomorrow, next week, next quarter, without special effort? If the answer is yes, the evidence is operational. If it required a mini-project to produce, it is performative, and the assessor's confidence in the control's sustainability drops accordingly.

Evidence categories

Across the L0 requirement set, evidence falls into five categories:

1. Policy and procedure documents. Information Security Policy, Acceptable Use Policy, Incident Response Plan, joiner-mover-leaver procedure, Supplier Due Diligence procedure.
2. Configuration outputs. Firewall rulesets, cloud security group exports, Group Policy or MDM configuration, AD user exports, patch management dashboard screenshots.
3. Records of operation. Patch deployment reports, vulnerability scan outputs, user access review sign-offs, incident ticket logs, change management records.
4. Training and vetting records. Security awareness training completion logs, BS 7858 vetting certificates, starter checklists.
5. Supply chain assurance evidence. Supplier questionnaires, copies of supplier CE certificates, MSP contracts showing security obligations.

Most submissions need evidence from all five categories. A submission heavy on category 1 (lots of policies) and light on category 3 (few operational records) is the classic "policy shelf-ware" warning sign for an assessor.

Control-by-control evidence expectations

Firewalls

Strong evidence:

• Exported firewall ruleset with timestamps on rule creation and last review.
• Quarterly firewall review log showing rules reviewed, removed, or updated.
• Screenshot of the firewall administrative login page confirming MFA is enforced.
• For cloud: Terraform or AWS Config output showing the current security group state.

Weak evidence:

• A written statement that "our firewall is configured appropriately".
• A ruleset exported for the first time ever, five minutes before submission.

Secure configuration

Strong evidence:

• A one-page device build standard document per device type.
• MDM or Intune policy export showing enforcement.
• A sample device compliance report showing 95%+ adherence across the estate.

Weak evidence:

• "We use standard builds."
• A build document written specifically for the assessment.

Security update management

Strong evidence:

• Patch management policy stating the 14-day critical SLA.
• A monthly patch dashboard screenshot series from the last three months.
• An exception log showing any systems outside the SLA and the approved exception.

Weak evidence:

• "We have WSUS."
• A single current patch status report without historical context.

User access control

Strong evidence:

• The last three monthly user access review sign-offs.
• MFA enforcement policy export from Microsoft Entra or equivalent.
• The last five joiner-mover-leaver records with dates.
• Separation of duty evidence (named administrators with dual accounts).

Weak evidence:

• User list CSV with no review or sign-off evidence.
• "We disable leavers' accounts."

Malware protection

Strong evidence:

• AV/EDR management console screenshot showing compliance across the endpoint estate.
• Recent alert handling evidence (ticket or response log).
• Email gateway configuration showing attachment and link handling.

Weak evidence:

• "All our laptops have antivirus."
• Screenshot of a single device's AV status.

Governance evidence

Beyond the technical controls, L0 requires governance evidence:

• Information Security Policy. Covering scope, roles, acceptable use, data classification, incident reporting, remote working, supplier management, physical security. Signed by a director, reviewed within the last 12 months.
• Incident Response Plan. Named roles, notification thresholds, MOD contact routes, testing evidence (even a single tabletop exercise in the last 12 months).
• Acceptable Use Policy. Signed by every in-scope user as part of their onboarding or annual reacknowledgement.
• Supplier Due Diligence procedure. How you evaluate your own suppliers for cybersecurity posture.
• Staff vetting. BS 7858 certificates for staff with access to MOD data in sensitive roles, or equivalent evidence.

Evidence retention

The scheme expects evidence to be retained for the duration of the certificate (three years) plus a reasonable period for annual attestation and audit. A practical baseline:

• Policies and procedures: the current version plus the previous two versions.
• Configuration outputs: quarterly snapshots for the three-year certificate duration.
• Operational records: retained for at least 12 months rolling.
• Training and vetting records: retained for employment duration plus six years.

This is not a formal scheme requirement but is what the annual attestation process needs to draw on.

Common evidence errors

1. Submitting the document without the record. A policy without evidence it is applied is not evidence.
2. Over-submitting. Uploading 40 unrelated documents and asking the assessor to find the relevant parts. Submit specifically against each question.
3. Evidence without authorship or date. Unsigned, undated documents raise immediate authenticity questions.
4. Screenshots cropped too tightly. If the hostname, timestamp, or user is cropped out, the evidence does not support the claim.
5. Translated-then-edited evidence. Evidence that has been cleaned up "for neatness" often loses the operational fingerprint an assessor is specifically looking for.

How Fig Group prepares evidence

At Fig, evidence preparation is a consultant-supported activity, not a DIY exercise:

1. The consultant runs an evidence planning call at engagement opening and produces a specific evidence list for your scope.
2. You upload evidence into a shared secure folder structured by control family.
3. The consultant reviews the evidence before submission, flagging thin items, inconsistencies, or missing pieces.
4. The Fig technology platform runs across your estate to provide machine-generated evidence for the technical controls (which is stronger than screenshots because the data is objective).
5. Final submission happens only when the consultant is satisfied the evidence pack is complete.

This pre-review discipline is why Fig's first-pass rate on L0 is materially higher than audit-only models: the assessor sees a clean pack, not a work-in-progress.

Talk to a DCC assessor → | View L0 pricing →