If your volunteers log in, your charity is vouching for their phones

Your charity has built an online training product for your beneficiaries. They log in, record their progress, and love it.

You decide to tell your volunteers about it, and they also log in, record their progress, and love it. Same product, same experience, and often same demographics. But if you hold, or want to hold, Cyber Essentials certification, there’s one big distinction between the two groups.

The device of the volunteer completing the training is automatically in scope for your Cyber Essentials certification. The beneficiary’s is not.

That sounds like a drafting accident, or an overzealous reading of the guidelines – it’s not. It’s the deliberate, official position, explicitly stated (volunteers have their own line in the official scoping table, and, as we’ll see, their own clause in the question set’s definition of an employee), and the new Danzell question set removes most of the room that previously made it survivable.

What is settled – and what isn’t

Two things worth holding in view throughout this article.

Settled: a device a volunteer uses to log in to organisational systems – a rota portal, a training platform, case notes, your Microsoft 365 tenant – is in scope for your Cyber Essentials certification. This has been true since 2022. Danzell tightens the checking, not the rule.

Unsettled: whether passive receipt of communications (a volunteer email newsletter, a WhatsApp announcement group) or access to public content brings a device into scope. The definitions in the requirements document say one thing; the question set asks another; assessors differ. This article works on the practical reading – accounts and logins scope devices. The literal reading, and why it matters more than it should, gets its own companion piece: The Flaw.

What “in scope” means for Cyber Essentials

If a device is in scope, your charity is declaring – and must be able to demonstrate – that all of the following are true of it:

• the operating system still receives security updates from the manufacturer (including any required extended security update subscription)
• high-risk and critical security updates – and any update whose severity the vendor doesn’t disclose – are installed within 14 days of release, for the operating system and every app on the device, with automatic updates enabled where possible
• no unsupported or abandoned software is installed
• it locks with a biometric, password, or PIN of at least 6 characters, and throttles or locks out repeated wrong guesses
• it’s protected from malware – which for phones and tablets means apps come only from official stores and only from a list of applications your organisation has approved and maintains

You must also be able to state, accurately, the make and operating system version of every in-scope device in your assessment answers – and the answer has to still be true on the day a board-level representative signs it off.

The Rule

Any device a volunteer or staff member uses to access organisational systems is in scope for Cyber Essentials. The National Cyber Security Centre’s guidance is explicit, and worth quoting directly:

Bring your own device (BYOD). In addition to mobile or remote devices owned by the organisation, user owned devices which access organisational data or services (as defined above) are in scope. However, all mobile or remote devices used only for the purpose of:

• native voice applications
• native text applications
• multi-factor authentication (MFA) applications

are out of scope.

Section D(i), “Bring your own device (BYOD)”, Cyber Essentials Requirements for IT Infrastructure v3.3

Volunteers, trustees and employees are explicitly in scope for BYOD. Customers are explicitly out of scope – a category that, on any natural reading, includes a charity’s beneficiaries using your services in an external capacity. (The standard doesn’t say “beneficiaries” in terms; if your delivery model blurs the line, confirm the reading with your Certification Body.)

Section D(vi), “Devices used by third parties”, Cyber Essentials Requirements for IT Infrastructure v3.3

The question set is blunter still. Danzell’s very first section asks how many employees you have, and instructs:

“Please provide the number of people who are working for your organisation… This would include volunteers, agency workers, contractors and others who have access to your organisational data.”

Question A1.3, Danzell question set

And the scope guidance in the same document:

“You cannot exclude devices used by employees (such as laptops, desktops, or mobile phones) from the scope.”

Read those together. For Cyber Essentials purposes, a volunteer with access to your data is an employee, and employee devices are non-excludable by definition. The trap is set in the headcount question, before you ever reach a scoping table.

Example

A charity runs a WhatsApp group for its volunteers – shift swaps, updates, the occasional social invite. Every volunteer’s phone in that group is in scope: the messages are the charity’s data, and WhatsApp isn’t covered by the exemption for native calls and texts. Had the same messages gone by ordinary SMS, no device would be in scope at all. And if a staff member or a service user is in the same group, the rules differ for each of them – scope follows the person’s role, not the group.

Where one person holds two roles – the volunteer who is also a beneficiary – the sensible reading is that scope follows what they’re doing in that interaction. The standard doesn’t actually say so; treat it as a question to settle with your assessor rather than an assumption.

What’s changed in Danzell?

Any organisation applying for Cyber Essentials, or renewing an existing certification, from 27 April 2026 is assessed against version 3.3 of the requirements, using the Danzell question set (Danzell replaces version 3.2’s Willow).

