개정 사유: GMP/GDP 실태조사관 실무그룹(GMP/GDP Inspectors Working Group)과 PIC/S 위원회는 규제 환경과 제조 환경의 변화를 반영하도록 현행 컴퓨터화 시스템 Annex 11을 개정할 것을 공동으로 권고하였다. 개정 가이드라인은 규제당국의 요구사항과 기대 사항을 명확히 하고, 모호한 점과 일관되지 않은 점을 없애야 한다.

Reasons for changes: The GMP/GDP Inspectors Working Group and the PIC/S Committee jointly recommended that the current version of Annex 11 on Computerised Systems, be revised to reflect changes in regulatory and manufacturing environments. The revised guideline should clarify requirements and expectations from regulatory authorities, and remove ambiguity and inconsistencies.

IT 환경이 끊임없이 바뀌고, 클라우드 서비스 사용이 늘어나며, GMP 활동에 사용되는 컴퓨터화 시스템에 새로운 기술이 도입됨에 따라, 규제 요구사항에 관한 최신 지침과 유럽연합(EU) 회원국과 의약품 실태조사 협력기구(PIC/S) 사이의 공통 접근 방식을 채택할 필요성이 커지고 있다. 개정 Annex 11은 GMP 규제 대상 활동에서 컴퓨터화 시스템을 사용하는 데 필요한 요구사항을 제시하며, 이로써 제품 품질, 환자 안전 및 데이터 완전성을 보장한다.

With an ever-evolving IT landscape, increased use of cloud services, and introduction of new technologies in computerised systems used in GMP activities, there is a growing need for updated guidance on regulatory requirements, and for adopting a common approach between member states of the European Union (EU) and the Pharmaceutical Inspection Co-operation Scheme (PIC/S). The updated Annex 11 outlines the requirements for the use of computerised systems in GMP-regulated activities, thereby ensuring product quality, patient safety and data integrity.

이 Annex는 의약품 및 활성 물질의 제조에 사용되는 모든 유형의 컴퓨터화 시스템에 적용한다.

This annex applies to all types of computerised systems used in the manufacturing of medicinal products and active substances.

2.1. 수명주기 관리. 컴퓨터화 시스템은 사용 전에 밸리데이션하여야 하며, 수명주기 전반에 걸쳐 밸리데이션된 상태로 유지하여야 한다.

2.1. Lifecycle management. Computerised systems should be validated before use and maintained in a validated state throughout their lifecycle.

2.2. 품질위험관리. 품질위험관리(QRM)는 GMP 활동에 사용되는 컴퓨터화 시스템의 모든 수명주기 단계에 걸쳐 적용하여야 한다. 이 접근 방식은 공정의 복잡성, 자동화의 수준과 새로움, 그리고 제품 품질, 환자 안전 및 데이터 완전성에 미치는 영향을 고려하여야 한다.

2.2. Quality Risk Management. Quality Risk Management (QRM) should be applied throughout all lifecycle phases of a computerised system used in GMP activities. The approach should consider the complexity of processes, the level and novelty of automation, and the impact on product quality, patient safety and data integrity.

2.3. 대체 방법. 이 문서에서 요구하는 활동을 대체하는 방법이 같거나 더 높은 수준의 관리를 제공한다는 것이 입증되고 문서화되었다면 그 방법을 사용할 수 있다.

2.3. Alternative practices. Practices which constitute alternatives to the activities required in this document may be used, if they have been proven and documented to provide the same or higher level of control.

2.4. 데이터 완전성. GMP 활동에 사용되는 시스템이 수집, 분석 및 보고하는 데이터를 신뢰할 수 있어야 한다는 것은 매우 중요하다. ALCOA+ 원칙에서 정의하는 바와 같이, 데이터 완전성은 데이터 처리, 신원 및 접근 관리, 감사 추적, 전자서명, 보안 항에서 정한 요구사항을 포함하되 이에 국한되지 않는 여러 주제를 포괄한다.

2.4. Data integrity. It is critically important that data captured, analysed and reported by systems used in GMP activities are trustworthy. As defined by the ALCOA+ principles, data integrity covers many topics including but not limited to requirements defined in the sections Handling of Data, Identity and Access Management, Audit Trails, Electronic Signatures, and Security.

2.5. 시스템 요구사항. 규제 대상 사용자가 자동화하여 GMP 활동을 수행할 때 의존하는 기능을 기술한 시스템 요구사항은 문서화하여야 하며, 구축된 시스템과 그 사용 목적을 온전히 반영하도록 최신 상태로 유지하여야 한다. 요구사항은 시스템 적격성 평가와 밸리데이션의 가장 기본적인 근거가 되어야 한다.

2.5. System requirements. System requirements which describe the functionality the regulated user has automated and is relying on when performing GMP activities, should be documented and kept updated to fully reflect the implemented system and its intended use. The requirements should serve as the very basis for system qualification and validation.

2.6. 위탁 업무. 업무를 위탁하는 경우에도 규제 대상 사용자는 이 문서에 포함된 요구사항의 준수, 그 증거의 유지, 그리고 규제 검토를 위한 증거 제공에 대해 전적인 책임을 진다.

2.6. Outsourced activities. When using outsourced activities, the regulated user remains fully responsible for adherence to the requirements included in this document, for maintaining the evidence for it, and for providing it for regulatory review.

2.7. 보안. 규제 대상 사용자는 GMP 시스템에 대한 새로운 보안 위협을 계속 파악하고 있어야 하며, 필요한 경우 이를 막기 위한 조치를 적시에 시행하고 개선하여야 한다.

2.7. Security. Regulated users should keep updated about new security threats to GMP systems, and measures to protect these should be implemented and improved in a timely manner, where needed.

2.8. 위험 증가 금지. 컴퓨터화 시스템이 다른 시스템이나 수작업을 대체하는 경우, 그 결과로 제품 품질, 환자 안전 또는 데이터 완전성이 저하되어서는 안 된다. 공정의 전체 위험이 증가하여서는 안 된다.

2.8. No risk increase. Where a computerised system replaces another system or a manual operation, there should be no resultant decrease in product quality, patient safety or data integrity. There should be no increase in the overall risk of the process.

3.1. 의약품 품질시스템. 규제 대상 사용자는 GMP 활동에 사용되는 모든 컴퓨터화 시스템과 이에 관여하는 인원을 포괄하는 의약품 품질시스템(PQS)을 시행하여야 한다. PQS에는 이 문서에서 요구하는 모든 활동이 포함되어야 하며, 이에 더하여 다음 사항이 보장되어야 한다.

3.1. Pharmaceutical quality system. A regulated user should implement a pharmaceutical quality system (PQS), which covers all computerised systems used in GMP activities and personnel involved with these. It should include all activities required in this document and in addition, it should be ensured that:

4.1. 수명주기. 품질위험관리(QRM)는 제품 품질, 환자 안전 또는 데이터 완전성에 미칠 수 있는 모든 영향을 고려하여 컴퓨터화 시스템의 수명주기 전반에 걸쳐 적용하여야 한다.

4.1. Lifecycle. Quality Risk Management (QRM) should be applied throughout the lifecycle of a computerised system considering any possible impact on product quality, patient safety or data integrity.

4.2. 파악 및 분석. GMP 활동에서 컴퓨터화 시스템을 사용하는 것과 관련된 위험은 확립된 절차에 따라 파악하고 분석하여야 한다. 위험관리 방법과 도구의 예는 ICH Q9(R1)에서 찾을 수 있다.

4.2. Identification and analysis. Risks associated with the use of computerised systems in GMP activities should be identified and analysed according to an established procedure. Examples of risk management methods and tools can be found in ICH Q9 (R1).

4.3. 적절한 밸리데이션. 밸리데이션 전략과 노력의 정도는 시스템의 사용 목적과 제품 품질, 환자 안전 및 데이터 완전성에 대한 잠재적 위험에 근거하여 정하여야 한다.

4.3. Appropriate validation. The validation strategy and effort should be determined based on the intended use of the system and potential risks to product quality, patient safety and data integrity.

4.4. 위험 완화. 해당되는 경우, GMP 활동에서 컴퓨터화 시스템을 사용하는 것과 관련된 위험은 완화하여 허용 가능한 수준으로 낮추어야 하며, 가능하면 공정이나 시스템 설계를 수정하여 그렇게 하여야 한다. 위험관리 과정의 결과로 적절한 컴퓨터화 시스템 아키텍처와 기능이 선택되어야 한다.

4.4. Mitigation. Where applicable, risks associated with the use of computerised systems in GMP activities should be mitigated and brought down to an acceptable level, if possible, by modifying processes or system design. The outcome of the risk management process should result in the choice of an appropriate computerised system architecture and functionality.

4.5. 데이터 완전성. 품질위험관리 원칙을 사용하여 제품 품질, 환자 안전 및 데이터 완전성에 대한 데이터의 중요도, 고의 또는 비고의적인 변경·삭제·손실에 대한 데이터의 취약성, 그리고 그러한 행위가 발견될 가능성을 평가하여야 한다.

