DCC Scoping Mistakes That Fail Certification (and How to Avoid Them)

The IASME Scoping Guide warns that inaccurate or incomplete scope can prevent certification even when included controls are met. Misjudged scope can prevent certification even where the included systems meet their controls. This post covers the six most common scoping mistakes Fig Group sees at scoping conversations, what each costs in time and fees, and how to avoid each. The principle: scoping is the most critical first step. Treat it as load-bearing, not paperwork.

DCC is built on Defence Standard (Def Stan) 05-138 issue 4, and the standard scope is intentionally broad. Per clause 1.1 of the standard, the scope is the supplier overarching corporate or enterprise environment - all systems, processes, procedures, and data necessary for the effective protection of the data and functions in scope of the MOD contract. This goes beyond protecting only the information provided to the supplier in support of the contracted output. Per the IASME Scoping Guide, scope is not just about the data held: if the processes and systems are essential for the organisation to operate as a business in support of the contract, they must be within the DCC scope.

That breadth is where most scoping errors happen. What follows is the practical pattern of mistakes that fail certification.

The trap is "we will include everything to be safe." Suppliers default to including every site, every system, every supplier, on the theory that more is safer than less.

Why it fails. Every site, system, and supplier you include adds evidence work. A five-site organisation may have more evidence to review than a two-site organisation, but MOD-contract relevance alone does not justify excluding sites. Include all functions and services essential to the certified organisation’s secure and resilient operation, including essential non-MOD dependencies; any exclusion needs an evidenced boundary and assessor agreement. The assessor reviews every artefact you submit. Out-of-scope assets that get pulled in still need governance evidence, identity evidence, device evidence, supply-chain evidence.

Real-world signal. The engagement runs two to three times the timeline of equivalent peers because the assessor is reviewing evidence that is not load-bearing for the contract.

How to avoid it. Agree in-scope assets at scoping based on the contract requirements, not "everything we own." An exclusion needs a defensible boundary. Absence of MOD data flow alone does not exclude a system essential to business operations supporting the contract. The assessor expects to see a list of what is in scope and a list of what is out of scope, with diagrams showing how the scopes overlap and a list of sites with their functions.

The opposite trap: "we will exclude everything we can to keep it cheap."

Why it fails. Under-scoping is the failure mode the IASME Scoping Guide warns about explicitly. If processes and systems essential to the organisation operations in support of the contract are excluded from scope, the assessor cannot recommend certification - even if the in-scope assets meet every control. The result is a failed assessment, regardless of how well the included evidence holds up.

Real-world signal. The assessor pushes back at evidence review, demands additional systems be added to scope mid-engagement, the timeline extends, and remediation rounds increase. In the worst cases, the assessment is paused while scope is re-defined - effectively a re-engagement.

How to avoid it. Include everything that is essential for the organisation to operate as a business in support of the MOD-contract Functions and Data. Per Def Stan 05-138 i4 clause 1.1, the scope is the Supplier overarching corporate or enterprise environment. The conservative test: if removing a system or service would impair the supplier ability to deliver the contracted output, that system is in scope.

The trap: "we have Cyber Essentials, the L1 evidence pack is mostly done."

Why it fails. Cyber Essentials covers five technical control families across firewalls, secure configuration, user access, malware protection, and security update management. DCC Level 1 covers 101 controls, including governance maturity, supply-chain flow-down, secure-configuration evidence depth, identity-control specifics, and incident response - all of which CE does not reach. CE is a prerequisite, not a partial L1 evidence pack.

Illustrative risk. Governance, identity and supply-chain gaps may remain despite current CE. No measured 60–80% failure rate is established by this guide.

How to avoid it. Treat CE as the floor, not the answer. Plan a separate evidence-collection sprint for each applicable Level 1 control without assuming a fixed thirteen-to-101 mapping. Do not rely on "CE-aligned" claims as a shortcut to L1 evidence. The CE evidence you hold underpins parts of the L1 secure-configuration and identity controls; it does not replace the governance, supply-chain flow-down, or secure-configuration depth required at L1.

The trap: "we will just attach our supplier list."

Why it fails. L1 supply-chain controls require documented flow-down (security clauses in supplier contracts), assessment evidence in the form of Supplier Capability Assessments (SCAs), and visibility on whether suppliers handle in-scope MOD data. A supplier list alone does not satisfy any of these.

