TL;DR
An access control policy normally governs accounts and stops there. The laptop is an access path too, holding cached sessions and local copies, and disabling a login does not reach any of it.
- Granting and removal are usually fine. Review and role change are not.
- A device holds access your identity system cannot revoke.
- Least privilege fails at the mover step, not at the grant.
- Review against current role, never against the last review.
- Write the suspension sequence before you need it.
- Keep the review output. The schedule is not evidence.
When a short version is enough
Four stages, and the first two need very little.
Under about fifteen people, few systems. Everyone has access to most things and that is a deliberate choice rather than a failure. Write down who administers what.
Best tools for HR Operations
First sensitive system. Payroll, or a customer database. Now there is something that genuinely should not be open to all, and the policy has one real job.
Teams and role changes. People move internally and access accumulates. This is where every access control policy starts to drift from reality.
Audited or certified. Somebody samples ten people and compares their access to their job. That sample is designed to find exactly what role changes left behind.
Why an access control policy misses the device
The discipline grew up around directories and applications. Access means an entitlement in a system, granted to an identity, revocable by an administrator. Everything in that sentence is clean and everything in it is logical rather than physical.
A laptop breaks the model. It is not an entitlement, it cannot be revoked from a console once it is offline, and the data on it was legitimately obtained by someone who had every right to it at the time. There is no clean place for it in a policy built around grants.
So it falls between documents. The access policy treats it as hardware, the asset policy treats it as a thing to count, and nobody treats it as a standing copy of whatever its user worked on. That is the gap, and it widens every time somebody leaves without returning a machine.
The standards do not make this distinction. Access control expectations in ISO/IEC 27001 cover information and the equipment holding it, and digital identity guidance from the National Institute of Standards and Technology treats the authenticator and the endpoint as part of one lifecycle. A policy that stops at the login is the narrower reading.
The five clauses worth writing
- Granting. Role-based where you can manage it, with a named approver and a second one for regulated systems.
- Change. What happens on a role change, stated as a removal step rather than only an addition. This is the clause that is always missing.
- Review. Frequency by system sensitivity, compared against current role, with the output retained.
- Removal. Triggered by the HR event, covering accounts and the device, with a stated timeframe for each.
- The device as access. Encryption, screen lock, and the requirement that recovery and sanitisation complete before access is considered removed.
Five clauses. The fifth is the one that turns a document about logins into a description of your actual exposure.
Five questions before you draft
What happens today when somebody changes role? If nothing is removed, that is the finding and you needed one question.
Can you list who has access to payroll? Pick your most sensitive system and try. The time it takes is the answer.
Who approves a request, and do they understand the system? A manager approving access to something unfamiliar is a signature, not a control.
Is a device with cached sessions covered anywhere? Usually not, in any of your documents.
Can you produce last quarter’s review output? The schedule is not the evidence. The output is.
How teams enforce it, and the trade-offs
Manual grants and a spreadsheet. Best for small teams and honest about what it is. It struggles on review, because reconstructing who has what means asking each system owner separately.
Single sign-on across everything. Best for control and for fast removal, since one disable covers many systems. It struggles on cost and on the long tail of tools that do not support it, which is where the forgotten access lives.
Group-based access from the directory. Best for role changes, because moving somebody between groups moves their access. It struggles when groups multiply faster than anyone prunes them, which they do.
Access reviews in a compliance tool. Best for evidence and for audits. It struggles on honesty, since reviewers approve long lists quickly and the tool records that as a review.
Closing the device half with a recovery route. Disclosure: RemoAsset is owned by the same people who publish this site. It handles retrieval and certified wiping across 80 or more countries, which matters here because access is not actually removed until the endpoint is recovered. Where it struggles: it is not an identity product and will not grant, review or revoke a single entitlement. The narrow part it covers is whether the device holding cached access is recovered and sanitised.
The decision table
| Situation | Scale | Setup | Primary pain | Recommended starting point |
|---|---|---|---|---|
| Small, open by design | Under 15 | No IT owner | Nothing sensitive yet | Record who administers what |
| First sensitive system | 15 to 50 | Part time owner | Everyone can see it | Grant and approval clauses |
| Frequent role changes | 50 plus | IT owner | Access accumulates | Write the change clause |
| Long tail of tools | Any | Any | No single sign-on | Inventory the tools first |
| Audit sampling access | Any | Security owner | No review output | Retain the evidence |
| Devices not recovered | Any | Any | Access survives removal | Fix recovery, then the policy |
What the gap costs
The first cost is accumulated entitlement. Somebody who has moved teams three times holds the union of four roles, and no individual grant was wrong. The total is wrong, and it is the thing inherited by anyone who compromises that account.
The second is the false completion. Your identity system reports the account disabled, the ticket closes, and a laptop with cached sessions and six months of downloaded files sits in a flat you have no address for. Everything green, nothing resolved.
The third is the review that reviews nothing. A reviewer handed a list of two hundred entitlements approves it in four minutes, and the tool records a completed review. That record is now evidence of a control that did not operate, which is worse than no record because somebody will rely on it.
There is a fourth cost that only appears in companies growing quickly, and it is the long tail of tools nobody put behind single sign-on. Each was adopted by one team for one job, each holds a little company data, and none appears in the review because none appears in any list. The access there is not excessive; it is simply unknown, which is a harder problem to describe to an auditor.
The fifth is inconsistency under pressure. Without a written suspension sequence, two similar situations get handled differently by different managers, and the difference is visible later to anybody who looks.
So the useful test is not whether your policy describes least privilege. It is what access the last person to change teams still holds, and whether anybody has looked.
When revoking access is not enough
Revocation is a console action and it is fast. Recovery is a physical process and it is not. The policy treats them as one step and they behave completely differently.
Three signals say the device half is where yours fails. You cannot list which machines are currently with former staff. Returns from outside your main market took weeks or never completed. And no wipe record exists for a meaningful share of last year’s departures.
Tightening the wording reaches none of those. They are logistical, and they set a ceiling on what any access control policy can honestly claim, because the strongest revocation in the world does not reach a powered-off laptop in another country.
It is worth separating before the next review, since the two halves have different owners and different fixes. Looking at how recovery and sanitisation close out a departure shows whether your gap is in the policy or beneath it.
See how endpoints are recovered after an exit
Read our guide to the information security policy
Related reading
- The information security policy
- The joiner mover leaver process
- Writing a password policy
- The offboarding policy
- Equipment during a suspension
Frequently Asked Questions
What should an access control policy cover?
How access is granted, reviewed, changed and removed, plus who approves each. Most policies do granting and removal well. Review and change are thinner, and the device as an access path is usually absent, which is where the gap between the document and reality opens.
Why does a laptop count as access?
Because it holds cached credentials, saved sessions, downloaded files and local copies of things your systems consider deleted. Disabling an account does not reach any of that. A policy that treats access purely as a login describes a smaller surface than the one you actually have.
How often should access be reviewed?
Quarterly for systems holding personal or financial data, annually for the rest, and immediately on a role change. The review that finds things compares entitlements against current role rather than against last year’s review, which simply reconfirms whatever drifted.
What is least privilege in practice?
Granting the access a role needs and nothing inherited from a previous one. In practice it fails at the mover step rather than at the grant, because each individual grant was reasonable when made. The accumulation is what breaks the principle, not any single decision.
Should managers approve access requests?
For most systems yes, because the manager knows the role. For anything holding regulated or financial data, add a second approver who owns the system, since a manager approving access to something they do not understand is a rubber stamp with a name attached.
What happens when somebody is suspended?
Write this sequence in advance. Suspension is not termination, so access is usually paused rather than deleted, and the device question is genuinely difficult. Deciding during a live situation produces inconsistent outcomes and looks punitive whichever way you go.
How do we evidence the policy works?
Keep the review output, not just the review schedule. A dated record showing who was checked, what was removed and who signed it off is the artefact an assessor can test. A policy stating that reviews happen quarterly proves only that somebody wrote that sentence.
