A store export may not contain everything needed for a customer data request

Define the request before opening the export tool

Write down what the requester actually asked for and what the merchant's authorized response owner has accepted as the scope. A request for 'everything you hold about me' and a request for order history are different jobs with different coverage. Record the request's date, the channel it arrived through and the owner assigned to it; those three facts decide whose review the package needs before it leaves.

Resist the shortcut of exporting the store's customer record and treating the download as the response. An export reflects what one platform chose to include, with its own field selection and date coverage. It cannot describe help desk tickets, mailing-list state or provider-side payment records, and its completeness is a claim to verify, not a property of the file format.

Inventory the systems that can hold this person's records

List the systems your operation genuinely uses: the store's orders and customer accounts, the help desk or shared inbox, the email marketing platform, the payment provider's dashboard, fulfillment or shipping tools, and any archives or retained exports. For each, name the internal owner who can search it under authorized access. This inventory is about one person's request; do not turn it into a general data audit performed under time pressure.

The ICO's UK GDPR guidance on finding information for a subject access request says a reasonable and proportionate search may involve multiple systems, emails and archived records. That guidance is specific to the UK regime and does not itself create identical duties elsewhere, but its operational point travels: coverage is a property of the search you actually ran, not of the first export you found. Record which systems were searched, by whom and on what date.

Match records to the requester without sweeping up other people

Within each system, identify this person's records using the identifiers the business already associates with them: the account reference, the order references on file and the contact details already linked to the relationship. Where an identifier is shared, such as a company email or a household address, mark the match as uncertain rather than pulling every record that touches it into the package.

The coverage map must protect third parties at the same time. A support thread that quotes another customer, or a fulfillment record naming a different recipient, is not this requester's record simply because it appeared in the same search. Record such items as requiring review or separation; the response owner decides how they are handled, with qualified advice where the rule is unclear.

Have the response owner review coverage and omissions

Before delivery, the designated response owner compares the package against the coverage map: every system searched, every system consciously excluded, and every category withheld. A system nobody searched is an omission; a record deliberately withheld is a decision that needs a stated basis. The UK's ICO guidance makes clear that not everything a search surfaces is necessarily disclosable, but the exemptions and their application are legal questions for qualified review in the applicable jurisdiction, not for this worksheet.

Record gaps honestly, and treat them as work against the clock, not as a reason to stop it. Open gaps do not extend the applicable response deadline: the response owner determines how to give a timely and accurate response under the applicable rules, whether that means completing the search in time, applying any lawful extension those rules provide, or another step the rules permit, while the search continues. What the owner must never do is describe a partial package as complete, because that closes the request on a false representation.

Deliver through the authorized channel and keep the index

Send the package through the merchant's approved delivery process, to the verified contact for the request, and retain an index of what was provided: systems covered, date ranges, formats and exclusions. The index lets a later question be answered without reassembling the search, and it records that the package reflects the search as it existed on the delivery date, not all information the business will ever hold.

If recurring requests expose that your public privacy page describes data handling your systems do not actually perform, a Prism website review can examine that public wording within an agreed scope; responsibilities, fees and terms are confirmed before work. The review does not assemble request packages or decide legal duties.

Customer-request coverage map

Complete one map per request, using internal system names and non-sensitive references. A system counts as covered only when a named owner searched it and recorded the result; unresolved rows stay open until the response owner signs off the package.

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.