The principle of least privilege (PoLP) refers to an information security practice of restricting a user to the minimum levels of access and/or permissions they need to perform their job. For example, a data entry user should not have permission to export data.

When implemented thoughtfully, the principle of least privilege (also referred to as the principle of minimal privilege or the principle of least authority) strikes a balance between 1) the usability of a software application, by simplifying how the user interacts with the software and reducing the impact of human error, and 2) the implementation of security protections, by enforcing safeguards to protect critical data, configuration settings and critical components of the software's operational performance. 

Applying the principle of least privilege in the context of a REDCap project is critical to 1) maintaining the integrity and validity of the project build, 2) preventing data quality and data loss issues, and 3) helping users comply with regulatory requirements and OHSU security and privacy policies.

In practical terms, to apply the principle of least privilege means the project point person uses the project's User Rights module to assign each user permission to only the tools or modules they need to perform their job as it relates to their responsibilities for that particular REDCap project.

Considerations for Setting Permissions

1: Consider the activities, in the list below, that are typically involved in collecting data for a research study: 

  • Data entry
  • Data monitoring/data collection monitoring
  • Data clean up
  • Data analysis
  • Developing and/or managing the tool or tools for data collection, in this case a REDCap project.

2: Consider the commonly used REDCap modules or tools in relation to the data collection activities listed above.

ActivityREDCap Modules/Tools/Functionality
Data entry
  • Create & Edit Records
  • Data Import Tool
  • File Repository
Data monitoring
  • Data Reports
  • Data Quality Rules
  • Stats & Charts
  • Record Locking
  • File Repository
  • Survey projects > Survey Distribution Tools
Data clean up
  • Create & Edit Records
  • Data Reports
  • Data Quality Rules
  • Data Resolution tool
  • Record Locking
  • File Repository
  • Survey collection > Edit Survey Response
Data analysis
  • Data Exports
  • Stats & Charts
Developing and/or managing
the REDCap project
  • Project Design & Setup
  • Logging
  • User Rights
  • Survey forms
  • Survey Project > Survey Distribution Tools
  • Optional, advanced or external modules (such as Randomization, Alerts and Notifications)

3: Consider institutional security and privacy policies and regulatory requirements, such as:

  • All users must be listed on the protocol.
  • All users must be up-to-date with trainings required by the institution, such as CITI trainings, Security and Privacy training, HIPAA training, etc.
  • Users are responsible for the data they download/export. If the data download/export includes protected health information (PHI) or any other type of restricted information, the user must be up-to-date with the institution’s security policies that define which devices are secure and in compliance for receiving/storing the restricted data.
  • Sharing user accounts or sharing passwords is prohibited by institutional security policies. 

4: Consider which users have completed trainings related to REDCap

  • Users assigned Project Design and Setup permissions should have completed our Basics training.
  • Users assigned Survey Distribution permissions should have completed our Survey training. 

5: Consider managing access for users accounts who have been suspended 

It's important to manage access for user who's accounts are tagged as being suspended because should the user's account be re-activated they would have access to your project. There are two approaches:

  1. Remove the user from the project 
    1. Entries for the user's activity activity will be retained in the project's Logging file. However, you will not be able filter the Logging file in REDCap by their username.
  2. Set an expiration for the user.
    1. Entries for the user's activity activity will be retained in the project's Logging file, and you will be able filter the Logging file in REDCap by their username.

Apply Best Practices

  1. General Guidance for All Projects

    1. User management is an ongoing activity and the project point person should monitor users assigned to the project and permissions assigned to each user.
    2. If a tool or module is not used by anyone, do not give anyone permission to that tool.
    3. If more than one user will be performing the same activities, such as data entry, create a role.
    4. No more than 2 users (the project point person and their back-up) should be assigned Project Design and Setup permissions.
    5. No more than 3 users (the project point person, their back-up, and another user with REDCap training) should be assigned User Rights permissions.

  2. Guidance for Specific Modules/Permissions

    1. Centralize survey distribution so no more than 3 users (the project point person and up to 2 other staff helping manage survey distribution) are assigned Survey Distribution permissions.
    2. Only a user with Basics and Survey training, and up-to-date with the wiki training for e-consent, should edit an e-consent survey.
    3. Multi-site Data Collection
      1. Use Data Access Groups (DAGs) if you are collecting data at more than one study site. 
    4. Randomization Module
      1. Once the allocation files have been uploaded and the test allocation file has been validated, the best practice is to disable, Setup permissions, for all users. This is because the allocation files can be downloaded from the Setup page while the project is in development. Keeping the allocation sequence concealed prevents selection bias, maintains blinding, and protects the integrity of the study's results by removing the potential for conscious or unconscious influence over participant assignment. 
    5. Delete Rights
      1. Don't enable ahead of time or leave enabled for any user permission to rename and delete records or form delete permissions.
        1. Renaming a record means editing the record id.
        2. Leaving these permissions enabled, by default, for users elevates the risk of inadvertent data loss from a user accidentally deleting a record or editing the record id to an be the id assigned to another participant.
        3. To delete or rename a record, enable the appropriate permission, delete or rename the record, and then immediately disable the permission.
        4. To delete form data, enable the permission for the specific form, delete the data, and then immediately disable the permission.