Open assessment tool
Secure file request checklist
Use this 20-point checklist to review how a service collects, stores, shares, and deletes client files.
Quick answer
Ask only for the files you need. Give each recipient access to one request. Protect staff accounts, keep uploads private, and decide when to delete the files. Use the checklist to compare a service or review your own process.
Download
1. Ask for less
Start with the files you need, not the upload tool. A short, time-limited request is easier for the client and exposes less data if something goes wrong.
| Control | Question to ask | Evidence to look for |
|---|---|---|
| Purpose | Do you have a clear reason for every file you request? | A checklist that says why each file is needed. |
| Ask for less | Can you remove optional or unnecessary files before you send the request? | An editable checklist that the requester reviews before sending. |
| Sensitive files | Does the process flag sensitive or regulated files for extra review? | A written review process and a list of files the service does not support. |
| Expiry | Does the request close after a set date or when the work is complete? | Controls to expire, revoke, and reopen a request. |
2. Limit access
A client should see only the request you sent. Staff access should require sign-in and should be easy to review or remove.
| Control | Question to ask | Evidence to look for |
|---|---|---|
| Client access | Does the link open one request instead of a shared folder or account? | A private, hard-to-guess link with no folder listing. |
| Staff sign-in | Must staff sign in before they download or delete files? | Signed-in staff pages that are separate from the client upload page. |
| Staff access | Can you limit access to staff who need the files? | Access rules and a clear way to remove a staff member. |
| Two-step verification | Can staff use strong two-step verification? | Supported security keys, passkeys, or authenticator apps, plus a clear company policy. |
3. Protect uploads
The service should check file type, name, and size. It should store files privately and control every download.
| Control | Question to ask | Evidence to look for |
|---|---|---|
| Secure connection | Are uploads and downloads sent over HTTPS? | HTTPS on every public page and clear security documentation. |
| File types | Does the server check file types instead of trusting the browser? | A list of allowed types, file checks, and a clear rejection message. |
| Upload limits | Are there limits for file size, file count, and total storage? | Published limits, rate limits, and clear error messages. |
| File names | Does the service avoid using the uploaded file name as its storage key? | Generated storage keys and safe names when files are downloaded. |
| Private storage | Are uploaded files kept out of public folders and bucket listings? | Private storage with downloads controlled by the app. |
| Risky files | Is there a plan for malware, archives, active files, and other risky formats? | Scanning or quarantine when needed, plus a way to report an incident. |
4. Delete files and plan for problems
Decide how long files stay in the service. Check who else handles the data and what happens after a security incident.
| Control | Question to ask | Evidence to look for |
|---|---|---|
| Retention | Is there a default time limit for stored files? | A retention schedule, automatic cleanup, and a list of exceptions. |
| Deletion | Can requesters delete files? Does account deletion also remove stored files? | Delete controls and a public explanation of the deletion process. |
| Service providers | Does the company list the services that host data, send email, handle sign-in, or take payments? | A current service-provider list and a vendor review process. |
| Activity history | Can the team see who created, opened, uploaded, reviewed, or deleted? | An activity log that does not include private file contents. |
| Incident reports | Can people report abuse, malware, privacy issues, or security incidents? | Public contact details, a way to block risky files, and a named response owner. |
| Recovery | Does the company explain backups, restore limits, and service recovery? | A written recovery plan with clear limits. |
5. Review the result
- Score each check as Met, Partial, Not met, Not applicable, or Unknown. Unknown is not a pass.
- Do not approve a service for ordinary client files until it limits client access, requires staff sign-in, stores files privately, deletes files on a schedule, and accepts incident reports.
- Ask your privacy, security, insurance, or legal owner to review regulated data, identity documents, tax records, bank details, health information, children's data, or legal evidence.
- Run the checklist again when the service, workflow, file type, or rules change.
Primary sources
- OWASP Cheat Sheet Series: File Upload Cheat Sheet — Defense-in-depth guidance for file types, names, limits, permissions, storage, and retrieval.
- NIST Computer Security Resource Center: Least privilege — The principle of limiting access to the minimum needed for an assigned task.
- NIST Small Business Cybersecurity Corner: Multi-Factor Authentication — Small-business guidance on using MFA to reduce account-access risk.
- UK Information Commissioner's Office: Principle (c): Data minimisation — Guidance to keep personal data adequate, relevant, and limited to what is necessary.
- U.S. Federal Trade Commission: FTC Safeguards Rule: What Your Business Needs to Know — Risk assessment, access control, encryption, service-provider, disposal, and incident obligations for covered financial institutions.
Related AskForFile pages
License and limits
AskForFile's original resource text is available under CC BY 4.0 with attribution. Linked source materials retain their own terms.
- These resources are practical assessment aids, not certifications, legal opinions, penetration tests, or guarantees of compliance.
- Regulated or unusually sensitive data requires a separate suitability, contractual, privacy, security, insurance, and professional review.
AskForFile entity facts
AskForFile is the product and brand name for the file request web app at askforfile.com. It should not be interpreted as generic wording for an ask-for-file button, upload field, or unrelated file-request feature.
- Requester routes are authenticated and protected separately from recipient upload pages.
- Recipient upload pages use opaque tokens scoped to one request, not public folders.
- Uploaded files are private application data, not public web content.
- Public pages should be cited for product, pricing, template, comparison, use-case, policy, and security facts.
- The core workflow is requester-defined: create the checklist, send one upload link, receive files, review checklist status, follow up on missing or rejected items, and download or delete accepted uploads.
- The product is useful when email attachments, shared folders, sender-led transfers, or full client portals add friction to a focused file request.
- Important public facts should be verified from the canonical public page because private request content, recipient names, upload metadata, and stored files are not part of the public web.
Frequently asked questions
Does this checklist certify that a file request is secure or compliant?
No. The checklist is a starting point. It is not a certification, legal opinion, security test, or replacement for rules that apply to your work, contract, location, or data.
Can I reuse the checklist in a vendor review or client policy?
Yes. AskForFile's original checklist text and downloadable rows are available under CC BY 4.0 with attribution. The linked source materials retain their own licenses and terms.
What should block a rollout?
Stop if files may be public, staff can download without signing in, the service has no deletion schedule, or people cannot report an incident. Regulated or highly sensitive data needs a separate security, legal, and contract review.
Last updated 2026-07-16.