A support product adds a feature that sends the text of a customer ticket to a third-party model provider to draft a reply. The contract lets the provider retain inputs for 30 days for abuse monitoring. The team updates the data-flow diagram by adding a box for the provider and an arrow to it. Which single further change does the privacy review actually need?
Show the full answer Hide the answer
The deciding property
A data-flow diagram exists to answer one question: which data crosses which boundary, and what happens to it on the other side. A box and an arrow record that a call happens. They do not record the two facts every downstream obligation attaches to - the category of data in the payload, and how long it rests on the far side.
Ticket text is the hard case precisely because it is unstructured. Nobody declared it as personal data, and it contains names, addresses, order numbers and whatever the customer chose to paste in. The classification travels with the field in a database and gets lost the moment the content is concatenated into a prompt.
Why the retention number is the load-bearing label
Thirty days of abuse-monitoring retention is not a footnote; it changes three answers:
- Erasure. A deletion request received on day one cannot be fully satisfied until day 31 unless the contract provides a deletion path into that buffer. The published response time for the request has to accommodate that, or be wrong.
- Subprocessor obligations. A party that stores your customers' content for 30 days is a processor, which means a data processing agreement, an entry in the subprocessor list, and in many contracts advance notice to your own customers.
- Breach scope. If the provider is compromised on day 20, the exposure is 30 days of ticket text, not the single request in flight.
Writing those two labels on the crossing is what makes the diagram answer the review's actual question instead of confirming that an integration exists.
Why the other options fail
- The SOC 2 note is a real control and the wrong artefact. A certification says the provider operates controls competently. It does not say what you sent them or how long they keep it, so it cannot answer an erasure or residency question. Teams reach for it because it is the document procurement already has.
- The return arrow is the mistake of drawing the mechanism instead of the risk. The reply coming back is the low-risk direction - it is your own content, generated. The outbound crossing is where the obligation is created. Drawing both is fine; drawing only the return adds a line and no information.
- Recolouring external boxes is good hygiene and belongs in the legend, not in this review. Colour marks what the box is. The review needs to know what crosses, and a colour cannot carry a data category or a duration.
What would flip the decision
| If this changes | Then | Because |
|---|---|---|
| Provider is contractually zero-retention | Label the crossing with categories only | No dwell time means no erasure or breach-window question |
| Content is redacted before the call | Label the crossing with the redaction and its failure rate | The residual risk is now the redactor's miss rate |
| Provider runs in your own account or region | Keep the boundary but drop the residency flag | The jurisdiction question disappears; the processor one does not |
When this is the wrong answer
For an internal prototype on synthetic data, the boundary label is overhead and the diagram's job is just to show the shape. The label earns its place the moment real customer content can reach the call - which, for a feature behind a flag, is the day the flag is enabled for one account, not the day it ships generally.