Getting a Handle on Access Security for 21 CFR Part 11

Feb 15, 2004

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 practices.

Table 1: Mandatory technical controls for Part 11 compliant systems and examples of resulting user requirements
Access Security 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:

"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.

Figure 1: Access security combined with automatic audit trail and electronic sign off
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.

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.

lorem ipsum