Why enumerate a system's exit points, not just its entry points, when threat modeling?

## Why the second half of the inventory exists A data-flow diagram has arrows in both directions. Threat modeling that only follows the inbound ones models the attacker's push and ignores the asset's pull. An **exit point** is any place where data crosses the trust boundary *outward*: to another system, another organisation, another retention regime, or a human audience. The reason this matters is that exit points defeat controls by construction. Authorization at an entry point is a check made at a moment in time; an export is a check made once, followed by a copy that persists indefinitely somewhere you do not control. Nothing you later do to the primary path reaches that copy. ## The families of exit point - **Operational telemetry.** Application logs, metrics, traces, crash dumps, debug streams. These are the most commonly missed because the team thinks of them as internal plumbing rather than as data leaving. They usually flow to a different retention, a different access-control model and a wider audience than production data. - **Business exports and integrations.** Scheduled reports, CSV downloads, outbound webhooks, partner feeds, invoicing files. Each one has a recipient outside the boundary. - **Lifecycle copies.** Backups, restore tests, disaster-recovery replicas, non-production refreshes seeded from production, analytics or data-science extracts. These reproduce the whole dataset, frequently into an environment with weaker controls than the one it came from. - **Human channels.** Support tooling that renders a customer record on a screen, ticket attachments, screenshots pasted into a chat, a screenshare during a call. Data leaves through a person just as surely as through an API. ## What to record per exit point Three questions, asked the same way every time: 1. **What leaves** — at field granularity, not "customer data". Does the export carry the payment reference, the full address, the free-text notes? 2. **Who receives it** — a named party and their boundary. "The accountant's mailbox" is a real answer and it is more useful than "the customer". 3. **Under what authorization and retention** — who authorised this flow, is that authorisation checked per export or once at setup, and how long does the copy live at the far end? A two-column mapping is enough on a whiteboard: | Exit point | What leaves, to whom, for how long | | --- | --- | | Weekly clinic report | Client names, visit notes, payment amounts, to each clinic's accountant by email, retained indefinitely by them | | Nightly restore test | Full production copy, to a shared bucket in a lower-trust account, until overwritten | | Crash dump upload | Process memory and request context, to the crash-reporting endpoint, per its retention | ## The subtle ones Two patterns are worth naming because they surprise teams. First, **exit points that carry credentials rather than business data**. A mobile game backend uploaded crash dumps and a debug telemetry stream from client devices; both carried live session tokens off the boundary. The asset leaving was not player data, it was authentication material — and it left to a destination with a different access model than the token store it came from. Anonymous parties, not insiders, were the plausible adversary because the destination was reachable from the client. Second, **exit points created by an operational habit rather than a design**. The restore-test copy exists because someone was doing the right thing: verifying that backups restore. Nobody designed it as a data flow, so it appears on no diagram, has no owner, and inherits whatever permissions the bucket happened to have. Exit points born of good operational practice are the most likely to be undocumented. ## What the inventory buys you Once exit points are on the diagram, several decisions become mechanical rather than argumentative. You can state the true blast radius of a compromise: every copy that has left is in scope. You can see which controls are worth strengthening: hardening a login helps nothing if the same records are mailed out weekly in the clear. And you can point at specific flows when someone asks what happens to a customer's data, instead of describing intent. It also changes design conversations early. "Which fields does this report actually need?" is a cheap question at design time and an expensive one after a year of recipients depending on the columns. ## Direction discipline One last piece of hygiene: keep the direction straight on the diagram. A backup *write* is an exit point; a restore *read* brings that data back in and is an entry point, because the restored content is only as trustworthy as the place it sat. Some flows are genuinely both, and drawing them as one undirected line loses exactly the information you drew the diagram to capture.