So what’s changed in 3.3? It’s not so much the concept itself – volunteers accessing organisational systems on personal devices has been in scope since 2022. What’s changed is enforcement:

• Automatic failures exist for the first time in the scheme’s history. Not enabling MFA on any cloud service that offers it is an automatic fail (questions A7.14–A7.17). So is failing to install high-risk or critical security updates within 14 days – question A6.4 for operating systems and firmware, A6.5 for applications.
• Cloud services are defined for the first time, and cannot be excluded from scope. The definition explicitly includes social media accounts. More on why that matters below.
• Partial scoping is tightened and publicly visible. Sub-sets must be created with a firewall or VLAN – security groups and software-based methods don’t count – and a partial certificate now says so on its face: “Partial Organisation, see certificate platform for details.”

Whether assessors were previously marking some of these questions pragmatically isn’t something that can be proven. It doesn’t need to be: auto-fail questions remove the discretion by design. Commentary from the IT and cyber security community has been clear – last year’s answers won’t pass muster against the new questions.

For many charities, Cyber Essentials certification isn’t optional. It’s often a condition of local authority contracts, NHS commissioning, and increasingly grant funding. Not being Cyber Essentials compliant isn’t an option – but for organisations dependent on volunteer delivery, digital platforms have revolutionised their operating models and the volunteer experience.

The result is that the default volunteer delivery model is on a collision course with the scheme. Certification becomes progressively harder to evidence – and, at scale, operationally disproportionate – while all three of the following are true:

• volunteers use personal devices,
• charities use platforms with no device-aware access control,
• certification involves a truthful whole-organisation scope.

What “in scope” actually means for a volunteer’s phone

If a volunteer accesses organisational services via their own device – whether that’s a web portal for rotas or service user data, a training platform, or the aforementioned WhatsApp group – they fall under the BYOD scope for Cyber Essentials.

In practice, this means knowing – and keeping current – the make and operating system version of every one of those phones. The assessment asks for a summary by make and OS (Danzell has actually dropped the old requirement to list device models, and has never wanted serial numbers), so the record-keeping is lighter than a full asset register. The problem isn’t the schema. The problem is that the answer has to be true on the day the board signs it – and a volunteer who upgrades their phone, or stops getting iOS updates, doesn’t file a change notice.

The controls again – now imagine enforcing them on a phone you’ve never seen:

• the operating system still receives security updates from the manufacturer
• high-risk and critical updates for the OS and every app installed within 14 days, automatic updates on where possible
• no unsupported or abandoned software installed
• locks with a biometric, password or 6+ character PIN, with brute-force protection
• apps only from official stores, and only from your approved list

The 14-day rule deserves unpacking, because it’s stricter than it looks. The requirement bites where an update fixes vulnerabilities the vendor describes as critical or high-risk, addresses a CVSS 7+ vulnerability – or where “there are no details of the level of vulnerabilities the update fixes provided by the vendor” (A6.4/A6.5, Danzell). Commercial app vendors almost never publish severity details. For compliance purposes, every release note that says “squished some bugs” is a critical fix until proven otherwise.

So: a volunteer whose only access to organisational services is a WhatsApp group, and who hasn’t updated Candy Crush Saga fifteen days after a release whose notes say only “bug fixes and improvements”, has – under the scheme’s own wording – an in-scope device carrying an overdue vulnerability fix. That doesn’t make the director who signed the declaration a liar; declarations are made on reasonable enquiry. It does make the estate non-compliant, and A6.5 is now an automatic fail.

It gets stranger. Phones can’t meet the malware-protection control with anti-virus – that option is listed for Windows and macOS. They meet it through application allow listing, and question A8.5 requires that users “only install applications that have been approved by your organisation” and that you “maintain this list of approved applications”. The guidance adds, in terms: “This includes employee-owned devices.” Combined with A1.3’s definition of an employee, that sentence means a charity with in-scope volunteer phones is required to operate an approved-application list for its volunteers’ personal devices. Not merely “your apps must be patched” – “your apps must be pre-approved by us.”

For Cyber Essentials Plus, the requirements move from unrealistic towards impractical. Assessors sample real devices from each declared category – but there is no enforceable obligation on a volunteer to produce their personal phone for inspection: there’s no employment relationship, and a very real privacy cost in asking. Sampled devices that can’t be produced or evidenced are failures, and a device list you can’t stand behind fails with them. CE Plus with volunteer BYOD is achievable only where the charity can reliably identify, contact, and produce every sampled device – which, at any real scale, it cannot.

