How to collect sensitive documents without email attachments

Sensitive document collection works best as a short, deliberate process: ask for specific files, send one upload link, limit who can review them, set a deletion date, and close the submission when the work is complete.

Email can move a file from one person to another, but an inbox is a poor place to manage the file afterwards. Attachments are easy to forward, download and forget. Copies may remain in Sent folders, shared mailboxes, local devices and backups long after the original request has been resolved.

In brief: use email to send the request, not the documents. Put the upload link, purpose, document list, review window and contact route in the message. Keep the received files in a separate intake workspace with controlled access and a deletion date.

This guide gives you a complete workflow that can be adapted to client onboarding, recruitment, accounting, supplier checks and other business processes. It is operational guidance, not a substitute for the legal or professional retention rules that apply to your organisation.

Define the finish line before requesting a file

Begin with the decision or task that the documents support. “Complete the supplier check” is a finish line. “Collect supplier documents” is not, because it says nothing about when the files stop being useful.

Write down five things before opening intake:

This small exercise prevents a common mistake: collecting a broad folder of documents first and deciding what to do with it later.

The European Data Protection Board lists purpose limitation, data minimisation and storage limitation among the core data-protection principles. Whatever law applies to you, defining the purpose before collection is also good operations. It gives the sender a clearer request and gives your team a clear point at which the temporary copy is no longer needed.

Ask only for what the process needs

List the exact documents, pages and date ranges required. Avoid requests such as “send all relevant financial information” or “attach anything that might support your application.” The sender cannot know what will be useful, so they may disclose much more than your reviewer needs.

A narrow request should explain:

• The exact document or pages required
• The relevant date or reporting period
• Whether the sender may redact unrelated information
• The accepted file types and size limit
• Why the evidence is needed
• The date by which it should be provided

The ICO describes data minimisation as keeping personal data adequate, relevant and limited to what is necessary for the stated purpose. Its data minimisation checklist also calls for periodic review and deletion of information that is no longer needed.

Use the more detailed data minimisation checklist for document requests when a team is deciding whether it really needs a full document, a particular page, or only one field from it.

Give every sender one intake point

A dedicated upload link is usually the simplest route. The sender opens the page, enters an email address, selects the requested files and receives a receipt. Your normal inbox carries the request and status notification, but not the document itself.

This separation reduces routine attachment copies and makes the collection process easier to monitor. It also gives the organisation one place to apply file checks, access rules and deletion timing.

A dedicated document email address can remain available as a fallback. It has an important limitation: the sender's message and attachments may remain in their mailbox, email provider and backups. Removing a file from the intake workspace cannot remove those external copies.

Standard email is not automatically unlawful or unsuitable for every file. The right choice depends on the sensitivity, consequences of disclosure, recipients and controls around the mailbox. Our upload portal and email attachment comparison shows the tradeoffs without pretending that one channel solves every risk.

Whichever route you choose, avoid collecting sensitive files through individual employees' inboxes. Staff changes, holidays, forwarded conversations and personal filing habits make those inboxes difficult to govern consistently.

Tell the sender what will happen

A secure transfer page does not replace a clear request. Before the sender uploads anything, tell them who is collecting the documents, why they are needed, who can review them, how long the intake copy is expected to remain and how to ask for a correction or deletion.

The ICO guidance on the right to be informed explains the privacy information organisations should provide when collecting personal data. Your exact notice depends on your role and legal basis, so use your approved privacy language rather than copying a generic compliance statement.

This short request format is a useful starting point:

Please upload the requested documents using the link below:

{upload_link}

We need these files to {specific purpose}:

• {document or page one}
• {document or page two}
• {document or page three}

Please provide them by {date}. Accepted files: {formats and limits}.

The documents will be available to authorised members of {organisation or team}. We expect to finish this review within {working period}, after which the temporary intake copies are scheduled for deletion. Contact {route} if you need to correct or withdraw your submission. Read our privacy information: {privacy_notice_link}.

Do not include personal data, document names or confidential details in the email subject. “Documents requested by North Street Advisory” is safer than “Passport and bank statements needed for Jane Smith.”

Review without routinely copying originals

Most day-to-day review does not require another copy of the original file. A browser view can let an authorised reviewer inspect the contents without automatically adding the source document to a laptop's Downloads folder.

Sunset Docs converts accepted files into watermarked page images for browser viewing. In view-only mode, the original file is not delivered to the browser. Authorised reviewers can produce an audited, watermarked print, while only the workspace owner can allow an original download when the work genuinely requires it.