Real-world signal. The supply-chain section of the L1 evidence pack returns the most findings of any control family. Suppliers respond to SCA requests on their own timelines - some take two to three weeks to return a signed assessment - and the engagement stalls while the supply-chain evidence is collected.

How to avoid it. Send SCAs to direct suppliers in week one of the engagement, not week five. Allow two to three weeks for supplier responses. Map flow-down clauses against the MOD contract scope - if your supplier contract says nothing about cyber security, the assessor will treat that as a gap. Use the applicable scheme evidence requirements and current MOD subcontract risk-assessment/SAQ process; a provider template is preparation advice, not a universal 15–20-control scheme rule.

The trap: "we will include the Windows Server 2012 box, it is still in production."

Why it fails. Unsupported software in the Cyber Essentials scope must meet the supported-software requirement. Check whether Windows Server 2012 actually has an active, valid Extended Security Updates arrangement before treating it as unsupported. Upgrade, replace or decommission unsupported software, or demonstrate a genuinely permitted isolated scope exclusion; segmentation or compensating controls alone do not waive the requirement.

Real-world signal. Remediation round one surfaces it. Round two confirms the patching plan or the decommissioning plan. Round three closes documentation. The engagement extends four to six weeks beyond the typical band for legacy decommissioning - or longer if the legacy system is genuinely load-bearing and cannot be moved.

How to avoid it. Identify lifecycle and support status at scoping, record the evidence and resolve unsupported in-scope software before certification. A future replacement plan does not make currently non-compliant software compliant.

The trap: "we will start gathering evidence at week five when the assessment opens."

Why it fails. A Level 1 evidence pack covers 101 controls. Assembling that documentation takes weeks. Starting at the assessment window means evidence is still being created during formal review. Assessors flag fresh evidence with weak retention provenance - a policy authored last week is materially different from a policy that has been in use for six months. The result is multiplied clarification rounds and an extended timeline.

Real-world signal. Assessor queries multiply. Clarification rounds extend. The engagement timeline slips by four to six weeks beyond the typical 6-10 week band.

How to avoid it. Start evidence preparation at scoping, not at formal assessment. If you are using Fig Group, the platform gap analysis surfaces what is missing in week one - giving you a four-week head start on remediation before the assessor sees the pack. As a Fig Group planning target, aim to enter formal assessment with the evidence pack 90% complete, with the remaining 10% being clarifications the assessor specifically asks for.

The six mistakes share a single root cause: treating scoping as paperwork rather than as the load-bearing decision it is. Under the DCC scheme, scoping decisions made in the first week of an engagement determine the cost, timeline, and outcome of everything that follows.

The IASME Scoping Guide includes essential business processes and systems, not only systems holding MOD data. Apply that test at scoping, document the result clearly, and most of the remediation cycles that fail engagements simply do not open.

The fix is operationally simple: book scoping with an IASME-licensed Certification Body before any other DCC work begins. The scoping call is normally free of charge - it confirms the Cyber Risk Profile, the level, the scope boundaries, and the timeline before any engagement fee is incurred.

If you are at the start of a DCC engagement, book a 15-minute Fig Group scoping call and we will walk through scope decisions before you commit. For the level-detail context, see DCC Level 0 and DCC Level 1. For the timeline context, see how long does Defence Cyber Certification take?. For the broader DCC overview, the DCC hub is the right starting point.

Use the MOD Cyber Security Model guidance to obtain the current CSMv4 numeric profile (Levels 0–3) and Risk Assessment Reference from your buyer. Legacy verbal profiles are not directly equivalent; ask the authority to confirm transition requirements. DCC is independent evidence of compliance, while the full contract-specific SAQ remains mandatory, including for DCC holders. Annual contract SAQs and applicable subcontract flow-down remain separate from DCC annual attestations. A non-compliant SAQ requires a Cyber Improvement Plan for the authority to consider; acceptance is not automatic.

IASME’s DCC FAQ explains certificate prerequisites: Cyber Essentials at every level, and Cyber Essentials Plus at Levels 2 and 3. Early scoping and preparation can proceed before these certificates are issued. Arrange Cyber Essentials certification and annual renewal separately if needed; confirm the DCC scope in writing. Planning durations and illustrative scenarios in this guide are provider estimates, not scheme deadlines or guarantees.

The assessing Certification Body must remain independent: it may explain requirements and review scope, but must not prepare answers, documents or evidence it later assesses. Confirm any separate preparation service and technology-provider boundary in writing; the applicant owns and approves its evidence.