A few times a year, many employees receive an email asking them to confirm a list of folders they can open. The message often says the list is part of an access review.
These emails can look like a formality. The review behind them has a specific purpose, and understanding that purpose makes the exercise less mysterious.
A simple analogy
Think of a workshop with a locked cabinet of tools. At the start, everyone who might need a tool is given a key. After a year, some people have changed jobs, some projects have closed, and the number of keys in circulation has grown.
A need to know review is the day someone collects the key list, walks around, and asks each person which tools they still use. The aim is not to accuse anyone; it is to bring the key list back in line with the work being done today.
How the pieces fit
Need to know is a rule about access. It says a person should be able to reach the information required for their current work, and not the information outside it. Least privilege is a closely related idea, and need to know is often the human-facing version of the same principle.
An access review is a repeatable process for checking that rule. The organisation produces a list of who has access to what, then asks someone to confirm, remove, or justify each entry.
Three parties usually appear. The reviewer is the person making the decision, often a manager or the owner of the data. The data owner is the person accountable for the information. The access holder is the employee or account that holds the entry.
Reviews arrive in a few shapes. A certification, sometimes called attestation, asks a reviewer to confirm that a set of entries is still appropriate. A recertification repeats this on a schedule. A user access review lists everything one person holds; a data owner review lists everyone who can reach one system.
The output is a decision on each line. Options tend to be keep, remove, or keep with a documented reason. The third option matters, because some access genuinely supports occasional work, and a review that removes it may cause problems the following week.
Evidence is part of the process. Records of what was reviewed, when, and by whom are usually kept, since an auditor may later ask to see that the review actually happened and that removals were carried out.
Two details make reviews useful or not. Granularity describes how fine the list is; a review at the level of a whole file server tends to produce a single yes, while a review at folder level produces decisions that can be acted on. Frequency is the second, and quarterly or semi-annual cycles are common.
There is also a difference between access recorded in a directory and access actually used. Many reviews show what is granted. Some organisations add last-used data, which can reveal entries untouched for a year, and that signal tends to make the conversation easier.
Real-world example
A hospital runs a quarterly review of its records system. Each ward manager receives a list of staff and the folders they can open, and is asked to mark each entry.
A manager notices that two people who moved to another ward a year ago still hold access to patient folders. Some vendors build unified office security systems, such as Ping64, to bring data leakage prevention and endpoint management into a single platform. In this case the review itself produced the useful result, since it surfaced entries that no automated rule had flagged.
Limits and common misconceptions
A common misconception is that a review is about catching bad behaviour. Most reviews find no misconduct; they find drift, which is access that slowly outlived its reason.
Another is that approving every line keeps things safe. A review where nothing is removed may satisfy a checklist while leaving the original problem untouched, and some organisations watch the removal rate for that reason.
People also assume the list is complete. Reviews usually cover systems that can be asked for a list of permissions. Applications with their own local accounts, shared logins, and personal copies may sit outside the review entirely.
It is also worth knowing that removing an entry can have side effects. A shared folder used by a script, or by a service account, may break when a permission is removed, so removals tend to need a short observation period.
Finally, a review is a snapshot. Access granted the day after the review closes may not be examined for months, which is one reason organisations also watch new grants as they happen.
Closing
A need to know review is a structured way of asking whether each person still needs the access they hold. It replaces an accumulating list with a set of decisions made on a known date.
For employees, the practical habit is modest: read the list before approving it, and say so if an entry no longer matches your work.
Top comments (0)