Skip to content
ThinkQuarryIdeas for a smarter digital life. Get in touch

Digital Essentials

How to share files with clients securely: a practical checklist

Sealed documents passed to a client beside a padlock and security key.

Featured image: original AI-generated photographic visual created for ThinkQuarry. Screen interfaces are conceptual mockups, not product screenshots.

The safest practical way to share files with clients is to use an approved cloud service, invite the smallest possible audience, grant only the permission the client needs, test the recipient experience, and remove access when the handoff is finished. A secure handoff is a short process, not a particular brand.

Documentation checked on 2 October 2026. This guide explains a general workflow for freelancers and small teams. It is not a security certification or legal/compliance advice. If a file contains regulated, legal, medical, financial, identity or other highly sensitive data, follow your organisation’s approved system and policy.

Quick answer: a secure client file-sharing workflow

  1. Classify what you are sharing and remove anything the client does not need.
  2. Place the approved deliverables in a separate handoff folder.
  3. Prefer named-recipient access for sensitive or private work.
  4. Start with view or download access; allow editing only when the task requires it.
  5. Add an expiry date or password when the service and plan support it.
  6. Test the link as the intended recipient would experience it.
  7. Send a short inventory of the expected files.
  8. Confirm receipt, then review and revoke access at the agreed time.

If you are still choosing a platform, compare the permission and recipient experience in our Google Drive vs OneDrive vs Dropbox workflow guide. The steps below work as an evaluation checklist as well as a delivery routine.

Why email attachments are a weak default

An attachment creates another copy that you cannot update or revoke after sending. Large attachments may also be rejected by the sender’s or recipient’s service. Microsoft’s current guidance recommends uploading a large file to cloud storage and sharing a link rather than relying on an oversized attachment.

A link does not become safe automatically. Its audience, permission, location and lifetime still need deliberate choices. A public or forwardable link may be appropriate for a public brochure, but it is a poor default for private client work.

Step 1: prepare a clean client handoff folder

Do not share your entire working folder merely because it is convenient. Create a separate handoff folder containing only the items the client needs. This reduces accidental exposure and gives the recipient a clearer experience.

A simple structure might look like this:

  • 00-Read-Me: a short inventory, contact and delivery date.
  • 01-Final: approved PDFs, images or exported deliverables.
  • 02-Source-Files: included only if the agreement requires them.
  • 03-Reference: relevant supporting material that the client may keep.

Use clear filenames with a project name, deliverable, version and date. Our digital file organisation guide includes a repeatable naming method.

Step 2: choose the smallest useful audience

For private work, named-recipient or “specific people” access is usually a better starting point than “anyone with the link.” Google Drive distinguishes restricted access from broader link access. OneDrive explains that specific-people links are limited to the people you name or people who already have access, while an anyone link may be forwarded.

Before sending, answer three questions:

  • Exactly who should open this folder?
  • Does the client need an account or identity check?
  • Could access also be inherited from a parent folder, team or site?

The third question matters. Removing one sharing link may not remove access inherited from somewhere else. Microsoft’s Manage access guidance separates links, direct access and inherited access. Google also recommends a limited-access subfolder when a subset of files needs a tighter boundary.

Step 3: give the least permission required

Start with view or download access for a final delivery. Give edit access only when the client is expected to change, replace or collaborate on files. Edit access to a folder can be broad: depending on the service, it may permit renaming, moving, adding or deleting contents.

Dropbox’s permission documentation distinguishes viewers from editors and notes that access on a parent folder can extend to subfolders. Google Drive supports viewer, commenter and editor roles for files. OneDrive provides view and edit choices, although the available controls can differ between personal, work and school accounts.

“Least permission” is not about making the client’s work difficult. It means matching access to the agreed task. If a client only needs to approve a PDF, editing the entire delivery folder adds risk without helping them.

Step 4: use expiry and passwords when they fit

Some services and paid plans support link expiration, password protection or download restrictions. Availability varies, so verify the controls in the account you actually use. Dropbox, for example, documents password and expiry controls for transfers and certain plans; OneDrive documents expiry and password management for supported links and accounts.

An expiry date is useful for a temporary review or delivery link. It does not replace a proper access review: direct or inherited access may remain even after one link expires. Likewise, a password does not help if it is shared carelessly with the same broad audience as the link.

For the account itself, enable multifactor authentication where available, particularly for file-storage accounts containing business or client information. CISA recommends MFA for systems such as email, file storage and remote access.

Step 5: test the client experience before sending

A link can work for the owner and still fail for the recipient. Test the route that matches the real handoff:

  1. Confirm the upload or sync has completed.
  2. Open the link in a signed-out browser only if it is intended to work without an account.
  3. For named access, test with a willing collaborator using the same kind of account as the client.
  4. Check which files are visible and whether the recipient can download, edit or reshare.
  5. Open the exported deliverable and inspect its pages, links, images and fonts. If a PDF exceeds the delivery limit, follow our offline PDF compression guide for Windows, keeping the original and checking readability after compression.

Do not test with real sensitive client information. Use representative sample files when evaluating a new service or workflow.

Step 6: send a useful handoff message

The message should explain what the link contains, what the client should do, and when access changes. A concise example:

The link contains the final PDF, six approved images and the project readme. Please download the files and confirm receipt by Friday. The link is intended for your named account and will be reviewed after 14 days. Reply here if another authorised recipient needs access.

Do not claim an expiry unless you configured it. Do not send a password in the same public channel as a broadly shared link. If your client has an established secure communication process, use it.

Worked example: a freelance design handoff

Scenario: a designer must deliver a final PDF, web images and source files to one client contact and a reviewer.

  1. The designer copies approved items into a new Client-Project-Final-2026-10-02 folder.
  2. A readme lists eight expected files and labels the PDF as the approved final version.
  3. The client contact receives view/download access. The reviewer receives access only if review is still required.
  4. Source files sit in a separate subfolder because they are not needed for routine approval.
  5. The designer tests a sample link with a collaborator, checks the final PDF, then sends the client link with the file inventory.
  6. After receipt is confirmed and the agreed access period ends, the designer reviews direct, link and parent-folder access rather than deleting only the email message.

This is an illustrative workflow, not a claim that every service exposes identical controls.

Client file-sharing checklist

Check Pass condition
Content Only agreed deliverables are present; working notes and unrelated files are excluded.
Audience Every recipient is expected, and broader link access is intentional.
Permission View, comment or edit access matches the task.
Folder boundary No parent folder, team or site grants unexplained access.
Link controls Expiry, password or download settings are configured if required and supported.
Recipient test The expected recipient can open the right files and cannot perform unintended actions.
File quality Final exports open correctly and match the handoff inventory.
Closeout Receipt, retention and access-removal dates are recorded.

After delivery: confirm, retain and revoke deliberately

Ask the client to confirm receipt before changing access. Keep the agreed business record or retained copy according to your contract and policy. A synchronised folder is not automatically an independent backup; irreplaceable work should have an appropriate recovery plan.

Then review access in the service itself. Look for sharing links, directly invited people, groups and inherited folder access. Removing the email or chat message does not remove the permission. Record when access was changed so the next project review does not depend on memory.

Choose a repeatable process

The best client file-sharing process is one your team can repeat without guessing: separate the deliverables, name the audience, limit the permission, test the recipient experience, and close access intentionally. Explore more Digital Essentials guides, then write this checklist into your project-closeout routine.

About ThinkQuarry

Practical explanations and useful frameworks for your digital life.

Our editorial standards ↗