4.5. Data integrity. Quality risk management principles should be used to assess the criticality of data to product quality, patient safety and data integrity, the vulnerability of data to deliberate or indeliberate alteration, deletion or loss, and the likelihood of detection of such actions.

5.1. 협력. 이 문서에서 요구하는 활동을 수행할 때에는 해당되는 경우 관련된 모든 당사자 사이에 긴밀한 협력이 있어야 한다. 여기에는 공정 책임자, 시스템 책임자, 사용자, 주제 전문가(SME), QA, QP, 사내 IT 부서, 공급업체 및 서비스 제공업체가 포함된다.

5.1. Cooperation. When conducting the activities required in this document, there should be, where applicable, close cooperation between all relevant parties. This includes process owner, system owner, users, subject matter experts (SME), QA, QP, the internal IT department, vendors, and service providers.

5.2. 교육훈련. GMP 활동에 사용되는 컴퓨터화 시스템에 관여하는 모든 당사자는 부여된 책임, 업무 및 접근 권한에 상응하는 적절한 시스템별 교육훈련을 받고, 적절한 자격과 경험을 갖추어야 한다.

5.2. Training. All parties involved with computerised systems used in GMP activities should have adequate system specific training, and appropriate qualifications and experience, corresponding to their assigned responsibilities, duties and access privileges.

6.1. GMP 기능. 규제 대상 사용자는 자신이 자동화하여 GMP 활동을 수행할 때 의존하는 기능을 정확하게 기술한 시스템 요구사항 일체(예: 사용자 요구사항 규격(URS))를 수립하고 승인하여야 한다. 이 원칙은 시스템이 사내에서 개발되었든, 상용 기성품이든, 서비스 형태로 제공되든 관계없이 적용하여야 하며, 선형 또는 반복적 소프트웨어 개발 방식 중 어느 것으로 개발되었는지와도 관계없이 적용하여야 한다.

6.1. GMP functionality. A regulated user should establish and approve a set of system requirements (e.g. a User Requirements Specification, URS), which accurately describe the functionality the regulated user has automated and is relying on when performing GMP activities. This principle should be applied regardless of whether a system is developed in-house, is a commercial off-the-shelf product, or is provided as-a-service, and independently on whether it is developed following a linear or iterative software development process.

6.2. 범위와 상세 수준. 정의된 요구사항의 범위와 상세 수준은 시스템의 위험, 복잡성 및 새로움에 상응하여야 하며, 그 기술은 이후의 위험 분석, 규격 작성, 설계, 구매, 구성, 적격성 평가 및 밸리데이션을 뒷받침하기에 충분하여야 한다. 여기에는 운영, 기능, 데이터 완전성, 기술, 인터페이스, 성능, 가용성, 보안 및 규제 요구사항이 포함되어야 하며, 이에 국한되지 않을 수 있다. 관련이 있는 경우 요구사항에는 공정 흐름도(process map)와 데이터 흐름도가 포함되어야 하며, 유스케이스(use case)를 활용할 수 있다.

6.2. Extent and detail. The extent and detail of defined requirements should be commensurate with the risk, complexity and novelty of a system, and the description should be sufficient to support subsequent risk analysis, specification, design, purchase, configuration, qualification and validation. It should include, but may not be limited to, operational, functional, data integrity, technical, interface, performance, availability, security, and regulatory requirements. Where relevant, requirements should include process maps and data flow diagrams, and use cases may be applied.

6.3. 소유권. 시스템을 구매하거나 시스템이 서비스형 소프트웨어(SaaS)로 구성된 경우, 요구사항 규격은 공급업체가 제공할 수 있다. 그러나 규제 대상 사용자는 그 문서를 신중하게 검토하고 승인하여야 하며, 시스템이 있는 그대로 GMP 요구사항과 회사의 업무 절차를 충족하는지, 아니면 구성하거나 맞춤화하여야 하는지를 고려하여야 한다. 규제 대상 사용자는 구축된 버전의 시스템을 다루는 문서의 소유권을 가져야 하며, 필요한 변경을 한 뒤 그 문서를 공식적으로 승인하고 관리하여야 한다.

6.3. Ownership. If a system is purchased or consists of software-as-a-service, a requirements specification may be provided by the vendor. However, the regulated user should carefully review and approve the document and consider whether the system fulfils GMP requirements and company processes as is, or whether it should be configured or customised. The regulated user should take ownership of the document covering the implemented version of the system and formally approve and control it after making any necessary changes.

6.4. 갱신. 요구사항은 시스템이 이후 변경과 맞춤화를 거치더라도 시스템 기능을 완전하고 정확하게 계속 기술하도록 시스템의 수명주기 전반에 걸쳐 갱신하고 유지하여야 한다. 갱신된 요구사항은 시스템 적격성 평가와 밸리데이션의 가장 기본적인 근거가 되어야 한다.

6.4. Update. Requirements should be updated and maintained throughout the lifecycle of a system to ensure that they continue to give a complete and accurate description of system functionality as the system undergoes subsequent changes and customisations. Updated requirements should form the very basis for qualification and validation of a system.

6.5. 추적성. 개별 요구사항, 그 바탕이 되는 설계 규격, 그리고 이에 대응하는 적격성 평가 및 밸리데이션 시험 사례(test case) 사이의 문서화된 추적성을 확립하고 유지하여야 한다. 요구사항을 수집·보유하고 추적성을 쉽게 하는 효과적인 도구의 사용을 권장한다.

6.5. Traceability. Documented traceability between individual requirements, underlaying design specifications and corresponding qualification and validation test cases should be established and maintained. The use of effective tools to capture and hold requirements and facilitate the traceability is encouraged.

6.6. 구성. 시스템 구성(configuration)으로 어떤 기능이 수정되거나 추가되는지(있다면)가 명확하여야 한다. 시스템 기능을 구성할 수 있는 선택 항목은 요구사항 규격에 기술하여야 하며, 선택한 구성은 관리되는 구성 규격(configuration specification)에 문서화하여야 한다.

6.6. Configuration. It should be clear what functionality, if any, is modified or added by configuration of a system. Options allowing configuration of system functionality should be described in the requirements specification and the chosen configuration should be documented in a controlled configuration specification.

7.1. 책임. 규제 대상 사용자가 GMP 활동에 사용되는 시스템에 대해 공급업체의 적격성 평가, 서비스 제공업체, 또는 사내 IT 부서의 적격성 평가 및/또는 운영에 의존하더라도, 이 문서에서 정한 요구사항은 달라지지 않는다. 규제 대상 사용자는 이러한 활동이 제품 품질, 환자 안전 및 데이터 완전성에 초래하는 위험에 근거하여 이 활동에 대해 전적인 책임을 진다.

7.1. Responsibility. When a regulated user is relying on a vendor’s qualification of a system used in GMP activities, a service provider, or an internal IT department’s qualification and/or operation of such system, this does not change the requirements put forth in this document. The regulated user remains fully responsible for these activities based on the risk they constitute on product quality, patient safety and data integrity.

7.2. 감사. 규제 대상 사용자가 GMP 활동에 사용되는 시스템에 대해 공급업체 또는 서비스 제공업체의 적격성 평가 및/또는 운영에 의존하는 경우, 규제 대상 사용자는 위험과 시스템 중요도에 따라 감사(audit) 또는 철저한 평가를 실시하여, 공급업체 또는 서비스 제공업체가 시행하는 절차, 산출물에 관련된 문서의 적절성, 그리고 해당 활동을 반복하는 대신 이를 활용할 수 있는 가능성을 판단하여야 한다.

7.2. Audit. When a regulated user is relying on a vendor’s or a service provider’s qualification and/or operation of a system used in GMP activities, the regulated user should, according to risk and system criticality, conduct an audit or a thorough assessment to determine the adequacy of the vendor or service provider’s implemented procedures, the documentation associated with the deliverables, and the potential to leverage these rather than repeating the activities.

7.3. 감독. 규제 대상 사용자가 GMP 활동에 사용되는 시스템에 대해 서비스 제공업체 또는 사내 IT 부서의 운영에 의존하는 경우, 규제 대상 사용자는 서비스 제공업체 또는 사내 IT 부서와 합의한 서비스 수준 협약(SLA)과 핵심 성과 지표(KPI)에 따라 이를 효과적으로 감독하여야 한다.

7.3. Oversight. When a regulated user is relying on a service provider’s or an internal IT department’s operation of a system used in GMP activities, the regulated user should exercise effective oversight of this according to defined service level agreements (SLA) and key performance indicators (KPI) agreed with the service provider or the internal IT department.

7.4. 문서 접근성. 규제 대상 사용자가 GMP 활동에 사용되는 시스템에 대해 공급업체, 서비스 제공업체 또는 사내 IT 부서의 적격성 평가 및/또는 운영에 의존하는 경우, 규제 대상 사용자는 이 문서에서 요구하는 활동에 관한 문서를 자신의 시설에서 열람할 수 있고 설명할 수 있도록 보장하여야 한다. 이때 규제 대상 사용자는 공급업체, 서비스 제공업체 또는 사내 IT 부서의 지원을 받을 수 있다.

