How to Revoke Access to a Shared File After Sending It

Table of Contents

1. The core distinction: hosted access versus copies
2. What you can revoke
3. What you cannot revoke
4. Revoking in cloud storage
5. Revoking in secure sharing platforms
6. Revoking in email
7. Comparison table
8. Incident workflow: what to do in the first hour
9. Handling copies you cannot reach
10. Preventing the need for revocation
11. Limitations to communicate internally
12. Frequently Asked Questions
13. Related Reading
14. Sources

The core distinction: hosted access versus copies

Every shared file exists in at least two places: the original stored where you keep it, and the copy the recipient received. When you share through a link, the recipient typically views a copy hosted by the platform, so you can change or stop that access centrally. When you share by attachment, or when the recipient downloads a file, a new copy now sits on their device, in their mailbox or in their storage, and you have no technical control over it.

This distinction is the most important thing to understand about revocation. Revoking a link or removing a recipient's permission stops future access to the hosted copy. It does not delete, unsend or decrypt anything that has already been retrieved. A recipient who downloaded the file last week still has the file. A recipient who photographed the screen still has the image. Your ability to revoke is limited by where the copy was made.

Writing this down for your team prevents a common expectation gap. People often assume that "revoke" means "make the file disappear everywhere". It does not. It means "stop the copy I control from being opened by this person or anyone else", which is a narrower but still useful capability.

What you can revoke

In practical terms, you can usually revoke the following, depending on the tool:

• Link access. Disabling or deleting a shared link stops anyone from opening the hosted copy through that link.
• Named-recipient permissions. Removing an individual's access stops their account or verified identity from opening the hosted copy, while leaving other recipients unaffected.
• Expiry. A time-limited link stops working when its expiry passes, if the platform enforces expiry server-side.
• Passcodes. Changing a passcode stops anyone who does not know the new code from opening the file, though it does not stop those who already did.
• Access to the source file. If the file is stored in a shared folder, removing the folder share, or moving or deleting the source file, can stop access to the hosted version, depending on how the platform handles links.
• Future versions. If you replace the document with a new version and share a fresh link, the old version remains available only if the old link still works. Revoking the old link prevents access to the outdated version.

These controls are valuable. They allow you to contain an incident, end a transaction cleanly and stop a forgotten link from being used years later.

What you cannot revoke

Several things sit outside your control once a file has left the platform or been delivered:

• Downloaded files. If the platform allowed download, the recipient has a complete copy on their device. Revoking the link does not remove it.
• Email attachments. Once an attachment is delivered to a mailbox, it exists in that mailbox, in the sender's Sent folder, in backups and possibly on the recipient's phone or other devices. Recalling an email is unreliable, depends on both mail systems and is often unavailable across organisations.
• Printed or photographed copies. Paper and screen captures cannot be reached by any setting.
• Forwarded copies. A recipient who forwarded the file or shared the link with someone else has created additional access paths. You can revoke the link, but you cannot see or revoke the people your recipient shared it with, unless the platform enforces named identity for every viewer.
• Cached or synced copies. Devices, browsers and sync clients may hold local copies. Some sync setups may remove files when access is revoked, but this depends on configuration and timing.
• Copies in third-party systems. If a recipient uploaded the file to another service, such as a personal cloud account or an AI tool, you have no control over that service through your sharing settings.

When your team understands these limits, they can make better decisions about what to share in the first place. The most effective revocation is the one you never need, because the file was never shared in a copyable form. See Step 2 in our business workflow article for how to reduce what you share.

Revoking in cloud storage

General cloud storage services, such as Google Drive, Microsoft OneDrive and SharePoint, and Dropbox, all provide link-sharing and permission controls. The exact menus change over time, so use the current official help documentation for your plan. Conceptually, the controls are the same:

1. Find the sharing settings for the specific file or folder. Settings may be inherited from a parent folder, which is a common source of unexpected access.
2. Review link access. Check whether the link is restricted to specific people or whether anyone with the link can access it. Change anyone-with-the-link access to restricted if the business need allows.
3. Remove named recipients who should no longer have access.
4. Disable the link entirely if you need to stop all link access quickly.
5. Check folder-level sharing. A file shared through a folder may remain accessible if the folder is still shared, even after you remove the file-level link.
6. Check for ownership and delegation. If another person owns the file or has permission to share it, they may be able to create new links. Review who has editor or sharing rights.

Two cautions apply. First, deleting a file from the cloud service does not automatically remove copies downloaded to devices or synced to local folders. Second, some services keep deleted files in trash or version history for a period, which may matter for retention and for your incident record. Check how your platform handles deletion and recovery.

Where your organisation uses an administrator console, administrators may be able to review sharing across the domain, see external shares and disable them centrally. Make sure at least two people know how to do this before an incident occurs.

Revoking in secure sharing platforms

Dedicated secure sharing platforms are designed for this exact use case. They typically provide per-link controls, including expiry, passcodes, email verification, view-only settings, download restrictions and access logs. Revocation is often a single action on the link: disable it, delete it or change its settings.

The advantages are speed and visibility. Good platforms show who viewed the document, when and how often, which helps you judge whether the file was accessed before you revoked it. They also tend to make it obvious which links are active, which reduces the chance of forgotten shares.

