Scanning Cloud vs On-Premises Estates for Cyber Essentials Plus

Net Sec Group is an IASME and NCSC certification body. Across our 800-plus engagement history, the CE Plus cloud vulnerability scan methodology shifts substantially between SaaS-only estates, IaaS-heavy hybrids, and on-premises-heavy hybrids. The IASME CE Plus test specification sets the assessment behaviour; what changes per estate type is which assets the scan touches, which scanner methodology applies, and which assets we routinely observe missing from the inventory the applicant submits.

This article splits the answer into the three estate shapes we see, names the assets in scope per type, names the scanner methodology that produces audit-acceptable evidence, and publishes the three categories of asset that get missed from cloud estate scanner inventories at audit time.

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

The three estate shapes, defined

SaaS-only: zero on-premises infrastructure, zero IaaS workloads. The firm runs Microsoft 365 or Google Workspace, plus a set of SaaS tools (Slack, Notion, GitHub, finance SaaS, CRM SaaS, payroll SaaS), plus company-issued laptops on home-office broadband. Boundary is the host-based firewall on each laptop plus the SaaS platforms' admin controls.

IaaS-heavy hybrid: laptops plus IaaS workloads (AWS, Azure, GCP) plus SaaS platforms. The firm runs services on cloud infrastructure but has no on-premises servers. The IaaS environment includes virtual hosts, containers, managed services, and a control plane. Boundary is the host-based firewall on laptops plus the cloud-platform security groups plus the SaaS admin controls.

On-premises-heavy hybrid: laptops plus on-premises servers and infrastructure plus a cloud component (typically Microsoft 365 with on-premises file servers, Active Directory, network-attached storage, possibly hypervisors hosting line-of-business applications). Boundary is the network-edge firewall plus the on-premises segmentation plus the cloud admin controls.

The same five Cyber Essentials controls apply to each. The scan methodology differs. Within each estate shape, the external-vs-internal scan tier mapping still applies (perimeter scan for boundary firewalls, authenticated scan for the host fleet), but the host fleet definition expands to include cloud-platform-specific assets that on-premises estates do not have.

The 3-row scan-methodology table

| Estate type | Assets in scope for scanning | Scanner methodology | Evidence the assessor accepts | |---|---|---|---| | SaaS-only | Company laptops (host-based firewall, OS patching, anti-malware), SaaS admin consoles (configuration, MFA, access reviews) | Authenticated endpoint scan on every laptop (typically Tenable Nessus, Qualys VMDR, or InsightVM); SaaS admin scanning is admin-console review and OAuth scope review, not network scan | Per-laptop authenticated scan output + per-SaaS admin-tenant configuration export + MFA report + OAuth-scope review notes | | IaaS-heavy hybrid | Laptops + IaaS virtual hosts + IaaS managed services + IaaS control plane + SaaS admin consoles | Cloud agent on virtual hosts (AWS Inspector / Defender for Cloud / GCP SCC for the platform-native side, plus a third-party scanner with cloud-agent deployment for managed-by-customer scan); network-based scan inside the VPC for accessible services; control-plane review via Identity-and-Access-Management console | Per-virtual-host cloud-agent or network-scan output + control-plane IAM export + cloud security-group configuration + same laptop and SaaS evidence as SaaS-only | | On-prem-heavy hybrid | Laptops + on-premises servers + on-premises infrastructure (firewalls, switches, NAS) + hypervisors + cloud component (Microsoft 365 admin) | Authenticated network scan from inside the on-premises network; agent-based scan for endpoints; supplementary cloud agent for any IaaS island; firewall and switch configuration export reviewed against CIS Benchmarks | Per-host authenticated scan output + on-premises firewall config export + hypervisor host evidence + cloud admin-tenant evidence |

What changes about the scope question per estate type

SaaS-only: the SaaS platform is in scope, not just the laptops

The recurring scoping mistake on SaaS-only estates is treating the SaaS platform as out of scope because it is "cloud" rather than infrastructure. The IASME requirement covers in-scope data; SaaS platforms hosting in-scope data are in scope as configurations, even though there is no host to scan. The evidence is admin-console screenshots showing the configured controls (MFA enforcement, audit logging, sharing controls, conditional-access policies), not vulnerability scan output. See the microbusiness scope playbook on the .io sister site for the related scope-decision detail.

