Understand what connected systems could do, then test the explanation against the records. Explore 20 practical questions and four interactive examples of collection, access, transformation, matching and later use.
Turn an explanation into a question.
These questions grew out of FilmPass’s search for answers after pausing its business. They turn that experience into practical enquiries others can adapt. Read why we paused and what we learned →
Use the primary references attached to each question for the relevant mechanism and rights.
Start with the answer you were given. Explore what the connected systems could do, the conditions needed and the records that would test the explanation. Follow the information through collection, access, transformation, matching and later use.
A statement about one category of data may leave another route unexplained. For example, protected fraud signals and a separately collected merchant record can concern the same checkout. Trace each branch.
The routes below are illustrative technical investigations. Source links support the building blocks and relevant rights; a particular organisation's configuration and records establish what happened in its case. Each answer explains what the evidence could support and what remains unresolved.
Use the personal-records request for information about you. An SME's supplier review or technical support enquiry is the route for wider configuration and integration evidence; access rights do not guarantee every internal document. Start with the event, reference and date you already have.
Try four interactive examples ↓Personal-records request ↓
No matching questions. Try a shorter search or use Clear filters above.
A checkout event can enter an order system and also trigger a configured connection. The receiving system may store selected fields under different names. A statement about collection alone leaves those later steps unresolved. Start with one event you can identify and reconstruct its route.
The additional route needs an enabled connection, accessible fields and a receiving system. A policy category alone establishes none of these.
For the event identified in my request, please explain which records were created, which fields went to each recipient, what was derived from them and how the resulting records were used. Please relate your policy explanation to those records.
Put the response beside a four-column route: source, fields, destination, use. Follow up on the first missing step with the event reference.
A mapped receiving record supports that connection. A general description leaves the connection unresolved; it does not establish that a transfer occurred.
Information relating to an identifiable person is personal data even when that person acts for a business. In this stock-purchase example, Person A works from home; the configured fraud tool records browser and mouse-activity information from A’s session. The payment carries Person B’s cardholder name and billing address. The stock is for Company C. Those are separate sources and roles. B’s billing address does not establish A’s location or who performed the session activity.
Establish how each record is linked to a person. Mouse-activity collection belongs to the fraud tool in this example; it is not a universal 3DS2 field. Authentication alone does not identify who physically operated every device.
The checkout user and named cardholder were different people. Please distinguish my browser/session activity from the cardholder and billing details. How were those records linked, whose profile received the resulting assessment, and was the billing address treated as my location? Please address my identifiable activity separately from company-only records.
Start with an order where the checkout user and cardholder differ. Compare the session reference, named account, payment reference and address fields, then trace the receiving profile. Ask which location was supplied, observed or estimated.
A business label does not remove personal-data status. Verified links establish whose information is involved; an unsupported assumption that the cardholder operated the checkout should be challenged.
There are two routes to test. A receiving system could use an accessible assessment result for another purpose. Alternatively, the merchant could separately send its own order or claim fields into a customer system. The second route does not require the fraud provider's protected raw signals to leave that provider.
The destination needs access to the relevant fields or output. It also needs a configured rule and, for a person-level profile, a usable matching key.
Please distinguish protected raw fraud signals, assessment outputs and separately collected merchant information. Which of those entered any reporting, customer-profile or marketing system, through which connection and for what use?
Trace each branch separately. A reply about raw fraud signals should be followed by a question about merchant-held fields and derived outputs.
An enabled, evidenced branch supports that route. A restriction on one category does not describe every branch, and a possible branch is not evidence that it operated.
A merchant can create a payment request containing a reference to its order. A provider can return a payment identifier and later send an event notification, often called a webhook. Another system may process that notification. Each participant can describe one stage while leaving the hand-off unexplained.
The references must correspond to the same transaction and account. Notifications must reach an enabled endpoint and be processed to produce the later action.
Please identify the records and decisions within your responsibility for this transaction. Which reference connects them to the other organisation's records, what did you send or receive, and which organisation controls the next processing step?
Send each organisation the same transaction reference and ask about its own hand-off. Compare the descriptions for missing or conflicting steps.
Matching records can establish a hand-off. They do not automatically mean both organisations controlled every later use.
A payload is the information carried in a message. An order submission, authentication request, device-signal request and analytics event can be separate messages. Common references can connect them even when their fields differ. A browser view may show the first requests while later server-to-server transfers need separate records.
Each branch requires its own integration. Matching requires reliable references and context, not just similar timing.
For this checkout, please identify the separate collection and transmission processes, the fields each carried and the references connecting them. Which later transfers occurred between servers and would not appear in the customer's browser?
Draw the branches and give each message its own reference. Keep collection, delivery and subsequent use as separate entries.
A browser request shows that request's destination and contents. It cannot, by itself, establish every onward transfer or the recipient's later use.
In an illustrative reward system, three claims within a month could be counted and turned into a 'repeat redeemer' attribute. A further rule could place the account in an offer audience. The attribute is a calculation about recorded activity; it is not something the customer typed into a form.
Events must be collected, correctly associated with an account and processed by a calculation or classification rule.
Please include information observed or inferred about me, including calculated attributes, scores and segments. Please explain the source records, meaning and date of those attributes, and how they were used.
Compare the disclosed profile with the source events you recognise. Ask separately about a missing calculation or a label that appears unsupported.
A stored attribute establishes that output. The input events and rule are needed to assess whether its calculation and interpretation are sound.
A person can view information in a dashboard, a program can retrieve it through an API, or a report can download selected fields. An automated connection can then forward accessible information. These are different mechanisms to examine; they do not all expose the same fields.
The user or integration needs permission to access the fields. A documented download feature does not establish that a particular export ran.
Does your answer cover dashboard visibility, API retrieval, report downloads and automated connections? For each applicable method, please identify the fields, permitted recipients and any relevant records of actual access or delivery.
Break a general denial into separate questions about each access method. Use the actual field names where available.
Permission establishes capability. A query, export or delivery record can establish use of that capability within its recorded scope.
Plans and roles can change which results are exposed. Stripe, for example, documents risk scores available on certain Radar plans. A merchant might use an exposed output in its own workflow. That is a different question from whether it can retrieve the provider's underlying device and activity inputs.
The particular account and role need the relevant entitlement. The integration must request and process the field.
At the date concerned, which results could this account and its connected applications access? Please distinguish those exposed outputs from the raw inputs, and identify whether any output was passed to another workflow.
Compare the historical configuration with the explanation you received. Current product documentation cannot establish an earlier account's settings.
An exposed field makes a route possible. Evidence of retrieval and downstream handling is needed to establish what happened next.
A configured function can rename a field, combine values, add context or output a category. In an illustrative rule, a claim count could become a repeat-use label. Searching the destination only for the original field name would miss that output. The mapping explains how the two records relate.
The function must receive the source field, execute the relevant rule and deliver its output to the destination.
Please identify derived or renamed fields created from the relevant source records. What transformation produced them, what do they mean, and which destination records retain those outputs?
Build a source-to-output dictionary. Search the resulting names and categories as well as the original names.
A matching name alone is weak evidence. A recorded transformation and corresponding input/output provide a stronger connection.
A customer reference can replace a name in an export. If the recipient has a corresponding lookup, it may reconnect the record to a person. A hashed value may also support matching under the relevant conditions. Removing a visible name does not describe what matching information remains available.
The identifier must be usable in the recipient's account context and the necessary matching information must be available. A campaign label is not necessarily a unique person key.
Which identifiers or distinctive attributes remain, and who can access the additional information needed to link them to a person? Please explain whether and how the receiving system performed that match.
Test one known reference against its corresponding receiving record. Check collisions, shared accounts and mistaken matches.
A verified lookup supports linkability for that recipient. A theoretical lookup that the recipient cannot reasonably obtain does not establish the same position.
An account may be linked through an old email, internal customer key, payment reference or device/session identifier. A search against one visible field may miss records stored under another. Related information can also sit in an archive or with a service processing it on the organisation's behalf.
A relationship between the identifiers must exist. Search scope should reflect the request and a reasonable, proportionate retrieval effort.
Please clarify whether the information was never collected, deleted, not located or withheld. Did the search cover the supplied references, related identifiers and relevant information held on your behalf? Please explain any remaining gaps.
Provide a concrete receipt, event reference or disclosed identifier and ask for a targeted search. Keep the earlier answer and the follow-up together.
A documented search explains its coverage. A missing result does not prove either that a record never existed or that it is being concealed.
An invented value such as category_3 could represent a segment, processing state or reason code. The same number may mean something different in another table or software version. A downstream rule could use the value to select an offer or trigger review even when the export provides no explanation.
The code needs a defined meaning in that system and a rule or process that uses it. Its appearance alone does not reveal the action.
Please explain the unfamiliar fields and codes in my disclosure, including what each describes, when it was assigned and how it was used. Where meanings changed, please provide the meaning applicable to these records.
Make a small table of unexplained fields and example values. Ask for each definition, then compare the explanation with the resulting activity.
A dictionary explains the code. An action record is needed to establish that the code affected this particular outcome.
In an illustrative receiving workflow, a payment's risk result could be copied into a customer table and used in a rule about future transactions or offers. This changes the level at which the result is applied. A prediction about one payment does not establish a person's general behaviour or commercial value.
The result must be accessible, the customer join must work and a downstream rule must consume the copied or derived value.
Was this assessment used only for the original payment, or copied into an account or customer profile? Please identify any derived labels and subsequent decisions that used it, including their dates and purposes.
Compare the original assessment with later profile values. Check whether a correction or expiry affected the copied attribute.
The full input-to-action chain supports a later use. A score's presence in an export alone does not establish that it drove a subsequent decision.
An illustrative export could retain 'refund' while omitting 'supplier cancelled the order'. A later rule might count the remaining events as customer behaviour. Similar errors can arise when retries are counted as new purchases or records from different people are joined. The source event and receiving interpretation need comparison.
Relevant context must be absent or misinterpreted and the later rule must depend on the remaining fields.
Please compare this label with the source event and its recorded reason. Was relevant context omitted or misinterpreted? Please correct inaccurate facts, complete missing context and explain which recipients or derived records were addressed.
Supply the cancellation or other source record. Follow the correction into the receiving profile rather than stopping at an acknowledgement.
An event mismatch can identify a specific error. A disputed opinion still needs examination of its supporting facts and how it is recorded.
A rule or model output can trigger an action before a support employee sees the case. A later message may repeat the recorded outcome without revealing how it was produced. Investigate the original trigger and the review as two events, including whether the reviewer had the evidence and authority to change the outcome.
Establish which stages were automated and what a person actually did. A support job title alone does not answer this.
Please explain how the original decision was made and what happened during the subsequent review. What evidence did the reviewer consider, could they change the outcome, and what decision did they independently reach?
Create separate timeline entries for the initial action and review. Ask about unexplained intervals or a review that does not address the disputed evidence.
A documented reconsideration can show what the review covered. A templated response alone leaves that process unexplained.
One source event can feed different processes: fulfilment, security assessment, reporting and a later customer segment. Giving the whole journey a broad label does not identify what each process does. Build a map connecting the fields and recipients to their actual purposes before assessing the explanation.
Identify the actual use, applicable date and precise basis. Ordinary legitimate interests and recognised legitimate interest have different requirements.
Which precise lawful basis and purpose apply to each processing step identified here? Please address any later matching, enrichment or reuse separately and explain the basis applicable at the relevant date.
Mark where the purpose changes on the route. Follow up on a basis that is stated only for collection but leaves the later use unexplained.
A specific explanation can be assessed against the records. Repeating a general basis leaves that comparison incomplete.
Authentication, advanced fraud collection and a merchant's own event tracking can run through distinct integrations. A statement about authentication does not describe every request made around the same visit. Some activity may happen on other pages or through later server events. Establish which process generated each record.
Each integration must be present and active in the relevant configuration. Collection scope and timing differ between systems.
Please distinguish authentication data from advanced fraud signals, merchant analytics and other event collection. Which integrations were active, what did each collect, and which subsequent server-side transfers used those records?
Keep a separate line for each integration. Ask whether the explanation covers only the payment step or the wider visit and subsequent processing.
A request capture establishes a particular collection event. Similar timing does not establish identical payloads or shared purposes.
An operational account, a receiving customer record and a derived segment can have separate lifecycles. Removing the first does not by itself demonstrate what happened to the others. Deletion and suppression tools have specific coverage, so each destination and any continuing event collection need checking.
A separate copy or derived record must have been created. What survives depends on retention rules, tool coverage and destination processing.
Please distinguish account closure from deletion and suppression. What records or derived attributes remain, for how long and why? Which destinations were notified, and what confirms that the relevant deletion or correction was completed?
Compare the answer across the source and receiving organisations. Ask about surviving identifiers and renewed collection, as well as visible account access.
A completed action establishes its stated coverage. It does not establish deletion from systems outside that coverage.
In an illustrative rewards service, a valid claim supports fulfilment and a per-claim fee. The same account-linked events could also be counted, categorised and used to select a later offer. The fee and the information flow are separate things to examine; a fee alone does not reveal the use of the resulting records.
The secondary use needs accessible claim fields, a matching identifier and a configured calculation or audience rule.
Beyond fulfilling and charging for the claim, were its fields used to derive customer attributes, build audiences or select offers? Please identify the relevant records, recipients and purposes, and explain separately what the claim fee purchases.
Follow one claim into both the settlement record and the customer record. Compare the commercial description with the operational uses.
A receiving segment can establish profiling activity. A settlement fee on its own does not establish a data sale or that profiling occurred.
A feature can exist without being enabled. An enabled connection can fail, filter out an event or deliver data that the recipient does not use. Trace a specific event through each stage. Compare both ends and account for retries, duplicates and transformations before treating them as one completed chain.
The records must correspond to the same event and relevant account context. Logs need enough coverage to support the conclusion being drawn.
Please identify the records connecting this source event to its destination and subsequent use. Which stages are confirmed, failed, filtered or unrecorded, and what evidence supports each part of the explanation?
Maintain a short evidence table: stage, record, source, confirmed fact, unresolved question. Investigate the first unsupported connection.
A matched chain supports a specific route and use. Failed delivery or a different recipient can rule out that proposed route. An unexplained gap remains a question, not a finding of intent.
Search and copying run in this page. No question or search is sent anywhere.
A statement that internal fraud telemetry is not shared can be accurate about that dataset and still leave questions about other records unanswered. A merchant may hold overlapping checkout facts, receive selected risk results, or send its own events through a separate connector. Follow those fields into the receiving system to establish what was actually copied, inferred and used.
The technical hinge is the accessible field and its destination. A new name can obscure the origin of a record. It does not change the underlying facts, make a person unidentifiable or establish permission for a new use.
These four scenarios are constructed examples. The references below explain the individual technical building blocks. All identifiers, amounts, labels and rules in the interactive tool are invented. No raw processor telemetry is exported in this demonstration.
Follow a fictional merchant event through access, transformation, matching and use.
Select a stage to see what changes.
The switches test a particular technical route. Turning off its lookup does not establish anonymity; turning on a connector does not establish lawful reuse. Source records remain held when a downstream route is stopped.
| Starting information | Illustrative mapping | What the label leaves unanswered |
|---|---|---|
| Merchant product and campaign fields | product_category → interest_hint | Was this a separate collection of merchant data? A purchase fact is being turned into an inference. |
| An accessible payment risk result | risk_level → offer_candidate | Which result was disclosed, and who chose to use it for offers? A risk score is not a validated measure of customer value. |
| Partner records with a shared token | member_token → profile_ref | Who issued the token and held the lookup? A shared payment provider does not itself establish this join. |
| Valid reward claims | claim_count → redemption_band | Where did fulfilment or duplicate checking become segmentation? A per-claim service fee alone does not show a data sale. |
A merchant-controlled event can branch before reaching a payment service. Separately, a merchant can transform a result returned by that service. These routes have different origins: copying merchant inputs is not extracting the processor’s private inputs. A plugin cannot read a cross-origin payment frame or private server records merely because it is present on the page; any such access needs its own demonstrated mechanism.
Ordinary event middleware can transform fields and forward events to configured destinations. That capability makes the examples technically plausible. To establish an actual route, inspect the deployed configuration, permissions, event samples and receiving logs for the relevant period. Technical reference T3.
Payment platforms document merchant-visible risk outputs and reporting/export tools. The accessible schema, account scope and product entitlement determine what a particular export can contain. An export facility does not establish access to every raw signal that contributed to a score. T1 · T2 · T5.
A verified row leaving a system establishes that row’s transfer. A later profile with the same customer reference can support a connection, but the mapping and import history are needed to establish how its fields were produced. Similar totals, close timestamps or similar labels alone do not identify the route.
Changing risk_level into offer_candidate is more than moving a column if the receiving business uses it to choose offers. Conversely, copying an order reference into a CRM for customer support may remain part of the original service. The destination software’s name does not settle the purpose; examine the actual operation and decision.
Current ICO guidance requires assessment of further use under purpose limitation and an appropriate lawful basis. Renaming, pseudonymising or moving data abroad supplies no automatic permission. L4.
In example 03, the receiving organisation holds the token-to-profile lookup. It can therefore reconnect the record to a person. A recipient without that lookup must be assessed separately, including other reasonably available ways to identify someone. Hashing an email or replacing it with a token is not, by itself, proof of anonymity. L5.
Customer tools can associate a user identifier with attributes and send them to configured destinations. This documents a general integration capability, not access to another merchant’s customers. T4.
“Which source fields produced this record about me, which identifiers connect it to me, who received it, and what was it subsequently used to decide?”
Access through a dashboard or API is still access. The ICO’s controller-to-controller sharing code includes making data available through IT systems. Processing on a controller’s behalf and movement within one controller are distinct arrangements, with their own obligations. L3.
“Business capacity” does not remove personal-data status. Information relating to an identified or identifiable living person is personal data. Start with the information, its context and the person it relates to. A stock purchase for a company does not turn a named user’s account activity into company-only information. L8 · L9.
Person A works from home and places a stock order for Company C using a card issued in Person B’s name. In this example, the configured fraud tool records browser/device information and mouse-activity indicators from A’s checkout session. The payment details contain B’s cardholder name and billing address. The stock is for C.
The billing address does not locate the person operating the browser. A’s session activity and B’s cardholder details come from different sources. Trace whether the system associates the session with A’s user account, B’s card, or both—and whose profile receives any resulting assessment. The name on the card does not establish who performed every recorded action.
If B separately completes a banking-app authentication, that is another action to distinguish from A’s checkout activity. Mouse-activity collection is a feature of the fraud tool in this example; it is not a universal 3DS2 authentication field. T5 · T7.
| Record | Identity to establish | What to examine |
|---|---|---|
| Company registration number, stock quantities and purchasing account | The legal company and its order | Separate company-only facts from embedded named-user information. |
| Named checkout account and login history | The account user and, where established, the person operating it | Which account and session references link the activity to that person? |
| Browser/device information and recorded mouse-activity indicators | The checkout session and any person linked to that activity | Which account or session key connects the observations to A, B or both? Check whose profile receives the output. |
| IP or available device-location information | The connection or device context | Distinguish observed or estimated location from the supplied billing address; account for shared networks and location accuracy. |
| Cardholder name, billing address and payment-account details | The named cardholder and billing information supplied for the payment | The billing address is not proof of the checkout operator’s location. Keep the cardholder and operator separate unless their identity is established. |
| Authentication result and subsequent risk or profile labels | The transaction, authentication participant and subject of each assessment | Which input and identifier produced the result, and to whose record was it attached? |
EMV 3DS exchanges transaction, payment-method and device information to support authentication. Risk assessment can include device or IP-related context, and a challenge can involve the cardholder’s banking app. The exact fields and flow depend on the implementation. T6 · T7.
That gives a concrete route to investigate: checkout user → session and device → payment account → authentication result → any later assessment. A successful authentication does not, by itself, establish who physically operated every device or their precise location. Ask how the systems linked these roles and whether a later profile merged them incorrectly.
“The purchase was for a business and the checkout user was different from the named cardholder. My request concerns the personal information relating to my activity. Please distinguish browser/session observations, any mouse-activity indicators, cardholder and billing details, and authentication records. Which references linked those records, and whose profile received each resulting assessment? Please explain any attribution of my activity to the cardholder, any use of the billing address as my location, and any classification of my identifiable activity as company-only information.”
This is an anonymous teaching example. Information can relate to more than one person; the response must address the requester’s personal information and the rights of others. Company-only information and any applicable access exemption require their own assessment. L1 · L7.
A customer experiences one purchase. Behind it, the merchant, payment service and issuer may exchange several messages and retain different records. Shared fields or linked references can connect those records without every participant receiving one identical payload. T6.
The role follows the processing activity. “Payment processor” is a commercial description, not a complete GDPR role analysis. The same service can process some information on a merchant’s instructions and act as a controller for a separate purpose. Receiving the same fields does not automatically make two organisations joint controllers. L10 · L11.
| Processing operation | Who determines it in this example? | What a useful response addresses |
|---|---|---|
| Customer account and order administration | The merchant decides the purpose; it is the controller for that operation. | The personal order/account records it controls, including records held on its behalf. |
| A payment service acting only on documented instructions | The merchant is controller; the service acts as its processor for this operation. | The controller handles the SAR with the processor’s assistance. |
| A service’s separately determined security processing | The service determines that separate purpose and acts as controller for it. | The service addresses the relevant personal information it controls, subject to applicable limits. |
| Jointly determined processing, if established | Two parties jointly determine the relevant purposes and means. | Their arrangement must not prevent the person exercising rights against either controller. |
These are assumed roles for explanation. The ICO explains both operation-specific roles and responsibility for SAR responses. L10 · L1.
Ask which order, payment, authentication or customer references connect your records; what each party received or derived; and which purposes it controls. A referral can help locate another controller. It does not resolve the referring organisation’s own processing merely because another party also holds information.
“Please distinguish the processing you undertake as controller from processing performed on another controller’s instructions. Address the personal information for which you are responsible, including records held on your behalf. Where you refer part of my request elsewhere, please identify the relevant controller and explain which processing that referral covers. Please provide the applicable source and recipient information for my records.”
The useful challenge is to an unexplained gap in responsibility. It does not require proving that every party received identical bytes, nor asking one party to produce records it does not hold or control.
A privacy notice and a copy of your personal information answer different questions. A policy link can supply relevant supplementary information. It does not replace the personal data requested under Article 15. That can include observed activity and inferred attributes where they are personal information held about you. L1 · L2.
| Provision | What it addresses | Useful question |
|---|---|---|
| Article 13 | Privacy information when personal data is collected from the person, including through observation. | What are you collecting from my activity, and for which purposes? |
| Article 14 | Privacy information when personal data is obtained from another source, subject to applicable exceptions. | Which other sources supplied information about me? |
| Article 15 | Confirmation of processing, access to the person’s personal data and supplementary information. | What data and derived records do you actually hold about me? |
L6 · ICO notice guidance · L1 · ICO access guidance. The right belongs to an individual. Information arising from a business relationship can still relate to an identifiable person; company records are not automatically that person’s personal data.
EMV 3DS exchanges transaction, payment-method and device information for authentication. A receipt or account profile may not show all personal records created around that process. Article 15 applies independently of 3DS2. It was not created by the protocol.
Authentication messages, advanced fraud signals, merchant analytics and CRM imports are separate systems. The protocol does not mandate every tracking field mentioned in research, nor establish universal marketing access or tracking of every non-buying visitor.
Include relevant identifiers, assessments, derived labels and records held on the controller’s behalf. A controller’s response should address the request across the processing for which it is responsible, including help from its processors.
For an SME reviewing its suppliers, also ask which integrations are enabled, which fields each can read or export, how permissions are scoped, and whether source and purpose survive transformations. Request the relevant configuration history, data dictionary, retention rules and audit evidence through the appropriate contractual or review route. Those records can help test the explanation; Article 15 does not guarantee delivery of every underlying document.
The anonymous examples build on themes in FilmPass’s research. Current documentation supports the mechanisms below. For an earlier period, check the documentation and configuration applicable at that time.
Data-law update: follow the purpose and the actual use → Legislative context checked 21 October 2026.
Ask each organisation to identify its own role, the records it holds and which part of the explanation belongs elsewhere. Then reconcile the answers against the same order and payment references.
Explore the merchant, platform and processor example →