Cyber Essentials: NCSC Five Controls Explained
The five technical controls in the NCSC Cyber Essentials requirements v3.3, including patching, multi-factor authentication and scope.
Many successful cyber attacks use basic weaknesses: unpatched software, weak passwords, accounts nobody remembered to remove. The UK National Cyber Security Centre (NCSC) built the Cyber Essentials scheme around five technical controls that address those weaknesses. This guide summarises the NCSC's scheme page and its April 2026 requirements document, version 3.3. It supports our Information Security and Cyber Hygiene course overview, and connects to our guides on business email compromise and the NIS2 Directive for finance teams.
What Cyber Essentials is
The NCSC says Cyber Essentials is the government's recommended minimum cyber security standard for organisations of all sizes, protecting against the most common internet-based threats, and notes that most common cyber-attacks are basic in nature. There are two levels. Cyber Essentials combines self-assessment with independent audit, with pricing tiered by organisation size and starting at £320 plus VAT according to the NCSC page. Cyber Essentials Plus covers the same protections with more rigorous independent technical testing. IASME is the official delivery partner, and the page says UK organisations with turnover under £20 million that certify their whole organisation are automatically entitled to cyber liability insurance arranged by IASME.
Scope: what has to be covered
Version 3.3 of the requirements says the scope must cover the whole IT infrastructure used for the business, or a well-defined, separately managed subset with a defined boundary. End-user devices must be in scope, and cloud services cannot be excluded. The scope is agreed with the Certification Body before assessment begins.
The five controls in the requirements
1. Firewalls
Every in-scope device must be protected by a correctly configured firewall. Default administrative passwords must be changed or remote administration disabled, unauthenticated inbound connections must be blocked by default, and inbound rules must be documented and approved, with unneeded rules removed.
2. Secure configuration
Unnecessary accounts, software and services must be removed or disabled, default or guessable passwords changed, and auto-run features that execute files without user authorisation disabled. Users must authenticate before gaining access to data or services. For device unlock, guesses are limited to no more than 10 in 5 minutes, or the device locks after no more than 10 failed attempts, and unlock-only passwords or PINs must be at least 6 characters.
3. Security update management
Software must be licensed and supported, and removed when it becomes unsupported. Updates must be applied within 14 days of release where they fix vulnerabilities the vendor describes as critical or high risk, vulnerabilities with a CVSS v3 base score of 7 or above, or vulnerabilities where the vendor gives no severity details. Applying all updates within 14 days is strongly recommended, but not mandatory.
4. User access control
The requirements ask for a process to create and approve accounts, unique credentials for each user, and removal of accounts and special privileges when no longer needed. Authentication to cloud services must always use multi-factor authentication, and the document also expects it to protect administrative and internet-accessible accounts. Password-only authentication requires at least 12 characters with no maximum, or at least 8 characters plus automatic blocking of common passwords. Regular password expiry is not required, and administrative accounts must be separate and used for administration only, not for email or web browsing.
5. Malware protection
Malware protection must be active on all in-scope devices, using either anti-malware software that is kept updated and blocks malicious code and websites, or application allow listing that restricts execution to approved, signed applications.
Cloud services and shared responsibility
The requirements say the applicant organisation is always responsible for ensuring all controls are implemented, even though providers may implement some of them. Responsibility varies by service model, and where a provider implements a control it must be committed to contractually or through referenced documents such as security statements. For finance teams relying on software-as-a-service, the organisation must still configure the service securely.
Using this in a finance or compliance role: our suggestions
These steps are our suggestions, not requirements in the NCSC documents.
- Check the list of leavers against active accounts in every cloud finance system.
- Confirm that approval and payment systems use multi-factor authentication, which also helps against payment-diversion fraud.
- Keep a record of how quickly critical updates are applied, so you can show the 14-day expectation was met.
- Ask whether administrators use a separate account for administration.
For structured learning, browse our CPD courses.
What we could not confirm
We read the NCSC's scheme overview and the version 3.3 requirements document, which is dated April 2026, but we did not read the question set used for assessment, so this post does not describe how assessors test each control. The scheme page did not give a percentage for how many attacks the controls prevent. Pricing and entitlements may change. We have not covered Irish or EU cyber requirements in detail. This post is general information, not legal or security advice.
This page was last updated:
Learnsignal Education Team
Expert Tutor at Learnsignal
Qualified professional with years of experience helping students advance their professional careers.
View all posts by Learnsignal Education Team