This boundary reduces routine copying, but it is not digital rights management. A person who can see a document can take a screenshot, photograph the display, use browser tools, or print to another file when printing is available. Access still has to be limited to people who need it. The least-privilege checklist for client documents helps separate viewing, printing, original download, expiry changes and deletion.

Set the deletion date when files arrive

Do not leave retention as a clean-up task for later. Decide the normal working period before the first submission arrives, then attach a deletion date to every received file.

A short check may need seven days. A routine process may need 30, while longer work may need 90. These are examples, not universal legal periods. Choose a period based on the purpose, applicable law, professional obligations and the location of the authoritative record.

The temporary intake copy and the official business record do not have to share the same retention period. If a signed form must be kept for several years, move the approved record into the controlled system where it belongs, with the correct policy. The intake copy can still be deleted once handoff is confirmed.

Use our document retention policy worksheet to record the purpose, owner, trigger, exception path and system of record instead of choosing a number by instinct.

Make completion a clear action

When the review is finished, the reviewer should have an obvious final step: record the result, confirm that any required official record has been saved in the right place, and delete the temporary submission.

Deletion needs to reach more than the visible inbox row. Depending on the service, a file can produce an original object, previews, print output, access links, encryption keys, metadata, logs and backup residuals. Ask the provider what is removed from active systems, what minimal evidence remains, and how backup expiry works.

The FTC's Start with Security guidance recommends keeping sensitive information only while there is a legitimate business need and disposing of it securely. Our guide to secure deletion for cloud documents maps the copies that a credible deletion process should consider.

Automatic deletion should continue if a trial ends, a payment fails, or a workspace is cancelled. A billing event is not a reason to extend the life of a sensitive document.

Test the workflow with harmless files

Run a small acceptance test before sending the first real request. Use synthetic documents that contain no personal data.

• Send the request to someone who has not seen the process
• Confirm that the upload link opens the intended organisation's page
• Upload every supported format and one unsupported format
• Check what the sender sees after a successful and failed submission
• Verify that only the intended reviewers receive a notification
• Confirm that notifications do not expose filenames or sender details
• Review the file without downloading the original
• Exercise any print or download exception and check the activity record
• Change or shorten the deletion date if your plan allows it
• Delete the submission and confirm that its links no longer work

Repeat the test after material changes to identity, storage, file processing or deletion behavior. A policy is useful, but a completed test shows whether the workflow works as described.

Keep temporary intake separate from permanent records

Document intake does not need to become a folder hierarchy, editing suite, e-signature tool, identity-verification service or permanent archive.

The useful workflow is shorter: request only what is needed, receive it through one controlled route, review it with limited copying, move any required record to its proper system, and delete the temporary files on schedule.

That is the role Sunset Docs is built to support. It can help enforce parts of this workflow, but using a tool does not by itself make an organisation compliant. The customer still decides why documents are collected, which laws and professional rules apply, who may see them, and whether the service is appropriate for the data involved.

Frequently asked questions

Can a business still collect documents by email?

Yes. Email is not automatically unsuitable for every document. The decision should consider sensitivity, recipient verification, mailbox security, attachment scanning, forwarding, local downloads and deletion. A portal is useful when you need tighter control over the intake copy and its lifecycle.

Does an upload portal prevent people from copying a document?

No. A portal can avoid routinely sending the original to a browser and can restrict downloads, but visible information can still be captured. Treat view-only as copy reduction, not copy prevention.

How long should temporary documents be kept?

There is no single period that fits every process. Keep the intake copy only as long as the stated purpose, applicable law and operational handoff require. Document the reason for the chosen period and review exceptions rather than silently extending them.

Does deleting a portal copy remove the sender's copies?

No. A service can delete the copies it controls. It cannot remove a file from the sender's device, Sent folder, email provider, screenshots, downloads, or another external system.

Is the upload portal the official business record?

Not necessarily. Sunset Docs is temporary intake, not a statutory archive or permanent document-management system. If your organisation must retain an approved record, move it to the designated system before the intake copy expires.

Can every type of sensitive information be collected this way?

No. Some data needs a specific legal condition, stronger safeguards, a specialist provider, or a separate written agreement. Check the service terms and your own obligations before requesting special-category data, criminal-offence data, children's data, full payment-card details, passwords, authentication secrets or private keys.