Do you need to share the whole receipt?

Someone asks for a payment receipt. Before deciding what to send, confirm whom you are answering. The risk may lie both in the information exposed by the file and in a request impersonating a familiar person or organisation. After that trust check, ask: for this purpose and this recipient, is the whole document necessary?

In Brazil, the LGPD’s necessity principle limits processing to information relevant and proportionate to its purpose. It provides context for thinking about disclosure here, without automatically determining the legal duty in every private conversation or another country. [1, Article 6(III)]

Attack in focus: targeted phishing for information

Phishing uses deceptive communication to induce an action or obtain information. When aimed at a particular person or context, it is targeted phishing, or spearphishing. Here the focus is phishing for information, described by MITRE ATT&CK as T1598: the objective is collecting data, not necessarily running malicious software. The false role or justification presented in the request is its pretext. [5–7]

Here T1598 describes gathering information useful for later targeting; it is not a universal phishing code. MITRE T1566 concerns phishing for initial access, often involving delivery of malicious code. That second objective is not demonstrated by the fictional request below.

Fictional scenario: someone messages you claiming to organise an activity, mentions an expense and demands the full receipt “now”. You recognise the expense, but the channel is unexpected.

Exploited weakness: trusting apparent identity and urgency without verifying the request, while sharing more data than its purpose requires. This is a process and trust weakness, not a software CVE.
Possible consequence: disclosing personal information to an impostor. The data may provide context for later approaches; the example does not establish a real incident or show that a receipt alone grants account access.
Defence: reach the organiser through an already known channel and agree on what needs sending. If suspicious, do not rely solely on contact details supplied in the message itself. [6]
Verification: check the request/recipient and the final file separately. A sanitised copy does not authenticate its requester; recognising a name does not establish that an attachment is safe.

A legitimate request may require the full document through an appropriate channel. The control is making an adequately informed decision, not treating every request as a scam.

First agree on what needs confirming

Reporting an amount, answering a payment query and supplying a document required in a dispute are different situations. Avoid fixed rules such as “always remove this field”. What is necessary depends on the request, recipient and applicable requirements.

A reduced copy should limit disclosure without distorting what happened. Oversharing beyond the agreed purpose and making the document misleading are different failures; avoid both.

An entirely fictional example

In an activity-planning exercise, a person needs to tell the organiser about an expense of 42 example units on 15 October 2026. Both have agreed that a message stating the date and amount is enough. In this invented situation, no receipt attachment is needed.

If the organiser asks for a copy, the person first clarifies which details are required. The table is an editorial model, not a bank form or evidence of payment.

Example field — all values invented	Decision for the agreed purpose
Date and amount	Keep truthful and readable because these are the details being confirmed.
Description “activity materials”	Keep it if needed to identify the expense.
Identifier “EXAMPLE-NOT-VALID”	Assess whether it is needed; do not assume a real transaction identifier is unnecessary.
Additional personal details	Assess each one; if unnecessary and a reduced copy is accepted, remove them from that copy.

Every field is invented. No payment system’s layout or requirements are reproduced. The example does not establish receipt of funds, authenticity or settlement of a transaction.

Removing information differs from covering it on screen

A rectangle over PDF text can leave the information recoverable. Blurring and pixelation can also fail. ICO guidance distinguishes visual concealment from effective removal and describes, for images, opaque masking followed by export to a simple file without layers or editing history. This does not make every export automatically safe. [2, “Why is redaction a risk?” and “How do we redact images?”]

For a PDF, use a removal process appropriate to the format. The supplier documentation consulted distinguishes marking content, applying removal and saving, with an option to sanitise the file, meaning to remove hidden information. This workflow belongs to a specific product; do not assume every PDF reader can permanently remove content. Do not mistake a review mark for the finished version. Understanding this distinction does not require purchasing that product; whatever tool is available needs an appropriate, verifiable process. [3]

A check that exposes a failure: if you can still search for or copy a term that should have been removed from the final PDF, that information remains. Failing to find the term, however, does not establish that the whole file is free of hidden information. [2]

For this example, the proposed routine is:

Preserve the original. Work on a labelled copy and note its sharing purpose. ICO guidance also recommends separating and identifying the versions. [4]
Match the process to the file. For an image, use a workflow that removes the relevant pixels from the exported copy; for a PDF, use effective removal and consider hidden information. If you cannot verify the result, agree on another form of confirmation before sending. [2–3]
Reopen the final file. Check that the date, amount, necessary context and redaction markers remain correct. Searching and copying PDF text can reveal a failure, but passing those checks does not by itself certify that all hidden information has been removed. [2,4]
Check recipient and attachment. In the exercise, the organiser receives the agreed copy; the whole group does not accidentally receive the original. This is a proposed practical check, not a reported incident.

Limits and the final decision

A reduced copy must not change the amount, recipient, date or status to suggest a different outcome. If an institution or procedure requires a particular detail or the full document, clarify the requirement and appropriate channel; this guide does not authorise withholding required evidence. Do not modify a signed original and present it as untouched.

Removing fields does not guarantee anonymity: remaining context may identify people. The ICO guidance was written for organisations and is flagged as under review; we use its technical distinctions without treating UK duties as universal obligations. [2,4]

Before sending: confirm identity and channel, purpose and necessary details. If suspicious, verify the request by another means before replying. Share only a final version you can explain and check. Sanitising a file does not authenticate the person who requested it.

References

[1] BRAZIL. Law No. 13,709 of 14 August 2018 — General Personal Data Protection Law (LGPD). Consolidated Portuguese text, Article 6(III). Planalto. Accessed 17 October 2026. English description here is an editorial paraphrase, not an official translation.

[2] INFORMATION COMMISSIONER’S OFFICE. How do we avoid an accidental breach when redacting information? Part of the secure-document-disclosure guidance published on 31 July 2025 and flagged as under review. ICO. Accessed 17 October 2026.

[3] ADOBE. Redact sensitive content in Acrobat Pro. Updated 31 August 2026. Applying redactions and the sanitisation option. Adobe. Accessed 17 October 2026.

[4] INFORMATION COMMISSIONER’S OFFICE. Checklist: How to avoid an accidental breach when redacting documents. Sections on copies, labelling and checking. ICO. Accessed 17 October 2026.

[5] NIST. Phishing — CSRC glossary. NIST. Accessed 17 October 2026.

[6] MICROSOFT. Protect yourself from phishing. Recognising suspicious requests and verifying through official contacts or another means. Microsoft. Accessed 17 October 2026.

[7] MITRE. Phishing for Information — T1598. ATT&CK. Accessed 17 October 2026.