What does a level-0 context diagram show in a data-flow-diagram threat model?
answer
- start by drawing nothing inside
- who talks to it, not how it works
- one process, external entities, flows
- the outer boundary and what crosses it
- level 0 of the leveling hierarchy
basics
~20 sA level-0 context diagram draws the whole system as one process, every external entity that talks to it, and the flows between them. It fixes scope and shows what crosses the outer trust boundary, with no internal structure.
solid answer
~50 sThe context diagram sits at the top of the leveling hierarchy: a single process for the entire system under review, every external entity around it — end users, operators, partner systems, identity providers, batch feeds — and every flow in and out, annotated with protocol and data class. The one boundary it always carries is the outer one, so everything crossing it is untrusted input coming in or a disclosure going out. For a national driving-licence renewal service, level 0 is what a ministerial sign-off actually reads: applicants, the photo-and-identity checking service, the payment provider, the police records feed, the print bureau. It already yields real threats — an anonymous applicant spoofing another citizen, tampering with a submitted document in transit, repudiating a renewal they claim they never requested. What it cannot show is elevation of privilege between two internal components; that needs a lower level.
go deeper
Be ready to draw it on request: one box for the system, external entities around it, labelled arrows, and a line for the outer trust boundary. Say out loud that nothing internal is shown.
Explain what the level buys you — a scope everyone can dispute, and the outside-attacker entry points enumerated before any internal structure exists. Name the interfaces people forget: admin, batch, monitoring.
Show that you can produce real threats from level 0 alone and can state its limit: no internal privilege escalation, no component-to-component boundary. Be able to say which pending decision would force you to decompose.
Own the artifact politics: the context diagram is the page a sign-off actually reads and the one that stays true across releases. Decide who maintains it and what change to the external interface set triggers a re-review.
## The leveling hierarchy A data-flow diagram (DFD) threat model is not one drawing. It is a small hierarchy of drawings at increasing detail, and the convention borrowed from structured analysis names them by level. - **Level 0, the context diagram.** The entire system under review is drawn as a *single process*. Around it sit the external entities it exchanges data with, and between them the flows. Nothing inside the system is shown. - **Level 1.** That single process is opened up into its major internal processes and data stores, with the same external flows still arriving at the edge. - **Level 2 and below.** One level-1 process is opened up in turn, showing its internals. The context diagram is therefore the answer to a scoping conversation that has already happened: *this* is the thing we are modeling, and *these* are the parties it talks to. ## What belongs on it Four things and no more: 1. **One process** — the system, named as the business names it. 2. **External entities** — anything that interacts with the system but is not part of it, and that you do not control or model internally: citizens and customers, administrators and operators, partner services, identity providers, payment providers, regulators pulling reports, batch feeds, the monitoring backend you ship logs to. 3. **Flows** — every data path in and out, with a direction, a protocol and a data class (personal data, credentials, money instructions, telemetry). A flow with no annotation is half a flow. 4. **The outer trust boundary** — a line separating the system from everything around it. Every flow that crosses it is an entry point (untrusted input) or an exit point (a disclosure or an action taken on the outside world). What does **not** belong: internal components, internal databases, deployment detail such as hosts, subnets and load balancers, and message ordering. Those are the business of lower levels or of other notations entirely. ## Worked example A national driving-licence renewal service. The level-0 diagram has one box labelled *Licence Renewal Service*, and around it: the applicant (submits an application, a photo and a scanned proof of address; receives a status), the photo-and-identity verification provider, the payment provider, the police records feed that supplies disqualification data, the print bureau that receives an authorised production instruction, and the ministry's reporting users. That single page is what a non-technical sign-off reads and approves, and it is enough to enumerate a first tier of threats: | Flow crossing the boundary | Representative threat | | --- | --- | | Application submitted by applicant | Anonymous applicant impersonates another citizen (spoofing) | | Scanned document uploaded | Document altered before or during submission (tampering) | | Renewal confirmation | Applicant later denies having requested the renewal (repudiation) | | Instruction to the print bureau | An unauthorised instruction produces a genuine document (integrity of the physical artifact) | | Records feed from police | Availability loss stops all renewals (denial of service) | Notice the asset in play: personal data and the integrity of an official document, not a generic customer database. The context diagram is where you name that asset, because it is where you name who is on the other side of every line. ## Why the level exists at all Three jobs. **It fixes the boundary of the exercise in a form people can disagree with.** A one-page diagram makes a missing interface visible: someone in the room says *what about the call-centre agents who can amend an application?*, and you have found an entry point before you have modeled a single internal component. **It gives you the outside-attacker view for free.** The threats above are the ones an anonymous or lightly authenticated outsider can reach, and they are usually the highest-exposure ones. Starting inside the system, at level 1, tends to bury them. **It is the stable artifact.** Internals churn every sprint; the set of parties the service talks to changes rarely. A context diagram stays true for a long time, which is why it is the page you put in front of a sign-off. ## Common failures - Drawing internal components on it, so that it becomes a bad level-1 diagram. - Omitting the boring external entities — the monitoring egress, the nightly reconciliation feed, the admin console reached from an office network — because they feel internal. They are entry points, and they are frequently the least protected. - Treating it as too shallow to yield threats and skipping straight to level 1. - Confusing it with a deployment diagram. The context diagram is about *who exchanges what data with the system*, not about where anything runs. ## What it cannot tell you Anything that depends on internal structure: privilege escalation from one internal component to another, an internal store read by a component that should not read it, a boundary between two teams' services. If the pending question is one of those, you decompose. The context diagram is the start of the hierarchy, not the whole of it.
- Do trust boundaries appear on a context diagram, or only at lower levels?At least one appears: the outer boundary around the single system process. Every flow crossing it is an entry point or an outward disclosure, which is exactly the analysis the level-0 diagram is for. Boundaries *inside* the system — between components under different credentials, accounts or teams — only become drawable once you decompose, and finding one is itself a reason to go a level deeper.
- How do you know a context diagram is complete?Walk the interfaces rather than the architecture: who authenticates, who administers, who is billed, who receives exports, what runs on a schedule, where telemetry and backups go, and which third parties are called out. Each answer is an external entity or a flow. Any party a person can name that is not on the page is a gap, and the ones people forget are admin, batch and monitoring paths.
- Can a context diagram be too big?It can, and the fix is usually scope rather than layout. Thirty external entities normally means you have drawn a whole department as one system. Either the thing under review is genuinely a platform — in which case group entities by role and accept the page — or you should be modeling one service inside it, with the neighbours becoming externals.
It is the diagram on the front of an embassy building: who may approach, which windows they queue at, and what they hand over. It says nothing about the corridors inside.
saying these in an interview costs you the question
- Draws internal components and databases on the context diagram
- Says a context diagram is too shallow to produce threats
- Omits admin, batch and monitoring interfaces as internal
- Confuses the context diagram with a deployment or network map
- Leaves flows unlabelled, with no direction or data class