Your threat model assumes another team tokenises PII upstream — how should you treat that inherited control?

## The situation Your design depends on a control you did not build, cannot test, and do not operate. A feature store you own is fed by a pipeline run by the data platform team, and the modelling session is told: *the data platform tokenises PII before it lands.* If that is true, a large family of confidentiality threats against your store disappears — an analyst with broad read access sees tokens, not names, card numbers or addresses. If it is only partly true, you have shipped a model that quietly deleted its most important branch. This is an **inherited control**: a control that reduces your risk but is provided across a team boundary. Inherited controls are not unusual — most services rest on several — and they are the single most productive place to look for missed threats, because the model's author and the control's owner never had the conversation. ## Rule one: it is an assumption, not a mitigation A mitigation is something present in the design you are responsible for; you can point at it, test it, and see it break. An inherited control is a claim about someone else's system. Record it as an assumption with the owning team named, and keep the threat in the model with a **residual risk** rather than closing it. The distinction matters at review time. A threat marked *mitigated* is finished and stops being read. A threat marked *assumed handled by the data platform team, unverified* is an open question that someone will eventually chase. ## Rule two: confirm the shape of it, not the existence of it "Do you tokenise PII?" gets a yes from almost anyone. The useful questions are narrower: - **Which fields?** Names and card numbers, but perhaps not free-text notes, email addresses in a comments column, or a raw payload column kept "for debugging". - **On which paths?** This is where inherited controls are most often partly true. The main streaming path is tokenised; the one-off backfill that reloaded three years of history is not. Nor, frequently, is dead-letter reprocessing, a manual dataset load, or a break-glass export produced during an incident. - **When?** Tokenised before the write, or by a scheduled job that runs afterwards and leaves a window? - **What happens on failure?** Does the pipeline stop, or does it pass the record through untokenised and log a warning? Each of those answers is either a confirmed control or a newly discovered threat, and you get them in an hour of conversation instead of after an incident. ## Rule three: model it as if absent, then decide Before the answers land, enumerate the threat as though the control were not there, so the model states plainly what is at stake: an analyst with legitimate broad read access to the feature store — an insider position, not an anonymous attacker — reading customer personal data at scale, which violates confidentiality. Now you can make a decision with the impact visible: - **Accept** the dependency, record it, and give it a revalidation trigger. - **Compensate** where the blast radius is unacceptable: field-level access restrictions on your side, alerting on bulk reads, shortened retention, or your own masking on the read path. These are yours; they do not depend on anyone else's roadmap. - **Escalate** if the confirmation comes back negative and the exposure is large. ## Rule four: the assumption is not a transfer of accountability Recording "the data platform team tokenises PII" documents a dependency. It does not move the consequence. If the control fails, it is your feature store holding readable customer data and your service in the incident report. The register makes the dependency visible and gives the owning team a chance to dispute it; it does not make the risk theirs. Candidates who reach for "that's the platform team's problem" are answering an accountability question wrongly. ## Rule five: attach a trigger The most common way this fails is not a lie — it is drift. The control existed, was confirmed, and later changed for a reason nobody connected to your service. Write down the event that should force a recheck ("any change to the ingest transform", "any new load path into the store") and, where you can, ask the owning team to record you as a consumer so their change process surfaces you. ## The short version for an interview Name it as an assumption with an owner. Ask which fields, which paths, when and on-failure. Keep the threat open with residual risk until it is confirmed. Add your own compensating control if the impact of it being wrong is unacceptable. Attach a revalidation trigger. And be clear that the consequence stays with you regardless of who operates the control.