7.4. Documentation availability. When a regulated user relies on a vendor’s, a service provider’s or an internal IT department’s qualification and/or operation of a system used in GMP activities, the regulated user should ensure that documentation for activities required in this document is accessible and can be explained from their facility. In this, the regulated user may be supported by the vendor, the service provider or the internal IT department.

7.5. 계약. 규제 대상 사용자가 GMP 활동에 사용되는 시스템에 대해 서비스 제공업체 또는 사내 IT 부서의 적격성 평가 및/또는 운영에 의존하는 경우, 규제 대상 사용자는 서비스 제공업체와 계약을 맺거나 사내 IT 부서와 승인된 절차를 갖추어야 하며, 그 계약 또는 절차는 다음과 같아야 한다.

7.5. Contracts. When a regulated user is relying on a service provider’s or an internal IT department’s qualification and/or operation of a system used in GMP activities, the regulated user should have a contract with a service provider or have approved procedures with an internal IT department which:

8.1. 시스템에 대한 의존. 규제 대상 사용자가 어떤 사건을 알리는 데 시스템에 의존하는 경우, 컴퓨터화 시스템에 알람을 구현하여야 한다. 이는 사용자가 특정 조치를 취해야 하고, 그 조치가 없으면 제품 품질, 환자 안전 또는 데이터 완전성이 손상될 수 있는 경우에 요구된다.

8.1. Reliance on system. Alarms should be implemented in computerised systems where a regulated user is relying on the system to notify about an event. This is required when the user must take a specific action, without which product quality, patient safety or data integrity might otherwise be compromised.

8.2. 설정. 알람 한계, 지연 시간, 그리고 모든 조기 경고나 경보는 적절한 근거가 있어야 하며, 승인되고 밸리데이션된 공정 및 제품 규격 안에서 설정하여야 한다. 설정, 변경 또는 비활성화는 적절한 접근 권한을 가진 사용자만 할 수 있어야 하며, 승인된 절차에 따라 관리하여야 한다.

8.2. Settings. Alarm limits, delays, and any early warnings or alerts, should be appropriately justified, and set within approved and validated process and product specifications. Setting, changing or deactivation should only be available to users with appropriate access privileges and should be managed by an approved procedure.

8.3. 신호. 알람은 설정된 알람 한계를 넘고 정해진 지연 시간이 지나면 시각 및/또는 청각 신호를 울려야 한다. 신호는 적시에 대응할 수 있게 하여야 하며, 작업 환경에 적절하여야 한다.

8.3. Signalling. Alarms should set off visible and/or audible signals when set alarm limits are exceeded and after any defined delay. The signalling should accommodate a timely reaction and should be appropriate to the work environment.

8.4. 확인. 제품 품질, 환자 안전 또는 데이터 완전성에 영향을 줄 수 있는 핵심 알람은 적절한 접근 권한을 가진 사용자만 확인(acknowledge)할 수 있어야 한다. 확인, 즉 알람을 보았고 적절한 조치를 취하겠다는 확인의 일부로서, 알람을 확인한 이유에 관한 의견을 덧붙여야 한다(12항 감사 추적 참조).

8.4. Acknowledgement. Critical alarms potentially impacting product quality, patient safety or data integrity should only be acknowledged by users with appropriate access privileges. As part of the acknowledgement, i.e. a confirmation that the alarm has been seen and appropriate action will be taken, a comment should be added about why the alarm was acknowledged (see 12 Audit Trails).

8.5. 기록(log). 모든 알람과 확인은 알람 기록에 자동으로 추가되어야 한다. 이 기록에는 알람 이름, 알람 날짜와 시간, 확인 날짜와 시간, 알람을 확인한 사용자의 사용자명과 역할, 그리고 알람을 확인한 이유에 관한 의견이 들어 있어야 한다. GMP에 따라 작업하는 사용자가 알람 기록을 비활성화하거나 편집할 수 없어야 한다.

8.5. Log. All alarms and acknowledgements should be automatically added to an alarm log. This should contain the name of the alarm, date and time of the alarm, date and time of the acknowledgement, username and role of the user acknowledging the alarm and any comment about why the alarm was acknowledged. It should not be possible for users working according to GMP to deactivate or edit alarm logs.

8.6. 검색 및 정렬 기능. 알람 기록은 원래 시스템에서 검색하고 정렬할 수 있어야 하며, 그렇지 않으면 이 기능을 제공하는 도구로 기록을 내보낼 수 있어야 한다. 같은 효과를 제공한다면 알람을 검토하는 다른 방법을 사용할 수도 있다.

8.6. Searchability and sortability. Alarm logs should be searchable and sortable in the originating system, or it should be possible to export logs to a tool which provides this functionality. Other methods of reviewing alarms may also be used, if they provide the same effectiveness.

8.7. 검토. 알람 기록은 승인된 절차에 따라 적절한 주기적 검토를 받아야 하며, 이 검토에서는 알람이 권한 있는 사용자에 의해 적시에 확인되었는지, 그리고 적절한 조치가 취해졌는지를 평가하여야 한다. 검토는 문서화하여야 하며, 그 결과를 평가하여 시스템이나 공정의 성능 저하 또는 제품에 대한 영향을 나타낼 수 있는 경향을 파악하여야 한다. 검토의 빈도와 상세 수준은 제품 품질, 환자 안전 및 데이터 완전성에 대한 위험에 근거하여야 한다.

8.7. Review. Alarm logs should be subject to appropriate periodic reviews based on approved procedures, in which it should be evaluated whether they have been timely acknowledged by authorised users and whether appropriate action has been taken. Reviews should be documented, and results should be evaluated to identify any trends that could indicate negative performance of a system or process, or impact on the product. The frequency and detail of reviews should be based on the risk to product quality, patient safety and data integrity.

9.1. 원칙. 컴퓨터화 시스템의 적격성 평가 및 밸리데이션 활동은 GMP Annex 15에 제시된 일반 원칙을 따라야 한다. 이 활동은 표준 시스템 기능과 구성된 시스템 기능뿐 아니라 맞춤화로 구현된 모든 기능을 다루어야 한다.

9.1. Principles. Qualification and validation activities for computerised systems should follow the general principles outlined in GMP Annex 15. The activities should address both standard and configured system functionality, as well as any functionality realised through customisation.

9.2. 품질위험관리. 컴퓨터화 시스템은 품질위험관리 원칙에 따라 적격성 평가 및 밸리데이션을 하여야 한다. 특정 기능과 시스템 전체에 대한 적격성 평가 및 밸리데이션의 범위와 정도에 관한 결정은 제품 품질, 환자 안전 및 데이터 완전성에 대한 위험을 고려하여, 개별 요구사항과 관련이 있는 경우 기능 규격에 대한 타당하고 문서화된 위해성 평가에 근거하여야 한다.

9.2. Quality risk management. Computerised systems should be qualified and validated in accordance with the principles of quality risk management. Decisions on the scope and extent of qualification and validation of specific functionality and entire systems should be based on a justified and documented risk assessment of individual requirements and, where relevant, functional specifications, considering the risk for product quality, patient safety and data integrity.

9.3. 설치 및 구성. 어떤 시험 활동이든 시작하기 전에, 컴퓨터화 시스템과 그 구성 요소가 규격에 따라 올바르게 설치·구성되었는지, 그리고 해당되는 경우 관련 구성 요소가 적절히 교정되었는지 확인하여야 한다. 운영 체제와 플랫폼은 지원되는 버전으로 업데이트하여야 하며, 관련 보안 패치를 적용하여야 한다(15.10 최신 플랫폼 및 15.13 적시 패치 참조).

9.3. Installation and configuration. Prior to commencing any test activity, it should be verified that a computerised system and its components have been correctly installed and configured according to specifications, and where applicable, that relevant components have been properly calibrated. Operating systems and platforms should be updated to supported versions and relevant security patches should be deployed (see 15.10 Updated platforms and 15.13 Timely patching).

9.4. 증거. 시스템 적격성 평가 및 밸리데이션은 요구사항과 해당되는 경우 그로부터 도출된 기능 규격이 시스템에 의해 충족된다는 증거를 실행된 시험 스크립트와 관련이 있는 경우 화면 캡처의 형태로 제공하여야 한다.

9.4. Evidence. System qualification and validation should provide evidence in the form of executed test scripts, and where relevant, screen dumps, that requirements, and where applicable, derived functional specifications, are met by the system.

9.5. 추적성. 시험 사례는 예를 들어 요구사항 추적 매트릭스를 통해 개별 요구사항 또는 규격으로 추적할 수 있어야 한다. 요구사항이나 해당 규격을 참조하지 않는(추적할 수 없는) 시험 사례는 적격성 평가 및 밸리데이션의 요구사항을 충족하지 않는다.

