Customer receives another customer's data

What this means

Treat this as a personal data incident until you prove otherwise.

The first report may mention one file and one recipient. The real problem can be wider. The same export job may have run for other customers. A download link may have been opened more than once. A support attachment may have been forwarded. A cache may have served the same file to several accounts.

Your job is to answer four questions:

1. What data left the correct customer boundary?
2. Who could receive or open it?
3. What harm could the data cause?
4. Has the same failure happened anywhere else?

Do not promise that the incident is contained before you can answer those questions.

If the data includes passwords, authentication tokens, payment information, government identifiers, health information, information about children, private communications, or other highly sensitive data, contact qualified security and privacy counsel immediately.

Warning signs

• A customer sees another person, company, invoice, order, or account in an export.
• A generated filename contains the wrong customer name or tenant ID.
• The export request belongs to one tenant, but the output rows belong to another.
• A download link works after the intended user signs out.
• A support agent attaches a file from the wrong conversation.
• A background job uses tenant context from a previous job.
• Two customers receive files with the same object-storage key.
• A cache key contains an export ID but no tenant ID.
• An administrator can generate exports without selecting or confirming the customer.
• Export logs record the request but not the resolved tenant, file, recipient, or download.

Recover now

First 15 minutes

1. Open an incident record and start a UTC timeline. Record who reported the problem, the exact discovery time, the affected customer, the unintended recipient, the file or link, and every action you take. This establishes the investigation record and helps track legal deadlines.

2. Disable the smallest unsafe path. Pause the affected export type, report template, support macro, attachment workflow, or download route. If you cannot isolate it safely, disable all customer exports temporarily. Confirm a fresh request can no longer produce or retrieve a file.

3. Expire access without destroying evidence. Revoke signed URLs, sharing tokens, CDN links, and application download sessions. Remove public access from the object. Do not delete the only copy, job record, or access log. Move the affected artifact to a restricted evidence location when necessary.

4. Preserve the original artifact securely. Save the exact file, filename, object key, export ID, request ID, template version, code version, and a cryptographic hash. Restrict this evidence to the incident team. Do not paste customer data into chat, tickets, or screenshots.

5. Preserve logs before retention removes them. Protect application, job queue, database, object storage, CDN, email, support, identity, and audit logs covering the likely exposure window. Record time zones and known clock differences.

6. Contact the unintended recipient through a trusted channel. Ask them not to open, use, copy, or forward the data. Ask whether they downloaded, viewed, printed, synced, or shared it. Request secure deletion from downloads, email, trash, synced folders, and backups they control. Their confirmation reduces uncertainty; it does not erase the fact that disclosure occurred.

7. Notify the incident owner and privacy decision-maker. Start the legal and contractual review now. Some laws start notification clocks when the organization becomes aware of a breach, not when the investigation finishes.

Build the scope table

Create one row for every known or suspected disclosure:

Do not collapse “sent,” “delivered,” “opened,” and “downloaded” into one status. They mean different things.

Today

1. Find the first possible bad export. Start with the last known-good code, template, query, cache, support process, or worker deployment. Expand the search earlier if the defect may have existed before that point.

2. Search for every affected execution. Query export jobs by template version, code version, worker release, query name, storage prefix, recipient domain, and mismatch between requested and resolved tenant IDs. Include failed and retried jobs.

3. Trace every copy. Follow the artifact into object storage, CDN caches, email attachments, support tickets, browser downloads, audit exports, backups, analytics events, and employee devices. Record which copies you can revoke and which require recipient action.

4. Determine whether the recipient accessed the data. Use delivery, open, download, CDN, and object-access logs where available. Be precise:

   • “We found no download event in retained logs” is supportable.
   • “Nobody accessed the file” is not supportable when logs are missing.

5. Classify the exposed data. List the exact fields. Do not write “customer information.” Separate names, email addresses, billing history, support conversations, credentials, financial information, health data, identifiers, and private files.

6. Count people and organizations separately. One export sent to one company can still contain data about thousands of people.

7. Identify the failure mode. Common causes include:

   • a query missing tenant_id;
   • tenant context taken from the request body instead of the authenticated identity;
   • a cache key shared across tenants;
   • a storage object key reused by another export;
   • a signed URL that checks possession but not current authorization;
   • a background worker reusing stale context;
   • an administrator choosing the wrong customer;
   • a support agent attaching the wrong local file.

8. Fix the failure in a controlled environment. Add the tenant boundary at the lowest reliable layer. A UI check is not enough. The database query, repository, storage path, cache key, and download handler must all enforce the correct customer context.

9. Test old links after the fix. Verify the application, CDN, object store, and direct URL all reject revoked artifacts. Test in a signed-out browser and as a user from another tenant.

10. Make the notification decision with qualified advice. Consider applicable privacy law, contracts, data-processing agreements, insurance requirements, industry rules, and customer commitments. You may need to notify a regulator, affected customer, affected individuals, insurer, payment provider, or another business.

Assess likely harm

Use this table to structure the decision. It is not a substitute for legal advice.

If GDPR or UK GDPR applies, certain personal data breaches must be reported to the relevant supervisory authority within 72 hours of awareness where feasible. High-risk breaches may also require communication to affected individuals without undue delay. Other jurisdictions and contracts have different thresholds and deadlines.

Communicate with the unintended recipient

Use a message like this after confirming the correct contact:

We sent you a file that was not intended for your organization. Please do not open, use, copy, or forward it.

If you already opened or downloaded it, tell us which actions you took. Please delete every copy you control, including downloads, email attachments, trash, and synced folders, then confirm deletion in writing.

