BritiAI · NHS SBS Bid Vault

NHS SBS Bid Vault SBS10523 · Healthcare AI Solutions

Deadline Tue 21 Jul 2026, 12:00 BST · Content complete Fri 10 Jul → internal review & audit → final submission Tue 14 Jul 2026 · Last updated 2 Jul 2026, 20:00
Time left
--days
:
--hrs
:
--min
:
--sec

32.01 Readiness Brief

9 min read

DRAFT — REQUIRES REVIEW BY IASME-ACCREDITED CE+ ASSESSOR AND SIGN-OFF BY BRITIAI CTO BEFORE INCLUSION IN BID.

CE01 — Cyber Essentials Plus Readiness Brief

Document owner: BritiAI CTO Prepared for: NHS SBS Healthcare AI Solutions Framework (SBS10523) submission, due 12:00 noon, Tue 21 Jul 2026 Prepared: 15 Jun 2026 Status: Internal readiness brief — not a customer-facing artefact

1. Purpose

This brief prepares BritiAI for the Cyber Essentials Plus (CE+) technical audit booked for the week commencing 23 Jun 2026, and frames the position we will take in the NHS SBS submission if the certificate has not yet been issued by the 21 Jul 2026 submission deadline. It is written for the BritiAI exec, IT lead, and the external IASME-accredited assessor we have engaged.

Verification timing (per NHS SBS Q&A). CE+ is not verified at bid submission. A bidder is appointed if it holds CE+ OR demonstrates equivalent controls, with ISO/IEC 27001 expressly accepted as the equivalent route. Information-security status is verified at the certification & accreditation due-diligence stage running 5 Apr – 19 May 2027 (via SAP Ariba), ahead of the Framework Start Date of 26 May 2027. BritiAI therefore has a dual route to passing this gate: the CE+ programme below, backed by its in-flight ISO/IEC 27001 programme as the accepted equivalent.

CE+ remains a disciplined workstream. On assessment day it is a binary state: either a representative sample of in-scope devices passes the assessor’s tests, or it does not. Preparation discipline matters more than control sophistication — but the equivalent-controls route means certificate timing is not a single point of failure for the bid.

2. What CE+ is, and what it is not

Cyber Essentials is a UK government-backed scheme operated by IASME. There are two levels:

  • Cyber Essentials (CE): a self-assessment questionnaire (SAQ) signed off by a board-level officer, verified by an IASME-accredited Certification Body.
  • Cyber Essentials Plus (CE+): the same five technical controls as CE, but verified by an independent assessor who performs hands-on technical tests against a representative sample of devices, plus an external vulnerability scan.

CE+ does not assess governance, policies, or supplier management beyond what the five technical controls require. That is ISO 27001 territory. CE+ is narrow, technical, and evidence-driven. For NHS SBS, it is the minimum bar; ISO 27001 is the differentiator.

The five technical controls are:

  1. Firewalls — boundary and host-based firewalls correctly configured on every in-scope device.
  2. Secure configuration — devices and software hardened from default; unused services and accounts removed.
  3. User access control — least privilege, MFA on cloud and admin accounts, separation of admin and standard user accounts.
  4. Malware protection — anti-malware on every in-scope endpoint, or equivalent application allow-listing.
  5. Security update management — high-/critical-severity patches applied within 14 days of vendor release; unsupported software removed.

3. What the assessor will test on assessment day

Under the current IASME “Montpellier” question set, the CE+ audit comprises five test components:

  1. Authenticated vulnerability scan of a sample of in-scope user devices (typically every OS/build combination, with a sampling formula based on device count).
  2. Authenticated vulnerability scan of in-scope cloud and on-prem servers exposing services.
  3. External vulnerability scan of all in-scope external IP addresses.
  4. Email and web malware tests — the assessor will attempt to deliver EICAR-like test files via email and via web download to confirm endpoint malware protection blocks them.
  5. Account separation and MFA verification — sampled walk-through of admin accounts, cloud admin accounts, and standard user accounts to verify MFA is enforced and admin/standard separation is real.

The assessor also re-verifies the CE self-assessment answers against observed reality. Discrepancies between the SAQ and what the assessor sees on screen are the single largest cause of CE+ failure for SMEs.

4. Evidence the assessor will want

The assessor will request, before or on the day:

  • Asset inventory of in-scope devices: make, model, OS version, build, owner, location, role (user endpoint / server / mobile).
  • Cloud service inventory with IdP/SSO mapping (Microsoft 365, Google Workspace, AWS, GCP, Azure, GitHub, etc.).
  • Network diagram showing the boundary between BritiAI (UK), Votee (HK), and Beever (Toronto), and which devices are in scope for this assessment.
  • Patch policy and evidence of patch cadence (MDM reports, screenshots of update settings, or Intune/Jamf/Kandji compliance reports).
  • MFA enforcement evidence for every cloud service that holds company data or admin access.
  • Endpoint protection evidence — vendor, version, definitions date, tamper protection state.
  • Admin account list with named owners, and confirmation each admin has a separate standard account for daily use.
  • Mobile device policy evidence (screen lock, encryption, biometric or 6+ digit PIN).
  • Removal of unsupported software evidence — no Windows 10 22H2 past end of support, no end-of-life macOS versions, no out-of-support browsers.

5. How to prepare devices and accounts before the day

