Anyone who reads daily legal news knows how much depends on who was allowed to see, sign or change a document. Engineers give the craft of deciding that a name: IAMOps, an informal label for treating permissions as something you design, test and revise, much like a statute that gets amended after it meets real cases. This list translates the idea into eight habits for a law office or in-house team. It is general information about how systems are organised, not legal advice.

The topic is laid out at length in its entry on IAMOps. That Ops Atlas page, published by xOps School, is careful to call the word a working label and not a settled discipline, so hold the vocabulary loosely and focus on the habits.

1. Ask the four questions of every request

Every access decision, in a software platform or a records room, comes down to the same four inputs: who is asking, what they want to do, which item they want to do it to, and the surrounding circumstances. A clerk who may read a filing from the office network may not be allowed to read it from a personal phone at midnight. Write these four questions on the wall of your document system rules and your decisions become easier to explain later.

2. Separate what grants from what limits

Some rules give access and others only cap it. A matter-team folder grants entry to the people on the team. An ethical wall around a conflicted matter does the opposite: it grants nothing, it only blocks. The Atlas stresses that a ceiling never hands out permission on its own, and that an explicit block wins wherever it applies. Law offices already live by that logic, so name it plainly in your policy.

3. Start narrow and widen with evidence

The old principle of least privilege, traced in the Atlas to a 1975 paper, says each person should hold only what the task needs. In practice it is a loop: set a modest permission, observe real use, then adjust. The tempting shortcut, giving someone full access now and promising to tighten later, tends to fail because the later usage data seems to prove the broad access was needed. Begin narrow and let genuine requests justify each widening.

4. Watch for the rarely used duty

Usage reviews have blind spots. A quarterly filing task or an annual audit may not appear in thirty days of logs, and cutting that access would break the job at the worst moment. Before removing a seldom-used permission, ask its owner what calendar event depends on it. This is a human check that no dashboard replaces.

5. Keep the rules in a versioned file, not in people’s heads

The central move in the Atlas entry is authorisation as code: the rules live in a reviewed, tracked repository, and each change passes a test before it lands. A legal team can mimic this without any programming. Keep the access policy as a controlled document with a change log, an approver and a date, so that a question next year about why a paralegal could see a folder has a written answer.

If you follow daily developments, you will notice how often outcomes turn on exact wording. Our roundup of Indian legal developments from 19 June is a handy reminder of how small drafting differences change what a rule actually allows, and the same is true of an access policy.

6. Prefer short-lived keys to standing ones

Long-lived credentials are the digital equivalent of a spare key left with a former contractor. The Atlas cites survey figures showing that a large share of cloud accounts still carry keys older than a year, and it favours temporary, federated identities that expire by design. For a legal office the parallel is simple: shared logins to research or e-filing portals should be personal, revocable and reviewed when staff move on.

7. Measure the policy, do not assume it

One metric the Atlas highlights is permission utilisation: of everything a role is allowed to do, how much does it actually do? In its worked example a single role used 27 of 180 available actions, about 15 percent. You can run a similar check on a document system by comparing who has access to a matter with who has opened it in the last quarter. The gap is your cleanup list, and the figure gives partners something concrete to approve.

Two cautions from the Atlas apply here as well. Rules that say “everyone except” can quietly admit people when information is missing, because a negative test passes when the fact it checks is absent. And a rule that exempts a named role needs a companion rule protecting the name itself, or anyone able to create that role name inherits the exemption.

8. Review on a rhythm and keep exceptions on a register

Maturity in the Atlas is a five-step ladder, from ad hoc handling up to a state where removing access causes no incident. Its middle rungs are unglamorous: most changes go through the review process, and a monthly look at the numbers happens whether or not anything went wrong. Pair that with an exceptions register listing every deliberate departure from the rule, with an owner and an expiry date. Our digest for 12 June shows what a dated, itemised record looks like when you need to review later; give your exceptions the same discipline.

A simple way to start this month

Pick one active matter and answer four things in writing: who has access, why, since when, and who approves changes. Then test the notes against a second reader. Where the answers are vague, that is the first policy gap. If a colleague wants a broader comparison of habits across sectors, the roundup from 17 June shows how a regular format lets readers scan changes quickly, and a regular review format does the same for access.

None of this requires new software. It asks for clear questions, written rules, a rhythm of review and honesty about exceptions. Treat these eight habits as a starting checklist, adapt them to your own practice area and professional obligations, and consult qualified professionals for anything that touches regulatory duties.