All five SOC analysts hold standing EDR execute-everywhere rights. How do you scope that without losing 03:00 speed?

## Reframe the grant The question is usually posed as a binary — standing rights or approval workflow — and both answers are bad. Standing execute-everywhere for five people means any one compromised console identity is the whole estate. A blanket approval workflow, in a team that cannot staff approvers around the clock, means either response stops overnight or the bypass path becomes the only path. The useful move is to stop granting *the console* and start granting *verbs*. A workable split, by blast radius and reversibility: | Class | Examples | Posture | | --- | --- | --- | | Reversible, single host | list processes, collect a file, isolate one workstation | Standing, all operators | | Irreversible, single host | delete a file, kill a process, remove persistence | Standing, but reviewed after the fact against the case | | Fleet scope | run a script against a host group or the whole estate | Just-in-time, second named approver | | Removes visibility | detection exclusions, policy disable, sensor uninstall | Just-in-time, second named approver, always reviewed | Isolation deserves a note. It feels destructive and it is disruptive, but it is reversible and it is the action most likely to be needed by a lone analyst at 03:00 with a live intruder. Putting it behind an approval nobody can give is how organisations end up watching an intrusion progress while they look for a manager. ## The constraint that actually decides it Five people covering 24x7 is roughly one person awake. Any control whose cost is *a second alert human* has to be honest about where that human comes from. Three sources, in order of preference: 1. **A peer on the same rota** — the on-call incident lead, already awake for the same case. Cheap, fast, and a genuine second opinion. 2. **A deliberate break-glass** with mandatory retrospective review inside one business day, for the hours when there is no second person. 3. **Nobody**, which is what you have today. The design failure to name explicitly: a gate that cannot be satisfied when it is needed does not slow anyone down, it teaches everyone to use the bypass. Once break-glass is routine it is standing privilege with paperwork, and the paperwork makes the auditor's report look better than the estate is. This is worth saying out loud in an interview, because it is the difference between designing a control and buying a control's appearance. ## Make it measurable A privilege posture nobody measures decays. Three numbers are enough, reported quarterly: - **Break-glass uses**, with a named reviewer for each. Rising means the gate is mis-scoped or the rota is too thin. - **Principals holding the execute-everywhere role**, including API clients. This number grows quietly — an integration here, a contractor there — and the inventory is the only thing that catches it. - **Actions with no case reference**, which is the same reconciliation key an investigation would later need. The second one deserves emphasis because it is where standing privilege actually accumulates. Human operators are visible; the API clients held by a SOAR platform, a ticketing integration, a backup tool and a reporting script are not, and each one carries the same execute role with no session lifetime, no multi-factor authentication and no leaver process. Every client needs a named owner, a scoped role, and a review that removes the ones nobody claims. ## What the auditor needs, and what they do not An auditor asking about destructive response actions wants two things: that a named human is recorded per action, and that the approval that policy claims exists actually happened. They are usually satisfied by the record. They are not asking you to slow the response down, and offering a heavier gate than you can staff is a poor trade — it converts a real control into a documented fiction. State the posture, state the break-glass path, show the review, and show the numbers. ## Owning the residual risk Whatever you choose, some standing privilege remains, because a SOC that cannot act at 03:00 is not a SOC. That residual belongs to a named owner — usually the SOC lead — stated in the risk register with the compensating controls beside it: phishing-resistant multi-factor authentication on console identities, individual federated logins, short session lifetimes, the console audit trail exported into your own platform, alerting on role grants and API-client creation inside the console, and periodic review of who and what holds the execute role. The answer an interviewer is listening for is not a policy. It is that you sized the control to the team you actually have, put the irreversible and visibility-removing verbs behind a person who is genuinely reachable, and committed to a number that tells you when the design has stopped working.