A Secure way to maintain Data Integrity while using Shared User Accounts

#A Secure way to maintain Data Integrity while using Shared User Accounts

Data Integrity

According to the US Food and Drug Administration (FDA), “ensuring data integrity is an important component of industry’s responsibility to ensure the safety, efficacy and quality of drugs” *1 and in recent years the FDA has found increasingly more violations involving data integrity. Because data integrity is a too broad of a topic to deal with in a single blog we will focus on one specific aspect of it: data integrity for systems that use shared user accounts. Furthermore, we will focus on addressing the requirement that data must be retained as “original records”, “true copies” or “other accurate reproductions of the original records” (“reliable and accurate data”).*1

The FDA defines data integrity as:

”The completeness, consistency and accuracy of data. Complete, consistent and accurate data should be attributable, legible, contemporaneously, recorded, original or a true copy and accurate (ALCOA)”. *1

During development or production of pharmaceutical products it is important that all used data is correct, available, accessible by authorized user only, and therefore can be relied on in decision-making. To achieve this, data integrity must be ensured.

If data integrity cannot be ensured, than the possibility exists that the produced /developed products do not meet the quality requirements and/or do not work as intended. Or worse, the pharmaceutical product may have properties that have a negative effect on patients’ health. This is why regulatory authorities are currently focusing on data integrity.

Thus, the importance of reducing your data integrity risks, and ensuring controls are correctly implemented and appropriately managed throughout the entire record life cycle is very clear.

Shared User Accounts

Data integrity while using shared user accounts is a difficult one. Shared user accounts could be an Operating System (OS) - or application user account that are not specific for one user, but are used by more instead. 

Some computerized systems are used with shared user OS accounts e.g. because the application software must be running 24/7, other software is only working when it is run with an administrator account (this is a user account with all possible user rights) or an account with elevated rights (more user rights than a normal locked down user). This results in increased data integrity (and security) risks.  Using such a computerized system gives the users the possibility to (accidentally or deliberately) alter or delete data stored on local hard drives.

Furthermore, if someone is logged in with a shared user account it is not registered which specific user it is. If a user is editing data, it is only logged that that shared user account did the editing, and not which actual user. So it cannot be checked who was the one responsible. Therefore, measures must be taken to avoid this.

Security software

One of the measures to  implement is to install security software that is designed to limit the rights of the users on the computerized system, while the rights of the application software stay the same.


  • User rights: A set of rules defining what a user can or cannot  do and for what folders of a computerized system  these rules apply, such as read, write and delete.
  • Software rights: A set of rules defining what an application can or cannot do and for what folders of a computerized system these rules apply, such as read, write and delete.
  • Both sets of rules can be set independently.

The security software acts as a ”point-police man” between the operating system (Windows) and the application software regulating the users and the application software, so to speak. With this security software, it is possible to:

Set the rights of the application software:

  • Define which folders the application software can access and with which rights;
  • Define which Windows dialog screens the application software is allowed to use (e.g. “Save As” window).

Set the user rights

  • Define which applications can be used;
  • Define which folders the user can access;
  • Define if executable files can be started or not;
  • Define network access (network folders, intranet and internet).

How the security software enforces the rules to meet compliance can be configured too:

  • Define if the application software is started automatically or a menu with several applications is presented.
  • Define if besides the applications software other software or the explorer may be used.
  • Define which phericals (USB sticks, DVD, Mobile Devices, etc. may be connected to the system.

To illustrate this theory pretend you’re using application software (DataPro900) that is run under a shared OS user account with elevated user rights. The steps taken to configure the security software would be:

  • Configuring the security software in such a way that its interface is started on booting of the system. Users can only start DataPro900 or File Manager which is a secure replacement for Windows Explorer;
  • Selecting which folders the users can access using File manager, in this case the directory with the data files of DataPro900. File Manager is configured in such a way that these files can only be read; no files can be edited or deleted. No executable files (e.g. .exe, .com, .bat files) can be executed.
  • Blocking system critical key combinations
    Blocking system critical key combinations
  • Blocking internet access, but allow intranet access.
  • The users cannot get on internet and accidently download a virus or download software that could compromise the integrity of the computer and therefore also data integrity;
  • Locking CD/DVD drives and blocking USB drives.
  • The users cannot accidently introduce malware or a virus from a CD/DVD, Phone, USB drive or use those media to install software that could compromise the integrity of the computerized system and therefore the data integrity;

When the system is rebooted after this configuration, the following start-up screen is presented:

As you can see the system is completely locked down, only the DataPro900 application software and File Manager can be started.

The security software has an interface that makes configuration rather straightforward, you just have to tick or untick the options you want to set for the software. The interface has several screens where you can set the different options you want to use for your software.  This security software stores its configuration in HTML language. The main advantage of the use of the interface is that no prior knowledge of HTML is required to configure the software. 

Ofcourse, knowledge of the application software and the system it is run on is needed because this knowledge is needed to guarantee the best possible protection when using this security software.

For an example of one of the interface screens, see the picture below.


In the case described above it is possible to make computerized systems with shared user accounts more secure, reliable and compliant with GxP regulations, when using security software. 

Data integrity is maintained because users have “reliable and accurate” *1 data to work with, which cannot be altered from outside the software application or the File Explorer.

Shared user accounts need to be assessed on a per system basis. E.g. The above procedure will not completely fix the problem when the application software uses shared accounts, like accounts based on roles (e.g. Analyst, Study Director, Lab Administrator). Then the application software itself is not compliant and that cannot be fixed by installing the security software. The advice then is to investigate new application software and make sure it has all functionality before taking it into use. At Xendo we developed and use standard lists to check if systems comply with 21 CFR Part 11 and Annex 11 for this purpose. Ideally, when starting from a  green field, infrastructure and application should both be assessed before deciding upon a computerized system to use.

*1 FDA Data Integrity and Compliance With CGMP Guidance for Industry DRAFT GUIDANCE

Blog by:  Anton van Rosmalen - Consultant at Xendo
Contact: Joost Havers - Managing Consultant at Xendo

Subscribe to newsletter