Cyber Essentials for a Cloud-Only Business, the Five Controls Translated

Net Sec Group is an IASME and NCSC certification body. We have assessed cloud-only businesses repeatedly across our 800-plus engagement history. The most common buyer profile is a 5 to 30 person SaaS startup, professional services firm, or remote-first consultancy with Microsoft 365 or Google Workspace, an Infrastructure-as-a-Service platform (AWS, Azure, or Google Cloud), no office, no servers on premises, no on-premise firewall, and a fleet of company-issued laptops on employees' home-office broadband. This article answers the specific question that profile arrives with: "how does Cyber Essentials apply to us?"

The five Cyber Essentials controls were originally written for offices with on-premise infrastructure. They still apply when the office is gone; the evidence shape changes. This article walks through each control translated into the cloud-only environment, with the per-control evidence formats an IASME assessor accepts. For the deeper technical reference covering all five controls in their original form, see the Cyber Essentials Five Controls Technical Guide on netsecgroup.io.

The cloud-only profile in scope

The example we use throughout this article is the 10-person SaaS startup running Microsoft 365 plus AWS, with no office, all employees on company-issued laptops connecting from home-office broadband. The five controls translate as follows; the same translations apply to broadly similar profiles (Google Workspace plus GCP, Office 365 plus Azure, professional services firm with Office 365 only). Where your profile differs, the scope-decisions hub indexes the variants.

Control 1, Boundary Firewalls and Internet Gateways

Original control: a perimeter firewall between the office network and the internet, with default-deny on inbound traffic.

Cloud-only translation: there are two boundaries to evidence in a cloud-only firm. The first is the host-based firewall on each company-issued laptop (Windows Defender Firewall, macOS Application Firewall, Linux UFW), since the laptop connects to the internet directly without an office gateway. The second is the IaaS network-layer controls (AWS security groups, Azure network security groups, GCP firewall rules) protecting any in-scope workload running in your IaaS account.

Evidence the assessor accepts:

• Per-laptop screenshot showing the host-based firewall is on, with default policy
• For each in-scope IaaS workload, the security group or NSG configuration showing default-deny on inbound and the explicit list of permitted inbound traffic
• A written network architecture diagram showing the in-scope cloud workloads and how they interconnect (one paragraph plus a sketch is sufficient)

What fails this control in a cloud-only firm: an open inbound rule on an IaaS security group ("0.0.0.0/0 to port 22") to support a temporary debugging session that was never cleaned up. The assessor sees the rule on the day; the applicant cannot explain why it is open.

Control 2, Secure Configuration

Original control: a hardened standard build for every in-scope device, with default accounts removed, default passwords changed, and unnecessary services disabled.

Cloud-only translation: there are two layers. The first is the laptop standard build, same as the original control with the cloud-native variation that MDM (Microsoft Intune, Jamf, Google Endpoint Management) is the configuration source. The second is the SaaS hardening baseline, where the configuration of Microsoft 365, Google Workspace, AWS, Azure, or GCP is the in-scope artefact, not a standard image.

Evidence the assessor accepts:

• Per-OS standard build documentation (Windows 11 24H2 Pro on the Pro Plan baseline, macOS 15 on the corporate baseline, etc.)
• MDM configuration export showing the policy applied to in-scope devices
• For each SaaS platform: a hardening baseline document referencing CIS Benchmarks for Microsoft 365 or Google Workspace, the AWS or Azure or GCP CIS Benchmark, with screenshots showing the configured controls
• A list of disabled or removed default features (Microsoft 365 Mailbox Audit on, Public Folder sharing off where not used, AWS root account locked behind hardware MFA, Azure default subscription tenant restrictions on)

What fails this control in a cloud-only firm: the Microsoft 365 tenant left at default (no audit logging configured, public sharing on, anonymous access enabled). The assessor sees the default and the applicant cannot show evidence of intentional configuration.

Control 3, User Access Control

Original control: administrative privilege separated from day-to-day user accounts, MFA enforced, leaver process documented and run.