It’s worth noting that Cyber Essentials is prescriptive about the controls, not about the mechanisms you use to apply them – but you must be able to evidence them.

Why you can’t scope your way out

The obvious question – “can’t we just scope the volunteers out?” – now has an explicit answer, and it’s no. Danzell closes each exit in turn:

• Sub-sets require network segregation. A sub-set must be separated by a firewall or VLAN (A2.2.1); “security groups, microsegmentation or software-based methods are not compliant.” A volunteer’s phone on their home Wi-Fi is not behind your VLAN.
• Cloud services cannot be excluded (A2.9) – and your volunteer platform is a cloud service.
• Employee devices cannot be excluded – and A1.3 makes volunteers with data access employees.
• Partial scope is publicly labelled. A partial certificate reads “Partial Organisation, see certificate platform for details.” The funder checking the certificate register sees the qualification before they see anything else.

There is one genuine relief valve in the question set, and it’s worth understanding precisely because volunteers can’t use it. A2.6 notes that “devices outside the declared scope are excluded, but user accounts accessing the cloud service must comply with Cyber Essentials controls, including mandatory MFA.” This is how customers, students – and beneficiaries – escape device scope while their accounts still get secured: account-level compliance without device-level scoping. It is exactly the mechanism a volunteer model needs. And volunteers can’t reach it, because their devices can’t be outside the declared scope in the first place. (The companion piece has more on this asymmetry.)

The other half of Danzell: your cloud services

The device rules are only half the story. Danzell requires you to list every cloud service your organisation uses, and none can be excluded. Two consequences matter for volunteer-driven charities:

Your volunteer platform is in scope regardless of device posture. Whatever you decide about phones, the platform itself must appear in your assessment, and if it offers MFA, MFA must be enabled for every user – volunteers included – or the assessment fails automatically (A7.14–A7.17). Whether your volunteer platform supports MFA just became a procurement criterion, not a nice-to-have.

Social media accounts are explicitly cloud services. The question set names Facebook, LinkedIn and X. If a volunteer administers your Facebook Page, your charity is now attesting that MFA is enabled on the personal Facebook account that holds the Page role – an account you don’t control, whose security posture belongs to the volunteer. Meta’s Business Manager does have a setting to require two-factor authentication for everyone with access to your business assets: turn it on, because it converts an unkeepable attestation into an enforced one. The deeper structural problem – that Facebook and LinkedIn administration is inseparable from personal identity – is picked up in the companion piece.

The four postures

Volunteer delivery models are still compatible with the latest Cyber Essentials guidance – but only by design, not by default. There are four honest postures. Most charities are currently running the first without ever having chosen it.

1. Governed BYOD – the decaying default

Volunteers use their own phones, and the charity manages compliance by policy: access is conditional on a supported operating system, timely updates, a screen lock, and the volunteer’s agreement to confirm these things when asked. IASME’s own guidance treats enforced policy as a legitimate control, and for a small number of engaged, digitally confident volunteers it genuinely works.

Key considerations:

• The burden scales linearly and the truthfulness decays. Six trusted coordinators who reply to an annual “still on a supported iPhone?” email is a control. Two hundred volunteers of mixed digital confidence is a fiction with a policy document attached.
• Danzell converts lapses from discussions into failures. Under discretionary marking, a policy plus best efforts might pass. Under auto-fail questions, one honest “we can’t guarantee that” on A6.5 or A7.17 ends the assessment.
• The one place this posture keeps genuine breathing room is, tellingly, the approved-application list (A8.5): it isn’t an auto-fail question, and its guidance explicitly accepts policy, process and training in place of MDM. A written acceptable-use policy is a defensible answer there. It’s the update question that kills at volume – A6.5 covers every app on every in-scope phone, and fails automatically.
• This is where most charities are today – not because they chose it, but because it’s what happens when volunteer access grows organically. The rest of this list is what choosing looks like.

2. De-authentication

Take self-service and volunteer data access off the table. This is the cleanest posture on the practical reading of scope, but costly and operationally fragile to maintain. Anything accessed by volunteers is public content; any record keeping (recording that volunteer X has watched this training video) becomes a staff task.

Key considerations:

• Staff admin time increases – defeating the very reason charities introduce volunteer access to systems in the first place.
• Content has to be genuinely public – no access controls at all. A public link is a permitted design, but treat “public” as meaning public: the obscurity of an unlisted link deteriorates over time as more people access it and links are shared.
• Data protection is the key consideration – nothing goes in a deauthenticated environment that you wouldn’t be comfortable seeing on page one of Google.
• This posture rests on the practical reading of scope this article uses; see The Flaw for the caveat.

3. Controlled endpoints

