A team's threat model for a new service covers only its two bespoke flows and inherits the platform by reference — when is that delta model legitimate?
answer
- thin and current beats thorough and stale
- name the controls you inherit
- inheritance transfers whatever the control really is
- draw the delta around departures, not new code
- reference, never copy
basics
~20 sLegitimate when the inherited part is named control by control, each of those controls has evidence behind it, and the team can show why its two flows fall outside the inherited pattern. Lazy when 'the platform handles it' names nothing.
solid answer
~50 sI actively want delta models — re-deriving the same twenty threats for every service is how a practice dies of its own volume, and a thin model people keep current beats a thorough one nobody reopens. The test I apply has three parts. First, the inheritance is specific: the model names which controls it takes from the platform, not 'the platform covers infrastructure'. Second, each named control has evidence behind it — an owner and a test — so inheritance transfers a verified control rather than optimism. Third, the team has justified the delta: they walked their trust boundaries and can say why these two flows sit outside the inherited pattern, usually because a boundary, a caller population or a data class differs. A model that skips the third part is not a delta model; it is an unstated bet that this service resembles the others.
go deeper
Understand what a delta model is: a model for a new service that covers only what is genuinely different and points at named platform controls for the rest, rather than restating them from scratch.
Be able to say what the inherited part must contain to mean anything — the specific controls named one by one, and a reference that stays live rather than a paragraph copied at a moment in time.
Demonstrate the check you run. Walk the new service's trust boundaries and show where it departs from what the inherited controls assume, because the missed threat sits at the departure and not inside the new code.
Own the volume argument: full models for every service collapse under their own weight, so delta models are how the practice scales. Defend the conditions that make inheritance safe, and be willing to say when you refuse one.
## Why delta models exist Once an organisation runs services on a shared platform, most of what a new service's threat model would contain is not about that service at all. Ingress termination, workload identity, secret distribution, runner isolation, backup handling — the same twenty threats and the same twenty answers, retyped for the fiftieth time. Insisting on a full model per service produces long documents written to satisfy a process, read once, and never reopened. The volume defeats the practice. A **delta model** is the correction: the new service models only what is genuinely different about it, and inherits the rest of the platform's threats and controls by reference. Done well, it is both cheaper and more accurate, because the team's attention lands on the part where they actually made novel decisions. Done badly, it is a one-page document asserting that somebody else has this covered. ## The three tests that separate the two **1. The inheritance is specific.** 'The platform covers infrastructure threats' is not inheritance; it is a wish. A legitimate delta model names the controls it is relying on individually — this identity mechanism, this isolation property, this key custody arrangement — because a named control can be checked, can be found again in a year, and can notify its dependants when it changes. An unnamed one cannot be any of those things. **2. Each inherited control has evidence.** Inheritance transfers whatever the control actually is. If the platform's claim has an owner and a test behind it, the new service genuinely gains a control. If the claim is itself an untested belief, the new service has inherited the belief, and now two models are wrong instead of one. This is the multiplier that makes unverified inheritance so much worse at portfolio scale than a single unexamined assumption in a single model. **3. The delta is justified, not assumed.** This is the part teams skip. The delta is supposed to be drawn around *where the service departs from what the inherited controls assume* — not around *the code the team wrote*. Those are different boundaries, and the gap between them is where the missed threat lives. A service can be entirely conventional in code and still depart from the pattern because: - it holds a **more sensitive data class** than the inherited controls were scoped for; - it exposes a **listener the platform's ingress does not front** — a raw socket, a queue consumer, a callback endpoint; - it is called by a **different population** — partner systems, or an internal tool used by staff rather than by services; - it runs under a **different tenancy or residency** constraint than the platform's default. The way to find the departure is to walk the new service's trust boundaries and ask, at each one, whether the inherited control was designed for this crossing. That walk is the work; the two bespoke flows are the easy part. ## Keeping a delta model honest over time Inheritance must be a **live reference, not a copy**. If the model quotes the platform's controls in a paragraph, the platform can later weaken or redesign a control and the quotation stays comfortably wrong. If the model points at the control, then a change to that control can reach every dependant — the owner knows who is downstream, the dependants know to re-examine their delta. That is the difference between an inheritance graph and fifty documents that once described the same thing. The dependants list is also what makes an incident tractable. When a platform control turns out to have been weaker than advertised, the answer to 'which services are exposed' should be a query, not an archaeology project. ## When a delta is the wrong answer Refuse the delta and ask for the full model when: - The service is the **first of its kind** on the platform — there is no verified pattern to inherit yet, and this model is what will define the pattern the next ten inherit. - The service **terminates its own external traffic**, holds a data class outside the platform's scope, or serves a tenancy model the platform's controls never contemplated. Too much departs for the inherited part to carry weight. - The inherited controls have **no evidence behind them**. Then the honest move is to fix the inheritance first, because a delta on top of unverified claims is a short document that looks like coverage. ## The judgment being tested An interviewer asking this is checking whether you can hold two things at once: that thoroughness per model is not the goal — sustained, current coverage across a portfolio is — and that the mechanism which buys that scale, inheritance, is exactly the mechanism that silently propagates a wrong belief across every model that uses it. The answer that gets full marks welcomes delta models and states the conditions under which they mean anything.
- What most often turns out to be missing from a delta model?The service was assumed to sit inside the inherited pattern when one attribute differs — a more sensitive data class, a listener the platform's ingress does not front, a caller population of staff rather than services. The team drew the delta around the code they wrote instead of around where the service departs from what the inherited controls assume, and the departure is exactly where the missed threat lives.
- How do you keep a delta model honest a year later, when the platform's controls have changed?Make the inheritance a live reference rather than a copied paragraph. The model points at the platform control, so when its owner weakens or redesigns it, everyone inheriting it can be told and can re-examine their delta. If inheritance is a copy, the platform can change underneath fifty models that all keep quoting a version that no longer exists.
- When would you refuse a delta model and insist on a full one?When the service is the first of its kind on the platform — there is no verified pattern to inherit, and this model is what defines the pattern others will inherit. Also when it terminates its own external traffic, holds a data class the inherited controls were never scoped for, or serves a different tenancy model. And when the inherited controls carry no evidence, fix that first.
Building on someone else's foundation is perfectly sound engineering — provided you know which foundation it is, and somebody has actually inspected it.
saying these in an interview costs you the question
- Says the platform handles it without naming a control
- Inherits controls that nothing has ever verified
- Copies the inherited section instead of referencing it
- Draws the delta around new code, not around differences
- Rejects delta models and demands full models every time
- Cannot list which services inherit a given control