Sending confidential documents via email is still the norm in most organizations, even though email was never designed for that purpose. The protocol was developed in the early 1980s for text messages. Attachments and encryption were added later. The fact that organizations don’t immediately consider using a specialized platform for secure document sharing is rarely due to a lack of knowledge.
Email is the default choice; the costs associated with the risks remain hidden, and no one takes ownership of the process. This article explains where these barriers come from and how to overcome them internally.
Short answer: Organizations continue to send confidential documents via email because email is already there, feels free, and has no owner who would call the channel into question. The limitations of an attachment are well known, but they only become apparent during an incident or audit. For those looking to switch, another list of risks is of little use; what’s more helpful are three things: an owner, a single, well-defined document workflow, and an alternative that works just as easily as an attachment.
This article is intended for IT managers, CISOs, and privacy officers who are responsible for coordinating the transition internally. To learn which attachments are and aren’t suitable for email, what risks a standard attachment poses, and what features a controlled sharing solution should offer, read “Why Email Attachments Aren’t Always Suitable for Sensitive Files.” This article addresses a different question: why does that knowledge translate so little into practice?
Email was built for messages, not for documents
When the standard for Internet messages was established in 1982, it was designed for text. The later MIME specification states this explicitly: RFC 822 was intended as a format for text messages. Transport via SMTP was limited to 7-bit text in lines of up to 1,000 characters. A PDF or a scanned passport did not fit into that design.
Attachments didn’t truly become a feature until MIME was introduced, as defined in RFC 2045 from 1996. A file is converted into plain text using Base64 so that existing mail servers can relay it. The authors candidly noted that compatibility took precedence over elegance. Encryption came even later: with STARTTLS (RFC 3207, 2002), mail servers can encrypt the transport if both ends support it. The IETF itself notes that an attacker who intercepts parts of the SMTP session can bypass that encryption. To address this , MTA-STS was introduced in 2018.
Each step solved a real problem without changing the underlying structure. The result is that, technically speaking, an attachment is simply a copy included in a message—not a shared document with its own terms and conditions. That explains the limitations of email. It does not, however, explain why organizations continue to rely on it en masse.
Why Sending Confidential Documents via Email Remains the Standard
The problem is not unknown. In the first half of 2024, 18 percent of the more than 9,800 data breach reports filed with the Dutch Data Protection Authority involved personal data in an email—for example, sent to the wrong recipient—according to preliminary figures from Statistics Netherlands (CBS) and the Dutch Data Protection Authority (AP). In 88 percent of all reports, no measures had been taken beforehand to encrypt the data or otherwise make it inaccessible. Yet such figures rarely lead to a switch to a different channel. Five mechanisms explain why.
1. Email is the status quo
Almost every decision includes the option to make no change. In 1988, economists Samuelson and Zeckhauser used experiments and real-world data to show that people disproportionately often stick with the status quo. Their research focused on choices such as health care and pension plans, not IT. The mechanism is recognizable, however: no one ever chose email—it was simply already there.
2. Email feels free
The email inbox is included in the existing license. A separate platform is a visible cost with a procurement process. The costs of the current channel remain scattered and invisible: hours spent on a data breach investigation, a report, recovery, and loss of trust only show up on the bill when things go wrong.
3. No one owns document exchange
IT manages the mail server, the privacy officer writes the policy, the CISO monitors the risks, and the departments do the work. The process of “sending a confidential document to an external party” falls in between. Without an owner, no one asks whether the channel is still appropriate.
4. “We’ve already taken care of that”
Many organizations have encrypted email, sensitivity labels, or SharePoint. These are valuable measures, but they partly address different issues. Message security protects the email, while collaboration environments support working together. Controlled transfer to an external recipient, with verification and proof, is a third issue. We explore the difference with SharePoint in “SharePoint vs. Secure File Transfer.”
5. The risk only becomes apparent during an incident or audit
A misdirected attachment feels like an isolated mistake, not a pattern. It is only when a regulator or auditor asks for proof of who received and opened a document that it becomes clear the email system cannot provide that answer. The GDPR requires organizations to be able to demonstrate compliance (Article 5, paragraph 2). Under the Cybersecurity Act, management must also approve and oversee security measures, as explained on our page about NIS2, the Cybersecurity Act, and secure file sharing.
Added to that is a valid concern: that a new channel will make the work more complicated. Complexity undermines compliance, so an alternative will only work if it’s at least as easy as attaching a file.
From Objections to Dialogue
Anyone who puts the transition on the agenda almost always hears the same objections. They’re rarely unreasonable, but they usually concern something other than whether email is suitable. The table links each objection to what lies behind it and to a question that makes the conversation concrete.
| Objection | What’s usually behind it | A question that changes the conversation |
|---|---|---|
| “Email works just fine, doesn’t it?” | Habit. Email was never consciously chosen. | “For which document workflow did we ever explicitly decide that email was sufficient?” |
| “We already have encrypted email and Microsoft 365.” | Message security and document control are being confused. | “For the last contract we shared externally, can we show who downloaded it?” |
| “A separate platform costs money.” | The costs of the current channel are hidden. | “How many hours did our last investigation into a misdirected email take?” |
| “Employees won’t use it.” | A valid concern about friction and shadow IT. | “Does the alternative work within the environment where employees already send emails?” |
| “That’s an IT issue.” Or: “That falls under privacy.” | There is no one in charge of the process. | “Who’s responsible if a file ends up with the wrong external party tomorrow?” |
| “It’s never gone wrong before.” | Incidents are viewed as isolated errors, not as a pattern. | “How many misdirected emails were reported internally last year?” |
Who is responsible for secure document sharing?
Ownership is the hurdle that most often remains unresolved, because every stakeholder has a stake in the issue. A workable division of responsibility looks like this:
| Role | What this role is about | Role in the transition |
|---|---|---|
| Department Manager (HR, Finance, Healthcare, Projects) | The Work Process and External Relationships | Owner of the document workflow |
| CISO or Security Officer | Information security policy and risks | Sets requirements for verification, access, and logging |
| Privacy Officer or Data Protection Officer | GDPR, data breaches, accountability | Assesses and advises; is not the process owner |
| IT Manager | Workplace, integration, and management | Selects and implements the channel |
| Management or Board of Directors | Ultimate responsibility and budget | Makes the decision and ensures its implementation |
The bottom line: assign ownership of each document workflow to the department that performs the work, with security and privacy serving as the deciding factors. Then the question of whether the channel is still appropriate finally has a clear answer.
Here’s how to put the transition on the internal agenda
An organization-wide change rarely succeeds all at once. A convincing initial decision, however, does. These five steps focus on that decision, not on the technical implementation.
- Choose one document flow. Select the flow where the consequences of an error are the most severe. Consider, for example, pay stubs sent to an external payroll agency, medical information sent to an insurer, or contracts sent to a supply chain partner. Compare two or three candidates side by side and count, for each workflow, how many times the answer to the six questions below is “yes.” Tackle the workflow with the most “yes” answers first. A workflow with zero “yes” answers can simply be handled via email.
- Ask the evidence-based question. Ask, as an auditor would: Can we demonstrate, for this workflow, who received which document, when it was downloaded, and how long it was available? The answer is often the strongest argument.
- Explain the risk in concrete terms using the decision-maker’s language. Describe what will happen if things go wrong tomorrow: the assessment, a potential report within 72 hours, the resolution, and the discussion with the affected customer or partner. Use estimated hours based on your own incidents rather than generic figures.
- Test in the existing work environment. Have real users process the data through the controlled channel for a few weeks, using real external recipients. Measure whether people choose the secure route and where they get stuck.
- Document the decision. Identify the person responsible, the next steps, and a time for evaluation. For broader channel policies by type of information, the step-by-step guide in our article on email attachments is a good next step.
- Does the data flow contain personal information, such as a Social Security number, medical information, or financial information?
- Is it being sent to a third party outside your own domain?
- Will you need to be able to prove later who received and downloaded it?
- Is it a problem if a document is forwarded or ends up with the wrong recipient?
- Should the documents only be available for a limited period?
- Is the data flow subject to the GDPR, DORA, the Cybersecurity Act, or contractual confidentiality obligations?
To learn about the GDPR requirements for sharing files containing personal data, visit our page on the GDPR and secure file sharing.
How Msafe Makes the Transition Easier
Most of the hurdles discussed in this article have to do with habit and convenience, not technology. That’s exactly what Msafe Secure File Transfer is designed for. With the Enterprise and Unlimited plans, employees share files directly from Outlook, so the secure sharing option appears on the same screen as the attachment. External recipients do not need an account. They gain access after verification, such as via an SMS code, an authenticator app, or a PIN. The sender sets an expiration date and can revoke access.
To address the evidence requirements from Step 2, Msafe records uploads, downloads, and shares in an exportable audit trail. Starting with Msafe 2.5, administrators can set central policies—such as which file types may not be shared—and automatically link users to the appropriate policies via SCIM. In this way, Msafe helps demonstrate what has happened to a document. Features and subscription plans are listed on the Msafe Secure File Transfer product page.
With Msafe as well, a downloaded file remains a copy with the recipient. The difference lies in the preconditions and the evidence provided afterward.
Frequently Asked Questions
Why do organizations still use email for confidential documents?
Because email is already in use, feels free, and has no single owner who would challenge the channel. The limitations of an attachment usually only become apparent during an incident or an audit inquiry. Until then, the status quo feels like the safe choice.
Who decides on a platform for secure document sharing?
Formally, it’s usually the executive management or the board, based on a recommendation from IT and security. In practice, it works better if the department that manages the document flow takes ownership, with the CISO and privacy officer serving as reviewers. Under the Cybersecurity Act, the board must also approve the security measures itself.
How do you build a business case for secure file sharing?
Don’t start with the entire organization; begin with a single high-risk document workflow. Define the problem, describe the cost of an incident in terms of hours and consequences, and test an alternative with real users. A measurable result from a small-scale test is more convincing than a general risk analysis.
Would you like to substantiate the transition using a single real-world document flow from your own organization? Request a Proof of Concept from Msafe Secure File Transfer.
