The one-page user-access policy
Nine of the user-access questions (A7.1–A7.9) are about process: who approves accounts, how fast leavers lose access, and how admin rights are controlled. This page writes the one-page policy that answers all nine — adapted from the same documents ReadyCert drafts, free to take.
Your user-access policy
The .md file opens in Word, Google Docs and Notion. Nothing leaves your browser.
User Access — Joiners, Leavers & Administrator Accounts — Your company
Adopted today.
When someone joins:
1. The owner confirms what access their role needs — and no more.
2. They get their own individual logins (never a shared account) to: our cloud services (see our asset register).
3. Two-factor login is switched on for each account from day one.
4. We note what they were given, so switching it off later is a checklist, not a hunt.
When someone leaves:
1. On their last day, we disable or delete their account in every tool on that list.
2. Company devices come back and are wiped or secured.
3. Any password they knew that was shared (Wi-Fi, router admin) gets changed.
Administrator accounts. Admin rights are given deliberately, not by default: the owner approves each case, only where the role genuinely needs it. Admin work happens on separate admin accounts — never the account used for everyday email and web browsing. We keep a written list of who has admin access to what.
Reviewing it. Every three months, we re-read the admin list and remove rights from anyone who no longer needs them. Removing is the default outcome of a review, not the exception.
This fits on one page because we are a small team — and it works because we actually follow it.
What this policy covers, and which questions it answers
The joiner section answers how accounts are created with approval and least privilege (A7.1, A7.4), with individual logins (A7.2) and MFA from day one. The leaver section answers how access is removed promptly (A7.3) — the template defaults to the last day, because that is the habit worth committing to, and choosing “within a few days” keeps the document honest if that is your reality. The administrator section answers how admin rights are granted deliberately (A7.5), used from separate accounts kept off email and browsing (A7.6, A7.7), listed (A7.8) and reviewed on a cycle with removal as the default outcome (A7.9). The user-access guide walks through each rule.
Making it true before you adopt it
- Convert shared logins first. The policy promises individual accounts; info@ run as a shared password contradicts it on day one — shared mailboxes are the fix.
- Create the separate admin accounts the policy describes, and strip admin rights from everyday logins.
- Write the admin list. Person, system, why — three columns, kept with this policy. The review cadence you picked is a promise to re-read it.
- Run one leaver sweep. Any ex-staff account still alive anywhere makes the leaver section fiction; close them before the policy says you do.
Frequently asked questions
Does Cyber Essentials require a written access-control policy?
The questionnaire asks how accounts are created, how quickly leavers lose access, and how administrator rights are granted, separated, listed and reviewed (A7.1–A7.9). A one-page written process is the simplest way to answer those consistently — and to keep the answers true at renewal.
What should it commit to?
Accounts created only with an approver’s sign-off and only the access the role needs; individual logins, never shared; leavers disabled promptly — this template defaults to their last day; admin work on separate accounts never used for email or browsing; and a listed, regularly reviewed set of admin rights.
Is one page really enough?
For a small team, yes. The scheme rewards short, true descriptions of what actually happens; this page is adapted from the same document ReadyCert drafts from assessment answers, and it fits on one page by design.