False Positives in CE Plus Vulnerability Scans, What the Assessor Accepts

Net Sec Group is an IASME and NCSC certification body. Across our 800-plus engagement history, the recurring night-before-audit question we field on a CE Plus false positive scan finding is "the scan flagged a high or critical finding I believe is a false positive, what evidence does the assessor accept as documentation". This article is the answer at audit resolution: three tiers of FP claim, what the assessor accepts cleanly, what the assessor queries before accepting, and what the assessor rejects.

The scan tool produces the finding. The applicant produces the documentation that explains why the finding is not exploitable in the in-scope estate. The assessor reads both and decides whether the patching or secure-configuration control passes despite the open finding. The decision turns on the documentation, not the engineer's verbal assurance.

For the broader CE Plus assessment-day reference, see the CE Plus Assessment Guide on netsecgroup.io. For the related vulnerability-scanning content on this site, see the vulnerability-scanning hub.

Why false positives matter at CE Plus

The IASME CE Plus test specification requires the in-scope estate has no critical or high-severity CVEs older than 14 days from vendor patch release. The internal authenticated scan tests this directly. When the scanner reports a finding, the assessor reads it as a control breach unless the applicant has documented why the finding is a false positive or why a compensating control mitigates the risk to acceptance level.

Engineering teams familiar with internal vulnerability management have a sense of which findings are noise. The CE Plus assessor reads the scan output cold; the applicant cannot rely on the assessor's prior knowledge of the estate. Documentation is the only path that survives the audit.

The three-tier acceptance table

The table below comes from the assessor's typical decisions across our engagement history. Each tier is a category of FP claim with a representative example.

| Tier | Category | Assessor decision | Example | |---|---|---|---| | 1 | Vendor advisory excludes the CVE | Accept | Microsoft Security Response Center advisory states CVE-2025-XXXXX does not affect Windows Server 2022 Datacenter Edition; scanner flagged it on a 2022 Standard Edition install where it does apply | | 1 | Compensating control with logged enforcement | Accept | A web-application firewall rule blocks the exploitation path, with the WAF rule deployed before vendor patch release date and the firewall logs showing zero matched events on the rule signature | | 1 | Version banner mismatch with proof | Accept | Apache HTTP Server 2.4.58 banner shows on a server actually running 2.4.62 due to a build-string default; vendor source confirms the build is 2.4.62 and the running binary's checksum proves it | | 2 | In-house written exception | Query | Engineering team writes "this is a known false positive, the affected component is not in use" without vendor advisory backing; assessor asks for the vendor advisory or compensating-control evidence | | 2 | Scanner-specific quirk | Query | A particular scanner version reports a CVE on a host that, when re-scanned with another scanner or the same scanner at a different patch level, does not show the finding; assessor asks for the cross-scanner evidence | | 3 | Undocumented "we know it's fine" | Reject | No vendor advisory, no compensating control, no logged enforcement; engineering team's verbal assurance only | | 3 | Deferred remediation without compensating control | Reject | "We will patch in next quarter's release window" without a compensating control covering the gap | | 3 | Age of finding overrides documentation | Reject | A finding older than the 14-day window with no patch applied and no compensating control, even if the engineering team has been "monitoring" it |

What tier 1 evidence looks like in practice

Three sub-categories the assessor accepts cleanly. Each requires concrete evidence, not assertion.

Vendor advisory exclusion

The vendor's published security advisory names the affected versions explicitly. The applicant's evidence pack includes a link to the advisory, a screenshot of the relevant section, and the per-host inventory showing the running version is outside the affected range.

For Windows, the source is Microsoft Security Response Center; for macOS, Apple Security Updates; for Linux distributions, the distribution security tracker (Red Hat Security Data, Ubuntu Security Notices, Debian Security Tracker). For commercial application vendors, the vendor's own security bulletin pages. For cloud-platform CVEs (AWS, Microsoft 365, Google Cloud, Azure), each platform's security advisories page is the source of record; the per-platform scope considerations are covered in scanning cloud vs on-premises CE Plus.

Compensating control with logged enforcement

The applicant demonstrates the exploitation path is blocked by a control deployed before the CVE's vendor-published date. Concrete examples: a web-application firewall rule, a network-segmentation policy preventing lateral movement, an application-control policy preventing the affected component from running. Evidence includes the control configuration export, the deployment date, and logs showing zero matched events for the period since deployment.

The control needs to be enforcement-level (logs evidence the enforcement happened), not detection-level (the control would have logged if anything had happened, but nothing did, so there is nothing to show).

Version banner mismatch with proof

The scanner reads a service banner that does not match the actual running build. The applicant proves the running build differs from what the banner reports, and the actual build is not affected by the CVE. Evidence includes the package-manager version output, the binary checksum compared against vendor checksums, and the vendor advisory excluding the actual build.

This is rarer than the first two but recurs in long-running infrastructure where vendor patches change behaviour without changing reported version strings.

What tier 2 evidence looks like

Tier 2 evidence is plausible but incomplete. The assessor queries before deciding. The query process is not failure; it is the assessor asking for the evidence the documentation should already include.

In-house written exception

The engineering team has documented the FP claim internally but has not produced the vendor-advisory or compensating-control backing. Typical wording: "after investigation, the team determined the finding is a false positive". The assessor's query is "produce the vendor advisory excluding the CVE, or produce the compensating-control evidence". The applicant produces it, the FP claim moves to tier 1.

Scanner-specific quirk

