The Cyber Essentials Plus Second-Sample Rule, When It Triggers and What Happens Next
Net Sec Group is an IASME and NCSC certification body. The second-sample rule is a Danzell-era change to Cyber Essentials Plus that catches applicants out, because it is not yet in the v3.3 NCSC requirements document and is buried in the IASME test specification under a single paragraph. The practical effect is: if your first internal vulnerability scan finds unpatched vulnerabilities, the assessor takes a second random sample from across your estate, and if that second sample also has issues you fail the engagement.
This article walks the rule in plain English, with the trigger, the timing, the size, and the failure consequences, plus a contrast pair drawn from real assessment days.
If you are scoping CE Plus and want to understand the second-sample contingency before booking, this is the explainer. If you are mid-engagement and the assessor has just called for a second sample, this is the diagnostic.
What the rule actually says
In plain English, the second-sample rule is:
- The first internal vulnerability scan runs against the original sample (calculated from the IASME table per Cyber Essentials Plus Sample Sizes)
- If that first scan finds unpatched vulnerabilities (high or critical CVSS findings outside the 14-day window, or end-of-life software, or other patching control failures), the assessor selects a second sample
- The second sample is the same size as the first
- The second sample is selected at random from across the estate, not from the same build the first failure was on
- The applicant gets a maximum of 3 days' notice before the second sample scan runs
- The 30-day remediation window from the original engagement still applies; the second sample does not restart the clock
- If the second sample is clean, the engagement passes (subject to the other controls passing)
- If the second sample has the same vulnerabilities that failed the first, the engagement fails and the applicant's basic Cyber Essentials certificate (the VSA) can be revoked
- If the second sample has different vulnerabilities, the engagement passes but the applicant receives an advisory about the new findings
- There is no third sample. If the second sample fails, the engagement fails
The rule applies to internal vulnerability scans only. Other CE Plus tests (boundary firewalls, anti-malware, account controls, secure configuration) do not trigger second samples in the same way.
For the formal netsecgroup.io reference covering the rule and its rationale, see Cyber Essentials Plus Second Sample Rule.
What triggers the second sample, exactly
The trigger is "unpatched vulnerabilities found in the first internal vulnerability scan". In assessor-day practice, that means:
- A high or critical CVSS finding on a sampled device where the patch was released more than 14 days before the assessment day
- An end-of-life operating system or end-of-life application on a sampled device
- A patch-management coverage gap that produces an unmanaged piece of in-scope software with known CVEs
The trigger is not:
- A failure on the boundary firewall test
- An MFA configuration failure on the account-controls block
- An anti-malware agent that is missing or not reporting (this is malware-protection, not internal scan)
- An evidence-format failure where the documentary evidence was the wrong format but the underlying control was fine
- A soft fail that the IT lead corrects on the live screen-share inside the same scan window (some platforms allow this; the assessor accepts the corrected state)
The distinction matters because applicants who hear "second sample" sometimes assume any failure causes one. The trigger is specifically internal vulnerability scan unpatched-software findings.
How the second sample is selected
The second sample is not "another batch from the same build that failed". The assessor selects randomly across the entire in-scope estate, weighted by the sample-size formula:
- Same total sample count as the first
- Each build is sampled per the IASME band table (see Cyber Essentials Plus Sample-Size Rules Explained)
- Devices already in the first sample are not in the second sample
- Servers are tested in full again if the first server scan had a failure (the no-sampling-on-servers rule applies on the second sample as well)
The randomisation is the point of the rule. The applicant cannot remediate one device, present it as evidence, and have the assessor declare the estate fixed. The randomisation forces the question "is this a sample failure or an estate-wide failure".
When the assessor pauses the day versus carries on
In assessment-day practice, the assessor's decision on when to call for the second sample is shaped by where the failure surfaced:
| First-scan finding | Day-of decision | |---|---| | One device, one critical CVE, IT lead can patch on the call | Soft fail, patch on the call, assessor verifies on the live screen-share, no second sample | | Multiple devices, same CVE, fix is the same patch across the build | Second sample called, scheduled inside the 30-day window, day continues with non-vuln-scan tests | | One device, end-of-life OS | Hard fail on that device, second sample called to confirm the EOL is not estate-wide | | Patch-management coverage gap (third-party software not in tooling) | Second sample called once the coverage gap is documented | | One device, a scanner false positive that the IT lead can demonstrate is not actually a vulnerability | Assessor verifies the false-positive claim on the live screen-share, finding withdrawn from the report, no second sample |
The assessor does not usually pause the assessment day for the second sample. The first scan completes, the assessor schedules the second sample inside the 30-day window with the 3-day notice rule, and the rest of the assessment day continues with the other test blocks.
Contrast pair: when the second sample triggered, when it did not
These are two anonymised cases drawn from our 800+ assessment history. Both had a similar surface failure count on the first internal scan. Only one triggered a second sample.
Case A: second sample triggered
A 60-device firm on Windows 11 Pro 24H2 with mixed Adobe Acrobat versions. The first scan found 5 critical CVSS findings: two on Windows (a cumulative update missed across the estate), two on Adobe (the Acrobat version was outside the patch window), one on a browser plug-in.
The assessor's read: the underlying causes (un-deployed Windows cumulative update, untracked Adobe coverage, untracked plug-in) all imply estate-wide gaps. The second sample triggered.
The second sample, scheduled 3 days later, hit a different group of devices in the same fleet. The Windows update had been deployed across the estate in those 3 days. The Adobe issue had not. The plug-in issue had been removed by removing the plug-in. The second sample found Adobe issues on the new devices and confirmed the estate-wide gap. The engagement failed.
Case B: second sample not triggered
A 60-device firm on Windows 11 Pro 24H2, similar fleet shape. The first scan found 5 high CVSS findings, all on a single Linux development server that the firm had taken out of the standard patch cadence to support a vendor-pinned application stack.
The assessor's read: the failures clustered on one device, the underlying cause was a documented vendor pinning, and the firm had a documented compensating control statement for the device with monitoring in effect. No estate-wide pattern.
The assessor accepted the compensating-control statement, recorded the device-specific findings as a hard fail on the device with documented mitigation, and did not call for a second sample. The remediation closed within the 30-day window with the device's vendor pinning lifted on a documented schedule.
The lesson: surface failure count is not the trigger. The trigger is whether the underlying cause looks estate-wide. A single-device failure with a documented technical justification is not the same as a multi-device failure with an estate-wide cause.
What evidence the second sample requires
If a second sample is called, the assessor needs the same evidence shape as the first sample, applied to the new devices:
- Patch-management tooling export covering each device in the second sample, with patch state and last-scan timestamp
- Anti-malware management-console reporting status for each device in the second sample
- For servers in the second sample: the server-specific evidence the first sample collected (configuration, account list, MFA on management interfaces)
- For end-user devices: the build-standard verification evidence (screen-lock, AutoPlay state, software firewall state)
The second sample evidence is collected during the second-sample scan, not pre-staged. The applicant does not have to gather a separate evidence pack before the scan; the assessor's tooling captures what is needed during the scan.
For the broader evidence-format reference covering both first and second samples, see The evidence the CE Plus assessor accepts.
What happens if the second sample also fails
The IASME rule is binary: if the second sample finds the same vulnerabilities that failed the first sample, the engagement fails. There is no third sample.
The downstream effects are real:
- The CE Plus engagement fails. The applicant has to re-engage from scratch (the 30-day reassessment window does not apply to the engagement, only to the original first-attempt engagement; once the second sample fails, the engagement is closed)
- The basic Cyber Essentials certificate (the VSA) can be revoked. This is at the IASME accreditor's discretion based on the severity of the failures. A second-sample fail on Adobe is unlikely to revoke the VSA; a second-sample fail showing systemic patching failure across the estate may
- Customer procurement timelines slip. If you are CE Plus-blocked on a customer contract, a second-sample fail typically adds 30 to 60 days to the timeline (re-engagement plus remediation). Talk to the customer at the same time you receive the report
For the formal re-engagement rules after a complete fail, see The CE Plus second-attempt rules.
How to defuse the second-sample risk before the assessment
If you are scoping a CE Plus engagement and want to minimise the second-sample risk, the work below is roughly the same as the patching pre-assessment checklist, with a few additions specific to the second-sample trigger:
- Run a live external vulnerability scan against your internet-facing in-scope assets, inside the 24 hours before the assessment day. No high or critical findings remain
- Run a live internal vulnerability scan against your in-scope estate (not just a sample), inside the 24 hours before the assessment day. No high or critical findings remain
- Confirm patch-management tooling covers every in-scope device, including third-party software (Adobe, Java, browser plug-ins)
- Confirm no end-of-life operating systems or applications are in scope
- Confirm any vendor-pinned applications have a documented compensating-control statement and the controls are demonstrably in effect
We routinely run a pre-assessment vulnerability scan as part of CE Plus engagement preparation. The pre-assessment scan finds the kind of issue the assessor's first-scan would, before the assessment day, with time to fix.
For the deeper drill on patching failure cases, see The CE Plus patching failure cases. For BYOD-specific sampling considerations, see BYOD sampling on CE Plus. For the broader failure-pattern reference, see The most common CE Plus failures by control.
Common questions
Is the second-sample rule in the NCSC requirements document?
Not in v3.3 yet. It is in the IASME test specification and is the process assessors are expected to follow under the Danzell-era changes. The rule applies to engagements running today.
Does the 3-day notice include weekends?
The 3-day notice is calendar days, the same as the 30-day remediation window. A second sample scheduled on a Tuesday with 3 days' notice runs on Friday.
Can we ask the assessor to defer the second sample beyond the 3-day notice window?
The 3-day notice is a maximum, not a minimum. The applicant can request more notice; the assessor can accept the request as long as the second sample completes inside the original 30-day remediation window. The assessor cannot extend the 30-day window itself; that is an IASME-level decision.
Does a soft fail on the first scan that we fix on the live screen-share trigger a second sample?
No. Soft fails corrected on the live call are recorded as soft fails closed, and the assessor does not call for a second sample on that issue. The trigger is unpatched vulnerabilities that remain at the end of the first scan, not failures that were corrected during it.
What if we have a small estate where the first sample is the same as the second sample?
For very small estates (a single build with fewer than the table's smallest band), the first sample is the entire fleet. In that case the second-sample rule does not have additional devices to test; the assessor relies on the first-sample evidence and the applicant's remediation across the entire fleet.
Does the second-sample rule apply to BYOD devices?
Yes. BYOD devices in scope are part of the sample population for both first and second samples. For the BYOD-specific sampling considerations, see BYOD sampling on CE Plus.
Next steps
- For the base sample-size formula, see Cyber Essentials Plus Sample-Size Rules Explained
- For BYOD sampling specifics, see BYOD sampling on CE Plus
- For the full reassessment rules if the engagement fails, see The CE Plus second-attempt rules
- For the broader failure-pattern reference, see The most common CE Plus failures by control
For the deeper netsecgroup.io references:
- Cyber Essentials Plus Second Sample Rule
- Cyber Essentials Plus Sample Sizes
- Cyber Essentials Plus Assessment Guide
When you are ready to book or want a pre-assessment vulnerability scan to defuse the second-sample risk before the engagement starts, contact Net Sec Group or book a Cyber Essentials Plus assessment directly.