Cloud-only translation: this control applies almost identically in the cloud-only environment because identity is the new perimeter. At CE Basic the IASME requirement is MFA enforced and verifiable on every cloud admin account; per-user MFA at the account level is acceptable evidence at this tier. Conditional Access is the requirement at CE Plus.

Evidence the assessor accepts:

• Microsoft 365 MFA report or Google Workspace 2-step verification report showing every admin account with MFA enforced
• AWS IAM credential report and Azure AD MFA report showing the same
• Admin account list with each entry mapped to one named human (no shared accounts)
• Worked-example leaver record from the last 90 days showing identity-provider account disabled and access revoked across SaaS platforms within a defined window
• Joiner process documentation showing how administrative privileges are granted, reviewed, and time-bounded

What fails this control in a cloud-only firm: a service account on AWS or Azure with administrative permissions and no MFA, identified during evidence intake. The fix is to replace the service account with a managed identity (AWS IAM role, Azure managed identity, GCP service account with workload identity federation) and document the substitution. See MFA on Cloud Services on netsecgroup.io for the deeper treatment.

Control 4, Malware Protection

Original control: anti-malware software on every in-scope device, configured to scan and report.

Cloud-only translation: identical in shape, evidenced from the device. Microsoft Defender for Endpoint is acceptable on Windows; the macOS equivalent or CrowdStrike, ESET, Sophos, Bitdefender are acceptable on macOS. The cloud-only variation is that the management console is itself a SaaS service (Microsoft Defender XDR, CrowdStrike Falcon Console), which simplifies evidence capture but adds the requirement that the SaaS console is also in scope and protected by MFA.

Evidence the assessor accepts:

• Per-device screenshot showing anti-malware service running and definitions current
• Management-console screenshot showing the in-scope device fleet reporting healthy
• Documented exclusions list (which paths are excluded and why)

What fails this control in a cloud-only firm: a personal laptop in scope (because it has corporate mailbox access) with no managed anti-malware, identified on the day. The fix path is BYOD scoping; see BYOD Cyber Essentials decisions, fast for the BYOD evidence formats.

Control 5, Security Update Management

Original control: critical and high-severity patches applied within 14 days of vendor release for every in-scope device, application, and firmware.

Cloud-only translation: this is the control where cloud-only firms miss the evidence shape more than any other. Founders assume that Windows Update on auto, macOS Software Update on auto, and SaaS platforms updating themselves are sufficient. The assessor needs the report showing the 14-day window was met for each in-scope device, not the auto-update toggle.

Evidence the assessor accepts:

• Patch-management console export (Intune compliance report, Jamf patch report, third-party patch tool report) showing every in-scope device and its patch status against critical and high-severity updates
• Manual patch evidence per device for firms without a patch-management tool: per-device screenshot of "Windows Update" or "Software Update" history showing the most recent critical patches applied within the window
• For SaaS platforms: documentation referencing the platform's published patch cadence (Microsoft Service Health, Google Workspace status, AWS service notifications) and confirmation the applicant subscribes to the relevant security bulletins
• Written patching policy covering frequency, coverage, exception handling, and escalation

What fails this control in a cloud-only firm: an applicant who relies on auto-update without producing the report. The single highest-frequency cloud-only failure we see is patching evidence shape, not patching itself. The fix is to enrol every in-scope device in MDM (if not already), pull the compliance report, and produce the export. The fix is fast; the realisation that the evidence is the report not the toggle is the part that takes founders by surprise.

What ties the cloud-only translation together

Three principles thread through all five controls:

1. Identity is the new perimeter. Every control either touches identity directly (Control 3) or is secured by identity (cloud-platform admin protected by MFA in Controls 2, 4, 5). MFA on every cloud admin is the load-bearing precondition for the entire cloud-only assessment.

2. The SaaS platform is in scope, not just the laptop. Controls 1, 2, and 5 all require evidence from the SaaS platform's admin console, not just from the device. A founder who scopes only the laptops and not the cloud platforms misses three controls' worth of evidence.

