The extra export: how support quietly creates a second customer database

One refund case has accumulated a thousand-row spreadsheet, an identity-document screenshot and a forwarded conversation. Each file contains a useful detail, so nobody sees themselves as creating a leak. Yet the team has created several new stores of customer data. Reduce this risk by redesigning routine support work, not just by telling people to be careful.

For payment operators, data protection becomes practical when each record has a clear job. Start by asking what a person needs to complete a task, where that information should live and when it should stop being available.

Map the task before choosing the fields

Consider three tasks: answering a refund query, reviewing an onboarding case and diagnosing a failed notification. They involve the same business, but should not automatically expose the same information.

A proposed support view might show an internal customer reference, payment identifier, amount, status and refund progress. The onboarding evidence belongs in a more restricted workflow. A diagnostic event might need a timestamp, event type and correlation identifier, without copying the original customer submission.

Where UK GDPR applies, the ICO describes data minimisation as keeping personal data adequate, relevant and limited to what is necessary for the purpose. That is a scoped legal principle; the field design above is an operational example, not a universal legal checklist. ICO guidance on data minimisation.

Make the easy path the safer path

In the hypothetical refund case, give support a link to the authorised transaction view rather than a downloaded spreadsheet. Provide a structured escalation form asking for the relevant reference and a short description. If a specialist genuinely needs more evidence, let the access request identify that need.

A practical design test is to ask a new employee to resolve the ticket using only the normal interface. If they must export hundreds of rows to find one refund, the tool is pushing them toward excessive copying. Fixing that workflow can matter more than another reminder to “be careful.”

Keep test and training examples synthetic where possible. If an actual case is necessary for a controlled review, remove unrelated details and limit its audience. Replacing a name with an internal identifier does not automatically make a record anonymous.

Do not let logs become a second customer database

OWASP’s logging guidance recommends excluding or appropriately protecting secrets and sensitive data rather than recording them directly. This includes access tokens, passwords and payment-related data. OWASP Logging Cheat Sheet.

Translate that into a field allowlist for each event. For example, a failed callback can record the event identifier, error class and processing result. Decide separately whether additional fields are necessary. Avoid making complete request-body logging the default simply because it is convenient during debugging.

Test the failure paths as carefully as successful payments. An exception message, support attachment or diagnostic export may carry data that the main application hides. Include those outputs in review before a release, and check that temporary debugging settings are removed afterward.

For merchants and their processing systems, card verification codes must not be retained after authorisation under PCI DSS, including in encrypted form. A customer’s permission does not remove that restriction. PCI SSC’s explanation.

Give retention a reason and an owner

There is no single retention number suitable for every payment record. The ICO notes that UK GDPR does not prescribe specific periods for every data type; organisations must justify retention against their purposes. Other applicable obligations can require particular records to be retained. ICO guidance on storage limitation.

Create a schedule by record category, identifying the purpose, responsible owner, applicable requirement, starting event and deletion or review action. Have qualified legal and compliance staff resolve conflicts. A support attachment and an accounting record need not follow identical rules just because they mention the same payment.

An export should explain why it exists

A useful interface test is whether an operator can hand a disputed payment to a colleague through one appropriately permissioned record link. If so, an export usually needs a separate justification. If not, people will create portable copies because the work cannot otherwise proceed. A prohibition without a usable workflow rarely removes the cause.

For a necessary export, define the fields, audience, storage location and deletion condition in advance. Row limits and expiring links may reduce the impact of mistakes, but do not replace recipient checks. Keep sensitive details out of filenames: notifications, recent-file lists and sharing logs can expose them. Use a neutral case reference.

Test deletion through the recovery path

Create a synthetic record in a training exercise and follow its copies through the normal workflow: support case, export, log, analytics store and backup. Then apply the approved retention-ending policy. The aim is to test your process, not to imply that every category of data may be deleted immediately.

Ask how restoration from backup will respect restrictions or deletions already applied. The answer depends on architecture and lawful obligations and needs to be agreed beforehand. Otherwise a routine technical recovery may return information to ordinary access after it had been removed. A process owner should be accountable for that outcome rather than an incidental support employee with a folder of old exports.

Start with one frequent support case. Remove one unnecessary export and verify that the operator can still resolve it. That change reduces copies while making the safer workflow the shortest one.