Data minimisation for document requests: a practical checklist

Data minimisation starts before a file is uploaded. Ask for the smallest document, page range, reporting period and level of detail that can support the decision you need to make.

"Send anything relevant" transfers the decision to the sender. They may provide a full statement when one page would do or a long contract containing unrelated information. The business then has to secure, review and delete material it never needed.

A precise request is better for both sides. The sender knows what will satisfy the process, and the team receives less sensitive information to handle.

Data minimisation is a design decision

Article 5 of the EU General Data Protection Regulation says personal data should be adequate, relevant and limited to what is necessary for the stated purposes. That principle applies to the request itself as well as later storage.

The European Data Protection Board's guidance on data protection by design and by default connects necessity to the amount collected, processing, storage period and accessibility. The default request should be narrow.

The US Federal Trade Commission reaches a similar operational conclusion in Start with Security: do not collect personal information you do not need, and keep information only while there is a legitimate business reason.

These sources do not tell every business which exact page to request. The organisation must make that decision based on its purpose, applicable law and the evidence the process genuinely requires.

Minimise four parts of every request

1. The document

Ask whether the decision requires a source document at all. A confirmation, reference number or recorded outcome from an approved system may be enough.

If the source document is required, name it. "Financial documents" is vague. "The account summary showing the account holder and June closing balance" gives the sender a target.

2. The pages

A document may contain dozens of pages while the process needs one. State the required page or section and whether unrelated pages may be omitted.

Allow redaction only when the process permits it. Say what may be hidden and what must remain visible.

3. The period

Specify a month, tax year, contract version or date range. An exact period avoids follow-up and years of unnecessary records.

4. The detail

Decide which fields must be visible. An age check may not need a full date of birth. An account-ownership check may not need transaction history. A signed agreement check may need the signature page and version identifier rather than every appendix.

The correct level depends on the task. Do not remove information required to make the decision accurately or meet a documented obligation.

Rewrite broad requests

Use this table as an editing exercise. The narrower versions are examples, not universal requirements.

Broad request	More precise request	Why it is easier to control
Send proof of identity	Upload one accepted identity document. Show the name, photograph and expiry date. You may cover unrelated identifiers if our stated process allows it.	Defines one document and the fields needed
Send recent bank statements	Upload the account summary page for June 2026 showing the account holder and closing balance. Transaction pages are not required.	Limits the period, pages and transaction disclosure
Send all documents relating to the contract	Upload the signed signature page and the page showing the contract date and version. We will ask separately if another clause is needed.	Avoids collecting unrelated schedules and correspondence
Send payroll information	Upload the payslip for the specified pay period showing employer, employee and gross pay. Other identifiers may be covered where permitted.	Names the evidence and fields
Send supporting evidence	Choose one document from the accepted list below that proves the stated fact. Do not upload additional evidence unless we ask.	Prevents duplicate evidence and speculative disclosure
Send your company records	Upload the named registration extract and current ownership page dated within the required period.	Replaces an undefined category with two items

Some processes will require the complete document. If so, say why in the internal record and tell the sender not to remove pages. Minimisation does not mean damaging the evidence. It means making the scope deliberate.

Start with the decision, then work backwards

Request owners often inherit a checklist and never ask why each item exists. Reverse the process.

Write the decision in one sentence: "We need to confirm that the named account belongs to the supplier before approving payment details." Then list the facts needed for that decision. Only after that should you choose the document that proves each fact.

Complete these prompts for every item:

The decision or action is: ___
This document proves: ___
The required page or section is: ___
The fields that must remain visible are: ___
The relevant period is: ___
An acceptable alternative is: ___
We can delete the intake copy when: ___
The official record we keep afterwards is: ___

If the team cannot complete the second prompt, remove the item. If several documents prove the same fact, choose one normal option and list alternatives.

Use conditional requests

Long universal checklists collect documents that only apply to a minority of people. Ask a short qualifying question first, then show the relevant request.

For example, a supplier process might ask whether payment will go to a personal or business account. The next request can match that answer. An employment process can wait until a candidate reaches the correct stage before requesting onboarding evidence. A client intake process can request an additional schedule only when the initial document shows that the schedule applies.

Keep qualifying questions factual. Test the logic so a wrong answer can be corrected without a support ticket that repeats private information.

Tell the sender what not to upload

