By Mark Newton

Data integrity cannot be achieved without good system administration.  The administrator (“admin” for short) provides the oversight of systems to assure they remain controlled, and as a result, critical data is protected from unauthorized creation, deletion or modification.


Although it can vary, the admin often is responsible for implementing access controls and configuration controls.  The admin often reviews records for unapproved access attempts and failed transfers of information.  In short, they guard the system.  Their work is critical to preserving controls that ensure data integrity.


Like any oversight function, objectivity is needed for an effective admin—it is their duty to defend the system and its data.  Therefore, an admin with close friends in a business team is a problem for conflicts of interest.  If someone needs access today for a priority project—but their training is not complete—the team might feel pressured to ask for a “special exception”. Now the admin has a conflict: either be a team player or be an admin.  Procedural controls may not be properly observed when the admin has to sit every day with the people making the request and those people can influence performance reviews as well.

The organization must set up the admin for success.  The admin should ideally sit in an area close by—easily accessible—but not with the team that uses the system.  In a small firm lacking dedicated resources, someone from a different group can manage the system(s): someone in Group A is admin for Group B, and vice versa.

Another issue is the admin who also can perform business actions on the system.  This is a conflict—how can you be system guardian when acting as a user?  Admittedly, some COTS systems are designed to allow the admin to go anywhere within the application.  You can only limit admin actions for these systems with procedural controls and training.  Some systems can be configured to prevent the admin from executing business functions on the system.  If available, this should be done to eliminate one potential data integrity gap.


Several Warning Letters list defects in system configuration as a data integrity gap(1).  The person typically responsible for managing the configuration is the admin.  Most critically, they manage the audit trail for post-collection modification/processing of raw data.  It is essential that an admin periodically review the system configuration to assure that it provides a complete record of testing, as required by predicate rule regulations.  Since COTS software packages can vary widely with regard to configuration management, diligence and good documentation are necessary to assure that a configuration remains compliant throughout its useful life.  The reward is a system that functions as intended, able to detect aberrant activities that place data integrity at risk.

In summary:  (1) The system administrator should be independent of the supported business area to eliminate potential conflicts of interest;  (2) If possible, the system should be configured to prevent the administrator from performing business activities; (3) Verify that audit trails are enabled—especially audit trail activities that involve changes/calculations related to raw data after its collection.


(1)    Example FDA Warning Letters include Micro Labs Ltd (Jan 2015), Posh Chemicals (Aug 2013), USV Ltd (Feb 2014), Wockardt Ltd (Jul 2013), Novacyl Wuxi Pharmaceutical Company (Dec 2014).

Are you looking for a hands-on approach for identifying, mitigating, and remediating potential causes of breaches in data integrity?

Don’t miss this special half-day Data Integrity Workshop focused on key data integrity issues facing the pharmaceutical product lifecycle. This interactive workshop will identify important regulatory issues impacting data integrity, answer key questions surrounding current expectations, and provide an overview of the Application Integrity Policy.  Learn more about the Data Integrity Workshop and how to register.