---
id: KB-AD-014
url: https://app.codecontract.io/help/administration/permissions-nobody-needs
idioma: en
categoria: administracion
audiencia: administrador
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-ET-010, KB-AD-011, KB-AD-017]
citadoPor: [KB-CD-017, KB-AD-020]
---

# Permissions nobody needs

_Access grows by itself and never shrinks. How to cut it back without breaking anyone's work._

**Responde a:** reviewing user permissions · removing access no longer needed · least privilege in practice · too many people see too much

Permissions are granted at a specific moment for a specific reason — a project, an absence, an emergency — and nobody removes them when that reason disappears. Two years on, half the staff can see things they do not need, and nobody remembers why.

## Where surplus permissions come from

| Origin | When it was granted | Why it persists |
| --- | --- | --- |
| A temporary cover | During an absence | Nobody removed it on return |
| A project that ended | While it lasted | The project ended, the access did not |
| A change of role | On arriving in the new one | It was added to the old rather than replacing it |
| "Just in case" | At onboarding | There was never a specific reason |

> [!IMPORTANT]
> The third row grows fastest and is hardest to see. Someone who has held three roles accumulates all three sets, and on paper they look like a normal user: nobody checks that the sum makes no sense.

## How to review without slowing anyone

1. **Once a year, with a list of who sees what** — An hour catches 90%, and the month does not matter as long as it is always the same.
2. **Start with whoever changed role or department** — That is where the accumulation is.
3. **And with outsiders' access** — The previous accountants, the consultant from the closed project.
4. **Remove and wait** — If someone needed it, they will ask within a week. Faster than auditing case by case.

> [!WARNING]
> The fourth looks blunt and is the most practical, but with one exception: do not apply it to permissions that automatic processes or integrations depend on. There, remove-and-wait means breaking something nobody is watching.

## What to look at besides who sees what

**En corto**

- Who can approve, which is different from who can see.
- Who can grant permissions to others, the most forgotten of all.
- And how many administrators there are: more than three in a small company is too many.

The second point decides whether an annual review is sufficient or pointless: if three people can grant access without criteria, the list will grow back by itself within six months.

> [!NOTE]
> Fewer permissions also means cleaner assistant answers and less noisy searches: each person sees their own, which is almost always what they were looking for.

**What if I remove something that was needed?**

It is restored in a minute. The cost of a surplus permission lasts years.

**Should the review be announced?**

Yes, and it cuts complaints to nearly zero.

**How often is reasonable?**

Annually for everyone; every six months for external access.

## Ejemplos

**A company finds an engineer who has held three roles can see almost everything.**

- Reviews role-changers first
- Removes what no longer applies and waits

→ Nobody complains and permissions match what each person actually does again.

**There are permissions nobody remembers granting.**

- Reviews case by case with the owner

→ What remains has a reason.

**Somebody changed role and kept the previous rights.**

- Reviews permissions on role changes

→ Access follows the role.

**Broad permissions were granted for a one-off case.**

- Withdraws them when the case ends

→ The temporary stops being permanent.

**Nobody has reviewed in years.**

- Schedules the periodic review

→ Access reflects today's organisation.

**The review happens and nothing is recorded.**

- Records what was reviewed and what changed

→ The review is demonstrable.