The Access Request That Revealed a Bigger Problem
A customer emails asking for a copy of all data you hold about them and, in the same message, mentions that they were able to see another customer's order history in your portal last week after a page refresh. You are the privacy lead at a mid-size e-commerce company. Your access-request workflow is a shared inbox monitored by two support agents who use a checklist; median turnaround is 34 days against a 30-day statutory deadline. The portal was rebuilt eight months ago by a contractor; no privacy review was performed on the rebuild. Your engineering team says the order-history page 'uses a session token, so it should be fine.' You have no logging on that endpoint. The customer has not threatened to complain to a regulator.
1. Separate this into its components and sequence your response.
Read the worked answer
There are three distinct matters tangled in one email; untangling them is the first task.
Components:
- Access request - a statutory obligation with a 30-day clock, and your median is already 34 days.
- Potential unauthorized access - the customer saw another person's order history. If confirmed, that is a personal data breach affecting a third party who does not yet know.
- Design defect - a portal rebuilt without privacy review, with no logging on the affected endpoint.
Sequence:
- Preserve and investigate the access issue first. Breach clocks may run from awareness; the access request clock is already at risk and will not be helped by delay, but the breach question may carry its own short deadline and a duty to the other customer.
- Acknowledge the access request in writing immediately, confirm receipt and the date, and start the clock formally. This protects you on the deadline even while investigation proceeds.
- Do not tell the customer 'it should be fine.' Engineering's session-token answer is a hypothesis, not a finding. Ask for a specific test: reproduce the refresh scenario, check whether the token is scoped to the user, and inspect cache behavior.
- Assess the third-party customer's exposure - whose order history, how much, whether it includes address or payment fragments.
Why this order: the access request is a known, dated obligation you can control; the access issue is an unknown with potentially shorter clocks and a duty to a person who has not contacted you.
2. The access request is already missing the statutory deadline on average. How do you handle this one and fix the workflow?
Read the worked answer
Handle the individual case and the systemic defect separately - the customer is entitled to both.
This request:
- Acknowledge in writing on day 1, log the date, and assign a named owner rather than the shared inbox.
- Because the request is entangled with a potential incident, respond within the deadline even if the incident investigation is ongoing - you can provide the access response and note that a related security matter is under review without disclosing the other customer's data.
- If you cannot meet the deadline, communicate before it lapses, state the reason and a date, and document the extension basis if your jurisdiction permits one.
Workflow fix:
- A 34-day median against a 30-day deadline is a systemic failure, not an outlier. The shared inbox with a checklist has no queue ownership, no aging visibility, and no escalation trigger.
- Move to a ticketing system with automatic clock start on receipt, aging alerts at day 15 and day 25, and escalation to the privacy officer at day 25.
- Define identity verification steps so agents are not stalling on verification ambiguity.
- Track and report median and 90th-percentile turnaround monthly.
Root cause: two agents and a checklist is a staffing and tooling decision, not a process. Fixing the checklist alone will not move the median.
3. Engineering wants to close the portal issue as 'no evidence of exploitation.' How do you respond, and what do you do about the other customer?
Read the worked answer
'No evidence' is not the same as 'no incident,' and the distinction matters here because you have no logging on the endpoint - absence of evidence is manufactured by the absence of logs.
Responding to engineering:
- The customer's report is itself evidence. A user describing a specific behavior (page refresh, saw another's order history) is a credible signal that must be tested, not dismissed.
- 'Uses a session token' does not answer the question. The questions are: is the token bound to the requesting user, is the order-history response cached at a shared layer, and can a refresh serve a cached response belonging to another session?
- Without endpoint logging you cannot determine scope. That is a finding in itself and should be remediated regardless of outcome.
The other customer:
- If the report is credible, that person's data may have been exposed and they have not been told. Assess whether your jurisdiction requires notification to affected individuals and, if the exposure is significant, to a regulator.
- You cannot identify them from your own logs (there are none), which is precisely why you need the reporting customer's cooperation - ask what they saw (order number, name fragment) to scope the affected record, while being careful not to collect more of the third party's data than necessary.
- Do not contact the third party with speculation; contact them once you have a scoped finding and a clear description of what was exposed.
Program-level: the missing privacy review on the rebuild is the upstream cause. Add a privacy review gate to the engineering change process so the next rebuild does not repeat it.