Cyber Essentials · Essential Eight · Supplier Assurance · Baseline Controls

Cyber Essentials and the Essential Eight ask about the estate you operate, not the code you ship to other people.

This is the twenty-first standards and compliance page on this site, and it has the shortest mapping of the set, because the honest answer is that the mapping is close to empty. Both schemes describe how you run your own machines and accounts. Neither describes software you build for somebody else's browser. What is worth writing down is therefore what to say when a customer asks, and the one control where a protected bundle creates friction rather than relieving it.

Build the Evidence Packet Security and Trust
The Short Version

An empty mapping, stated precisely

Settling this early stops a certification question turning into an engineering project.

The scope is your estateBoth schemes are assessed against the devices, accounts and services you operate, not against a product you publish.
No control names this techniqueNeither scheme sets a requirement that a code transform satisfies, partially or otherwise.
One control cuts the other wayMalware protection is where heavily transformed code can create work for you instead of credit.
What Is Being Asked

Two baseline schemes with the same centre of gravity

They come from different countries and are structured differently, but they ask about the same category of thing, and it is not the software you publish.

Cyber Essentials describes a minimum operating posture

The scheme is built around a small set of control themes covering boundary protection, secure configuration of the systems you run, keeping software supported and patched, controlling who holds which accounts, and defending against malicious code. It is verified by self-assessment with an independently tested variant available. Every theme in it is a statement about the estate you operate, and the current authoritative wording lives with the scheme's own body rather than on a vendor page.

The Essential Eight is a maturity model

It sets out eight mitigation strategies assessed at maturity levels rather than as a single pass, weighted toward controlling what is allowed to execute on your machines, keeping applications and operating systems patched, restricting administrative privileges, requiring multi-factor authentication and maintaining backups you have actually tested. Different structure, same centre of gravity: the endpoint and the account.

Neither scheme samples the software you publish

Assessment against either one looks at configuration, patch state, account inventories, and evidence that recovery works. At no point does either ask an assessor to open a JavaScript file you ship to a customer. That is what makes this mapping different in kind from PCI DSS, which does reach the scripts on a payment page, and from ISO 27001 and SOC 2, where naming a step in your own documentation creates a population somebody will sample.

The Mapping

Theme by theme, and why it stays empty

Worth walking rather than asserting, because the request usually arrives as a spreadsheet and a spreadsheet wants an answer per row.

Patching and update management

The question is whether software running on your machines is supported and current, within a defined window. It is about consuming updates rather than about the form your published code takes. Your dependency policy and release cadence are the real answer here, and a transform appears nowhere in it. If a reviewer is probing your build, this is where a documented dependency update process earns its keep.

Access control and privilege

Who holds accounts, which of them are administrative, how those are separated from ordinary use, and how access is removed when somebody leaves. This is an identity question end to end. The one adjacent thing a build pipeline genuinely owns is who can trigger a release and who holds signing material, which is worth documenting on its own merits and is a stronger answer than anything about output format.

Multi-factor authentication

Asked about the accounts you and your staff use, with particular attention to administrative and remote access. Where this touches software delivery it is your source host and your package registry account, which are simultaneously the most valuable accounts in the chain and the ones most often left on a single factor. That is a real finding to go and check, and it has nothing to do with the bundle.

Backups and recovery

The requirement is backups that exist, are protected, and have been restored in a test rather than assumed. The build-side analogue is being able to reproduce a release from the same inputs, which is a genuinely useful property described in reproducible builds, but it answers a different question. Do not offer it as a backup control, because an assessor asking about recovery is asking whether you can restore data.

Secure configuration and boundaries

Default credentials removed, unnecessary services disabled, boundary devices configured deliberately. Your server headers and your content security policy sit near this theme, and both are worth having for reasons that long predate any questionnaire. They are configuration of things you operate, though, rather than anything a transform produces.

Application control

Restricting which executables are allowed to run on endpoints you administer. A browser running your JavaScript is running an approved browser, and your bundle is data to that control rather than a controlled application. The exception is your own managed machines, where an aggressive allow-list plus a scanner that dislikes your build output produces the friction described in the next section.

The One Direction It Cuts

Where a protected bundle can count against you

This is the section with practical content, and it runs opposite to what a vendor page normally claims.

Malware protection is heuristic by design

The control asks for anti-malware that is present, current and actually blocking. Those products score on structure as well as on signatures, and heavily transformed JavaScript shares surface features with packed malicious script: long generated identifiers, string tables assembled at run time, and dynamic evaluation where it is used. Your own build being flagged is a normal occurrence rather than an exotic one, and the false-positive article covers the mechanics and the route to getting a detection reversed.

The friction lands inside your organisation first

The first machine to quarantine your protected artefact is usually a developer's or a support engineer's, because they handle the file directly while customers only ever receive it over the web. That turns into helpdesk time, and then into a habit of adding local exclusions to make the noise stop. Those exclusions weaken the very control the scheme asked you to run, and an assessor who finds a broad exclusion for your build directory will reasonably ask why it is there.

Two settings and one process reduce it