The scanning question on SaaS-only estates collapses to the company-issued laptops. Each laptop runs an authenticated scan. The scan finds OS-level CVEs, application-level CVEs (Office, browsers, runtime libraries), and configuration drift from the standard build. The SaaS platforms are scanned conceptually through admin-console review, not network scan.

IaaS-heavy hybrid: the IaaS workloads need agent-based or platform-native scanning

The IaaS workloads are in scope as hosts. Network-based scanning from outside the VPC catches the perimeter; the deeper assessor evidence requires authenticated scanning inside the VPC, which means cloud agents. The platform-native scanners (AWS Inspector, Microsoft Defender for Cloud, GCP Security Command Center) cover the IaaS side cleanly; they are workload-centric and do not extend to the laptop fleet.

The IaaS control plane is in scope as a configuration. Identity-and-Access-Management state, security-group rules, organisational-unit policies, audit-log destinations: these are the control-plane evidence. The assessor reads them as a configuration review, not as a vulnerability scan.

For the cross-tier scanner-comparison detail, see CE Plus Vulnerability Scanners Compared on this site.

On-prem-heavy hybrid: the network position of the scanner matters

On-premises estates have one architectural detail the cloud-only estates do not: where the scanner sits on the network. An authenticated scanner on a workstation segment that does not have read access to the server segment will not produce coverage for the server fleet. The scanner needs network-layer reachability plus authentication credentials with the appropriate scope.

The fix is typically to deploy the scanner on a dedicated management segment with explicit firewall rules permitting scanner-to-target traffic across all in-scope segments. The scanner's network position becomes part of the network-architecture evidence the assessor reviews. See Network Segmentation on this site for the segmentation reference.

The three asset categories we see missing from cloud-estate inventories

Across our engagements, three asset categories recur as gaps between the firm's claimed scope and the scanner inventory the assessor reads.

Untracked SaaS applications

The applicant lists Microsoft 365 and Google Workspace and forgets the long tail: GitHub Organisation, the AWS root account paid through the founder's personal card, the Slack workspace under a separate domain, the Calendly licence, the Loom workspace. Each is a SaaS configuration in scope if it handles in-scope data. The scanner inventory does not catch these because SaaS platforms do not deploy agents the scanner sees; the asset list does not catch them because the founder has not enumerated them. The fix is to pull the cloud-services list from finance and reconcile against the firm's identity provider's SaaS app list.

IaaS workloads outside the scanner inventory

The applicant's primary AWS account is in the scanner inventory; the secondary AWS account where the staging environment lives is not. The staging environment processes in-scope production-like data during development; the assessor reads it as in scope and the inventory does not contain it. The fix is to enumerate every cloud account paying for in-scope data processing and ensure the scanner has cross-account access or is deployed in each account.

Unmanaged virtual hosts

The applicant runs Microsoft Azure with managed virtual machines covered by the agent. A developer has spun up a personal lab VM in the same subscription using a free-tier credit, and forgotten to remove it. The lab VM is in scope as a host because it is in the in-scope subscription; the scanner does not cover it because it was not enrolled in the agent management tier. The fix is the periodic asset-list reconciliation against the cloud platform's actual VM inventory, not just the inventory the platform's monitoring layer reports.

How each native scanner sources its CVE data

A practical detail engineers ask about: where does each cloud-native scanner pull its CVE feed from, and how does that match the IASME-recognised authoritative sources.

AWS Inspector v2 uses the AWS-curated vulnerability database, which is sourced primarily from the NIST NVD feed plus AWS-specific advisories for AWS-published software (Amazon Linux, AWS-managed AMIs). For container scans, Inspector reads the image manifest and matches installed packages against the database. The CVE coverage is broad for AWS-native workloads and adequate for third-party software running on AWS hosts.

Microsoft Defender for Cloud uses Microsoft's own threat-intelligence feed alongside NVD, with Microsoft Defender Vulnerability Management as the underlying scanner for Windows and Linux hosts. The feed is unusually current for Microsoft-published software (Windows, Office, .NET runtime); third-party software coverage matches the NVD baseline.

GCP Security Command Center uses Google's threat-intelligence feed plus NVD, with the underlying scanner being a combination of OS Config and Container Analysis depending on workload type. Coverage is current for Google-published software and adequate for third-party software on Compute Engine instances.

The implication for CE Plus evidence: the assessor reads the CVE numbers and CVSS scores in the scan output. Where two scanners disagree on whether a CVE applies to a specific host (a tier 2 false-positive scenario covered in false positives in CE Plus vulnerability scans), the resolution path is to cite the authoritative NVD entry alongside the scanner output and let the assessor read both.