9.5. Traceability. Test cases should be traceable to individual requirements or specifications, e.g. by means of a requirements traceability matrix. Test cases not referring (traceable) to requirements or applicable specifications do not meet the requirements to qualification and validation.

9.6. 중점. 시스템이 핵심 기능 요구사항을 처리하는 방식, 활동이 GMP에 따라 수행되도록 보장하기 위한 기능, 그리고 데이터 완전성을 보장하도록 설계된 기능의 시험에 더 중점을 두어야 한다. 여기에는 접근 권한, 제품 및 결과의 출하, 계산, 감사 추적, 오류 처리, 알람 및 경고 처리, 경계값 시험 및 부정 시험(negative testing), 보고서 및 인터페이스, 백업으로부터의 복원이 포함되며 이에 국한되지 않는다.

9.6. Focus. Increased focus should be on testing a system’s handling of key functional requirements, on functionality intended to ensure that activities are conducted according to GMP, and on functionality designed to ensure data integrity. This includes but is not limited to access privileges, release of products and results, calculations, audit trails, error handling, handling of alarms and warnings, boundary and negative testing, reports and interfaces, and restore from backup.

9.7. 계획 및 승인. 적격성 평가 및 밸리데이션 활동은 승인된 계획, 계획서 및 시험 스크립트에 따라 수행하여야 한다. 시험 스크립트는 시험 단계와 전제 조건을 정확하고 반복 가능하게 수행할 수 있도록 충분히 상세하게 기술하여야 한다.

9.7. Plan and approval. Qualification and validation activities should be conducted according to approved plans, protocols and test scripts. Test scripts should be described in sufficient detail to ensure a correct and repeatable conduct of test steps and prerequisites.

9.8. 사용 전 완료. 적격성 평가 및 밸리데이션 활동은 시스템을 승인하고 사용에 들어가기 전에 성공적으로 완료하고 보고하여야 한다. 일부 허용기준이 충족되지 않았거나 일탈이 완전히 해결되지 않은 경우, 시스템 사용 개시를 위한 조건부 승인을 할 수 있다. 이를 위한 조건은 영향을 받는 시스템 기능이나 GMP 공정의 결함이 제품 품질, 환자 안전 또는 데이터 완전성에 영향을 주지 않는다는 문서화된 평가가 있는 것이다. 조건부 승인을 하는 경우 이를 밸리데이션 보고서에 명시하여야 하며, 미결 조치가 계획에 따라 승인되는지 면밀히 추적하여야 한다.

9.8. Completion prior to use. Qualification and validation activities should be successfully completed and reported prior to approval and taking a system into use. Conditional approval to proceed to taking a system into use may be granted where certain acceptance criteria have not been met, or deviations have not been fully addressed. A condition for this is, that there is a documented assessment, that any deficiencies in the affected system functionality or GMP processes, will not impact product quality, patient safety or data integrity. Where a conditional approval is issued, it should be explicitly stated in the validation report and there should be close follow-up on approval of outstanding actions according to plan.

9.9. 승인. 적격성 평가 및 밸리데이션 문서는 서비스 제공업체, 공급업체 또는 사내 IT 부서가 일부 또는 전부를 제공할 수 있다. 그러나 규제 대상 사용자가 전적으로 책임을 지며, 그 문서를 신중하게 검토하고 사용을 승인하여야 한다. 규제 대상 사용자는 그 문서가 구축된 버전을 다루고 있고 있는 그대로 GMP와 회사의 업무 절차를 뒷받침하는지, 아니면 규제 대상 사용자가 일부 또는 전부를 다시 수행하여야 하는지를 신중하게 고려하여야 한다.

9.9. Authorisation. Qualification and validation documentation may be provided by a service provider, a vendor or an internal IT department in parts or in whole. However, the regulated user is fully accountable and should carefully review and authorise the use of the documentation. They should carefully consider whether it covers the implemented version and supports GMP, and company processes as is, or whether it should be repeated in parts or completely by the regulated user.

10.1. 입력 확인. 핵심 데이터를 수동으로 입력하는 경우, 해당되면 시스템은 입력값의 타당성(예: 예상 범위 안에 있는지)을 확인하고 입력값이 타당하지 않을 때 사용자에게 경고하는 기능을 갖추어야 한다.

10.1. Input verification. Where critical data is entered manually, systems should, were applicable, have functionality to verify the plausibility of the inputs (e.g. within expected ranges), and alert the user when the input is not plausible.

10.2. 데이터 전송. 일상 업무 공정에서 핵심 데이터를 한 시스템에서 다른 시스템으로 전송하여야 하는 경우(예: 실험실 기기에서 LIMS 시스템으로), 가능하면 수동 전사가 아닌 밸리데이션된 인터페이스에 근거하여야 한다. 핵심 데이터를 수동으로 전사하는 경우, 이로 인해 데이터 완전성에 위험이 생기지 않도록 효과적인 조치를 갖추어야 한다.

10.2. Data transfer. Where a routine work process requires that critical data be transferred from one system to another (e.g. from a laboratory instrument to a LIMS system), this should, where possible, be based on validated interfaces rather than on manual transcriptions. If critical data is transcribed manually, effective measures should be in place to ensure that this does not introduce any risk to data integrity.

10.3. 데이터 이전. 비정기적인 공정에서 핵심 데이터나 데이터베이스 전체를 한 시스템에서 다른 시스템으로 이전(migration)하여야 하는 경우(예: 폐기된 시스템에서 새 시스템으로 데이터를 옮길 때), 이는 밸리데이션된 공정에 근거하여야 한다. 무엇보다도 보내는 쪽과 받는 쪽의 제약 조건을 고려하여야 한다.

10.3. Data migration. Where an ad hoc process requires that critical data or a whole database be migrated from one system to another (e.g. when moving data from a retired to a new system), this should be based on a validated process. Among other things, it should consider the constraints on the sending and receiving side.

10.4. 암호화. 해당되는 경우, 핵심 데이터는 시스템에서 암호화하여야 한다.

10.4. Encryption. Where applicable, critical data should be encrypted on a system.

11.1. 고유 계정. 모든 사용자는 고유한 개인 계정을 가져야 한다. 읽기 전용 접근(데이터나 설정을 바꿀 수 없음)으로 제한된 계정을 제외하고, 공유 계정을 사용하는 것은 데이터 완전성 위반에 해당한다.

11.1. Unique accounts. All users should have unique and personal accounts. The use of shared accounts except for those limited to read-only access (no data or settings can be changed), constitute a violation of data integrity.

11.2. 지속적 관리. 사용자 접근 권한과 역할은 사용자가 GMP 활동에 참여하거나, 참여 내용이 바뀌거나, 참여를 끝낼 때 적절하게 그리고 적시에 부여, 변경 및 회수하여야 한다.

11.2. Continuous management. User accesses and roles should be granted, modified and revoked as relevant and in a timely manner as users join, change, and end their involvement in GMP activities.

11.3. 확실한 신원 확인. 인증 방법은 높은 확실성으로 사용자를 식별하고 무단 접근을 효과적으로 막을 수 있어야 한다. 일반적으로 고유한 사용자명과 비밀번호를 사용할 수 있으나, 적어도 같은 수준의 보안을 제공하는 다른 방법(예: 생체 인식)을 사용할 수도 있다. 토큰이나 스마트카드만으로 하는 인증은 다른 사용자가 이를 사용할 수 있다면 충분하지 않다.

11.3. Certain identification. The method of authentication should identify users with a high degree of certainty and provide an effective protection against unauthorised access. Typically, it may involve a unique username and a password, although other methods providing at least the same level of security may be employed (e.g. biometrics). Authentication only by means of a token or a smart card is not sufficient, if this could be used by another user.

11.4. 비밀번호 기밀 유지. 비밀번호와 그 밖의 인증 수단은 시스템 차원과 개인 차원 모두에서 기밀로 유지하고 다른 모든 사용자로부터 보호하여야 한다. 관리자나 시스템 관리자 등에게서 받은 비밀번호는 처음 로그인할 때 바꾸어야 하며, 시스템이 이를 요구하는 것이 바람직하다.

11.4. Confidential passwords. Passwords and other means of authentication should be kept confidential and protected from all other users, both at system and at a personal level. Passwords received from e.g. a manager, or a system administrator should be changed at the first login, preferably required by the system.

11.5. 안전한 비밀번호. 비밀번호는 안전하여야 하며 시스템이 이를 강제하여야 한다. 비밀번호 규칙은 시스템과 데이터의 무단 변경에 따른 위험과 결과에 상응하여야 한다. 핵심 시스템의 경우, 비밀번호는 무단 접근을 효과적으로 막을 수 있을 만큼 충분히 길어야 하며 대문자, 소문자, 숫자 및 기호를 조합하여야 한다. 비밀번호에는 사전에 나오는 단어, 사람 이름, 사용자 ID, 제품 또는 조직 이름 등이 들어가서는 안 되며, 이전 비밀번호와 크게 달라야 한다.

