A platform must demonstrate to a reviewer where personal data goes. Which diagram serves this, and what must it include that a component diagram does not?

The diagram

A data-flow diagram with trust boundaries and data classification, which is a different artefact from a component diagram and answers a question no component diagram can.

A component diagram shows what talks to what. A reviewer needs to know what data moves, of what sensitivity, across which boundaries, and what happens to it at rest at each stop.

What it must include

1. Data classification on every flow. Not "customer data" but the specific categories: identifiers, addresses, payment details, real-time location. Different classes attract different controls, and location data in particular is routinely under-classified because it is produced as operational telemetry.

2. Trust boundaries, drawn explicitly — between the public internet and the platform, between tenants, between the platform and third parties, between regions subject to different regimes. The boundaries are the subject of the diagram, not decoration on it.

3. Storage at each point, with retention. Where does data come to rest, for how long, and under what retention policy. Reviewers care more about resting data than moving data.

4. Flows leaving the boundary. Analytics exports, partner integrations, vendor telemetry, backups. These are the flows most often omitted and most relevant to a privacy or residency review, because they are not part of the product and therefore not on anyone's component diagram.

5. Derived data. Aggregates, search indexes, caches, model training sets. A deletion or residency requirement applies to these too, and they are frequently invisible.

6. Geographic placement, where residency is a constraint. Which flows and which stores are in which jurisdiction.

Why this is architectural rather than a compliance artefact

The diagram routinely reveals design problems: personal data in a log aggregation platform in another region, location data retained in an event stream for years because nobody set a policy, or a third-party integration receiving more than it needs because the payload was convenient.

Each of those is an architecture defect found by drawing a picture, and each is far cheaper to fix at design time than after a review.

The maintenance requirement

A data-flow diagram that is out of date is actively dangerous, because it is used to make compliance assertions. It needs an owner, a review trigger tied to new integrations and new data stores, and ideally automated detection of classified data appearing where the diagram says it does not go.