Scoping the scanner agent rollout

For IaaS-heavy hybrids in particular, the scanner agent rollout is its own engineering project before the CE Plus engagement begins. Three considerations decide whether the rollout produces audit-ready evidence on the day or produces incomplete coverage that pushes the engagement out.

Coverage completeness: every in-scope virtual host needs the agent installed. The deployment mechanism varies (Systems Manager / Patch Manager on AWS, Azure Automation / Defender for Cloud auto-provisioning on Azure, GCP OS Config Management on GCP). The applicant verifies the agent is installed by exporting the agent inventory and reconciling against the asset list. Gaps go through the missing-asset triage described above.

Permission scope: the agent needs read access to the host's package inventory, configuration files, and running services. Default agent permissions are typically sufficient on cloud-platform-managed hosts; custom-built hosts may need permission grants. The applicant validates permission coverage on a sample host before rolling out to the fleet.

Network reachability for callback: the agent reports findings back to the management console over the cloud platform's control plane. In segmented IaaS environments with strict outbound controls, the agent's callback path needs explicit firewall rules. The applicant confirms callback works by reading the management console's "last seen" timestamp per host.

When all three considerations are met, the scanner produces audit-ready evidence on the assessment day. When one is missed, the assessor reads incomplete coverage and the engagement extends.

Practitioner observations

Three observations from the engagement history.

1. SaaS admin scanning is configuration review, not vulnerability scanning, and that is the IASME-accepted treatment. Engineers who try to retrofit traditional scan output onto a SaaS-only estate end up with thin evidence packs. The correct path is admin-console export plus configuration documentation; both are valid CE Plus evidence.

2. Cloud-agent deployment lag matters. A new cloud agent deployed to a virtual host needs 24 to 48 hours of visibility before the first scan output is reliable. Plan the scan window with the deployment-to-output lag accounted for; running the scan the morning of the assessment with agents deployed the night before produces incomplete output.

3. The scope statement is the asset-list bridge. Where scanner inventory and asset list diverge, the scope statement reconciles them. A clean scope statement that names included subscriptions, excluded subscriptions, and the rationale for each exclusion, gives the assessor the framework to read the scanner output against the right baseline.

Common questions

Does Microsoft 365 count as in scope for CE Plus?

Yes if it handles in-scope data. The platform itself is in scope as a configuration; the configuration evidence is admin-console screenshots showing MFA enforcement, audit logging, conditional-access policies, sharing controls, and access reviews. The platform's underlying patching cadence is the platform vendor's responsibility; the firm's responsibility is the configuration on top.

Does CE Plus require scanning of containers as well as virtual hosts?

Yes when the containers run in-scope workloads. Container scanning is supported by the major scanners (Nessus, Qualys, Rapid7) and by the cloud-native platforms (AWS ECR scanning, Defender for Cloud container assessment, GCP Container Analysis). The evidence is image-level scan output plus the runtime-policy enforcement showing only scanned images can be deployed.

What about serverless functions (AWS Lambda, Azure Functions, GCP Cloud Functions)?

Serverless functions are in scope when they handle in-scope data. The vulnerability surface is the function's runtime image plus its dependencies; cloud-platform-native scanners cover this (AWS Inspector for Lambda, Defender for Cloud for Functions). The configuration surface is the function's IAM role and trigger configuration, evidenced by control-plane export.

My estate uses Windows 365 cloud PCs. Does the agent on the Cloud PC count as covering it?

Yes, with the Windows 365 instance treated as a virtual host for scanning purposes. See the netsecgroup.io Windows 365 Contractor Scope reference for the scope mechanics. The host-based agent on the Cloud PC produces the per-host scan output the assessor reads alongside any other in-scope virtual host evidence.

Where do we book CE Plus?

Book a Cyber Essentials Plus assessment with Net Sec Group. The booking form lets you describe the estate shape (SaaS-only, IaaS hybrid, on-prem hybrid); the assessor confirms the scope and the engagement timeline.

Reference material

Where this fits on this site

This article is the cloud-vs-on-prem methodology 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 False positives in CE Plus vulnerability scans. For platform-specific deep dives, see the upcoming Google Workspace for CE Plus and Intune for CE Plus configuration under the platform-specific hub. For network-architecture references, see Network Segmentation and Secure Configuration on this site.