Data security procedures for researchers

Data security is critical to protecting confidential data, respecting the privacy of research subjects, and complying with applicable protocols and requirements. Even seemingly de-identified data may be re-identified if enough unique characteristics are included.¹  Additionally, the information revealed in this process could be damaging in unexpected ways. For example, computer scientist Arvind Narayanan successfully re-identified a public-use de-identified data set from Netflix. Through this, he was able to infer viewers’ political preferences and other potentially sensitive information (Narayanan and Shmatikov 2008).

Many research universities provide support and guidance for data security through their IT departments and through dedicated IT staff in their academic departments. Researchers should consult with their home institution’s IT staff in setting up data security measures, as the IT department may have recommendations and support for specific security software.

In addition to working with data security experts, researchers should acquire a working knowledge of data security issues to ensure the smooth integration of security measures into their research workflow and adherence to the applicable data security protocols. Researchers should also ensure that their research assistants, students, implementing partners, and data providers have a basic understanding of data security protocols.

Data-security measures should be calibrated to the risk of harm of a data breach and incorporate any requirements imposed by the data provider. Harvard University’s classification system for data sensitivity and corresponding requirements for data security illustrate how this calibration may function in practice.²

Data security breaches: Causes and consequences

A data security breach can result in serious consequences for research subjects, the researcher’s home institution, and the researcher. Research subjects may suffer unintentional disclosure of sensitive identified information, which may expose them to identity theft, embarrassment, and financial, emotional, or other harms. Both the researcher’s home institution and the researcher may suffer reputational damage and may have more difficulty obtaining sensitive data in the future. A breach will likely trigger additional compliance requirements, including reporting the data breach to the Institutional Review Board (IRB), and, in certain circumstances, to each individual whose data was compromised. The data provider may require additional security protections or terminate access to the data. There may, in some cases, be financial and/or criminal liability to the data provider and/or the research subjects.³

Sensitive data are vulnerable to both inadvertent disclosure and targeted attacks

If data security protocols are not adhered to, data may be disclosed through email, device loss, file-sharing software such as Google Drive, Box or Dropbox, or improper erasure of files from hardware that has been recycled, donated or disposed of. All hardware that comes into contact with study data should remain protected including: laptops, desktops, external hard drives, USB flash drives, mobile phones, and tablets. Theft or a cyber-attack may target either a researcher’s specific data set or the researcher’s home institution more generally and inadvertently sweep up the researcher’s data set in the course of the attack. Sensitive data must be protected from all of these threats.

Minimizing the research team’s contact with sensitive, individually identifiable data may substantially reduce the potential harm caused by a data breach and the required data security measures that need to be put in place. This will often simplify and accelerate the research data flow.

Reduce the data security threat-level a priori by acquiring and handling only the minimum amount of sensitive data strictly needed for the research study. Researchers may, for example, request that the data provider or a trusted third party link particularly sensitive individualized data to individual treatment status and outcome measures, so that the researchers themselves do not need to handle and store the sensitive data.

De-identifying data

Separate Personally Identifiable Information (PII) from all other data as soon as possible

Data poses the most risk when sensitive or confidential information is linked directly to identifiable individuals. Once separated, the “identifiers” data set and the “analysis” data set should be stored separately, analyzed separately, and transmitted separately.⁴ Once separated, the identifiers should remain encrypted at all times, and the two data sets should only meet again if necessary to adjust the data matching technique. Tables 1, 2, and 3 illustrate this separation. J-PAL hosts programs for searching for PII in Stata and in R on a GitHub repository.

Paper-based surveys should also be designed in a way such that PII is removable. Refer to Figure 1 for a mock-up of survey design. All direct identifiers such as name or Social Security Number and contact information such as address or telephone number should appear on a separate cover sheet. The cover sheet and any consent form should be separated from the main questionnaire as soon as possible – ideally within 24 hours. As described below, participants will be assigned study IDs (listed on both sheets) so that the research team can match and re-identify the data if needed. A crosswalk document will contain the study ID link between these two sections and will be stored in a separate location from both survey halves to ensure confidentiality.