11.5. Secure passwords. Passwords should be secure and enforced by systems. Password rules should be commensurate with risks and consequences of unauthorised changes in systems and data. For critical systems, passwords should be of sufficient length to effectively prevent unauthorised access and contain a combination of uppercase, lowercase, numbers and symbols. A password should not contain e.g. words that can be found in a dictionary, the name of a person, a user id, product or organisation, and should be significantly different from a previous password.

11.6. 강력한 인증. 통제된 경계 밖에서 핵심 시스템에 원격으로 인증하는 경우 다중 인증(MFA)을 포함하여야 한다.

11.6. Strong authentication. Remote authentication on critical systems from outside controlled perimeters, should include multifactor authentication (MFA).

11.7. 자동 잠금. 계정은 미리 정한 횟수만큼 연속으로 인증에 실패하면 자동으로 잠겨야 한다. 계정 잠금은 그것이 무단 로그인 시도의 일부가 아니었음이 확인된 뒤, 또는 그러한 시도의 위험이 제거된 뒤에 시스템 관리자만 해제하여야 한다.

11.7. Auto locking. Accounts should be automatically locked after a pre-defined number of successive failed authentication attempts. Accounts should only be unlocked by the system administrator after it has been confirmed that this was not part of an unauthorised login attempt or after the risk for such attempt has been removed.

11.8. 미사용 시 로그아웃. 시스템에는 정해진 시간 동안 사용하지 않으면 사용자를 로그아웃시키는 자동 로그아웃 기능이 있어야 한다. 사용자는 미사용 로그아웃 시간을 (정해진 허용 한계 밖으로) 바꾸거나 이 기능을 비활성화할 수 없어야 한다. 미사용 로그아웃 후에는 재인증(예: 비밀번호 입력)을 요구하여야 한다.

11.8. Inactivity logout. Systems should include an automatic inactivity logout, which logs out a user after a defined period of inactivity. The user should not be able to change the inactivity logout time (outside defined and acceptable limits) or deactivate the functionality. Upon inactivity logout, a re-authentication should be required (e.g. password entry).

11.9. 접근 기록. 시스템에는 (별도로 또는 감사 추적의 일부로) 접근 기록이 있어야 하며, 이 기록은 로그인할 때마다 사용자명, 사용자 역할(여러 역할 중에서 선택할 수 있는 경우), 로그인 날짜와 시간, 로그아웃(미사용 로그아웃 포함) 날짜와 시간을 자동으로 기록한다. 이 기록은 정렬하고 검색할 수 있어야 하며, 그렇지 않으면 이 기능을 제공하는 도구로 기록을 내보낼 수 있어야 한다.

11.9. Access log. Systems should include an access log (separate, or as part of the audit trail) which, for each login, automatically logs the username, user role (if possible, to choose between several roles), the date and time for login, the date and time for logout (incl. inactivity logout). The log should be sortable and searchable, or alternatively, it should be possible to export the log to a tool which provides this functionality.

11.10. 기본 원칙. GMP 활동에 사용되는 컴퓨터화 시스템 사용자의 접근 권한은 다음 두 가지 기본 원칙에 따라 관리하여야 한다.

11.10. Guiding principles. Access privileges for users of computerised systems used in GMP activities should be managed according to the following two guiding principles:

11.11. 반복 검토. 사용자 계정은 반복적으로 검토하여야 하며, 이 검토에서 관리자는 소속 직원의 접근 권한 유지를 확인하여 일상 운영 중에 변경하거나 회수했어야 하나 실수로 잊힌 접근 권한을 찾아내야 한다. 사용자 계정을 역할로 관리하는 경우, 역할도 같은 방식으로 검토하여 역할별 접근 권한을 확인하여야 한다. 검토는 문서화하여야 하며, 적절한 조치를 취하여야 한다. 이 검토의 빈도는 권한 없는 사람이 시스템과 데이터를 변경했을 때의 위험과 결과에 상응하여야 한다.

11.11. Recurrent reviews. User accounts should be subject to recurrent reviews where managers confirm the continued access of their employees in order to detect accesses which should have been changed or revoked during daily operation, but were accidentally forgotten. If user accounts are managed by means of roles, these should be subject to the same kind of reviews, where the accesses of roles are confirmed. The reviews should be documented, and appropriate action taken. The frequency of these reviews should be commensurate with the risks and consequences of changes in systems and data made by unauthorised individuals.

12.1. 사용자의 수동 조작. 공정을 제어하거나 데이터를 수집, 보유 또는 보고하는 데 사용되고, 사용자가 데이터, 설정 또는 접근 권한을 생성, 수정 또는 삭제하거나 알람을 확인하거나 전자서명을 실행하는 등의 작업을 할 수 있는 시스템은, 사용자의 모든 수동 조작을 자동으로 기록하는 감사 추적 기능을 갖추어야 한다.

12.1. Manual user interactions. Systems which are used to control processes, capture, hold or report data, and where users can create, modify or delete data, settings or access privileges, acknowledge alarms or execute electronic signatures etc., should have an audit trail functionality which automatically logs all manual user interactions.

12.2. 누가, 무엇을, 언제, 왜. 감사 추적은 변경한 사용자(사용자가 둘 이상의 역할을 가질 수 있으면 그 사용자의 역할 포함), 변경된 내용(변경된 데이터와 이전 값 및 새 값 포함), 그리고 변경한 날짜와 시간(해당되면 시간대 포함)을 모호함 없이 기록하여야 한다. 감사 추적 데이터는 공정이 끝날 때가 아니라 사건이 일어날 때 기록하여야 한다. 데이터를 이전 값에서 새 값으로 변경하는 경우, 시스템은 사용자에게 변경 사유를 자동으로 묻고 이를 기록하여야 한다.

12.2. Who, what, when, why. The audit trail should unambiguously capture the user who made a change (including the user’s role, if users may have more than one role), what was changed (including the data that was changed and the old and the new value), and the date and time when the change was made (including the time zone if applicable). Audit trail data should be recorded at the time of events, not at the end of a process. Where data is changed from an old value to a new value, systems should automatically prompt the user for, and register the reason, why the change was made.

12.3. 편집 및 비활성화 금지. 감사 추적 기능은 항상 활성화되고 잠겨 있어야 하며, 어떤 사용자도 감사 추적 데이터를 편집할 수 없어야 한다. 감사 추적 설정이나 시스템 시간을 바꿀 수 있거나 이 기능을 비활성화할 수 있다면, 그 자체가 감사 추적에 기록을 남겨야 하며, 이는 GMP 활동에 관여하지 않는 시스템 관리자만 할 수 있어야 한다(11.10 기본 원칙 참조).

12.3. No edit or deactivation. Audit trail functionality should be enabled and locked at all times, and it should not be possible for any user to edit audit trail data. If audit trail settings or system time can be changed, or if the functionality can be deactivated, this should by itself create an entry in the audit trail, and it should only be possible for a system administrator not involved in any GMP activities (see 11.10 Guiding principles).

12.4. 검토 지원. 시스템은 감사 추적 데이터를 효과적이고 효율적으로 검토할 수 있도록 하여야 한다. 모든 사용자가 시스템 안에서 감사 추적 데이터(누가, 무엇을, 언제, 왜)를 정렬하고 검색할 수 있어야 하며, 그렇지 않으면 이것이 가능한 도구로 데이터를 내보낼 수 있어야 한다.

12.4. Accommodate review. Systems should accommodate effective and efficient reviews of audit trail data. It should be possible for all users to sort and search audit trail data (who, what, when and why) in the system, or alternatively, to allow export of the data to a tool where this is possible.

12.5. 검토. 감사 추적 검토는 특정 시스템 또는 시스템 유형에 대한 문서화된 절차에 따라 하여야 한다. 이 절차에는 누가 검토하고, 무엇을 검토하며, 언제 검토할지를 제시하여야 한다. 감사 추적 검토를 돕는 도구의 사용을 권장하며, 검토 후에는 적절한 조치를 취하고 문서화하여야 한다. 감사 추적 검토 중에 발견된, 예상 결과와의 중대한 차이는 철저히 조사하고 기록하여야 한다.

12.5. Reviews. Audit trail reviews should be conducted according to a documented procedure for the specific system, or type of systems. The procedure should outline who should make the review, what should be reviewed, and when should the review be made. The use of tools to help conduct audit trail reviews is encouraged and appropriate action should be taken and documented following the reviews. Any significant variation from the expected outcome found during the audit trail review should be fully investigated and recorded.

12.6. 독립적 검토. 감사 추적 검토는 검토 대상 활동에 직접 관여하지 않은 인원이 하여야 한다(동료 검토).

12.6. Independent review. Audit trail reviews should be conducted by personnel not directly involved in the activities covered by the review (a peer review).