3. Auto-update is not the evidence; the report is the evidence. Founders relying on platform auto-update for patching consistently fail the evidence shape. The fix is the report, not the policy.

Common cloud-only edge cases

No office at all, contractors only

If every worker is a contractor on their own hardware, the scope decision is whether the contractor laptops are in scope. They are in scope if they handle in-scope data; the evidence formats are then the BYOD formats described in the BYOD decisions article. For company-issued contractor laptops, treat them like employee laptops.

IaaS account is owned by a parent company, not the applicant

If the applicant uses a parent-company AWS or Azure tenant, the scope statement should clarify which tenant subscriptions or accounts are in scope. Evidence for those subscriptions is required; out-of-scope tenant subscriptions are excluded with documented justification.

Some employees use personal phones for corporate email

Personal phones with native corporate email apps are in scope; personal phones with browser-only access through a Conditional Access policy may be out of scope (the conditional-access controls become the in-scope evidence). The choice depends on the path. See the BYOD decisions article for the four worked shapes.

The firm uses Windows 365 cloud PCs instead of physical laptops

The Windows 365 instance is in scope as a device; the host hardware is in scope to the extent the connection touches it. See the netsecgroup.io Windows 365 Contractor Scope reference for the worked treatment.

The evidence pack for the example profile

For the 10-person SaaS startup on Microsoft 365 plus AWS, the assessor expects:

• 10 laptop screenshots showing host-based firewall on
• 10 laptop screenshots showing the standard build (operating system, version, patches current)
• 1 Microsoft 365 hardening baseline document with screenshots
• 1 AWS hardening baseline document with screenshots
• 1 Microsoft 365 MFA report (every admin and every user)
• 1 AWS IAM credential report
• 1 admin account list mapped to named humans
• 1 worked-example leaver record
• 10 anti-malware screenshots per device, plus management-console summary
• 1 Intune patch compliance report (or per-device patch evidence)
• 1 patching policy document

That is the complete pack for the profile. Capturing it takes 1 to 2 days for a prepared founder; the engagement runs in 12 to 48 hours after the pack is in place. See the 12-hour fast-track, 7-day prep plan, and 30-day prep plan for the engagement options.

Common questions

We have no formal IT team and only one founder running everything. Does that change the scope?

No, the scope is the same. The work concentrates on one person rather than a team. See the Cyber Essentials microbusiness scope article for proportional treatment.

We use a managed service provider for IT. Can they prepare the evidence pack?

Yes, this is common. The managed service provider produces the evidence; the named signatory at the applicant signs the SAQ. The evidence shape is the same.

One of our employees is in the US. Are their laptops in scope?

If they handle in-scope data, yes. The location does not affect scope; the data flow does. The laptop is treated like any other in-scope laptop.

Our IaaS workloads run customer data, but no employee logs into the IaaS console day to day. Does the IaaS layer need full evidence?

Yes. Customer data on an IaaS platform makes that platform in-scope regardless of login frequency. The evidence is the configuration of the platform's controls (security groups, IAM, audit logs), not the login frequency.

Where do we book?

Book a Cyber Essentials assessment with Net Sec Group. The booking form lets you describe the cloud-only profile in scope; the assessor returns a confirmed scope statement and engagement timeline.

Reference material

For deeper Net Sec Group references covering cloud-specific scope decisions:

• Cyber Essentials Five Controls Technical Guide
• MFA on Cloud Services for Cyber Essentials
• Cyber Essentials Windows 365 Contractor Scope
• Cyber Essentials Certification Guide
• CE Self-Assessment Tool

Where this fits on this site

This article is the cloud-only spoke under the scope-decisions hub. The other scope-decision spokes are the Cyber Essentials microbusiness scope, Cyber Essentials without an IT team, and the BYOD decisions article. Once the scope decision is settled, the timelines hub indexes the three engagement-speed paths.