skip to content

Which controls do you put in the ceiling above every account, and which do you leave to detection, when one business unit is regulated and another ships daily?

level: principalimportance: should knowfreq 38%

answer

  1. the ceiling is a scarce resource
  2. immediate harm, or detect it
  3. the rule must fit on the call
  4. narrow attachment beats estate-wide strictness
  5. refusals of real work mean it is misplaced

basics

~20 s

Put a rule in the ceiling when the action is harmful the moment it happens and is expressible as a condition on the request. Leave it to detection when the harm is tolerable for the detection window or the rule needs facts the call does not carry.

solid answer

~50 s

Treat the ceiling as a scarce resource, because every rule in it is flexibility taken from every team beneath. Four tests decide: is the harm immediate and hard to undo; can the rule be expressed as a condition on the call; how often will it refuse legitimate work; and can the refusal be resolved by anyone other than the level that attached it. A geographic restriction for the regulated unit passes all four, so it goes in a ceiling attached to that unit rather than across the estate. A rule about ownership, review state or the life of a resource after creation fails the second test and belongs to detection. Keep the estate-wide ceiling to the few removals no account has any business needing, and attach the strict set narrowly. Then watch the refusal record - repeated refusals of legitimate work mean the ceiling is misplaced, not that teams are wrong.

go deeper

for a junior

Recall that some rules stop an action and others only report it, and that the choice is made deliberately. Not everything that matters is blocked.

for a middle

Explain the constraint that decides most cases: a preventive rule must be expressible as a condition on the call, so rules about later life or about facts outside the platform cannot be preventive.

for a senior

Show the operating consequences you have lived: refusals landing mid-deploy, a ceiling blocking its own remedy, and findings nobody worked. Say which risks you would knowingly leave detective and why.

for a principal

This is your call to own. Decide how much of the estate's safety is bought with flexibility taken from every team, attach the strict set as narrowly as the requirement allows, and be able to state what the ceiling does and does not prove.

## The decision you are actually making A **permission ceiling** above the accounts is not a rule you write for yourself; it is a standard you impose on every team beneath it, enforced at the moment they try to work, and resolvable only by you. That asymmetry is the whole of this decision. A **detective control** over the recorded actions costs the teams nothing until something is found, and costs you an exposure window and a responder. ## Four tests for putting a rule in the ceiling 1. **Is the harm immediate and hard to undo?** Documents landing in a geography they may not be in is harmful the moment it happens, and deleting them afterwards does not unmake the fact. An untagged resource is not. The first belongs in the ceiling; the second does not. 2. **Can the rule be expressed as a condition on the call?** A ceiling can test the region requested, a declared property, the shape of what is being created. It cannot test a review status in another system, or anything about the life of the resource after that call. A rule that fails this test cannot be preventive however much you want it to be. 3. **How often will it refuse legitimate work?** A ceiling that refuses a real task weekly does not survive; it gets worked around, or it gets detached in an incident and never re-attached. If the exceptions are frequent and genuine, the rule is not ready to be a ceiling. 4. **Who can resolve a refusal?** Nobody beneath the ceiling can. If the answer is "an administrator two levels up, during their working hours", then the rule had better be one where waiting is the correct outcome. ## A workable split for a mixed estate | Rule | Where it goes | Why | |---|---|---| | No region-scoped resource outside the approved list, for the regulated unit | Ceiling attached to that unit | Immediate harm, testable on the call, exceptions genuinely should wait | | New stores must declare encryption at rest | Ceiling, estate-wide | A bad default with a conforming alternative always available | | Nobody may weaken the audit record | Ceiling, estate-wide | It protects the detective controls everything else depends on | | Every resource carries an owner | Detection | Harm is not immediate, and the rule is about a state, not a call | | Keys rotate on schedule | Detection | Happens long after any constrained call | | Stores match the data map the business maintains | Detection | The fact lives outside the platform | The shape that falls out is a **small estate-wide ceiling** - the few removals no account has any business needing - plus a **strict ceiling attached narrowly** to the regulated unit. A team that ships daily then meets almost nothing, and the unit that must not move meets a hard edge. ## What owning a ceiling costs you - **The refusal path is yours.** The team sees an unauthorised call, not your policy. Publish what the ceilings remove and where to ask, because the accounts cannot discover it themselves. - **You can deny your own remedy.** A ceiling broad enough to block an action in a region also blocks cleaning up what is there. Know, before you attach it, which principal can still act if you need one. - **Every addition is permanent in practice.** Removing a ceiling later reads as a weakening, and nobody wants to sign it. Add the rule you are prepared to keep. - **Silence is ambiguous.** A ceiling that has never refused a call may be perfectly placed, or attached where it never applies. The refusal record is the only thing that tells the two apart. ## How you know the split is right - Refusals of **legitimate** work trend toward zero, while refusals overall are non-zero - the ceiling is in the path and is not in the way. - Findings from detection are **worked**, with a time-to-action you would be willing to state to whoever asks about the regulated unit. - The estate-wide set stays **small enough to recite**. When you cannot list what the ceiling removes, no team beneath it can either.

  • A rule passes every test except that it refuses legitimate work weekly. What do you do?
    Leave it detective for now and fix the reason the legitimate case exists - a missing conforming path, a workflow that produces the wrong shape. A ceiling that regularly refuses real work is detached in the first incident, and a control that is not there is worse than one you knew was detective.
  • The regulated unit's ceiling has refused nothing in a year. What do you conclude?
    Only that no call beneath it matched. That is either a well-behaved unit or a ceiling attached where its accounts are not, and the two look identical from outside. Confirm placement by checking which accounts inherit it, and test with a deliberate non-conforming call in a sandbox account beneath it.
  • Why attach the strict set to the regulated unit rather than the whole estate?
    Because the cost of a ceiling is paid by every team beneath it, and a rule that is necessary for one unit is friction for the rest. Attaching narrowly keeps the strict edge where the requirement is real, and keeps the estate-wide set small enough that teams can actually know it.

saying these in an interview costs you the question

  • Puts every rule in the ceiling because prevention sounds stronger
  • Treats a ceiling that has never refused a call as proof the estate is compliant
  • Ignores that nobody beneath the ceiling can resolve a refusal
  • Attaches the regulated unit's strict set across the whole estate
  • Adds a preventive rule for a fact the call does not carry
  • Forgets the ceiling can block the remedy for what it was added to stop