Data Integrity Starts With User Access

Reprinted with permission from Colgin Consulting, Inc.

User access to databases can impact data integrity and get you in trouble with FDA.

In my next few blog posts, we'll be covering user access and how it can impact data integrity. For starters, let's explore the Principle of Least Privilege. What is it? What happens when it's violated? Finally we'll map out five actions you can take to protect your company.

You may need to pick up some new vocabulary.

Why?

Because it will help you have intelligent conversations with your clients and get better results for your company.

My sad story...

Once upon a time, I was a new statistician in industry assigned to general tox studies.

As I reviewed the study data, I saw "tarry stools."

I read "tarry" as in "to delay" or "to be late."

What the heck? Late rat stools? How would anyone know? My colleagues professed not to know. So I called the Study Director for clarification. Color me red. I'm pretty sure they're all telling that story over a beer to this day.

Let me help you not be that guy when it comes to computer systems.

What is the Principle of Least Privilege?

The Principle of Least Privilege means providing users the minimum access they need to do their work for the minimum time required.

(I'm not a fan of acronyms, but you might see Principle of Least Privilege abbreviated PoLP. Just not in my blog posts.)

The Principle of Least Privilege also applies to computer programs and processes. In this blog post, we'll address only human users.

Violations and Corrective Actions

Violations of the Principle of Least Privilege can result in

• Loss of data integrity
• Loss of data
• Data leakage (you still have the data, but so does your competitor!)

Any of these violations may qualify as a security incident in your organization - be familiar with your policies and procedures so you can involve the right people at the right time. DON'T ACT ALONE! Taking action on your own may cloud the issue and interfere with the effectiveness of any necessary investigation.

In all three cases below, the violations should trigger a review of all user access to quantify the extent of the problem and make all necessary corrections.

Violation 1: User Gets Too Much Access

You're a clinical auditor who has suddenly realized you have investigator access to all sites in the EDC system. You don't think you've created, modified, or deleted any records.

Correcting the Problem

• Log off.
• Notify your management.
• Determine if the problem meets your company's definition of a security incident and, if it does, follow that procedure.
• Someone must
  • Record the fact the problem occurred, including the start and end dates.
  • Change your access to the appropriate level.
  • Review the audit trail for the period in question to determine if you created, modified, or deleted any records.
  • Restore data appropriately and notify the investigator if you changed, modified, or deleted any records. (Remember the predicate rule: eCRFs are the investigator's responsibility!)
  • Figure out how you were assigned the wrong access level.

Violation 2: User Changes Jobs and Retains Access

This is a variation of Violation 1 and demonstrates why the Principle of Least Privilege has a time element attached.

You're a clinical auditor auditing one of your company's providers: a clinical lab. The lab hosts an in-house developed web-based application allowing clinical project teams at your company to view all the data for their assigned studies and download it into Excel. Once a user has access to the system, they can access it from anywhere - their personal smart phone, their home computer, their work laptop, etc. As you review the user list, you notice the name of someone you know well. Unfortunately, they left your company months ago to work for a direct competitor. Whoops!

Correcting the Problem

• Notify your management.
• Determine if the problem meets your company's, or the lab's, definition of a security incident and, if it does, follow that procedure.
• Someone must
  • Record the fact the problem occurred, including the date the user left your company.
  • Revoke their access.
  • Review the system log and audit trails to determine if and how the user accessed data after they left your company. (This goes for all studies to which they had access.) Special note: If the lab cannot provide you this information, the system has a serious design flaw. Your management should consider ceasing its use until it is improved.)
  • If the user did download data after leaving your company (and this is where it gets ugly), the lawyers will step in to help.

Violation 3: Users Share Login ID and Password

You're a GLP auditor auditing one of your company's GLP labs. During the tour, you notice multiple technicians and supervisors interacting with the chemistry analyzer without signing on and off. Through interviews, demonstrations, and record and document review, you confirm they are all sharing the same login ID and password, the account has super user access to all instrument functionality and the access level allows for modification and deletion of data before they are transmitted to the LIMS. How do you know the data are complete and accurate? To whom can you attribute actions?

Correcting the Problem

Let's assume the analyzer offers role-based access, and the lab just isn't taking advantage of it.

• Notify your management and the Study Director.
• Someone must require the lab to implement role-based access.
• See the postcript at the end of this blog post...

(If the analyzer doesn't provide role-based access, you have an even bigger problem. More and more manufacturers are taking heed of regulators' concerns about data integrity and are modernizing their instruments to allow role-based access and good audit trail functionality. Your company may need to upgrade.)

Real Life Examples

For some real life examples highlighted in FDA Warning Letters, see these instances of sharing login IDs:

• Study coordinator used the subjects' login IDs to complete the subjects' e-diaries instead of the subjects.
• Lab workers shared login IDs for high performance liquid chromatograph units, the X-Ray Diffraction unit, and the Windows operating system on the gas chromatography standalone workstations.
• Lab failed "to use separate passwords for each analyst's access to the laboratory systems."

Here are some examples from Europe, in the GMP environment.

• Lab analysts with PC administrator privileges "set the controlling time and date setting back to over-write previously collected failing and/or undesirable sample results."
• Lab had "no limitation of access levels."

And the forecast isn't good....According to Medical Economics, of all the industries in the Standard and Poor's 500, "healthcare and pharmaceutical companies have the worst cybersecurity." And for a European perspective, see "Pharmaceutical firms 'can't keep ignoring information risk'".

Protect Your Company

I'm sure your VP of Quality or Executive Director of Development Quality Assurance doesn't want to have to go to Executive Management or the Board of Director's Audit Committee to explain

• All the subject-recorded data at your highest enrolling site had to be excluded from analysis because the subjects didn't record their data - the study nurse did.
• The biomarker data generated at a contract lab to drive a new indication can't be relied on because no one knows who created, modified, or deleted data.
• Your competition has all the lab data for your oncology program because a clinical team never notified the lab that an employee left your company for the competition.

Here are five actions your company should be taking (and requiring your service providers to take) to protect itself from violations of the Principle of Least Privilege:

1. Have a policy in place requiring use of the Principle of Least Privilege.
2. Have procedures in place to investigate and correct violations of the Principle of Least Privilege.
3. Grant access based on user roles and what they need to be able to do in the system, and only when properly authorized by management.
4. Review access periodically to ensure assigned roles are still appropriate.
5. Revoke access as soon as reasonably possible when users no longer need access.

Postscript

In the GMP environment, regulators are taking a firm stand on violations of least privilege when they can be demonstrated to impact data integrity. At the very least, they require "a retrospective review" of data (see Finding 1). They may require hiring a data integrity consultant (see the end of this Warning Letter) to get to the root of the problem at your entire company. And in the most extreme case, when combined with other quality problems, product may be blocked from a country or an entire region (see official report here).