Volunteers only access organisational data through devices your organisation owns and manages. Their personal phones never touch your systems, so they never enter scope – the devices that do are yours: bought, configured, listed, and answerable for.

This isn’t a way out of scope. It’s the opposite – it accepts scope and moves it onto devices where the promise is actually keepable. A managed device can prove its own compliance: enrolment shows the OS version, updates install on schedule, the screen lock is enforced rather than hoped for. Everything the standard asks you to demonstrate about a volunteer’s phone and can’t be demonstrated is routine on a device you administer.

Key considerations:

• Volunteer requirements are usually pyramid-shaped. Most volunteers need only communications, rota notifications and occasional training – the base of the pyramid, which can be met without any login at all through the de-authenticated routes above. Controlled endpoints are for the apex: the handful of volunteers who genuinely need access to client records, case notes or systems.
• Because the apex is small, so is the cost. A befriending charity with two hundred volunteers may find only six coordinate visits or record session notes. Six managed devices – or supervised sessions at the office on shared managed machines – is a solvable problem. Two hundred is not, which is why sizing the apex honestly is the first task, not choosing the hardware.
• Loaned devices are explicitly in scope – the standard says devices you own remain in scope whoever uses them. That’s fine: they’re enrolled, so they’re the scope you can evidence. Budget for the unglamorous parts as recurring costs, not a one-off purchase – asset tracking, breakage and replacement, support demand, return on departure, wiping between users – because an unreturned loan device with cached client data is a bigger real-world risk than anything else in this section.
• Charity pricing changes the arithmetic. Microsoft’s nonprofit licensing makes device management far cheaper than commercial rates, and a small fleet of modest Android or iOS devices competes well against per-volunteer platform subscriptions – provided the apex stays small.
• This is the posture most dependable at Cyber Essentials Plus. An assessor can ask to sample a device and you can hand them one – because it’s yours. Every other approach to volunteer access either can’t produce the device or depends on the assessor accepting evidence in its place. If your funding requires Plus, this section is less an option than a destination.
• The trade-off is friction, and it’s real. Volunteers must collect a device, carry a second phone, or come to a hub – and some will walk away over it. The honest comparison isn’t “managed devices versus what we do now”; it’s “managed devices for six people versus vouching for two hundred phones you’ll never see.”

4. Scope honestly, and accept the consequence

For some charities – because of size, resources, or a volunteer model that can’t be redesigned – an honest whole-organisation scope may simply not be certifiable. That is a legitimate position, provided it’s chosen rather than drifted into.

Choosing it means two things. First, the controls don’t stop mattering because the certificate is out of reach: MFA, patching, managed staff devices and access control reduce real risk whether or not anyone attests to them, and a charity can implement everything within its power while declining to sign for the devices it cannot see. That charity has arguably better governance than one holding a certificate on answers it couldn’t defend – it has simply refused to make a promise it can’t keep.

Second, the decision is a trustee decision, recorded as one: a risk-register entry naming what was considered, what was accepted, and what it costs – chiefly, exclusion from contracts and funders that specify Cyber Essentials, a set that is growing and that every future bid will inherit. Put a review date on it; the certification landscape, your volunteer model, and the postures above will all change.

What this position cannot do is stand in for safeguarding. A charity working with vulnerable people or holding sensitive personal data can honestly decline the certificate – but it cannot honestly tolerate the underlying exposure, and the volunteers who touch that data still need one of the controlled routes above regardless of what any assessor ever sees.

A control, not a posture: app protection without device management

There’s a middle path between managing volunteers’ phones and trusting them blind. Microsoft 365 can apply app protection policies on a personal device without enrolling or managing the device itself: organisational data lives in a protected container, opens only in approved apps, requires a PIN, can be wiped remotely without touching the volunteer’s photos – and, critically, access can be refused to phones running outdated or jailbroken software. The volunteer keeps their phone; the charity keeps control of its data on it.

Be clear about what this is and isn’t. It is a genuine, technically enforced security control – probably the strongest available on a device you don’t own. It is not a way out of scope: the phone remains fully in scope, and the standard’s promises still attach to the whole device – every app on it, not just yours.

App protection gates the operating system’s version and patch level, but it cannot see, let alone enforce, whether the rest of the volunteer’s apps are up to date – which is precisely where the 14-day rule bites hardest. So the honest description is: it converts some of the unkeepable promises into enforced, reportable facts, and leaves the rest exactly as unkeepable as before. That’s why it appears here as a control to deploy inside a posture, not a posture of its own.

Key considerations:

