Although the overall scope of 21 CFR Part 11 has been narrowed and FDA announced enforcement discretion for certain requirements,
most technical controls mandated by the original rule remain unchanged. Limiting system access to authorized personnel continues
to be a strong requirement for compliance with Part 11. The implementation decisions must be based on a documented risk analysis.
Whether Part 11 applies to a certain system or record depends on the predicate rules (such as cGMP, GLP, and GCP) and business
There are two aspects to limiting access to a computer system: physical and logical security. Physical security requires access
controls to facilities, which are standard in regulated environments and accredited laboratory facilities. It is virtually
impossible for an unauthorized individual to walk into a pharmaceutical manufacturing or drug development site. In contrast,
logical security minimizes the chances of accessing data in a protected area and inspecting or manipulating records. Dedicated
logical security mechanisms built into data management systems are required to minimize the possibilities of accidental or
intentional misuse, error, or fraud. After 21 CFR Part 11 became effective in 1997, FDA started citing logical security violations
as unacceptable risks to product quality:
Table 1: Mandatory technical controls for Part 11 compliant systems and examples of resulting user requirements
"Failure to establish and maintain procedures to control all documents that are required by 21 CFR 820.40, and failure to
use authority checks to ensure that only authorized individuals can use the system and alter records, as required by 21 CFR
11.10(g). For example, engineering drawings for manufacturing equipment and devices are stored in AutoCAD form on a desktop
computer. The storage device was not protected from unauthorized access and modification of the drawings."1
Secure access to information systems is of utmost concern for IT personnel in charge of the implementation, administration,
management, and maintenance of those systems. Modern operating systems support many security aspects but require knowledgeable
and careful management and configuration. Without appropriate service packs, configuration settings, and carefully designed
security and password policies, operating environments are vulnerable.
Generally, access security in most modern IT systems is governed through a user account management system. Every authorized
user on the system is assigned an appropriate login — typically, a user name or ID and a password. System administrators assign
appropriate login credentials. If a user ID is combined with a password only known to that individual, the combination is
unique and can be used as the equivalent of a handwritten signature — provided the company has an appropriate policy and
documented with FDA its decision to use electronic signatures in accordance with Part 11.
In most professionally managed IT environments today, policies and conventions, along with the built-in functionality of the
operating systems, ensure the uniqueness of user ID and password combinations. Furthermore, operating systems such as Windows
2000 offer application programming interface (API) functions, allowing application programmers to directly leverage the user
authentication and access security functions of the underlying infrastructure, rather than duplicating such mechanisms.
When implementing access security, the data management system ideally should provide the capability to reuse existing operating
system security mechanisms. This prevents the multiplication of effort involved in administering users and their access rights
within and outside the regulated environments. Even in analytical laboratories, corporations frequently need to manage distributed
teams collaborating across sites, cities, or even continents.
Operating systems typically employ access control lists (ACL) or permissions to grant or prohibit access to specific records
on a per-user basis. This ensures that users can modify their own records, but, at most, only read the records of other users.
Role- and Object-Based Security
Role-based and object-based security settings can be used to manage access and confidentiality of records. Role-based security
schemes manage access rights of all application users based on their respective job roles, responsibilities and training.
Examples of such roles are "chemist," "senior analyst," "study director," "technician," or "system manager."
Role-based security schemes are especially practical for structured environments where the distribution of work is strictly
defined and most tasks are routine with predictable results, as is the case of manufacturing or quality control environments.
A technician may be assigned to prepare instruments for analysis (for example, equilibrate a column or calibrate a detector),
schedule sequence analyses on an instrument, and conduct a first-pass review of the data. A senior scientist may be assigned
to develop new methods, implement custom calculations, and sign off on the second-pass review of the results.
Object-based security governs which users (or user groups) can access specific "objects" managed by the system. For instance,
data from project A may be modifiable only by users from department A but readable by some users in department B. Role-based
and object-based security schemes can then be combined with automated audit trail and electronic sign-off functions (see Figure
1). Configurable, role-based access security allows the organization to decide which tasks are permissible according to users'
job roles. The tasks that require an electronic signature should be configurable according to the organization's policies
and business practices, not dictated by the data system supplier.
Figure 1: Access security combined with automatic audit trail and electronic sign off
As the records managed by a data system (raw data, results, and the meta-data that transforms the former into the latter)
have intrinsic dependencies, it is impossible to control and manage them from outside the application. Therefore, a data system
itself should manage the integrity and security of its records, using its internal knowledge of how the individual pieces
are linked. Otherwise, the integrity of results and raw data have to be manually "emulated" by a knowledgeable system manager
(for example, by relying on a file server and trying to set file permissions appropriately).
Solutions that are merely based on standard file server functionality can be very dependent on manual or semi-manual data
organization and therefore more susceptible to human errors than integrated ones.