The applicant has noticed the finding is reported by Scanner A but not by Scanner B at the same patch level on the same host. The cross-scanner evidence is the FP signal. The assessor queries: produce the cross-scanner output side by side, with the host inventory, scan timestamps, and scanner versions. The applicant produces it, the FP claim resolves.

The category exists because scanners do disagree, especially on edge-case detection (banner-based detection vs registry-based detection, certificate-chain interpretation, custom-built component CVEs). Resolution is mechanical when the evidence is collected.

What tier 3 evidence looks like, and why the assessor rejects

Tier 3 is the category that fails CE Plus on the day. The applicant has the finding open, has not produced documentation that meets tier 1 or tier 2, and the patching control fails.

The reason the assessor rejects is structural: CE Plus is a test of the firm's vulnerability management practice, not of the assessor's willingness to accept verbal claims. Accepting "we know it's fine" without documentation would let any firm pass any scan finding by saying so. The audit-resolution standard exists to keep CE Plus a meaningful technical certification.

The fix when an applicant has tier 3 findings: either patch them inside the 14-day window before the assessment, or escalate to a vendor support call to get a tier 1 advisory, or design and deploy a compensating control with logged enforcement and re-scan to demonstrate the control's effect. The escalation does not happen on assessment day; it happens before.

A sample exception template the assessor accepts

The following template covers the fields an assessor expects when reviewing a documented FP. Net Sec Group has accepted the template structure on hundreds of engagements; vendors and consultancies have minor variants but the field set is consistent.

CVE: CVE-YYYY-NNNNN
Scanner finding ID: <scanner-specific>
Affected host(s): <hostname or IP, in scope>
Date scanner reported: <ISO date>
Vendor patch release date: <ISO date>

FP claim category: [tier 1: vendor exclusion | tier 1: compensating control | tier 1: banner mismatch | tier 2: in-house exception | tier 2: scanner quirk]

Evidence supporting claim:
  - <link to vendor advisory + screenshot of relevant section>
    OR
  - <compensating control configuration export + deployment date + log evidence>
    OR
  - <package version proof + checksum comparison + vendor source>

Control owner: <named human, role>
Sign-off date: <ISO date>
Review date (next): <ISO date, typically scan + 90 days>
Notes: <any additional context the assessor should know>

The fields are the same regardless of scanner. Apply them in your scanner's exception or suppression workflow, attach the evidence as artifacts, and the assessor reads them on the day without needing additional clarification.

Practitioner observations from 800-plus engagements

Three observations decide whether tier 2 findings escalate to tier 1 cleanly or slide to tier 3.

1. The vendor-advisory hunt is faster than engineers expect. A finding marked "false positive" on day 1 of evidence collection routinely resolves to a tier 1 vendor-advisory citation by day 2 if someone runs the right MSRC or RHSA query. Investing 30 minutes per finding before the assessment saves the back-and-forth on the day.

2. Compensating controls need to predate the CVE, not follow it. A WAF rule deployed in response to the scan finding is a remediation, not a compensating control. The assessor reads the deployment dates against the CVE published date; controls deployed after the published date do not earn FP acceptance, they earn remediation credit toward the patching window.

3. Suppressions in the scanner carry forward, exceptions in the evidence pack do not. When the next CE Plus assessment runs in 12 months, the in-scanner suppression travels with the scanner; the manually-written exception document in the evidence pack does not. Update the in-scanner suppression with the same evidence as the written exception, and the next assessment reads cleanly without rework.

For the scanner-suppression mechanics per tool, see CE Plus Vulnerability Scanners Compared on this site.

Common questions

Does the assessor accept a CVSS environmental score adjustment as a tier 1 FP?

Yes when the adjustment is documented per the FIRST CVSS specification and the modified score reflects the in-scope estate's actual configuration. The CVSS v3.1 environmental group has two sub-groups: the Modified Base Metrics (Modified Attack Vector, Modified Attack Complexity, Modified Privileges Required, Modified User Interaction, Modified Scope, and Modified Confidentiality / Integrity / Availability impacts), and the Security Requirements metrics (Confidentiality Requirement, Integrity Requirement, Availability Requirement). Both are the documented mechanism for adjusting a finding's severity to reflect the local environment. When the adjusted score moves a finding below the high-severity threshold, the 14-day patching window does not apply. The assessor reads the environmental adjustment and the supporting evidence; if both are sound, the FP claim is tier 1.

Can I document a finding as a false positive without the vendor's advisory?

Yes if the compensating-control evidence is solid. Vendor advisories are one of three tier 1 paths; the other two are compensating control with logged enforcement and version banner mismatch with proof. Pick whichever fits the actual situation.

The scan is reporting findings on a host that is in scope but unreachable on the day. What does the assessor expect?

The assessor expects either evidence the host was scanned within 48 hours of the assessment day (with the scan output produced), or evidence the host has been removed from the in-scope estate before the assessment (with the scope statement updated to reflect this). A host in scope per the SAQ but unreachable for scanning is a control gap, not a false positive. The scope-decision and scan-tier mechanics behind unreachable-host handling are covered in external vs internal scanning for CE Plus.

Where do we book CE Plus?

Book a Cyber Essentials Plus assessment with Net Sec Group. The booking form lets you describe the scanning tooling and FP-handling workflow you intend to use; the assessor confirms the engagement timeline.

Reference material

Where this fits on this site

This article is the FP-handling spoke under the vulnerability-scanning hub. The other vulnerability-scanning spokes are CE Plus Vulnerability Scanners Compared, External vs internal scanning for CE Plus, and Scanning cloud vs on-premises CE Plus. For the foundation patching topic, see Patching and Updates and Vulnerability Scanning on this site.