SOP for Computer System Control Policy (Physical and Logical Security)

In short: This example SOP sets out how a pharmaceutical plant can control physical and logical access to GxP computerised systems: who may enter, who may log in, what each role may do, and how access is reviewed and withdrawn. It is an illustrative template. Adapt every value to your own quality system, your validated systems and a documented risk assessment.

Regulatory basis

A computer system control policy is the written answer to a simple GMP expectation: only authorised people can use a computerised system, and everything they do can be traced back to them. The main references are:

• EU GMP Annex 11, Computerised Systems (January 2011), clause 12 (Security): physical and/or logical controls must restrict access to authorised persons (12.1); the extent of security controls depends on the criticality of the system (12.2); creation, change and cancellation of access authorisations must be recorded (12.3); and data and document management systems must record the identity of operators who enter, change, confirm or delete data, with date and time (12.4).
• Annex 11, clauses 4.3, 7, 9, 11 and 16: an up-to-date inventory and, for critical systems, a system description that includes security measures (4.3); data secured against damage and regular back-ups (7.1, 7.2); risk-based audit trails (9); periodic evaluation including security (11); and business continuity provisions (16).
• 21 CFR Part 11, section 11.10 (controls for closed systems): limit system access to authorised individuals (d); secure, time-stamped audit trails (e); authority checks (g); and training of people who develop, maintain or use the system (i).
• 21 CFR 211.68(b): controls must ensure that only authorised personnel can change master production and control records or other records held in a computer system, and backups must be kept exact, complete and protected.
• ISPE GAMP 5 (Second Edition, 2022): an industry good-practice guide for risk-based validation of computerised systems. It is not a regulation.

Example SOP

This example SOP is a template. Every figure, role name and setting below is an example in-house criterion, not a regulatory requirement.

1.0 Purpose

To define how physical and logical security of GxP computerised systems is planned, implemented and administered.

2.0 Scope

This SOP applies to all computerised systems used in GxP activities at the plant, including laboratory instruments with software, manufacturing and utility control systems, and enterprise systems that hold GMP records.

3.0 Responsibilities

4.0 Abbreviations and definitions

5.0 Procedure

5.1 Process overview

1. Security management protects the confidentiality, integrity and availability of regulated systems, records and processes.
2. GxP computerised systems and their data must be protected against deliberate or accidental loss, damage or unauthorised change, using suitable physical and logical controls.
3. The extent of the controls is based on risk. Consider at least: the regulatory and business requirements for the intended use, the impact on product quality, patient safety and data integrity, the complexity of the system, the number of users, the potential for a security breach, and the maturity of the technology.
4. A security plan and a security administration SOP are required for each system and support its validation.

5.2 Security plan

The security plan documents the physical and logical controls for one system and is kept current. It includes a description of the data security model:

1. The type of data handled by the system.
2. The types of users.
3. Identification and authentication mechanisms.
4. Authorisation mechanisms.
5. Confidentiality and integrity mechanisms.
6. The availability required and how it is ensured (for example back-up and continuity arrangements).

5.3 Physical controls

Keep physical controls in place to protect the system from loss, damage or unauthorised change. They typically cover:

1. Access to the building and the room.
2. Fire protection.
3. The mechanism used for controlled access (keys, access cards, biometrics).
4. Temperature and humidity control.
5. Electrical backup and UPS.

5.4 Logical controls

Establish logical controls that limit access to authorised users across the whole system life cycle. They apply to hardware, software (including source code), documentation and data. The plan should define the following.

1. Role-based access levels, including special privileges, third-party access and supplier access. The table below shows an example only.

2. Elevated or additional access. Name the groups or individuals who receive elevated rights, such as system administrators. If a user needs a right beyond the default role (for example an analyst who also needs review rights for a defined period), approve and record it case by case.
3. Conflicts of interest. Identify them and the mitigation, for example the same person being able to request, grant and approve their own access.
4. Individual accounts. Assign each account to one person; accounts must not be shared. Describe any account not tied to a person, such as batch-job, interface or administrative accounts, and who is accountable for it.
5. Credentials. User IDs and passwords (or other credentials such as PINs or biometrics) must be strong. Describe the system-enforced minimum length and complexity, restrictions on re-using recent passwords, the password change interval, and the automatic time-out for unattended sessions. Example in-house criterion: at least 8 characters with mixed character types, no re-use of the last 5 passwords, change at least every 90 days, session lock after 10 minutes of inactivity.
6. Data protection. Describe how data stored or transmitted internally is protected against loss or change.
7. System clock. Restrict access to the system date and time settings to named, appropriate personnel.
8. Malware protection. Describe the protection in place (see 5.8).
9. Lock-out. Accounts are locked or deactivated on defined security triggers, such as a breach or a set number of failed log-in attempts. State the triggers and how an account is reset. Example in-house criterion: lock after 3 failed attempts; reset only by the administrator after identity verification.

