The shared baseline
What people in a given job normally need. Stable, broad, and reviewed periodically. Good at describing the ordinary case.
How it works
The authority model.
Three mechanisms doing different jobs, and one lifecycle that makes sure temporary authority actually ends.
Three mechanisms, three jobs
Most organisations already use the first two. The third is usually the gap.
The context
Conditions applied at the moment of use: which region, which classification, which device posture. Good at narrowing the ordinary case.
The accountable exception
One person acting for another, for a reason, with an owner and an end date. Good at the case roles and attributes cannot describe honestly.
The point is not to replace roles with delegations. It is that some authority is genuinely exceptional, and modelling it as a permanent role is how organisations end up unable to explain their own access.
The lifecycle
Nine steps, each with an owner. The last two are the ones that usually go missing.
- Request and evaluate
- Someone states what authority is needed and why. The request is checked against policy before it reaches a human approver.
- Approve
- A named, accountable person grants it. Separation of duties applies: the person requesting it is not the person approving it.
- Activate and use
- The entitlement appears in the platform that enforces it, carrying the same scope and end date as the authority behind it.
- Review
- At a set interval, the owner confirms the authority is still needed. An unanswered review is itself a signal.
- Expire and revoke
- Authority ends on its date without anyone acting. Revocation handles the cases that cannot wait for the date.
- Audit
- Every step leaves a record, so the question "why could they do that" has an answer that does not depend on memory.
Want to walk through it against your environment?
Bring the authority that is hardest to explain in your organisation today.