Keep in mind that a platform's controls may not reach copies that were downloaded, if downloads were permitted. If the platform offers a view-only mode, rely on it for stronger control, but understand that view-only is still an enforced presentation rule rather than cryptographic protection against copying. Check the vendor's documentation for what each setting enforces and what it does not.

When you revoke, record the time and the link identifier. Some platforms let you replace a link with a new one for a corrected version. Use this approach when you need to replace content, rather than re-enabling the old link.

Revoking in email

Email is the hardest channel to revoke. An attachment is a complete copy, delivered to every recipient address in the message. Once delivered, the sender cannot change it.

Some mail systems offer message recall or unsend features, but these generally work only for messages within the same organisation, under specific conditions, and often only if the recipient has not already opened the message. Do not rely on recall as a security control. Treat it as a best-effort step that may or may not succeed.

If you realise you sent a sensitive attachment by email, take these steps:

1. Try recall if your system supports it, and record the attempt.
2. Contact each recipient directly and ask them to delete the message and attachment from all devices, including trash folders and downloads.
3. Ask for written confirmation that deletion has been done.
4. Assess whether the attachment was encrypted and whether the password was sent in the same message, since that affects your risk assessment.
5. Replace the file with a link-based share going forward, so that any future version can be controlled.

Email is best used for short messages that point to controlled links, rather than for carrying confidential documents themselves.

Comparison table

Capabilities depend on product, plan and settings. Confirm them in current vendor documentation.

Incident workflow: what to do in the first hour

When you discover that a shared file has gone to the wrong recipient, or that a link has been shared more widely than intended, speed matters. Follow a predetermined routine rather than improvising.

Minutes 0 to 15: contain hosted access.

1. Disable or restrict the link, or remove the recipient from named access.
2. Change the passcode if one is used, and do not send the new passcode by the same channel as before.
3. Check whether any folder or other link also exposes the same file, and disable those too.
4. Note the time you took each action.

Minutes 15 to 45: establish the facts.

1. Identify exactly what was shared: file name, version, classification, pages and any attachments.
2. Identify every recipient and every channel used, including forwards you know about.
3. Pull the access log from the platform, if available, and record who viewed the file, when and from where.
4. Determine whether the file contained personal data, financial data, legal material or other sensitive categories.
5. Check whether a download was permitted or occurred.

Within the first hour: inform and request.

1. Tell the people responsible for data protection, legal or security matters inside your organisation.
2. Contact the unintended recipient, state what was received, and ask them to delete it from all devices, including downloads and trash folders, and to confirm in writing.
3. If the recipient is a known contact, consider a phone call in addition to email. Verify the contact details through a channel you already trust.
4. If personal data is involved, assess notification duties. The GDPR, for example, sets specific timing and content requirements for certain personal data breaches.

Within the following days: learn and close.

1. Decide whether to replace the document with a new version and share it through a new link.
2. Document the incident: timeline, decisions, evidence, communications and outcomes.
3. Review what caused the mistake, whether it was a wrong address, a permissive default setting, a forwarded link or a missing classification.
4. Update your sharing defaults or training to address the cause.

Keep a template for the incident record so that every incident produces the same kind of evidence. Include fields for time detected, time contained, documents affected, recipients, actions taken and sign-off.

Handling copies you cannot reach

When a copy is outside your control, your options are limited but not zero. You can ask the recipient to delete the file and confirm, which is a request rather than a control. You can document that you asked, which matters for accountability. You can consider whether the information in the document is still sensitive once the recipient has seen it, because some information loses sensitivity over time, while other information, such as credentials or personal identifiers, does not.

Where the information is sensitive and the exposure is large, you may need to change the underlying facts. Rotate passwords or API keys that appeared in the document. Notify affected individuals if personal data was exposed. Update contracts or pricing if commercial terms were disclosed. Revocation is only one part of the response. The information itself may need to be managed.

Preventing the need for revocation

The best revocation strategy is to reduce the situations that require it:

• Use links, not attachments, for confidential material, so that you keep a central control point.
• Default to restricted access. Set new links to named recipients and expiry, rather than anyone-with-the-link.
• Set short expiry periods that match the transaction, and review open links monthly.
• Remove download permission for documents that do not need to be downloaded.
• Use watermarks to identify the source of a leak and deter casual sharing.
• Verify recipients before sending, especially for new contacts or changed payment details.
• Keep a register of active shares. A list of who has access to what, reviewed regularly, prevents forgotten links from becoming long-term exposures.
• Train staff on the limits. People who understand that revocation does not reach downloads will be more careful about what they send.

Limitations to communicate internally

Be explicit with your team and any clients who depend on your sharing practices:

• Revocation controls the hosted copy and future access only.
• Downloads, prints, screenshots and forwarded copies cannot be reached through platform settings.
• Recall of sent emails is unreliable and should not be your primary plan.
• Platform controls depend on configuration, plan and vendor behaviour. Verify them.
• Revocation does not undo the disclosure of information, so the response may need to include other actions.

Clear expectations protect your organisation from false confidence, and they help you set the right tone when you ask a recipient to delete a file.