The week before assessment, complete the following on every in-scope device:

  1. Run all pending OS and application updates; confirm “up to date” status on screen.
  2. Confirm firewall is on (Windows Defender Firewall / macOS Application Firewall) for all three profiles where applicable.
  3. Confirm disk encryption is on (BitLocker / FileVault) and recovery keys escrowed in MDM or IdP.
  4. Confirm endpoint protection is running, definitions are within 24 hours, and tamper protection is on.
  5. Confirm the device is enrolled in MDM and reporting compliant.
  6. Confirm the logged-in user account is a standard (non-admin) account for normal use.
  7. Remove or update any browser extensions, local utilities, or developer tools that are out of support.
  8. Reboot. Many “pending update” failures on CE+ day are simply pending-reboot states.

For every cloud account in scope:

  1. Enforce MFA at the tenant level — preferably phishing-resistant (FIDO2, passkey, or platform authenticator). SMS is permitted but weak.
  2. Disable legacy authentication protocols (IMAP, POP, basic auth).
  3. Review admin role assignments; remove unused admins.
  4. Confirm there is a documented break-glass account with its credentials sealed.

6. Common failure modes for SMEs

Based on IASME’s published failure-mode guidance and assessor practitioner notes, the most common reasons SMEs fail CE+ on the day are:

  • Out-of-support software — usually a forgotten Node.js runtime, an old Python, an EOL browser on a contractor’s laptop, or an unmanaged BYOD device that slipped into scope.
  • Patches older than 14 days for high/critical CVEs, often on macOS Safari, Chrome, or a Linux dev VM.
  • MFA gaps on cloud admin accounts, especially in GitHub Organisation owners, AWS root, and DNS registrar accounts.
  • Admin account separation not real — a single Microsoft 365 account being used both as Global Admin and for daily email.
  • Mobile devices not enrolled — phones used for work email and Slack but not in MDM, with no enforced screen lock policy.
  • External vulnerability scan surprises — a forgotten staging environment, an old test subdomain, or a vendor-managed appliance exposing a deprecated TLS cipher.
  • Self-assessment answers don’t match reality — the SAQ was filled in optimistically and the assessor sees something different.

We recommend a whole-organisation UK scope covering:

  • All BritiAI Ltd (UK) employee endpoints (laptops, mobiles).
  • All BritiAI-controlled cloud tenants (Microsoft 365 UK, AWS eu-west-2, GitHub Organisation, identity provider, DNS, code-signing).
  • The UK production environment for the NHS-facing AI services.

We recommend excluding from this CE+ scope:

  • Votee (HK) and Beever (Toronto) corporate IT estates. These are separate legal entities with their own IT, do not handle NHS data, and are segregated by the UK-only deployment topology already confirmed in the bid. Bringing them in-scope would multiply assessor effort and introduces non-UK time-zone risk into the audit window with no NHS benefit.
  • Personal devices. BYOD is not permitted for NHS-data-touching work; this must be backed by policy.

The scope must be declared in writing to the assessor before the audit, and the network diagram in §4 must visibly show the Votee/Beever boundary as out of scope. The assessor will confirm that out-of-scope networks have no routed access into the in-scope environment (i.e. no shared VPN, no shared SSO that grants production access, no shared admin accounts).

8. How the BritiAI / Votee / Beever boundary affects scope

The corporate structure (BritiAI UK parent, Votee HK subsidiary, Beever Toronto sub-subsidiary) introduces three risks the assessor will probe:

  1. Shared identity. If Votee or Beever staff have accounts in the BritiAI Microsoft 365 or GitHub Organisation, those accounts become in-scope. Mitigation: confirm Votee/Beever staff use separate tenants, or — if they have BritiAI accounts — those accounts are in-scope and must meet CE+ standards.
  2. Shared code repositories. If Votee/Beever engineers push code to the BritiAI GitHub Organisation, the Organisation is in-scope and every contributor account is in-scope for MFA verification. This is almost certainly the case; we should assume the GitHub Org is in-scope and every member has MFA enforced at the Org level.
  3. Shared admin. If a Votee or Beever staff member is an admin of any BritiAI cloud tenant, they are in-scope as an admin account and must meet the admin separation and MFA tests. Audit and remove any such cross-entity admin rights that are not strictly necessary.

The cleanest defensible position is: NHS-facing systems are operated only by BritiAI UK staff on BritiAI UK-managed endpoints, authenticated through the BritiAI UK identity provider, with no Votee or Beever access path. This is the position the bid already takes and CE+ scope must match it.

9. Path-to-pass timeline and bid implication

Assessment week 23 Jun 2026. Typical IASME certificate issuance is 5–10 working days after a clean pass, so a certificate is comfortably plausible well before the 21 Jul 2026 submission, and in any event before the Apr–May 2027 due-diligence verification stage. If we are clean on the day but the certificate has not issued, the bid declaration (see CE05) cites the assessor’s pass confirmation email as evidence and references the in-flight IASME issuance step. If we are not clean on the day, we have one re-test window allowed (typically 30 days) and the bid declaration uses the in-flight variant honestly.

10. Open actions before assessment week

See CE03 for the day-by-day roadmap. The headline pre-assessment risks are: (a) mobile device MDM enrolment coverage, (b) GitHub Organisation MFA enforcement audit, (c) external attack surface enumeration, (d) admin account separation walk-through. These four items drive the dry-run agenda.

End of CE01.

Graph View

Backlinks