• Its certification value is uncertain by design. Whether conditional access reports satisfy an assessor in place of inspecting devices is a judgement call – and this article has spent several sections explaining that judgement calls are being removed from the scheme. A charity building its certificate on this approach is betting that the discretion Danzell deleted elsewhere survives here. At Cyber Essentials Plus, the bet is off entirely.
• Expect the window to close, not open. Every revision since 2022 has narrowed interpretation. If the criteria harden again, partial technical control over an in-scope device is a more likely casualty than a survivor. Treat any assessment passed this way as provisional.
• Its reach is the apps that integrate it. App protection covers Microsoft’s apps and third-party apps built on the Intune SDK or wrapped for it – a growing list, but one that will rarely include your specialist volunteer platform’s app. Adopting it usually means consolidating volunteer touchpoints into the tenant – Teams, SharePoint, shared lists – on nonprofit licensing. That’s a real migration, not a setting.
• Someone has to feed it. The minimum OS and patch levels it enforces are only as current as the person updating them – after every major security release, forever. Set once and forgotten, the control quietly stops mapping to the requirement while continuing to look like compliance.
• Its best home is the honest-scope posture. For a charity that has concluded certification isn’t achievable, this is the single most valuable control it can still deploy: it protects the actual data on the actual phones, demonstrates documented intent to any funder or regulator asking questions, and – should the standard ever grow a workable BYOD tier – is the position most likely to certify with least additional work. Do it because it reduces risk. If it one day also satisfies an assessor, that’s a bonus you didn’t build on.

What trustees need to know

The declaration is signed at board level, or certification cannot be awarded – so this is a governance decision wearing an IT costume. Four things belong in front of the board:

• The failure modes changed. Auto-fail questions mean a single honest “no” – one cloud service without MFA, one class of device you can’t patch on time – ends the assessment. There is no longer a version where goodwill and a strong overall posture carry a weak answer.
• Revocation cascades. If the primary legal entity’s certificate is revoked, the certificates of every included legal entity are revoked with it.
• Partial scope is public. A partial certificate is labelled as such on its face. Anyone checking the register – including the commissioner who required certification – sees the qualification.
• A certificate held on answers you couldn’t defend is worse than no certificate. It’s a misrepresentation to every funder and contracting authority that relied on it, and it puts the bundled cyber insurance in question exactly when you’d need it. The honest-scope posture above exists because declining to certify is a defensible governance position; certifying on hope is not.

The Volunteer Design Principles

Every organisational login used by volunteers is in scope for Cyber Essentials. When building a Cyber Essentials compatible volunteer model:

Principle one: does this volunteer journey need an account, or does it need content plus record keeping? Accounts create scope; content doesn’t.

Principle two is derived from the first: if a volunteer journey does require an account, can we tell a managed device from an unmanaged one? Policy is still a viable part of your control posture – volunteers with accounts should only log in from approved devices – but technical enforcement is what survives an auto-fail question.

Principle three is a procurement one. This is an area where Cyber Essentials is more likely to tighten than relax, so when building criteria for organisational systems, specify technical device controls – and, since Danzell, MFA support.

A platform with no MFA option is still technically certifiable – you list it as an exception under A7.15 – but it’s a fragile position: the exception is an automatic fail if the claim turns out to be wrong, the question set counts MFA as “available” if the service can merely be linked to another cloud service that provides it, and the exemption expires the day the vendor ships MFA.

Specifying MFA at procurement – ideally federated to your identity provider – is cheaper than discovering any of that at renewal. This enables a managed infrastructure journey that tracks the direction of the Cyber Essentials criteria.

And a closing question set for the board, which is where this decision actually lives: Do we need Cyber Essentials or Plus, and must it cover the whole organisation? Which volunteer journeys genuinely require authenticated access? Which of those involve personal or sensitive data? And what operating cost and volunteer friction are we prepared to accept to keep the promises we’re signing?

One thread has run underneath this whole article: the practical reading of scope, on which logins matter and newsletters don’t. The requirements document arguably says something stricter – strict enough that, read literally, no organisation with a single volunteer could certify at all. Why the scheme works anyway, why charities alone feel the overreach, and what the question set quietly does to save everyone: that’s The Flaw.

Footnote on the 14-day rule: “Updates must be applied within 14 days where they fix critical/high vulnerabilities, address CVSS 7+, or where the vendor provides no details of the vulnerability levels fixed” – IASME Cyber Essentials Knowledge Hub, Vulnerability Fixes; now reproduced as the CE Requirement under questions A6.4 and A6.5 of the Danzell question set. Applying all updates within 14 days is “strongly recommend[ed]… but not mandatory” (A6.4).