In order to maintain the ability to re-identify the analysis data set, a unique “Study ID” can be created by the researcher, data provider, or implementing partner

This ID should be created by a random process, such as a numbered list after sorting the data on a random number, or through a random number generator. This ID should not be:

• Based on any other characteristic of the data, such as numerical or alphabetical order, or a scrambling or encryption of Social Security numbers or other uniquely identifying codes
• An arbitrary mathematical function
• A cryptographic hash⁵

One method for creating Study IDs is:

1. Create a random number from a physical source (e.g., dice) or from a pseudo-random number generator (e.g., in Stata). Random number generators may change between software versions; note or specify which version of the software used. (e.g., write a command “version 14” in the Stata do-file).
2. Use the first random number as a “seed,” and use a pseudo-random number generator (e.g., in Stata) to sort the observations.
3. Use another random number as a second “seed,” and use a pseudo-random number generator to
   create a Study ID.
4. Ensure each Study ID is unique (e.g., using the -isid- command in Stata).

J-PAL and IPA’s randomization exercise in Stata includes the creation of Study IDs using this process.

Depending on how the Study ID is created, it may be essential to maintain a secure crosswalk (i.e., mapping/decoding) between the Study ID and PII. This crosswalk should be guarded both to ensure confidentiality, and to insure against data loss. Innovations for Poverty Action (IPA) has a publicly-available Stata program on GitHub that automates the separation of PII from other data and the creation of a crosswalk.

Researchers have many options for secure data storage and access. Relevant considerations for choosing among these options include: the sensitivity of the data, applicable compliance requirements, the research team’s technical expertise, internet connectivity, and access to IT expertise and support.

• Encryption is the conversion of data into a code that requires a password or pair of “keys” to decode, and is a requirement for all J-PAL-implemented projects.⁶ Data may be encrypted at many levels, at multiple stages of the data lifecycle, and through a variety of software and hardware packages. 
• Device-level (whole-disk) encryption. Computers, flash drives, tablets, mobile phones, and any other hardware for data storage and/or primary data collection may be whole-disk encrypted. This method protects all files on the device, and requires a password on device start-up. For tablets used in primary data collection, an application such as AppLock can be used to prevent users from accessing other applications during data collection. This protects data from being transferred across applications. The research team should also enable remote wiping capabilities on these devices in case of loss or theft.⁷ After installation and implementation, whole disk encryption should not materially affect the user experience. Methods and software available for whole-disk encryption vary by hardware type. Researchers are advised to contact their institution’s IT department for advice or assistance.
• Cloud storage. Many cloud storage providers including Dropbox, Box, and Google Drive have configured their platforms to comply with various industry, federal, and international regulations to keep files secure on the cloud (while data will still need to remain encrypted at all endpoints). Some of these services allow users to “upgrade” to a specific level or type of data security compliant with regulations such as the Health Insurance Portability and Accountability Act (HIPAA) or the Family Educational Rights and Privacy Act (FERPA). Without a formal agreement to store data in compliance with a specific set of regulations or other file-level encryption, simply storing files using these services is not a fully secure option for sensitive data. The original data provider and any reviewing IRBs should be consulted prior to initiating agreements with cloud-storage providers. For more information on cloud storage services & security:
  • Box (and HIPAA Specific Overview)
  • Dropbox (and HIPAA Specific Overview)
  • Google Drive (and HIPAA specific Overview)
• Folder-level encryption. While cloud storage tools encrypt the connection and files “at rest” on their systems, they retain the encryption keys, which technically gives their employees read access to all files saved on their servers. To address this, tools including Cryptomator and VeraCrypt ⁸ encrypt files before they are stored in the cloud. VeraCrypt is free and open-source​, while Cryptomator has both a free and paid version. 
• File-level encryption. While whole-disk or device-level encryption encrypts all files on a device, it does not protect the files once they leave the device--for example, while they are in transit or being shared with another researcher. File-level encryption applies to specific files, and facilitates data sharing. Proper use of file-level encryption requires strong protocols for password sharing and for unlocking and relocking files before and after use. Options for file-level encryption include PGP-Zip ⁹ and 7-zip.
• IT-administered options. For researchers with access to a professional IT team, and whose team members have access to reliable, fast internet, IT-administered options may be preferable. These options allow researchers to delegate the administration of a data access and storage solution to IT experts. IT administrators may also be able to provide several additional levels of data protection. As with cloud storage, IT staff may have access to all data on a server, including PII. Researchers should be sure to understand who has access to the data, and maintain as much direct control as possible to prevent compliance issues or accidental data breaches.

