The most common access model in backup software is one login that can do everything, shared by everyone who might need it. It is fine until the day it is not, and the day it is not tends to be a bad one.
The useful way to draw the boundary is not by job title. It is by what happens if the action is taken in error.
The boundary, by consequence
Read operations have no blast radius. A technician who reads every backup log across every client cannot damage anything by doing so, which is why restricting reads is counterproductive: it produces shadow processes, shared credentials and screenshots in chat.
Write operations are different in kind. Each of the three below changes state in a way the person who caused it usually cannot undo.
| Operation | Tier 1 | Tier 3 | If it happens in error |
|---|---|---|---|
| Read backup status across every client | ✓ yes | ✓ yes | Nothing |
| Read the audit chain | ✓ yes | ✓ yes | Nothing |
| Run a restore into a live directory | ✗ no | ✓ yes | Objects reappear that were deleted deliberately |
| Delete a snapshot | ✗ no | ✓ yes | A recovery point is gone, silently |
| Release a legal hold | ✗ no | ✓ yes | Spoliation exposure |
Why "we trust our team" is the wrong axis
Least privilege is not a statement about trust. It is a statement about the cost of a mistake made by a trustworthy person at the end of a long shift.
It is also a statement about attribution. When every action is taken by an account called "admin", the audit chain records that admin did it — which is precisely no information at the moment you need information most. Roles are what make an audit trail answer the question it exists to answer.
And it is a statement about scope. In a multi-tenant platform the boundary has to hold across every client uniformly, not be configured per tenant, because a per-tenant configuration is another 200-event process with the drift characteristics that implies.
Request the permission matrix with the consequence column filled in. If a vendor can produce the grid but not the consequences, the roles were probably drawn around the UI rather than around risk.
Where this meets identity restores
The sharpest case is a restore into a live production directory. It is the one write operation that looks completely benign in a demo and is capable of quietly undoing a deliberate security action — reinstating a terminated account, a revoked role, or a Conditional Access policy that was retired for being too permissive.
Role separation is the first control on that. An approval gate is the second, and the two are complementary: roles decide who may ask, approval decides whether it happens.