We have disabled the original link. Reply to [incident contact] or call [number] if you need help.

Do not send another copy of the exposed data to identify it. Use the filename, delivery time, and message subject.

Communicate with the affected customer

Have privacy counsel review the message when legal duties may apply. A useful notice answers:

• What happened?
• When did it happen and when did you discover it?
• What exact data was involved?
• Who received or could access it?
• What have you confirmed about access?
• What did you do to contain it?
• What should the customer or individual do now?
• When is the next update?
• Who can answer questions?

Separate facts from unknowns. Say “we are still determining whether the file was downloaded” instead of filling the gap with reassurance.

Verify recovery

• A user from Tenant A cannot request, list, download, or infer an export belonging to Tenant B.
• Export queries include the authenticated tenant at the data-access layer.
• Cache keys include tenant and authorization-relevant context.
• Storage paths cannot collide across tenants.
• Signed links expire, cannot be reused after revocation, and do not bypass current authorization where current authorization is required.
• Background workers receive immutable tenant context per job and clear it before the next job.
• Old links fail at the application, CDN, and object-storage layers.
• The affected export template works for authorized users.
• Replayed and retried jobs do not send duplicate files.
• Every suspected execution has a documented outcome.
• Every exposed data field, person, organization, and recipient is counted or explicitly marked unknown.
• Legal, contractual, insurance, regulator, customer, and individual notification decisions are recorded with an owner and deadline.
• Monitoring covers tenant mismatches, unusual export volume, repeated downloads, and authorization failures.

After recovery

Write an incident report while the details are fresh. Include:

• the detection source and timeline;
• the first and last affected execution;
• the root cause and contributing controls that failed;
• every affected tenant, person, artifact, and recipient;
• evidence that reduced or increased likely harm;
• containment and deletion confirmations;
• notification decisions and copies of notices;
• the permanent technical fix;
• tests added;
• owners and dates for remaining work.

Keep the report and breach decision record for the period required by your laws, contracts, and internal policy.

Prepare now

Tenant isolation

• The backend derives tenant_id from the authenticated identity or trusted server context, never from an untrusted request field.
• Every export query filters by tenant at the shared data-access layer.
• Database row-level security or an equivalent second control protects the highest-risk tenant tables.
• Cache keys include tenant ID, user authorization scope, export version, and relevant parameters.
• Object-storage paths include a non-guessable tenant namespace and unique artifact ID.
• Every download request verifies the current user’s access to the export.
• Administrative cross-tenant access is explicit, time-limited where possible, and logged.

Export safety

• The confirmation screen shows customer name, tenant ID, record count, date range, fields, and recipient before generation or delivery.
• High-risk exports require a second confirmation or reviewer.
• Generated files use unique names and cannot overwrite another customer’s artifact.
• Links have short expiry, can be revoked, and are never written to analytics or referrer logs.
• Email delivery is separate from file generation, so the recipient can be rechecked before sending.
• Support agents attach files from a controlled picker, not an unrestricted local file chooser.
• Test and staging exports contain generated data rather than copied production records.

Evidence and detection

• Each export records request ID, authenticated user, intended tenant, resolved tenant, query version, artifact ID, recipient, and row count.
• Creation, delivery, open, download, revocation, and deletion are separate audit events.
• Export audit logs are stored outside the application database and retained for the defined investigation period.
• An alert fires when requested, resolved, artifact, and recipient tenant IDs do not agree.
• An alert fires on unusual export volume, size, frequency, or recipient changes.
• The team knows exactly how long email, CDN, object, and application access logs are retained.

Response ownership

• One named person can disable exports without deploying code.
• One named person owns privacy risk and notification decisions.
• Security, privacy counsel, insurer, regulator, and customer communication routes are recorded outside the affected system.
• A pre-approved recipient deletion request and customer holding message are ready.
• The breach record includes awareness time, decision deadlines, evidence, and notification status.

Practice

• Automated tests create Tenant Alpha and Tenant Beta, generate an export for Alpha, and prove Beta cannot list or download it.
• Tests repeat the same export through browser, API, background job, cache hit, expired link, revoked link, and administrator paths.
• A tabletop drill traces one synthetic export from request to storage, delivery, download, revocation, scope assessment, and customer message.
• A second person can find every related audit event and disable the export path within 15 minutes.

Common mistakes

• Treating one recipient as one affected person. The file may contain records about many people.
• Deleting the file before preserving evidence. You lose the artifact, hash, metadata, and a reliable basis for scoping.
• Accepting deletion confirmation as proof that no breach happened. It can reduce risk, but the disclosure still occurred.
• Checking only the visible export endpoint. Caches, background jobs, admin tools, APIs, support tools, and direct object links may use different paths.
• Fixing the UI but not the authorization layer. A hidden button does not protect the underlying object.
• Waiting for perfect scope before starting notification review. Some clocks begin when you become aware of the breach.
• Using vague language with customers. “Some information may have been involved” prevents people from making useful protective decisions.
• Adding tenant IDs to logs but not access decisions. Better evidence does not prevent another cross-tenant disclosure.

Sources

• NIST: Incident Response Recommendations and Considerations
• FTC: Data Breach Response — A Guide for Business
• ICO: Personal data breaches — a guide
• ICO: Personal data breach self-assessment
• EU GDPR: Articles 33 and 34
• OWASP: Multi-Tenant Security Cheat Sheet
• OWASP: Authorization Cheat Sheet
• OWASP: Authorization Regression Testing