Why does a team agree its replacement triggers and who may declare one before an exposure happens?
answer
- decide once, recognise later
- the argument happens at the worst moment
- the declarer field is load-bearing
- no approval step before the one bounding action
- default: arguable means replace and record
basics
~20 sAgreed triggers turn a judgement call made under pressure into a fact of record: the event is recognised rather than argued. Naming who may declare one without approval stops the single action that bounds the exposure from waiting on an escalation chain.
solid answer
~50 sWithout a written list, every event becomes an argument at the worst possible moment, and the argument is about cost and blame rather than reach. The usual outcome is "probably fine", because nobody in the room wants to own a disruptive change on a maybe. A trigger register fixes the decision in advance: each entry names the **event**, the **values it applies to**, the **action**, a **deadline**, and the **person who may declare it without asking**. That last field is the one that changes behaviour — if the engineer who noticed has to escalate two levels to change a value, the replacement effectively waits for the next calendar slot. The register also needs a default for the arguable case (replace and record why) and a place the declaration is written down, so the deadline can be checked afterwards.
code
json · 29 lines{
"triggers": [
{
"event": "a holder leaves the team or the contract ends",
"appliesTo": "every shared value that holder could read",
"action": "replace, move holders, then refuse the old value",
"withinHours": 72,
"declaredBy": "the on-call engineer, no approval step",
"recordAs": "declaration entry with time, scope and reason"
},
{
"event": "a device holding a checked-out value is lost",
"appliesTo": "values that device was entitled to read",
"action": "end its session with the store, then replace and refuse",
"withinHours": 24,
"declaredBy": "the on-call engineer, no approval step",
"recordAs": "declaration entry with time, scope and reason"
},
{
"event": "a person outside the team observes a value",
"appliesTo": "the observed value only",
"action": "replace, move holders, then refuse the old value",
"withinHours": 48,
"declaredBy": "whoever observed it happening",
"recordAs": "declaration entry with what was seen and when"
}
],
"default": "if an event is arguable, replace and record the reasoning"
}go deeper
Recall that some events force a credential change regardless of any schedule, and that teams write that list down instead of deciding each time.
Explain what a usable entry contains — event, values, action, clock, declarer, record — and why an entry without a clock changes nothing.
Show why the declarer field carries the weight: the escalation the register removes is the delay between noticing and bounding the exposure.
Set the standard across teams and defend it: which events qualify, what the default is when an event is arguable, and what a repeatedly missed deadline says about the estate.
## What the list is actually for The list is not a reminder. Everyone already knows that a leaver, a lost device or a supplier compromise *might* mean replacing something. What is missing in the moment is **authority and a decision**, and both are hard to manufacture while a room argues. Agreeing it in advance does three things: - **It converts a judgement into recognition.** The question stops being "is this bad enough?" and becomes "is this on the list?" — which is answerable by one person in a minute. - **It removes the incentive problem.** Deciding under pressure, the person who calls for a replacement owns the disruption and the person who does not owns nothing visible. The default is therefore inaction, and the list is what removes the choice. - **It makes the omission visible.** A declared trigger with a deadline leaves a record. A quiet decision that it was probably fine leaves nothing for anyone to find later. ## What each entry has to carry 1. **The event, described so it can be recognised** — "a holder of a shared value leaves the team or the contract ends", not "personnel changes". 2. **The values it applies to**, by class rather than by name, because names go stale: "every shared value that holder could read". 3. **The action**, stated in the right direction: replace, move holders, then refuse the old value at the system that accepts it. 4. **A clock**, so "we are doing it" cannot mean next quarter. 5. **The declarer** — a role that is on call, not a named individual on holiday, and explicitly with no approval step. 6. **Where the declaration is recorded**, so the completion can be checked against the clock. ## Who may declare, and why it is the load-bearing field A replacement is disruptive and someone will always be senior enough to be worth asking. That is exactly the failure: the hours spent finding that person are hours the exposed value keeps working. The register's job is to say, in advance and in writing, that a named role may declare a trigger alone, and that nobody will be second-guessed for a declaration that turns out to have been unnecessary. That last clause is not softness. Without it the list is decorative, because the cost of a wrong declaration lands on one person and the cost of a missed one is diffuse. Pair it with the default rule: **if an event is arguable, replace and record the reasoning.** ## What does not belong on the list A trigger list describes events that force a replacement *when the calendar does not*. Routine work does not belong on it and dilutes it: - A scheduled review of which services still hold long-lived values. - Onboarding a new consumer of an existing credential. - Planned work on the store itself. If every change is a trigger, nothing is, and the register stops being something anyone reads in an emergency. ## The honest limits A list does not make the replacement possible. If nobody knows which consumers hold a value, or the accepting system cannot take a new one without a release, the declaration just starts a slower problem — and the register is where that becomes visible, because an entry with a two-day clock that nobody can meet is an argument for fixing the underlying estate. It also does not decide *scope*. The entry says the class of values; establishing which specific values a given event touched is work done at the time, from entitlements and read records. ## What an interviewer is listening for The thin answer is "we have a runbook". The strong answer names the declarer field and explains why it exists, gives the default for the arguable case, and admits what the list cannot do — it cannot make a replacement cheap, and the events it lists are the ones that force one anyway.
- An entry's deadline has never once been met. What does that tell you?That the estate cannot carry out that replacement, not that the clock is wrong. Usually the holders of the value are unknown, or the accepting system needs a release to take a new one. The useful response is to fix the underlying constraint; lengthening the deadline to make the register look green hides the real defect.
- Who should be able to declare a trigger — the security team or the owning team?Whoever will notice first, which is usually the owning team, with the security function able to declare across teams. Restricting it to one function guarantees delay for events that surface elsewhere. What matters more than the choice is that the role is on call and needs no approval.
- How is a declared trigger different from an incident being declared?A trigger commits to one bounded action on named values with a clock. Declaring an incident commits to a wider process — coordination, investigation, notification decisions — and the two are often appropriate together, but a trigger must be usable without any of that machinery, or it will not be pulled.
saying these in an interview costs you the question
- Says the list is a reminder rather than a pre-made decision
- Requires approval before the value can be replaced
- Names an individual instead of an on-call role as declarer
- Puts routine scheduled work on the trigger list
- Leaves the arguable case undefined, so inaction wins
- Claims the list makes the replacement itself cheap