12.7. 검토 범위. 감사 추적 기록의 모든 항목을 검토하는 것은 효과적이지 않을 수 있다. 검토는 위험에 근거하여 대상을 정하고, 해당 제조소의 제조공정에 맞추어야 한다. 감사 추적 검토 절차는 활동의 반복, 오류, 누락, 승인되지 않은 공정 일탈, 데이터 완전성 상실을 포함하되 이에 국한되지 않는, GMP 원칙 위반을 나타내는 핵심 공정이나 데이터의 고의 또는 비고의적인 변경을 찾아내는 데 중점을 두어야 한다. 핵심 요소는 변경이 이루어진 사유를 확인하는 것이어야 한다.

12.7. Scope of review. Reviewing all entries in an audit trail record may not be effective. Reviews should be targeted, based on risk and adapted to local manufacturing processes. Procedures for audit trail reviews should focus on detecting any deliberate or indeliberate changes to critical processes or data that indicate a violation of GMP principles, including, but not limited to, repetition of activities, errors, omissions, unauthorised process deviations and loss of data integrity. A key element should be to verify the reason why a change is made.

12.8. 검토의 적시성. 감사 추적 검토는 검토 대상 공정의 위험에 따라 적시에 하여야 한다. 감사 추적 검토는 배치 출하 전에 하여야 하며, 부당한 변경을 나중에 발견하는 위험이 타당하다고 입증할 수 있는 경우는 예외로 한다.

12.8. Timeliness of review. Audit trail reviews should be conducted in a timely manner according to the risk of the process reviewed. The audit trail review should be conducted prior to batch release, unless the risk of a later detection of any unwarranted changes can be justified.

12.9. 전자 사본. 감사 추적 데이터를 포함한 시스템 데이터의 완전한 전자 사본을 얻을 수 있어야 한다. 평면(flat) 파일과 잠긴 파일은 허용되지 않으며, 데이터를 검색하고 정렬할 수 있어야 한다.

12.9. Electronic copy. It should be possible to obtain a complete electronic copy of system data including audit trail data. Flat and locked files are not acceptable, it should be possible to search and sort data.

12.10. QP의 열람 가능성. 제품 출하에 직접 영향을 주는 감사 추적 검토는 배치 출하 시점에 QP가 열람할 수 있어야 한다.

12.10. Availability to QP. Audit trail reviews with direct impact on the release of a product should be available to the QP at the time of batch release.

13.1. 적용 범위. 이 문서의 전자서명 요구사항은 GMP에서 서명을 요구하는 공정에 사용되는 시스템과 도구에 적용한다.

13.1. Scope. Requirements for electronic signatures in this document apply to systems and tools used in processes where GMP require a signature.

13.2. 개방형 시스템. 시스템 책임자가 시스템 접근을 완전히 통제하지 못하는 경우(개방형 시스템) 또는 다른 법령에서 요구하는 경우, 전자서명은 이에 더하여 신뢰 서비스(trusted services) 등 해당 국가 및 국제 요구사항을 충족하여야 한다.

13.2. Open systems. Where the system owner does not have full control of system accesses (open systems), or where required by other legislation, electronic signatures should, in addition, meet applicable national and international requirements, such as trusted services.

13.3. 재인증. 전자서명을 실행할 때 시스템은 사용자가 적어도 시스템 로그인 때와 같은 수준의 보안을 제공하는 완전한 재인증을 하도록 강제하여야 한다(11.3 확실한 신원 확인 참조). 이어서 곧바로 연속하여 전자서명을 실행하는 경우에는 비밀번호나 생체 인식만으로 인증할 수 있다. 스마트카드나 PIN 코드만으로 하는 인증, 또는 이전의 시스템 인증에 의존하는 것은 허용되지 않는다.

13.3. Re-authentication. When executing an electronic signature, a system should enforce users to perform a full re-authentication providing at least the same level of security as during system login (see 11.3 Certain identification). When executing subsequent electronic signatures in immediate sequence, authentication may be by means of a password or biometrics only. Authentication only by means of a smart card, a pin code, or relying on the previous system authentication is not acceptable.

13.4. 날짜와 시간. 시스템은 전자서명을 한 날짜와 시간, 그리고 해당되는 경우 시간대를 자동으로 기록하여야 한다.

13.4. Date and time. Systems should automatically log the date and time and, where applicable, the time zone when an electronic signature was applied.

13.5. 의미. 사용자가 언제 전자서명을 실행하는지가 명확하여야 하며, 해당되는 경우 시스템은 사용자에게 서명의 의미(예: 검토자 또는 승인자)를 묻도록 하여야 한다.

13.5. Meaning. It should be clear when a user is executing an electronic signature and where applicable, systems should prompt the user for the meaning of the signature (e.g. reviewer or approver).

13.6. 표시. 전자서명을 (화면이나 인쇄물에) 표시할 때에는 사용자의 성명, 사용자명, 해당되는 경우 서명자의 역할과 서명의 의미, 서명한 날짜와 시간, 그리고 필요한 경우 시간대가 포함되어야 한다.

13.6. Manifestation. When an electronic signature is displayed (on screen or print), the manifestation should include the full name of the user, the username, where applicable the role of the signer and the meaning of the signature, the date and time, and where needed the time zone, when the signature was applied.

13.7. 부인 불가. 전자서명은 부인할 수 없어야 하며 자필 서명과 동등하여야 한다.

13.7. Indisputability. Electronic signatures should be indisputable and equivalent to hand-written signatures.

13.8. 끊을 수 없는 연결. 전자서명은 해당 기록과 영구적으로 연결되어야 한다. 서명된 기록을 수정할 수 없도록 하거나, 그렇지 않으면 서명된 기록이 나중에 변경되는 경우 그 기록이 서명되지 않은 것으로 명확히 나타나도록 하는 관리 수단을 갖추어야 한다.

13.8. Unbreakable link. Electronic signatures should be permanently linked to their respective records. Controls should be in place to ensure that a signed record cannot be modified or alternatively, that if a later change is made to a signed record, it will clearly appear as unsigned.

13.9. 하이브리드 방식. 컴퓨터화 시스템에 보관된 전자 기록에 서명하기 위해 (종이에) 자필 잉크 서명을 사용하는 경우(하이브리드 방식), 전자 기록이 조금이라도 변경되면 그 서명이 무효가 된다는 것을 높은 확실성으로 보장하는 조치를 시행하여야 한다. 이는 전자 기록의 해시 코드(체크섬)를 계산하여 서명 쪽에 인쇄하는 방식으로 시행할 수 있다.

13.9. Hybrid solution. If a wet-ink signature (on paper) is used to sign electronic records held in a computerised system (a hybrid solution), measures should be implemented to provide a high degree of certainty that any change to the electronic record will invalidate the signature. This may be implemented by calculating a hash code (check sum) of the electronic record and printing that on the signature page.

14.1. 주기적 검토. 시스템을 처음 밸리데이션하고 운영에 들어간 뒤에는 주기적 검토를 하여야 한다. 이 검토에서는 시스템이 계속 ‘사용 목적에 적합’하고 ‘밸리데이션된 상태’인지, 아니면 변경이 필요하고 (전체 또는 일부) 재밸리데이션이 요구되는지를 확인하여야 한다. 검토는 문서화하여야 하며, 발견 사항을 분석하여 제품 품질, 환자 안전 및 데이터 완전성에 미치는 영향을 파악하고 재발을 방지하여야 한다.

14.1. Periodic reviews. After a system has been initially validated and is put into operation, periodic reviews should be conducted. This review should verify whether the system remains 'fit for intended use' and in 'a validated state', or whether changes should be made and re-validation (complete or in parts) is required. The reviews should be documented and findings analysed to identify any consequences on product quality, patient safety and data integrity, and to prevent recurrence.

14.2. 검토 범위. 해당되는 경우, 주기적 검토에는 다음이 포함되어야 하며 이에 국한되지 않을 수 있다.

14.2. Scope of review. Where applicable, periodic reviews should include, but may not be limited to:

이전 검토 이후의 변경:

Changes made since the previous review:

지원 절차의 후속 조치:

Follow-up on supporting processes:

14.3. 빈도. 주기적 검토는 계획에 따라 실시, 승인 및 종결하여야 한다. 검토 빈도는 시스템이 제품 품질, 환자 안전 및 데이터 완전성에 미치는 위험에 근거하여 정하고 그 타당성을 제시하여야 한다. 시스템 사용을 중단할 때에는 최종 검토를 하여야 한다.

14.3. Frequency. Periodic reviews should be conducted, approved and closed according to plan. The frequency of reviews should be established and justified based on the risk the system poses to product quality, patient safety and data integrity. A final review should be conducted when the system is taken out of use.

15.1. 보안 체계. 규제 대상 사용자는 GMP, 시스템 및 데이터에 대한 승인된 접근을 보호하고 무단 접근을 탐지·방지하는 효과적인 정보보안 관리체계를 시행하고 유지하여야 한다.

15.1. Security system. Regulated users should ensure an effective information security management system is implemented and maintained, which safeguards authorised access to, and detects and prevents unauthorised access to GMP, systems and data.

