01 · The Question
Can You Just Attach the Dataset and Click Send?
A collaborator asks for the latest dataset. It is only one spreadsheet, so attaching it to an email seems much easier than setting up another transfer system.
Then comes the uncomfortable part. The spreadsheet contains participant-level information. Perhaps the data are pseudonymized. Perhaps they include names, contact details, interview transcripts, health information, or other sensitive material.
Email is not automatically prohibited for research data, but sending participant information as an ordinary attachment can create risks involving interception, incorrect recipients, compromised accounts, uncontrolled copies, forwarding, retention, and inadequate encryption. The correct question is not simply whether email works, but whether it provides an appropriate transfer mechanism for the particular data.
03 · What You Need to Know
Email Creates More Than One Kind of Data-Transfer Risk
Email is a transfer mechanism, not a research data repository
Email was designed primarily for communication. It can move files conveniently, but convenience should not be confused with controlled research data management.
When a dataset is attached to an email, copies may remain in the sender's mailbox, the recipient's mailbox, sent folders, synchronized devices, server backups, archives, and potentially forwarded messages. Researchers may lose practical control over where the attachment exists.
If the purpose is ongoing collaborative access rather than a one-time message, an approved research storage or sharing environment may provide more appropriate access control, version management, logging, revocation, and retention.
The wrong recipient is one of the simplest ways to disclose data
Encryption discussions can make email security sound highly technical, but one of the most ordinary risks is typing or selecting the wrong address.
The UK Information Commissioner's Office identifies sending personal information to the wrong recipient as a common disclosure scenario. The Philippine National Privacy Commission has similarly warned that human errors involving email, including inappropriate use of the CC function, have resulted in unintended exposure of personal information.
Autocomplete makes this particularly easy when people have similar names or addresses. Distribution lists and reply-all chains can expand the number of recipients further.
Before sending participant information, verify the recipients rather than relying solely on autocomplete. Where the message is going to multiple people, check whether every recipient actually needs the data.
CC and BCC can create their own privacy problem
The data at risk may not even be in the attachment. Email addresses themselves can constitute personal information.
The Philippine National Privacy Commission specifically warns that using CC exposes each recipient's email address to all other recipients and can unintentionally disclose personal, sensitive, confidential, or restricted information contained in the email or its attachments.
If researchers communicate with groups of participants by email, they should consider whether recipients are supposed to know one another's identities or addresses. BCC or an appropriate mailing system may be required where addresses should not be mutually visible, subject to institutional procedures.
Encryption can protect the contents during transfer and storage
Encryption can make email content or attachments unreadable to people who do not possess the necessary key or credentials.
The Philippine National Privacy Commission advises organizations transferring personal data by email to ensure that the information is encrypted or to use a secure email facility that facilitates encryption. Its work-from-home guidance specifically recommends encrypting files and attachments when sensitive data are transferred by email.
For Philippine government agencies, NPC Circular 16-01 expressly requires personal data transferred by email either to be encrypted or sent using a secure email facility that facilitates encryption of the data and attachments.
ICO guidance likewise identifies encryption of email content and attachments as an important control, especially when sensitive personal information is involved.
An encrypted attachment can be useful, but password handling matters
One common approach is to encrypt a file before attaching it to an ordinary email. The recipient then needs a password or cryptographic key to open it.
Sending the password in the same message largely defeats the point if an unintended recipient receives both. ICO guidance recommends communicating the key through a separate channel to obtain the strongest benefit from encrypted attachments. Philippine government guidance similarly states that passwords should be sent separately.
The separate channel might be an approved messaging system, telephone call, or another institutionally authorized method, depending on the organization's security procedures.
Watch Out
Encryption does not fix an incorrect recipient if that recipient also receives the password or otherwise has the ability to decrypt the attachment. Recipient verification remains necessary even when files are encrypted.
Transport encryption and attachment encryption are not identical
Modern email systems often encrypt connections between devices and servers or between mail servers. That protects information while it travels across particular parts of the network, but it does not necessarily mean that only the intended human recipient can access the message after delivery.
An encrypted attachment provides a different layer of protection because the file itself remains encrypted unless opened with the appropriate credentials.
Researchers should follow the encryption method approved by their institution rather than assuming that seeing a padlock icon somewhere in the email interface answers every security question.
A secure link may be preferable to an attachment
Instead of sending the dataset itself, some institutional systems allow researchers to send an authenticated link to an approved storage or file-transfer environment.
This can provide practical advantages. Access may expire, permissions can sometimes be revoked, authentication can be required, large files need not be duplicated across mailboxes, and the authoritative copy can remain within an approved environment.
The Philippine National Privacy Commission's data-security guidance recommends identity authentication when online links are used to provide access to personal data.
A secure link is not automatically safe merely because it begins with HTTPS. The underlying storage, access permissions, recipient authentication, provider, expiration settings, and institutional approval still matter.
Send only what the recipient actually needs
If a statistician needs selected pseudonymized variables, do not email the entire identifiable master dataset simply because it is easier than making an export.
Apply data minimization before the transfer. Remove unnecessary variables, identifiers, records, and supporting files. If direct identifiers are not required, keep them out of the transfer.
The same reasoning applies to recipients. Before sending participant-level information to a collaborator, determine whether that collaborator is actually authorized to receive the data.
Verify what the recipient will do with the attachment
Sending a file securely is only half of the transfer. What happens after receipt?
Will the recipient download the attachment to a personal computer? Forward it to another team member? Upload it to a different cloud service? Leave it indefinitely in the mailbox? Use a personal email application that synchronizes attachments to multiple devices?
Where research data are shared under an agreement or defined collaboration, the recipient's storage, access, onward sharing, retention, and deletion arrangements should be consistent with that authorization.
Email creates retention issues
Attachments can survive long after the research team believes a working copy has been deleted. Email archives and backups may be subject to organizational retention systems outside the researcher's direct control.
This does not necessarily mean email can never be used. It means the research team should understand whether sending the data by email creates additional copies that conflict with the project's retention, minimization, contractual, or data-management requirements.
Highly sensitive datasets may warrant a different transfer method
The more serious the potential consequences of unauthorized disclosure, the stronger the justification should be for the chosen transfer method.
Identifiable health data, genetic information, detailed financial information, highly sensitive interview material, reidentification keys, credentials, or large identifiable datasets may be inappropriate for ordinary email even where less sensitive information can legitimately be sent that way.
Use the transfer mechanism approved for the project's data classification. If the appropriate method is unclear, ask the institutional privacy, information-security, research IT, or data-governance office before sending the file.
Using email does not eliminate transfer-governance requirements
If data are being sent to another institution or organization, the fact that the technical transfer occurs by email does not determine whether the disclosure itself is authorized.
You may still need to address purpose, recipient role, legal basis, ethics commitments, confidentiality, security, retention, and whether a data-sharing or data-transfer agreement is required.
Email answers only the question of how the bits move. It does not answer whether they should move.
