Skip to main content

User access control

Section 7: User access control

7.1 Are user accounts only created after an approval process? Describe the process.

NCSC requires a process to create and approve user accounts (Requirements v3.3, page 19).

Describe how new accounts for staff, governors, supply staff and pupils are requested and approved before they are created, and who approves them. Approval should come from a person in a leadership role.

7.2 Are all user and administrative accounts accessed using unique credentials?

IASME says shared accounts are not compliant, including a shared login for a third-party web application. Every user and administrator must sign in with their own unique credentials. No device, application or cloud service should be reachable without them, and accounts must not be shared.

Common school examples to check are generic supply or visitor logins and shared class logins (NCSC Requirements v3.3, page 19).

7.3 How do you ensure accounts for departed staff are deleted or disabled?

NCSC requires accounts to be removed or disabled when they are no longer required (Requirements v3.3, page 19).

Describe how you make sure you disable or delete accounts for staff and pupils who leave, including supply staff, volunteers, governors and contractors. Say who tells IT and how quickly it is done.

7.4 Do staff only have the access privileges they need for their current role?

Cyber Essentials requires "least privilege." People only get the access they need for their current job, and no more. Explain how permissions are set when someone joins and how they change when someone moves role, for example from classroom teaching to finance or leadership. Include sensitive systems such as the MIS, finance and safeguarding records (NCSC Requirements v3.3, page 19).

7.5 Do you have a formal process for granting administrator-level access?

Describe the process you follow before giving someone administrator access, who approves it and where it is recorded. Approval might come from a senior leader, governor or trustee.

All administrator accounts need approval by a person of authority. If your IT provider holds administrator accounts, explain how you control and approve them (NCSC Requirements v3.3, page 19).

7.6 How does your organisation ensure separate accounts are used for administrative tasks?

Anyone who carries out administrator tasks, such as installing software or changing settings, must use an administrator account separate from their normal account. This applies to:

  • local administrator accounts
  • network or domain administrator accounts
  • cloud service administrator accounts such as Microsoft 365 or Google Workspace admin

Switching one account to administrator for a short time does not meet the requirement. IASME says “just in time” elevation is not compliant, only “just enough.”

Include accounts used by your IT provider (NCSC Requirements v3.3, page 19).

7.7 How does your organisation prevent administrator accounts being used for everyday tasks?

NCSC says administrator accounts are for administrative activity only, with no emailing or web browsing (Requirements v3.3, page 19).

Explain how you make sure people with administrator accounts (including your IT provider) do not use them for everyday tasks like browsing the web or reading email. A mix of policy, procedure and regular training is enough; you do not need a technical block.

Downloads should be done as a standard user and then installed as an administrator. This includes cloud service administrator accounts.

7.8 Do you formally track which users have administrator accounts?

Keep a written list of everyone who holds an administrator account on devices, networks and cloud services, including accounts held by your IT provider. The list should come from the approval process in 7.5 (NCSC Requirements v3.3, page 19).

7.9 Do you review who should have administrative access on a regular basis?

NCSC requires special access privileges to be removed or disabled when no longer required (Requirements v3.3, page 19).

Review the list of people with administrator access regularly, for example each term or annually. Remove access from anyone who no longer needs it, for example when a staff member changes role.

If a provider holds administrator access, tell them promptly when someone no longer needs it.

7.10 How are passwords protected from brute-force attacks?

For on every system that uses a password, or is a backup for a passwordless system, explain how passwords are protected from guessing with repeated tries (brute force). Accepted methods are:

  • MFA
  • throttling, with no more than 10 guesses in 5 minutes
  • locking accounts after no more than 10 unsuccessful attempts

Name at least one for each type of system (NCSC Requirements v3.3, page 21).

7.11 Which technical controls are used to manage password quality?

Describe the technical controls that manage password quality. You must name at least one:

  • MFA
  • a minimum length of 12 characters with no maximum
  • a minimum of 8 characters with no maximum plus automatic blocking of common passwords using a deny list

Complexity rules are not required (NCSC Requirements v3.3, pages 21 to 22).

7.12 How do you encourage staff to use unique and strong passwords?

Explain how you help staff and, if relevant, pupils choose unique, strong passwords (NCSC Requirements v3.3, page 22) . For example:

  • teach people to avoid common or guessable passwords
  • encourage longer passwords made of at least three random words
  • provide secure storage such as a password manager or locked cabinet
  • do not force regular password expiry
  • do not force complexity rules

You do not need to do everything on this list.

7.13 Do you have a process for when passwords or accounts are believed to be compromised?

You must have an established process for promptly changing passwords if you know or suspect a password or account has been compromised. If your IT provider handles resets, make sure you can still reach your own accounts and know how to start the process: IASME warns that you cannot pass all responsibility to your IT provider (NCSC Requirements v3.3, page 22).

Staff need to know what counts as a possible compromise and who to tell.

7.14 Do all your cloud services have MFA available?

Answer Yes if every cloud service you use has some way of using MFA, whether it is:

  • built in
  • free
  • a paid extra
  • provided by linking the service to another service such as Microsoft 365 or Google Workspace

If a service can be set up to sign in through another service that provides MFA, make sure it is set up.

Answer No only for services with no MFA option at all, and list them in 7.15. NCSC says authentication to cloud services must always use MFA (Requirements v3.3, page 19).

7.15 Please list cloud services that do not provide MFA.

If you answered No to 7.14, list the cloud services that have no MFA option at all. You will fail your assessment if a service you list has an MFA option, including a paid or linked one, so check each one with the supplier first.

Check your list against 2.9.

If you answered Yes to 7.14, write All our cloud services have an MFA option.

7.16 Has MFA been applied to all administrators of your cloud services?

If you answer No you will not be awarded certification (NCSC Requirements v3.3, pages 19 to 21).

Every cloud service administrator account (including accounts held by your IT provider or a supplier) must use MFA together with a password of at least 8 characters.

The only exceptions are services you listed in 7.15 that have no MFA option.

7.17 Has MFA been applied to all users of your cloud services?

Answering No means you will not be awarded certification.

All your cloud service users must use MFA together with a password of at least 8 characters, except for services (listed in 7.15) with no MFA option.

IASME asks if MFA is enabled for every account that accesses every cloud service. This includes accounts you give to pupils on services such as Microsoft 365 or Google Workspace.

NCSC lists 4 additional factors:

  • a managed or enterprise device
  • an app on a trusted device
  • a physically separate token
  • a known or trusted account

This is covered in the Requirements v3.3, page 21.

Did you find what you needed?

Fill in our 3 question survey and let us know if you need more help.

Is this page useful?

Report a problem with this page