A customer data export contains another person's information

Stop at the point the export becomes mixed

This page starts after the request has been verified and the correct systems have been searched. The remaining problem is not a missing record; it is a real shared order, household shipment, joint support thread, copied message or team note that names or identifies someone besides the requester. Preserve the original export unchanged in restricted storage and work from a review copy with an internal reference.

Do not resolve the issue by deleting the other person from the original, exporting everything because the record was correctly located, or refusing the entire request because one field is mixed. Keep three outcomes available: information that is the requester's, information that is another person's, and information whose attribution or identifiability is uncertain. Uncertain fields stay unresolved until the authorized reviewer decides them.

Separate fields by person, purpose and identifiability

Review the export field by field rather than document by document. A billing name may be the requester while a delivery recipient is not; a support ticket may contain the requester's question and a third party's reply; an order note may identify a researcher, purchasing contact or recipient who did not make the request. Record categories and locations only, not the sensitive values themselves.

Assess whether removing a name actually prevents identification. UK ICO guidance on other people in subject access requests treats these as contextual decisions involving disclosure, confidentiality and redaction, and it warns that deleting a name may not stop someone being identified. That guidance is UK-specific; it supports careful reasoning, not a universal rule that every mixed field is released or withheld. For other jurisdictions, identify the applicable framework with qualified privacy review.

Use context instead of a blanket rule

For each mixed field, record why the third-party information is present, whether the requester already knows it, whether it is confidential to the third party, whether consent exists, and what harm or unfairness could follow disclosure. Also record whether the response can remain meaningful without that field. These are reasons to weigh, not automatic answers, and no universal deadline or automatic right is supplied here.

Where the balance is unclear, escalate before release to the role your organization has designated for privacy decisions and to qualified counsel where legal rights or exemptions are involved. Keep the requester's need for their own information in view: a third-party problem in one field should not unnecessarily block clearly releasable requester fields. The response copy should be as complete as the authorized decision supports, not as large as the raw export.

Prepare an authorized response copy with reasons

Create the response copy only after the mixed-field decisions are recorded. Use the minimum effective treatment for each field: include, summarize, omit, or contextually redact, according to the authorized decision. Preserve enough context that the requester can understand their own transaction or ticket, while avoiding disclosure of another person's confidential details. Do not use a visual cover-up that leaves the underlying text selectable or embedded.

Record the reason for each treatment beside the field category: requester's own information, third-party information withheld for confidentiality, uncertain field escalated, or identifying detail removed where context still identifies someone. Have the designated approver check the actual file to be sent, including attachments, comments and metadata where relevant. A draft, an approval and the released copy are three different states.

Close with delivery, exceptions and scope left visible

Send the approved copy through the channel your privacy procedure authorizes and keep a delivery record naming request reference, date, copy version and approver. If information was withheld or a field was left unresolved, state that a limitation was applied without exposing the third party's confidential content. Record any advice source and jurisdiction assumption used for the decision.

Keep this process separate from provider evidence and storefront review. A payment provider's later questions are not answered by a customer export, and Prism's public inquiry form is not a place for requester files, customer records, identity documents or third-party personal data. If a website representation issue is connected, Prism can discuss public pages and a non-sensitive summary in a scoped consultation; scope, responsibilities, fees and terms are confirmed before work.

Mixed-person response worksheet

Use one worksheet per request and record category decisions only. Never paste requester files, third-party personal data, identity documents, card data, passwords or customer lists into the sheet.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.