15.2. 지속적 개선. 규제 대상 사용자는 새로운 보안 위협을 계속 파악하고 있어야 하며, 이러한 변화에 대응하기 위해 GMP 시스템과 데이터를 보호하는 조치를 상황에 맞게 지속적으로 개선하여야 한다.

15.2. Continuous improvement. Regulated users should keep updated about new security threats, and measures to protect GMP systems and data should be continuously improved as applicable to counter this development.

15.3. 교육훈련 및 시험. 규제 대상 사용자는 사이버 위협과 안전한 행동에 대한 이해를 높이고 유지하기 위해 필요에 따라 반복적인 보안 인식 교육훈련을 받아야 한다. 교육훈련의 효과는 예를 들어 모의 시험으로 평가하여야 한다.

15.3. Training and tests. Regulated users should undergo recurrent security awareness training, as relevant, to raise and maintain their understanding of cyber threats and safe behaviour. The effectiveness of the training should be evaluated, e.g. by means of simulated tests.

15.4. 물리적 접근. GMP 활동에 사용되는 서버, 컴퓨터, 장치, 인프라 및 저장 매체는 무단 접근, 손상 및 분실로부터 물리적으로 보호하여야 한다. 서버실과 데이터센터에 대한 물리적 접근은 필요한 최소한으로 제한하여야 하며, 예를 들어 다중 인증을 통해 안전하게 잠가 두어야 한다. 무단 접근이 가능한 경우(예: ‘코로케이션(co-location)’), 개별 서버에 대한 접근을 보호하여야 한다.