Institutions may offer space on a server or provide a location to host a server. Storing data on such a server may be preferable to relying on laptops or desktops and cloud storage to maintain data. Depending on the institution, the IT department may be able to provide secure remote access for off-campus users, automated secure backups of data, and encryption.

Access to these servers is typically automatic when connected over an official institutional internet connection. Off-site access requires the use of a Virtual Private Network (VPN). This may provide additional layers of security by encrypting all network connections and requiring two or more types of authentication (e.g., a password and a code sent via text message). Data will still need to be encrypted at both endpoints – i.e., the server or files on the server must be encrypted, and any data transferred to or from the server to another server or hard drive must be encrypted at those points.

Additional features that may be available upon request include:

• Inactivity timeouts for remote access
• Nonretrievable passwords. If a user forgets his or her password, the password is reset by the system, rather than the original password being returned.
• Password expiration settings that require a new password be created on a regular basis.
• Restriction on the number of password guesses permitted before account lockout.
• Access logs that describe who signed in, from where, and when.

IT or data managers may be able to grant access permissions to specific users for specific files or folders on the server. This level of control would enable teams to share general access to a folder while limiting access to identified data to a specific subset of the team. Seek out your IT department’s official recommendations regarding passwords and permission, such as IS&T Policies for MIT projects.

Data must be protected both when at rest and in transit between the data provider, research team members, and partners. Data that are encrypted while at rest on a whole-disk encrypted laptop, or on a secure server, will not necessarily be protected while being transmitted. The options presented below may vary in their level of security.

Unsafe transmission methods include:

• Email without encryption
• Uploading unencrypted data to Dropbox or Box (no matter how quickly the data are deleted afterwards). See Cloud Storage under Data storage and access.
• Mailing unencrypted media devices (e.g., CDs, USB memory sticks, flash drives, external hard drives)
• Password-protected Excel file

Safer transmission methods include:

• Secure Shell File Transfer Protocol (SFTP), including Secure Shell (SSH) or Secure Copy (SCP).
• Many universities provide SFTP support for SecureFX.
• Uploading an encrypted file to Dropbox or Box
• Emailing an encrypted file, and sharing the password separately and securely
• Mailing encrypted files loaded onto encrypted devices
• Survey software with encryption features, such as SurveyCTO, that supports encryption during data collection and transmission to a central server

Communication and data sharing with partners

Many research partners, such as service providers, survey enumerators, and holders of administrative data, have had minimal prior exposure to data security or data sharing protocols. It is best practice to develop a data sharing and security protocol with these partners, and to guide them in understanding their role in data security. All partners handling or transmitting data should be informed of and trained on data collection, storage, and transfer policies agreed upon for the study. Request that partners notify the research team before sharing any data to ensure compliance with the data protocol. Teams should communicate with each other and with partners by referencing Study ID numbers rather than using PII. Consider developing standard operating procedures for checking for and responding to breaches in following the agreed upon method for sharing data. For example, if partners share data in a non-secure way or if unauthorized data are disclosed to researchers or partners. This will allow staff to respond quickly in the event of a breach. A standard operating procedures document should include:

1. Process for sharing data and receiving updates
2. Process for verifying data set does not contain unauthorized information prior to downloading, if possible
3. Timeline for reviewing new data for unauthorized information or PII
4. Plan for notifying the source of the breach and requesting corrective action to prevent future breaches
5. How files with unauthorized information will be removed and destroyed

Personal device security

There are several simple steps researchers and their staff can take to ensure their machines remain secure and to minimize possible weak points. These steps include:

• Use a password-locked screensaver and timeout lock.
• Install and maintain antivirus software. MIT currently recommends Sophos; other institutions may support or recommend alternatives. Keep this software up to date, and allow it to perform regular checks.
• Use a firewall. Most operating systems (including Windows 10, macOS, and Linux) have built-in firewalls.
• Keep all software up to date. Most computers and platforms regularly check for new versions of software. New versions are often created to fix security problems or other known issues.
• Don’t install or run programs from untrusted sources.

IT departments generally have recommended software to help secure personal devices and may be able to assist with updating this software or may push automatic updates.

Password policies

Strong passwords are essential to ensuring data security. A different password should be used for each high-value account. For example, the passwords for Dropbox, email, institutional servers, and encrypted files should all be different.

The National Institute of Standards and Technology (NIST) published revised guidelines for passwords in 2017. These guidelines and the underlying rationale are explained in more approachable language in a NIST staff blog post.

In general, strong passwords should:

• Be at least eight characters, but preferably much longer
• NOT contain or solely comprise:
  • Dictionary words in any language, even with a varied capitalization scheme or with numbers or symbols substituted for letters (e.g., 1 for l, @ for a, 0 for O)
  • The name of the service or related words
  • Your name, username, email address, phone number, etc. (forwards or backwards)
  • Repetitive or sequential letters or numbers

Do not forget your password

Strong passwords may be difficult to remember. When using some software, a forgotten password is completely irretrievable and means the loss of all project data.

Store and share passwords securely

An unencrypted, password-protected Excel file of passwords is not a secure way to store or share passwords. Passwords should never be shared using the same mechanism as file transfer, nor should they be shared over the phone.

Password storage systems such as Bitwarden and 1Password offer a secure way to create, manage, and store passwords online. On this webpage and mobile application, notes and passwords also can be securely shared with specified teammates. A hard copy of a password list, locked in a safe, is another secure option.

Preventing data loss

In addition to securing against outside threats, preventing data loss is an essential component of data security. Data and crosswalks between study IDs and PII should be backed up regularly in at least two separate locations, and passwords must not be forgotten.

Cloud-based backup tools such as CrashPlan and Carbonite offer a range of options for data backups and may offer additional packages to back up data for longer periods of time to protect against the unintentional erasure of data. Cloud-based storage tools such as Box, Dropbox, and Google Drive offer packages to back up data for several months or more, and may insure against unintentional erasure of data if it is noticed within the backup time period; these storage tools are not true backup tools as they do not keep deleted files forever. Institutional servers may also have data backup plans, and device-level backup plans are also available. Backing up data to an encrypted external hard drive (stored in a separate location from daily computers) is an option for low-connectivity environments.

The IRB or data provider may dictate whether and when data must be retained or destroyed. PII linkages should be erased when they are no longer needed. Simply moving files to the “recycle bin” and emptying the bin is not sufficient to thoroughly erase sensitive data. There are several software options for removing all files. For example, MIT maintains recommendations for removing sensitive data. Some IT departments may offer support for secure removal and disposal services. For paper-based surveys, J-PAL recommends that hard copies of PII cover sheets, questionnaires, and study ID crosswalks be destroyed within 3-5 years of the end of a project (or as committed on IRB protocol).¹⁰

The data provider will need to be confident that all files have been securely removed and no additional copies have been retained. In order to document data erasure, some researchers have taken screenshots of the removal process.

Data Use Agreements (DUAs) and IRBs often require researchers to provide a description of their data security and destruction procedures, and some may include specific requirements on these processes dependent on the sensitivity of requested data.¹¹ This section provides examples of descriptions of data management plans drawn from approved DUAs. This language is provided for informational purposes only; it is not necessarily comprehensive nor feasible in all environments. Please refer to your university’s (and/or department’s) research support center, libraries, or IT department for detailed protocols, potential templates, and descriptions of what is feasible, required, and sufficient at your location. Additional external resources on describing data security plans are in the "Resources for data security" section at the bottom of this page.

Last updated May 2023.

These resources are a collaborative effort. If you notice a bug or have a suggestion for additional content, please fill out this form.