5.5 Password storage and transmission

1. Passwords must never be stored or sent as plain text in any system or medium.
2. Passwords must be stored in a protected form, using a suitably strong algorithm (for example salted hashing).

5.6 Default accounts and passwords

1. Disable default accounts where possible.
2. If a default account cannot be disabled, change its default password immediately on installation and configuration.

5.7 Unique user identification

1. Every user has a unique user ID.
2. A user ID is never re-assigned to anyone other than the person it was first issued to.
3. Uniqueness must be maintained for as long as the records created by the system are retained. GMP records are kept at least 1 year after the expiry date of the respective product batch (EU GMP Part I, Chapter 4, clause 4.11; 21 CFR 211.180(a)), longer where local law or the marketing authorisation requires. Audit trails are retained as long as the records they relate to.
4. Follow the site’s user ID creation procedure for the detailed steps of creating an ID.

5.8 Software security updates and malware protection

1. When a critical security patch or service pack becomes available, assess its impact on the validated state of the system. Decide on implementation based on risk and handle it under change control.
2. Install and enable anti-virus software on all networked computer systems.
3. Where anti-virus software cannot be installed (for example on an instrument PC with a supplier restriction), document the exception, give the justification and describe the alternative protection, such as network isolation, USB port blocking or controlled media use.

5.9 Public-domain software

Open-source software, shareware or freeware may be introduced only after a documented check that it does not harm the system, its data or its validated state.

5.10 Approval of the security plan

The IT owner and the functional owner approve the security plan to confirm that all appropriate persons have reviewed it, that the plan is accurate and complete, and that remaining security risks and limitations, with their mitigations, are understood and accepted.

6.0 Security administration processes

The security administration SOP covers account and password management and limits access to the system and its documentation to authorised users. It addresses access review, physical security, logical security and, where applicable, electronic signature devices.

6.1 Access review

Access to each secured physical location and to each computer system account is reviewed periodically, so that only authorised people have access and their access levels remain appropriate. The review process states the steps, how the review is documented and what actions follow. Example in-house criterion: review at least every 6 months, and whenever roles change.

6.2 Physical access management

1. Control access to secure locations.
2. Describe how access is requested, how the request is checked against the person’s job function, and who documents and approves creation, change and cancellation of access.
3. Remove access promptly when someone leaves the company or the area, or changes role.
4. Where keys are used, record who issued the key, who received it, which key it was, and the date and time of issue and return.
5. Describe how temporary physical access, for example for a supplier or service engineer, is requested, escorted, limited in time and recorded.

6.3 Logical access management

1. Define how access is requested and how the request is checked as appropriate to the role.
2. Define who documents and approves new access. Creation, change and cancellation of access authorisations are recorded (Annex 11, clause 12.3).
3. Complete the required training before access is granted (21 CFR 11.10(i)).
4. Create or reset passwords with suitable strength and pass them to the user securely; the user changes the initial password at first log-in.
5. Grant temporary access only for the period needed and define how its removal is ensured when the period ends.
6. Remove access that is no longer required in a timely manner.

6.4 Deactivating access

Accounts that are no longer needed are deactivated, not deleted, so that the identity linked to earlier records is preserved.

6.5 Unauthorised access attempts

Monitor unsuccessful log-in attempts and report unauthorised attempts when detected. This is also relevant when electronic signatures are used. The process states the method and frequency of monitoring, the events that trigger a review, who is notified of unauthorised attempts or account deactivation, and the measures taken.

Frequently asked questions

Is a computer system control policy required by law? Neither Annex 11 nor Part 11 asks for a document with this exact name. They require that access is restricted to authorised persons and that this is controlled and recorded (Annex 11 clause 12; 21 CFR 11.10(d) and (g)). A policy and security plan are the usual way to show this.

Can a team share one log-in for a laboratory instrument? No. Shared accounts break the link between data and the person who created it (Annex 11 clause 12.4). Use individual accounts, and describe any technical account that cannot be personal.

Should accounts of leavers be deleted? Deactivate them. Deleting an account can leave records that no longer point to an identifiable person.

How strict should password rules be? Annex 11 does not set numbers. The extent of controls depends on the criticality of the system (clause 12.2), so the settings are a risk-based, documented decision of each site.

Related reading: What Is Data Integrity in the Pharmaceutical Industry, SOP for Backup and Restoration, SOP on Data Integrity.

References

1. European Commission, EudraLex Volume 4, Annex 11: Computerised Systems (revision January 2011), clauses 4.3, 7, 9, 11, 12 and 16.
2. US FDA, 21 CFR Part 11, section 11.10(d), (e), (g) and (i) (eCFR, current).
3. US FDA, 21 CFR 211.68, Automatic, mechanical and electronic equipment (eCFR, current).
4. European Commission, EudraLex Volume 4, Part I, Chapter 4, clause 4.11 (record retention), and 21 CFR 211.180(a).
5. ISPE, GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition (2022).