15.4. Physical access. Servers, computers, devices, infrastructure and storage media used in GMP activities should be physically protected against unauthorised access, damage and loss. Physical access to server rooms and data centres should be limited to the necessary minimum and these should be securely locked, e.g. by means of multi-factor authentication. If unauthorised access is possible (e.g. `co-location´), access to individual servers should be protected.

15.5. 재해 및 장애. 데이터센터는 자연재해와 인적 재해 및 장애의 위험과 영향을 최소화하도록 건설하여야 한다. 여기에는 폭풍, 홍수, 누수, 지진, 화재, 정전, 네트워크 장애 등이 포함되며 이에 국한되지 않을 수 있다.

15.5. Disasters and disturbances. Data centres should be constructed to minimise the risk and impact of natural and manmade disasters and disturbances. This includes, but may not be limited to, storms, flooding, water leaks, earthquakes, fires, power outages, and network failures etc.

15.6. 복제. 관련이 있는 경우, 핵심 데이터는 주 데이터센터에서 보조 데이터센터로 복제하여야 한다. 복제는 데이터 손실 위험을 최소화할 만큼 짧은 지연 시간으로 자동으로 이루어져야 한다. 보조(장애 조치(failover)용) 데이터센터는 같은 사고로 두 데이터센터가 모두 파괴될 위험을 최소화하도록 주 사이트에서 안전한 거리만큼 떨어진 곳에 두어야 한다.

15.6. Replication. Where relevant, critical data should be replicated from a primary to a secondary data centre. The replication should take place automatically with a delay which is short enough to minimise the risk of loss of data. The secondary (failover) data centre should be located at a safe distance from the primary site to minimise the risk that the same incident destroys both data centres.

15.7. 재해 복구. 재해 복구 계획을 마련하고 시험하여야 하며, 재해가 데이터센터, 서버, 컴퓨터, 인프라 또는 데이터에 영향을 미치는 동안과 그 이후에 이용할 수 있어야 한다. 해당되는 경우, 이 계획은 정해진 복구 목표 시간(RTO) 안에 운영의 연속성을 보장하여야 한다.

15.7. Disaster recovery. A disaster recovery plan should be in place, tested and available during and after a disaster has affected a data centre, server, computer, infrastructure, or data. Where applicable, the plan should ensure the continuity of operation within a defined Recovery Time Objective (RTO).

15.8. 네트워크 분할 및 방화벽. 네트워크는 분할하여야 하며, 네트워크 사이에 장벽을 두고 들어오고 나가는 네트워크 트래픽을 통제하는 효과적인 방화벽을 시행하여야 한다. 방화벽 규칙(예: IP 주소, 목적지, 프로토콜, 애플리케이션 또는 포트 기준)은 실제로 가능한 한 엄격하게 정하여 필요하고 허용되는 트래픽만 허용하여야 한다.

15.8. Segmentation and firewalls. Networks should be segmented, and effective firewalls implemented to provide barriers between networks, and control incoming and outgoing network traffic. Firewall rules (e.g. based on IP addresses, destinations, protocols, applications, or ports) should be defined as strict as practically feasible, only allowing necessary and permissible traffic.

15.9. 방화벽 검토. 방화벽 규칙은 시간이 지나면서 변경되거나 불충분해지는 경향이 있으므로(예: 포트를 열고 닫지 않거나, 새로운 사이버 위협이 생겨나면서) 주기적으로 검토하여야 한다. 이 검토를 통해 방화벽이 계속 가능한 한 엄격하게 설정되도록 하여야 한다.

15.9. Review of firewalls. Firewall rules should be periodically reviewed as the rules tend to be changed or become insufficient over time (e.g. as ports are opened but never closed, or as new cyber threats evolve). This review should ensure that firewalls continue to be set as tight as possible.

15.10. 최신 플랫폼. 애플리케이션의 운영 체제와 플랫폼은 지원되지 않는 상태로 사용되지 않도록 공급업체 권고에 따라 적시에 업데이트하여야 한다.

15.10. Updated platforms. Operating systems and platforms for applications should be updated in a timely manner according to vendor recommendations, to prevent their use in an unsupported state.

15.11. 밸리데이션 및 이전. 업데이트된 운영 체제와 플랫폼에서의 애플리케이션 밸리데이션과 데이터 이전은 공급업체 지원이 끝나기 전에 충분한 여유를 두고 계획하고 완료하여야 한다.

15.11. Validation and migration. Validation of applications on updated operating systems and platforms and migration of data should be planned and completed in due time prior to the expiry of the vendor’s support.

15.12. 지원되지 않는 플랫폼. 공급업체가 더 이상 지원하지 않고, 위협을 더 이상 모니터링하지 않으며 해당 보안 패치도 배포되지 않는 운영 체제와 플랫폼 위의 애플리케이션은 매우 취약하므로, 컴퓨터 네트워크와 인터넷으로부터 격리하여야 한다.

15.12. Unsupported platforms. Applications on operating systems and platforms, which are no longer supported by vendors, and for which threats are no longer monitored and applicable security patches released, are highly vulnerable and should be isolated from computer networks and the internet.

15.13. 적시 패치. 운영 체제와 플랫폼이 지원 기간 중에 있는 동안, 공급업체는 일반적으로 확인된 취약점에 대응하는 보안 패치를 배포하며, 그 가운데 일부(치명적 취약점)는 그렇지 않으면 권한 없는 사람이 시스템에 대한 특권 접근을 얻고 코드를 실행하는 데(예: 랜섬웨어 공격) 악용될 수 있다. 따라서 운영 체제와 플랫폼 공급업체가 배포한 관련 보안 패치는 공급업체 권고에 따라 적시에 적용하여야 한다. 치명적 취약점의 경우에는 즉시 적용해야 할 수도 있다.

15.13. Timely patching. While operating systems and platforms are under support, vendors typically release security patches to counter identified vulnerabilities, some of which (critical vulnerabilities) could otherwise be exploited to give unauthorised individuals privileged access to systems and allow code execution (e.g. ransomware attacks). Hence, relevant security patches released by vendors of operating systems and platforms should be deployed in a timely manner according to vendor recommendations. For critical vulnerabilities, this might be immediately.

15.14. 패치되지 않은 플랫폼. 공급업체 권고에 따라 적시에 보안 패치(치명적 패치)가 적용되지 않은 운영 체제와 플랫폼 위의 애플리케이션은 매우 취약하며 데이터 완전성 상실의 주요 위험이 된다. 관련이 있는 경우, 이러한 시스템은 컴퓨터 네트워크와 인터넷으로부터 격리하여야 한다.

15.14. Unpatched platforms. Applications on operating systems and platforms, which are not security patched in a timely manner (critical patches) according to vendor recommendations are highly vulnerable and constitute a major risk for loss of data integrity. Where relevant, such systems should be isolated from computer networks and the internet.

15.15. 엄격한 관리. GMP 활동에 사용되는 서버와 컴퓨터에서 양방향 장치(예: USB)의 사용은 조직 안에서 엄격하게 관리하여야 한다.

15.15. Strict control. The use of bidirectional devices (e.g. USB) in servers and computers used in GMP activities should be strictly controlled within the organisation.

15.16. 효과적인 검사. 양방향 장치(예: USB)가 조직 밖에서(예: 개인적으로) 사용되었을 수 있다면, 그 장치는 고의 또는 비고의로 악성코드를 들여와 코드 실행을 일으킬 수 있다. 따라서 그러한 장치는 효과적으로 검사하여 무해하고 시스템 및 데이터 완전성을 훼손하지 않는다고 확인되지 않는 한 사용해서는 안 된다.

15.16. Effective scan. If bidirectional devices (e.g. USB) may have been used outside the organisation (e.g. privately), they may intentionally or unintentionally introduce malware and cause code execution. Hence, they should not be used unless they have been effectively scanned and found to be harmless, and not compromise system and data integrity.

15.17. 비활성화된 포트. 핵심 서버와 컴퓨터의 양방향 장치(예: USB)용 포트는 시스템 운영에 필요한 장치(예: 키보드나 마우스)에 사용되는 경우가 아니면 기본적으로 비활성화하거나, 차단하거나, 아예 제거하여야 한다.

15.17. Deactivated ports. Ports for bidirectional devices (e.g. USB) in critical servers and computers should be deactivated by default, blocked or even removed, unless they are used for devices necessary to operate the system (e.g. keyboard or mouse).

15.18. 백신 소프트웨어. GMP 활동에 사용되는 시스템, 특히 인터넷과 연결된 시스템에는 백신(anti-virus) 소프트웨어를 설치하고 활성화하여야 한다. 백신 소프트웨어는 알려진 컴퓨터 바이러스를 식별, 격리 및 제거할 수 있도록 최신 바이러스 정의로 계속 업데이트하여야 한다. 이 과정의 효과를 모니터링하여야 한다.

15.18. Anti-virus software. Anti-virus software should be installed and activated on systems used in GMP activities, especially those interfacing the internet. The anti-virus software should be continuously updated with the most recent virus definitions to identify, quarantine, and remove known computer viruses. The effectiveness of the process should be monitored.

15.19. 모의 침투 시험. 인터넷에 노출된 핵심 시스템에 대해서는 취한 보안 조치의 적절성을 평가하고 시스템 보안의 취약점을 찾아내기 위해 정기적으로 모의 침투 시험(윤리적 해킹)을 하여야 한다. 여기에는 권한 없는 자가 시스템과 그 데이터에 접근하고 이를 장악할 가능성이 포함되어야 한다. 이 과정의 효과를 확인하고 모니터링하여야 한다. 발견된 취약점, 특히 데이터 완전성 상실 가능성과 관련된 취약점은 적시에 해결하고 완화하여야 한다.

15.19. Penetration testing. For critical systems facing the internet, penetration testing (ethical hacking) should be performed at regular intervals to evaluate the adequacy of security measures taken, and to identify vulnerabilities in system security. This should include the potential for unauthorised parties to gain access to and control the system and its data. The effectiveness of the process should be verified and monitored. Vulnerabilities identified, especially those related to a potential loss of data integrity, should be addressed and mitigated in a timely manner.

15.20. 암호화. 인터넷을 통해 시스템에 원격으로 접속할 때에는 안전하고 암호화된 프로토콜을 사용하여야 한다.

15.20. Encryption. When remotely connecting to systems over the internet, a secure and encrypted protocol should be used.

16.1. 정기 백업. 데이터와 메타데이터는 우발적이거나 고의적인 변경 또는 삭제, 오작동이나 손상(예: 사이버 공격의 결과)으로 인한 손실이 발생했을 때 데이터 손실을 막기 위해 확립된 절차에 따라 정기적으로 백업하여야 한다.

16.1. Regular backup. Data and metadata should be regularly backed up following established procedures to prevent the loss of data in case of accidental or deliberate change or deletion, loss as the result of a malfunction or corruption, e.g. as the result of a cyber-attack.

16.2. 빈도 및 보존. 백업의 빈도, 보존 기간 및 보관 방식은 데이터 손실을 완화하는 과정의 효과에 매우 중요하다. 백업은 적절한 간격(예: 매시간, 매일, 매주, 매월)으로 하여야 하며, 그 보존 기간은 위험 기반 접근 방식으로 정하여야 한다(예: 각각 1주, 1개월, 1분기, 수년).

16.2. Frequency and retention. The frequency, retention period and storage of backups is critically important to the effectiveness of the process to mitigate the loss of data. Backups should be made at suitable intervals (e.g. hourly, daily, weekly and monthly) and their retention determined through a risk-based approach (e.g. correspondingly a week, a month, a quarter, and years).

16.3. 물리적 분리. 백업은 같은 사고로 둘 다 영향을 받지 않도록 원본 데이터를 보유한 서버나 컴퓨터와 물리적으로 분리하여 안전한 거리만큼 떨어진 곳에 보관하여야 한다.

16.3. Physical separation. Backups should be physically separated from the server or computer holding the original data and stored at a safe distance from this, to prevent that both would be impacted by the same incident.

16.4. 논리적 분리. 백업은 동시에 파괴되거나 변조되는 것을 피하기 위해 원본 데이터와 같은 논리 네트워크에 보관해서는 안 된다.

16.4. Logical separation. Backups should not be stored at the same logical network as the original data to avoid simultaneous destruction or alteration.

16.5. 범위. 사고 후 복구의 중요도와 긴급성에 따라 애플리케이션과 시스템 구성도 백업해야 할 수 있다.

16.5. Scope. Depending on the criticality and urgency for recovery after an incident, applications and system configurations may also need to be backed up.

16.6. 복원 시험. 백업으로부터의 데이터 복원은 시스템 밸리데이션 중에, 그리고 백업 또는 복원 과정과 도구가 변경된 뒤에 위험에 근거하여 시험하고 문서화하여야 한다. 복원 시험은 문서화하여야 하며, 시스템에서 데이터에 접근할 수 있는지 확인하는 것을 포함하여야 한다.

16.6. Restore test. Restore of data from backup should be tested and documented based on risk during system validation and after changes are made to the backup or restore processes and tools. Restore tests should be documented and include a verification that data is accessible on the system.

17.1. 읽기 전용. 공정이 완료된 뒤(예: 제품 출하 후), GMP 데이터와 메타데이터(감사 추적 포함)는 보존 기간 내내 삭제와 변경으로부터 보호하여야 한다. 이는 데이터가 생성되거나 수집된 시스템에서 그 상태를 읽기 전용으로 바꾸거나, 밸리데이션된 인터페이스를 통해 전용 장기 보관 시스템으로 옮기는 방식으로 할 수 있다.

17.1. Read only. After completion of a process, e.g. release of a product, GMP data and metadata (incl. audit trails) should be protected from deletion and changes throughout the retention period. This may be by changing its status to read-only in the system where the data was generated or captured, or by moving it to a dedicated archival system via a validated interface.

17.2. 확인. GMP 데이터와 메타데이터를 시스템 안에서 한 위치에서 다른 위치로 옮기거나 전용 장기 보관 시스템으로 옮길 때에는, 데이터를 삭제하기 전에 예를 들어 체크섬을 이용하여 높은 확실성으로 데이터의 완전성을 확인하여야 한다. 이것이 가능하지 않으면 데이터의 완결성과 완전성을 수동으로 확인하여야 한다. 그러나 이 확인을 한다고 해서 장기 보관 및 검색 과정과 관련 시스템 및 인터페이스를 밸리데이션할 필요가 없어지는 것은 아니다.

17.2. Verification. When moving GMP data and metadata from one location to another in a system, or to a dedicated archival system, the integrity of the data should be verified by a high degree of certainty before any data is deleted, e.g. by means of a checksum. Where this is not possible, the completeness and integrity of the data should be verified manually. However, this verification does not alter the need for a validation of the archival and retrieval process, and of the systems and interfaces involved.

17.3. 백업. 데이터를 서버(디스크)에 장기 보관하는 경우, 운영 중인 데이터와 같은 절차에 따라 정기적으로 백업하여야 한다(16 백업 참조). 다른 백업과 마찬가지로, 이 백업은 장기 보관된 데이터와 물리적·논리적으로 분리하여야 한다.

17.3. Backup. If data is archived on a server (disk), it should be regularly backed up following the same procedures as for live data (see 16 Backup). As for other backups, these should be physically and logically separated from the archived data.

17.4. 내구성. 내구성이 제한된 휘발성 저장 매체(예: CD)에 데이터를 장기간 보관하는 경우, 밸리데이션된 과정을 따라야 한다. 이 과정은 데이터가 공급업체 권고에 따라 확인된 기간 동안만 보관되도록 하고, 필요하면 안전한 방식으로 새 매체로 옮겨지도록 보장하여야 한다(16 백업 참조).

17.4. Durability. If data is archived long-term on volatile storage media with limited durability (e.g. CD), this should follow a validated process. It should ensure that data is stored only for a verified duration according to vendor recommendations, and if necessary, transferred to new media in secure manner (see 16 Backup).

17.5. 검색. 장기 보관된 데이터와 메타데이터는 데이터를 검색하고 정렬할 수 있는 형식으로 불러올 수 있어야 하며, 그렇지 않으면 이것이 가능한 도구로 데이터를 내보낼 수 있어야 한다.

17.5. Retrieval. It should be possible to retrieve archived data and metadata in a format which allows searching and sorting of the data, or alternatively, to allow export of the data to a tool where this is possible.