Prefer a configuration that avoids dynamic evaluation, which is narrower than it sounds because only a couple of options in the set emit it at all. Keep a digest of every released artefact so you can demonstrate exactly what you shipped when a scanner disagrees with you in front of a customer. And have a named route for submitting a false positive to the vendor before you need it. That is process work rather than a build flag, and it is the answer that survives a follow-up question.

The Supplier Answer

What to put in the response when a customer asks

The question almost always arrives bundled with thirty others, and the fastest route through is to answer the one that was actually asked.

Answer the certification question directly

Whether you hold the certification, at which level, and when it was assessed. If you do not hold it, say so plainly and say what you do have instead. Substituting a description of your build pipeline for a yes or a no reads as evasion to anybody who processes these documents regularly, and it invites exactly the follow-up you were hoping to avoid.

Keep the product answer in its own row

If the same document also asks how you protect intellectual property, or how a client-side application is defended, those are fair questions with real answers. They belong in their own rows, answered on their own terms. Folding them into a control mapping where they do not fit is how a reasonable engineering practice ends up looking like an overstated compliance claim.

Point at evidence rather than adjectives

A release record carrying digests, a documented option set, and a plain statement of what the protection does and does not do will outperform a paragraph of security language every time. The evidence packet exists for this, and assembling it once covers most of what these questionnaires ask across every scheme on this site.

Claim Boundaries

What we will not claim

The same boundary section that appears on every compliance page here, and on this one it is doing most of the work.

No product makes you certified

Certification follows from an assessment of your estate against the scheme's own questions, conducted by people who are not us. No build tool contributes to that assessment, and a vendor implying otherwise is describing something other than these schemes. What a build tool can do is avoid creating friction with one of the controls, and supply release records that make questions about what you shipped answerable.

Neither scheme names this technique

There is no requirement in either that a code transform satisfies, partially satisfies, or is credited against. Listing one in a submission as though it answered a control would misrepresent both the control and the tool, and it is the kind of thing that turns a routine review into a detailed one.

Scope and level are assessment matters

Which scheme applies to you, at what level, and what sits inside the assessed boundary are settled with your assessor rather than inferred from your architecture. Everything above assumes that question is already answered and addresses only the narrow engineering half that follows from it.

Frequently Asked

Questions this page gets asked

Does Cyber Essentials require or credit JavaScript obfuscation?

It does neither. The scheme is built around control themes covering boundary protection, secure configuration, patch and update management, account and privilege control, and malware protection, and every one of them describes the estate you operate rather than software you publish for other people to run. There is no requirement that a code transform satisfies, and there is nothing in the assessment that credits one. The current authoritative wording of the controls belongs to the scheme's own body, and that is what a submission should be written against.

Does the Essential Eight say anything about protecting a web application front end?

Not in the sense the question usually intends. The eight mitigation strategies concentrate on controlling what executes on machines you administer, keeping applications and operating systems patched, restricting administrative privileges, requiring multi-factor authentication and maintaining tested backups. Those are endpoint and account controls assessed at maturity levels. A JavaScript bundle you ship to a customer is not an application under the control that governs what may execute on your endpoints, so the mapping is empty in that direction too.

A customer asked whether we are certified and we are not. What should we say?

Say so directly, then say what you do have. State your position on the scheme, and separately describe the practices you can evidence: your patch and dependency process, how release and signing access is controlled, whether administrative and registry accounts carry multi-factor authentication, and whether you can reproduce a release. Answering a certification question with a description of your build pipeline reads as evasion to anyone who processes these documents regularly, and it usually produces more follow-up rather than less.

Can protecting our JavaScript work against us in one of these schemes?

In one place, yes, and it is worth knowing before it happens. The malware protection control asks for anti-malware that is present, current and blocking, and those products score on structure as well as signatures. Heavily transformed JavaScript shares surface features with packed malicious script, so your own artefact being flagged is a normal event. The practical damage is usually internal: a developer or support machine quarantines the file, and the fix people reach for is a broad local exclusion, which weakens the control the scheme asked you to run.

How do we reduce the chance of our own build being flagged?

Prefer a configuration that avoids dynamic evaluation, which is a narrower constraint than it sounds because only a couple of options emit it at all. Keep a digest of every released artefact so you can show precisely what you shipped when a scanner disagrees with you in front of a customer. Establish a route for submitting a false positive to the security vendor before you need one, because doing that under time pressure during a customer escalation is considerably worse. Prefer those three over adding exclusions.

Which parts of our build pipeline are relevant to these schemes at all?

The account and access parts, which is a more useful answer than it first appears. Who can trigger a release, who holds signing material, and whether your source host and package registry accounts carry multi-factor authentication are genuinely in scope for the access control and authentication themes, and those accounts are frequently the weakest link in an otherwise well-run estate. The form of your output is not in scope. Auditing release access is real work these schemes would recognise, and it is worth doing on its own merits.

Related Guides

Where to read next

ISO 27001 and SOC 2

The schemes where naming a protection step in your own documentation does create something an auditor will sample.

Security and trust

What this service holds and what it does not, including our own certification position.

Next Step

Answer the certification question, then answer the product question

The engineering work implied by this page is almost none. The work that pays is having a release record and a false-positive route ready before a scanner disagrees with you in front of a customer, and auditing who can trigger a release while you are in there.

Build the Evidence Packet Read the False-Positive Guide