L1 is where DCC becomes a substantial engagement rather than a documentation exercise. L0 suppliers who have just completed their L0 and assume L1 is "L0 plus a bit more" are usually in for a shock. L1 requires a consultant-led engagement, interviews with named roles, evidence of operational control (not just documented control), and - for a well-delivered engagement - technology platform gap analysis before the formal assessor arrives.
This guide walks through a practical six-phase L1 preparation sequence. For a prepared supplier it collapses to six weeks. For a supplier starting from a low baseline, plan for 10-12 weeks.
Scope is the decision that most materially affects the rest of the engagement. Get this wrong and every subsequent phase is working to the wrong specification.
Confirm the contract CRP. L1 applies to Low Cyber Risk Profile contracts. If the contract is actually Moderate or High, you need L2 or L3 and should not be running an L1 engagement.
Define the in-scope boundary. For L1 this typically covers a specific business unit, specific systems, and specific personnel rather than the entire organisation. Boundary definition must include:
Document scope explicitly. A written scope document (typically 3-5 pages) detailing what is in and what is out, with justification. This is not a formality - the assessor reads it and challenges the boundary.
Align with Cyber Essentials scope. DCC scope should match or be a subset of the Cyber Essentials scope. A DCC scope that includes systems the CE assessment excluded produces findings.
See our DCC L0 scoping guide for the common pitfalls - they apply equally at L1.
L1 governance evidence is substantially heavier than L0. L1 requires not just documented policies but evidence that the policies are approved, communicated, and operational.
Information Security Policy (reviewed/approved in the last 12 months). Coverage: acceptable use, data classification, incident reporting, joiner-mover-leaver, remote working, supplier due diligence, physical security, cryptography, business continuity touchpoints.
Risk Assessment and Risk Register. L1 expects a documented risk assessment methodology, a current risk register identifying cybersecurity risks to MOD-facing services, and evidence of periodic review.
Incident Response Plan. Named roles (not job titles), defined incident categories with severity and escalation, notification thresholds (internal, to MOD via the prime, to authorities), evidence of a recent tabletop exercise or live exercise within the last 12 months.
Business Continuity and Disaster Recovery Plan. Not required at L0, required at L1. Coverage: business impact analysis, recovery time and recovery point objectives for MOD-facing services, tested disaster recovery procedures.
Information Security Management System (ISMS) documentation. L1 does not require ISO 27001-style heavy ISMS documentation, but it does require evidence that security is managed as a system rather than as a set of individual controls. A 10-15 page ISMS overview covering the organisation's approach, policies, procedures, roles, and continual improvement is typically expected.
Supplier security register and flow-down. See the subcontractor assurance guide.
Personnel security. Vetting process, onboarding checks, training records, role-based access provisioning process.
L1 technical evidence goes beyond the five Cyber Essentials controls. Expect to evidence each of the following in operational form:
Network security. Firewall rulesets, cloud security group configurations, network segmentation documentation, evidence of periodic ruleset review.
Identity and access management. SSO configuration, MFA enforcement (not just enabled, enforced), conditional access policies, privileged access management, break-glass account procedures, evidence of quarterly or more frequent access reviews.
Endpoint security. MDM policy, compliance dashboards, AV/EDR management console, patch compliance reports for the last 90 days.
Logging and monitoring. Evidence of log capture for critical systems, log retention meeting MOD requirements (typically 12 months minimum), evidence that logs are actively reviewed rather than just captured.
Vulnerability management. Regular vulnerability scanning evidence, patch management SLA (typically 14 days for critical vulnerabilities), evidence of the process in action.
Cryptography. TLS on all public-facing services, encryption-at-rest for MOD-facing data stores, key management procedures.
Secure development. For suppliers that develop code: secure SDLC evidence, code review practice, SAST/DAST integration, secrets management, dependency scanning.
At L1 evidence must be operational. A firewall with a ruleset exported today but with no evidence the ruleset has ever been reviewed will not satisfy the "periodic review" expectation. Plan to produce at least 30-90 days of operational evidence, which means starting evidence collection early.
For L1 engagements delivered with a technology platform-equipped Certification Body, the platform runs automated gap analysis across the in-scope infrastructure and surfaces issues that would otherwise become assessor findings.
For Fig customers the Fig platform covers:
The platform typically identifies 20-50 low-to-medium severity findings in a typical L1 engagement. These are addressed quietly before the formal assessor ever sees the submission.
This phase is where audit-only Certification Bodies deliver a fundamentally different engagement. Without the platform, the assessor identifies the same findings during formal review, which then become clarifications, which extend the engagement.
Before submitting for formal assessment, run a mock assessment internally or with your consultant. The mock assessment covers:
The mock assessment catches the things that otherwise become clarifications during formal review. A disciplined mock typically surfaces 5-15 residual issues that are cheap to fix before submission.
At Fig, the dedicated consultant runs the mock assessment for L1 customers as part of the engagement.
The supplier submits the DCC evidence pack via the IASME portal. The Certification Body's assessor reviews the submission, conducts interviews, verifies specific controls, and issues a decision.
L1 submission typically involves:
For well-prepared suppliers with platform gap analysis completed, formal assessment typically concludes in 3-4 weeks from submission. Up to three rounds of assessor feedback are included in the Fig L1 fee.
For a prepared organisation with current Cyber Essentials, existing ISMS documentation, operational technical controls, and a competent internal lead, L1 is 6-8 weeks end-to-end.
For an organisation starting from a low baseline - no ISMS, stale policies, technical controls that need documentation and remediation, no named internal lead - L1 is 10-14 weeks.
The single biggest accelerator is a dedicated internal lead with executive backing, running L1 as a priority project rather than a side task. The single biggest delay is trying to complete L1 as a part-time effort for an already-stretched operations or IT lead.
Fig's L1 pricing ranges from £9,999.99 - £49,999 + VAT depending on organisation size. See L1 micro pricing for the tightest engagements, and the full DCC pricing guide for a breakdown of what drives variance.
The fee includes the technology platform (normally £4,200 per annum), a dedicated consultant, three rounds of assessor feedback, certificate issuance, three-year validity, and IASME DCC register listing. Cyber Essentials is priced separately but can be bundled on request.
Start with a scoping call. For L1 engagements, the scoping conversation is typically 45-60 minutes and establishes the expected timeline, the evidence gaps, the technology platform readiness, and a realistic quote within one working day.
A consolidated, practical readiness checklist for DCC Level 0 and Level 1 against CSM v4 (December 2025). Use it to audit your starting posture before engaging a Certification Body. Organised by control family, with specific evidence artefacts and pass/fail criteria for each item.
At L1 and above DCC assessments include interviews with named roles. This guide walks through the specific questions assessors typically ask the incident response lead, the IT/technical lead, and the senior governance attester - and what good answers look like.
Cloud-native and SaaS suppliers face specific DCC considerations: in-scope cloud infrastructure, shared responsibility model clarity, IAM evidence, and secure configuration baselines. This guide walks through how to scope and evidence DCC for a SaaS or cloud-native organisation.