How to Actually Revoke a File After You’ve Already Sent It
Deleting the email or asking someone to “please disregard” doesn’t work. Here is what actually stops access — and why a download that already happened can’t be undone.
You sent the file. The deal fell through. The relationship soured. The recipient left the company. The document should not be in their hands anymore. What do you do? If you sent it as an email attachment, the answer is: nothing. You can ask them to delete it. You can send a follow-up saying “please disregard.” You can recall the email in Outlook (which only works if the recipient hasn’t opened it yet and uses the same mail server). None of these actually revoke access. The file is a copy on their device. It is in their downloads folder, their inbox, possibly their desktop. You have no way to enforce deletion. This is the fundamental problem with download-based file sharing: once the transfer completes, you have given away a copy. No tool, no platform, no policy can take it back. “Revoke access” is an empty promise when the access was a download.
Why “please disregard” is not revocation
When you email a file and then ask the recipient to disregard it, three things are true:
1. The file is still on their device. They may or may not delete it. You have no way to verify. 2. The file may have been forwarded before you sent the disregard message. Copies may exist on devices you don’t know about. 3. The email itself — with the attachment — may still be in their inbox, on a mail server, or in a backup. Deleting it from their inbox doesn’t remove it from backups.
“Please disregard” is a social request, not a technical control. It depends entirely on the recipient’s goodwill and diligence. For files where a leak has consequences, that is not enough.
What real revocation looks like
Real revocation requires two things: the file was never downloaded in the first place, and access is controlled by a link that can be turned off.
When you share a file through FileLink, the file is streamed to a secure in-browser viewer. It is not downloaded to the recipient’s device. The recipient views it in their browser; when the session ends, zero bytes remain on their device. Access is controlled by the link — and the link can be revoked.
When you click “revoke,” three things happen immediately:
1. The link stops working. The next time anyone tries to open it, they see nothing. 2. There is no local copy to fall back on. The file was streamed, not downloaded. There is nothing on the recipient’s device to access. 3. The revocation is logged in the audit trail with a timestamp. You can prove when access was terminated.
This is revocation that is real, immediate, and verifiable. Not a request — a technical enforcement.
Scheduled revocation: set it and forget it
Most files have a natural lifecycle. A board pack is relevant before and during the meeting, not indefinitely. A vendor questionnaire is relevant during the diligence period, not after. An NDA is relevant during the negotiation, not after the deal closes or falls through.
FileLink lets you set a date and time for access to expire automatically. You don’t have to remember to revoke — the link stops working at the time you specified. This is date and time-bound sharing: you set the rules in advance, and the platform enforces them.
For board packs, this means access ends after the meeting. For vendor due diligence, it means access ends when the diligence window closes. For investor updates, it means access ends when the next update is sent. No manual cleanup, no follow-up emails, no lingering access.
What revocation cannot do
It is important to be honest about the limits. If you enabled downloads on a link before revoking it, and the recipient downloaded the file, revoking the link does not delete their local copy. That copy is on their device. This is why the default in FileLink is to block downloads — the secure viewer streams the file without copying it. If you choose to enable downloads, do so knowing that revocation applies to the link, not to copies already made.
This is also why dynamic watermarking matters. If you do enable downloads, every page is watermarked with the recipient’s email and IP address. If a downloaded copy surfaces somewhere it shouldn’t, you can trace it back to who had it. Watermarking doesn’t prevent a leak, but it makes a leak traceable — which is often enough to prevent one.
The bottom line
“Revoke access” is only meaningful if the file was never downloaded. If you sent a copy, revocation is a request. If you streamed the file, revocation is a technical control.
For files where access has a lifecycle — board packs, vendor documents, NDAs, investor updates — the ability to revoke access instantly or set it to expire automatically is not a nice-to-have. It is the difference between controlling your documents and hoping for the best.
To see how revocation, scheduled expiry, and the secure viewer work together, explore the [full feature set](/features).