People add extra files when they fear an incomplete submission will cause delay. Give them permission to stop.

Include lines such as:

Upload one document from the accepted list, not every document you have.
Only the named page is required.
Do not include passwords in the message or filename.
Do not upload payment-card security codes or account credentials.
Do not send health, criminal-offence or other specially protected information unless the request explicitly asks for it and the approved process covers it.
We will contact you through the stated channel if another item is needed.

The exclusions should match the service terms and process. A warning cannot make an unsuitable service appropriate for regulated data.

Write a request that can stand on its own

The sender may open an upload link days after the original conversation. The page should provide enough context without exposing private details in the URL or heading.

A request can follow this structure:

Purpose

We need the documents below to confirm {specific fact or complete specific task}.

What to upload

{one named document, page and period}

{second item only if independently necessary}

Accepted alternatives: {limited list}.

Do not upload: {clear exclusions}.

Who can review it

Authorised members of {team or organisation} can review your submission for this purpose.

Deletion

The intake copy is scheduled for deletion on {date or after stated period}. We may delete it sooner when the review is complete. Any record we are required to keep is handled under our separate retention policy.

Questions or corrections

Contact {approved channel} before uploading if the request does not match your circumstances.

Do not put a detailed case description, document list or personal data into a notification email. The message can direct the sender to the controlled request page.

Make alternatives comparable

Each accepted alternative should prove the same fact. Document:

The fact it proves
The required fields
The maximum acceptable age
Whether a partial page is accepted
What makes the copy unreadable or incomplete
Whether escalation is required

Avoid an open field that says "other document." It invites unpredictable formats and content. If the listed options do not fit, give the sender a contact route before upload.

Handle unexpected material safely

Even a precise request can receive extra pages or the wrong file. The reviewer should not download and circulate it while deciding what to do.

The procedure should:

Keep the submission in controlled intake.
Limit review to authorised people.
Record the error without copying contents into the log.
Request a corrected submission through the approved channel.
Delete the unnecessary item as soon as permitted.
Adjust wording if the same mistake recurs.

File validation and malware scanning answer whether a file is technically safe to process. They do not answer whether the business should have collected its contents.

Review the request with real submissions

Test the request with a colleague who does not run the process. Ask which file, page, period and fields they would provide. If two readers choose different evidence, revise the wording.

After launch, track non-sensitive operational signals:

Requests that need a follow-up
Submissions rejected as incomplete
Unexpected document categories
Repeated questions about redaction or accepted alternatives
Items deleted without being used

Do not put filenames, sender identities or contents into these metrics.

Review the list whenever the decision changes. A document may become redundant when an approved system supplies the result.

Connect collection to retention and access

After upload, limit access, avoid routine original downloads and set the deletion date.

The retention policy guide explains how to distinguish the temporary submission from an official record. The least-privilege checklist covers who should be able to view, print, download, extend or delete it.

The result is a shorter workflow: ask for defined evidence, review it for one purpose, record the outcome and remove the intake copy on schedule.

Frequently asked questions

Does data minimisation mean we can never ask for a full document?

No. A full document may be necessary to assess authenticity, context or a documented requirement. Record why the complete version is needed and avoid requesting extra documents that prove the same point without adding value.

Should we always allow people to redact documents?

No. Allow redaction only when the remaining information can support the decision and the applicable process permits it. Tell the sender exactly what may be covered. An unclear redaction policy creates rejected submissions and repeated disclosure.

Can we collect extra evidence now to avoid asking later?

Convenience alone does not show that the extra evidence is necessary. Use conditional requests when the later need can be identified. If there is a specific, documented reason to collect both items at once, explain it and apply an appropriate retention period.

Is choosing a short deletion period enough for data minimisation?

No. Retention and collection are separate controls. Deleting an unnecessary document after seven days still means the organisation collected and exposed it to review. Narrow the request first, then keep the accepted material only as long as needed.

What if a sender uploads more than we requested?

Keep the item inside the controlled workflow, restrict access, ask for a corrected submission when needed and delete the unnecessary material as soon as permitted. Do not move it into a permanent file merely because the business received it.

Who should approve a new document request?

The process owner should explain the purpose and evidence needed. The person responsible for privacy, legal or records obligations should review higher-risk categories and retention. Security or IT should confirm that the intake method can handle the proposed file types and access pattern.