ANNWX11&PART211.68B 国庆探讨：EU GMP 附录11与21 CFR Part 211.68 的 How to do 实践

引言（Introduction）

1.1 目的（Purpose of the Document）

EU GMP 附录 11《计算机化系统》（Annex 11: Computerised Systems）是欧盟 GMP 指南（EudraLex Volume 4）的组成部分，规定了计算机化系统在 GMP 受监管活动中的使用要求。Annex 11 是"做什么（what to do）"层面的要求文本，条款精炼、覆盖面广，企业执行时往往需要进一步理解"怎么做（how to do）"。

本指南参照 ICH Q7 "How to Do" Document（由 APIC 编制发布，对 ICH Q7《原料药 GMP 指南》逐条给出行业解释与做法建议）的编写方式，对 Annex 11 的每一条款给出三部分解读：

• 【条款意图】——该条款要求什么、为什么这样要求；

• 【如何实施】——企业落地该条款的具体做法（角色、文档、步骤、频次）；

• 【检查要点与常见缺陷】——检查员通常关注什么、行业常见不符合项。

目标读者：质量保证、计算机化系统验证（CSV）、信息技术（IT）、系统所有者（System Owner）、流程所有者（Process Owner）以及质量受权人（QP）。

1.2 历史背景（Historical Background）

欧盟 GMP 附件 11 于 1992 年首次发布，是欧盟层面针对计算机化系统 GMP 要求的专项附录。2011 年 6 月 30 日起生效的 revision 1 是现行版本。本次修订的背景（官方声明）是：计算机化系统的使用日益广泛、系统复杂性不断提升，原文本已不足以覆盖由此带来的质量风险；同时，作为配套修订，GMP 指南第 4 章（文件与记录，Chapter 4: Documentation）也做了同步调整。

Annex 11 的条款结构分为两大阶段：项目阶段（Project Phase，第 4 章验证）与运营阶段（Operational Phase，第 5~17 章数据、准确性检查、数据存储、打印输出、审计追踪、变更与配置管理、周期性评估、安全、事件管理、电子签名、批放行、业务连续性、归档）。这种"开发→运营"两段式结构，对应计算机化系统生命周期的完整链条：从需求、验证到日常运行、持续受控。

1.3 法规要求（Regulatory Requirements）

Annex 11 发布的法律基础为《Directive 2001/83/EC》（人用药品共同体法典）第 47 条与《Directive 2001/82/EC》（兽用药品共同体法典）第 51 条；其内容是对《Directive 2003/94/EC》（人用药品 GMP 原则与指南）与《Directive 91/412/EEC》（兽用药品 GMP）所规定 GMP 原则的细化解释。

对企业而言需要理解：Annex 11 的最低要求对在欧盟辖区开展 GMP 活动的所有计算机化系统均适用，不因系统规模、形态（本地部署、云部署、SaaS）或供应商来源而豁免；企业应将其纳入自身的 GMP 质量体系，并通过内部规程（SOP）转化为可执行的要求。

1.4 适用范围（Scope and Applicability）

Annex 11 适用于**所有作为 GMP 受监管活动一部分的计算机化系统**（见"原则"部分条款原文），包括但不限于：

• 生产控制系统：DCS/SCADA/PLC、批处理自动化系统；

• 实验室系统：LIMS、色谱数据系统（CDS）、电子天平/ pH 计等仪器软件；

• 质量体系系统：文档管理系统（DMS）、培训管理系统（TMS）、偏差/变更/CAPA 系统、环境监测系统（EMS）；

• 物流与仓储系统：WMS、温控冷链监控系统；

• 支持性基础设施：服务器、网络、操作系统、数据库、虚拟化与云平台（按"IT 基础设施确认"要求管理）。

特别说明：本指南以 2011 年生效的官方文本条款为解读对象；行业实践中常结合 GAMP 5（第二版，含云/SaaS 场景）与 ISPE IT 基础设施指南等作为实施方法论，本指南在相关条款处做了引用提示，但条款解读始终以 Annex 11 原文为基准。

原则（Principle）

Principle This annex applies to all forms of computerised systems used as part of a GMP regulated activities. A computerised system is a set of software and hardware components which together fulfill certain functionalities.

The application should be validated; IT infrastructure should be qualified.

Where a computerised system replaces a manual operation, there should be no resultant decrease in product quality, process control or quality assurance. There should be no increase in the overall risk of the process.

【条款意图】

原则部分给出三个总纲性要求，是理解全部条款的钥匙：

• 适用范围无差别：凡属 GMP 受监管活动一部分的计算机化系统，无论形态与规模，均受本附录约束。"计算机化系统=软件+硬件组合实现特定功能"，边界由功能定义，而非由设备外观定义（例如带数据记录功能的培养箱/灭菌器，其软件部分同样是计算机化系统）；

• 应用验证、基础设施确认：这是 Annex 11 最具辨识度的二分法——承载业务功能的应用程序（Application，如 LIMS、MES、CDS）需要"验证（validated）"，支撑其运行的信息技术基础设施（IT Infrastructure，如网络、操作系统、数据库、服务器、云平台）需要"确认（qualified）"。两者活动内容不同：验证聚焦功能符合预期用途（V 模型、测试、追溯），确认聚焦基础设施受控且适合其用途（配置管理、安全基线、性能与可靠性）；

• 替代人工操作不得降低质量：电子化/计算机化的目的可以是为了效率，但不得以牺牲质量为代价——电子记录不应弱于纸质记录（数据完整性不降低），电子流程不应弱于人工流程（过程控制与质量保证不降低），系统引入不得带来过程整体风险的上升。这条是"先评估后上线"的总原则。

【如何实施】

• 建立企业范围内的计算机化系统清单（系统盘点），逐系统标注：功能、GAMP 软件分类、所属业务流程、数据完整性关键性——清单是"适用范围"落地的第一抓手；

• 对清单内每个系统界定其"计算机化系统边界"：哪些组件属应用程序、哪些属 IT 基础设施，分别纳入验证或确认计划；

• 对"人工→计算机化"的转换（如纸质批记录→电子批记录、人工环境监测→EMS 在线监测），在变更控制中专项评估：质量/过程控制/质量保证是否降低、整体风险是否上升，评估结论文件化。

【检查要点与常见缺陷】

• 系统清单不完整：只列了"大系统"（LIMS/MES），漏掉嵌入软件的仪器、电子表格、小工具；

• 应用与基础设施混为一谈：对基础设施做"验证"或对应用只做"确认"，术语与方法错配；

• 电子化替代人工后，原纸质复核环节被直接取消且无等效控制（质量保证实质降低）。

第 1 章　风险管理（Risk Management）

1. Risk management should be applied throughout the lifecycle of the computerised system taking into account patient safety, data integrity and product quality. As part of a risk management system, decisions on the extent of validation and data integrity controls should be based on a justified and documented risk assessment of the computerised system.

【条款意图】

风险管理应贯穿计算机化系统生命周期全程，决策时应统筹考虑三个维度：患者安全、数据完整性、产品质量。验证的范围与深度、数据完整性控制措施（如审计追踪、电子签名、双人复核）的取舍，都必须建立在**经过论证并文件化**的风险评估基础之上——即"以风险定验证程度"，而不是一刀切地对所有系统做相同深度的活动。

【如何实施】

• 建立基于风险的评估层级：通常自上而下为——①系统影响评估（SIA：判定直接影响/间接影响/无影响，直接影响系统纳入 GxP 管理范围）；②GAMP 软件分类（第 1~5 类，确定验证策略基线）；③数据完整性风险评估（DI RA：识别关键数据与关键流程，决定数据完整性控制）；④功能风险评估（如 FMEA，聚焦具体失效模式）。层级之间应有逻辑推导关系，并体现在验证计划（VP）中；

• 风险评估文件化并用于决策：评估结论要落到具体决策上——验证活动中哪些测试做、做多深，数据上是否启用审计追踪、是否需要双人复核、备份频次如何。评估报告应写明"依据风险确定了哪些控制"，避免评估与实施"两张皮"；

• 风险文档随生命周期更新：系统大变更（架构调整、数据迁移、接口新增）后应重新评估；周期性评估（第 11 章）也应复核风险结论是否仍然成立；

• 与质量体系的 QRM 框架衔接：企业若已按 ICH Q9 建立质量风险管理规程，计算机化系统风险活动应纳入同一框架（风险识别→分析→评价→控制→评审），术语与评分规则保持一致。

【检查要点与常见缺陷】

• 风险评估做完即封存，验证范围并未真正"由风险决定"（例如低风险系统做了过度验证、高风险系统却只做冒烟测试）；

• 风险评分为拍脑袋：S/P/D 值无评分定义、无客观依据，审计时无法解释；

• 只评了"产品质量风险"，忽略数据完整性风险与业务连续性风险维度。

第 2 章　人员（Personnel）

2. There should be close cooperation between all relevant personnel such as Process Owner, System Owner, Qualified Persons and IT. All personnel should have appropriate qualifications, level of access and defined responsibilities to carry out their assigned duties.

【条款意图】

计算机化系统的管理是跨职能协作，条款点名了四类关键角色：流程所有者（负责业务流程）、系统所有者（负责系统可用性与维护、数据安全）、质量受权人（QP，负责批放行）、IT（负责技术运维）。各方应紧密协作；所有相关人员应具备适当的资质、与其职责相称的访问权限，并有明确的职责定义。

【如何实施】

• 明确角色与职责（RACI）：对每个 GxP 系统建立 RACI 矩阵，至少明确：流程所有者（业务端）、系统所有者（技术端）、验证负责人、QA 审批、IT 运维、用户代表的职责边界。角色定义写入岗位说明书或系统责任规程；

• 资质与培训：按岗位设计培训矩阵——用户接受操作规程培训、系统所有者/IT 接受系统管理与 GMP 基础培训、验证人员接受 CSV 方法论培训、QP 了解电子记录与数据完整性要求。培训要有记录与效果评估；

• 访问权限与职责匹配：按"最小权限"原则分配系统账号与角色权限（与第 12 章衔接）：操作员只能执行其职责所需功能，普通用户不得拥有管理/配置权限；权限授予需经申请-审批流程；

• 跨职能协作机制：系统重大事项（验证、变更、事件）应建立多角色参与的评审机制（如变更评审会、周期性评估小组），确保业务、技术、质量三方都在场。

【检查要点与常见缺陷】

• IT/系统管理员未接受 GMP 培训或培训无记录；

• 系统所有者虚位：业务部门认为系统是 IT 的、IT 认为系统是业务部门的、实际无人对系统整体负责；

• 共享账号、管理员账号与普通账号混用，作业无法追溯到具体人员（同时违反第 12.4 条）。

第 3 章　供应商与服务商（Suppliers and Service Providers）

3.1 When third parties (e.g. suppliers, service providers) are used e.g. to provide, install, configure, integrate, validate, maintain (e.g. via remote access), modify or retain a computerised system or related service or for data processing, formal agreements must exist between the manufacturer and any third parties, and these agreements should include clear statements of the responsibilities of the third party. IT-departments should be considered analogous.

3.2 The competence and reliability of a supplier are key factors when selecting a product or service provider. The need for an audit should be based on a risk assessment.

3.3 Documentation supplied with commercial off-the-shelf products should be reviewed by regulated users to check that user requirements are fulfilled.

3.4 Quality system and audit information relating to suppliers or developers of software and implemented systems should be made available to inspectors on request.

【条款意图】

计算机化系统的建设与运维大量依赖外部第三方（供应商、实施方、维护服务商、数据处理方）。条款要求：①任何第三方参与（安装、配置、集成、验证、维护——含远程访问维护、修改、保存、数据处理）都必须有**正式协议**且明确第三方职责；企业内部 IT 部门提供服务时，管理方式应"视同第三方"（即同样是职责界定清晰、按约定的服务水平管理）；②供应商选择要评估能力与可靠性，是否现场审计由风险评估决定；③商业现货产品（COTS）随附文档要由受监管用户（企业方）审阅，确认满足用户需求；④供应商质量体系与审计信息应能应检查要求提供给检查员。

【如何实施】

• 质量协议/SLA：与外部供应商签订正式协议，明确：服务范围与责任界面（谁负责什么）、远程访问的授权范围与记录要求、变更通知义务、数据所有权与保密、支持响应级别、服务终止时的数据移交安排；

• 远程访问受控：供应商远程维护访问应走申请-审批-记录流程（何时、谁、访问了哪里、做了什么），并尽量安排在受控窗口；

• 供应商评估分层：按系统关键性与供应商风险确定评估方式——问卷评估、书面材料（ISO 9001/27001 证书、CSV 能力证明）评审、现场/远程审计。高风险关键系统供应商应现场审计，并形成正式评估报告；

• COTS 文档审核：收到软件随附文档（用户手册、版本发布说明、已知问题/局限清单、历史缺陷记录）后，由受监管用户对照 URS 逐条核查功能满足性，记录核查结论；

• 检查可获取性：在协议中约定供应商质量体系与审计信息可提供给监管机构检查（必要时通过保密协议衔接）。

【检查要点与常见缺陷】

• 无质量协议，或协议只写商务条款、不写 GMP 相关责任（验证支持、变更通知、数据提供）；

• 远程访问不受控：供应商可随时远程登录系统，无授权、无记录、无审计；

• COTS 软件"装了就用"：随附文档无人审阅，UR 满足性未确认；

• 供应商审计流于形式：审计报告无结论、无整改跟踪；低风险系统反而做了过度审计。

第 4 章　验证（Validation）

第 4 章对应"项目阶段（Project Phase）"，是 Annex 11 篇幅最大的章节，规定了计算机化系统验证的完整要求。

4.1 验证文档覆盖生命周期

4.1 The validation documentation and reports should cover the relevant steps of the life cycle. Manufacturers should be able to justify their standards, protocols, acceptance criteria, procedures and records based on their risk assessment.

【条款意图】

验证文档与报告应覆盖生命周期的相关步骤；企业必须在风险评估基础上，对采用的标准、方案、接受标准、规程与记录给出依据（justify）——即每一步验证活动"为什么这样做、为什么做到这个深度"都要能讲出道理。

【如何实施】

• 按生命周期组织验证文档包：验证计划（VP）→ 用户需求（URS）→ 功能/设计规格（FS/DS）→ 测试（IQ/OQ/PQ 或按 GAMP 方法）→ 验证总结报告（VSR）；

• 验证计划中说明验证策略的确定依据（引用 SIA 结论与 GAMP 分类）、验证活动范围、角色职责、接受标准决策规则；

• 接受标准必须可测（明确参数值与判定规则），"系统工作正常"这类模糊表述不可接受；

【检查要点与常见缺陷】

• 接受标准模糊/不可测；标准、方案、记录之间对不上（如方案写测 A 项、记录里没有）；

• 验证活动与风险评估脱节：风险高而未验证、风险低而过度验证，且无理由。

4.2 验证文档包含变更与偏差记录

4.2 Validation documentation should include change control records (if applicable) and reports on any deviations observed during the validation process.

【条款意图】

验证过程不是"只记好结果"：验证期间发生的偏差（失败、异常、与预期不符）必须记录并报告；如验证过程中系统发生变更（如发现缺陷后修改配置/打补丁），相关变更控制记录应纳入验证文档。

【如何实施】

• 测试执行中发现的偏差按偏差管理流程记录（描述、原因分析、处置、对验证结论的影响评估）；

• 验证期间的变更（含测试脚本本身的修订）走变更控制并在验证总结报告中说明；

• 偏差未关闭或影响未评估前，不得得出"验证通过"结论。

【检查要点与常见缺陷】

• 测试失败被悄悄重跑成功，无偏差记录、无原因分析；

• 验证期间打了补丁改了配置，但验证总结报告未提及。

4.3 系统清单与关键系统描述

4.3 An up to date listing of all relevant systems and their GMP functionality (inventory) should be available.

For critical systems an up to date system description detailing the physical and logical arrangements, data flows and interfaces with other systems or processes, any hardware and software pre-requisites, and security measures should be available.

【条款意图】

①维护一份最新的系统清单（inventory），列明所有相关系统及其 GMP 功能——这是盘点、分组验证、审计应答的基础；②关键系统还应有最新的**系统描述**：物理与逻辑布局、数据流、与外部系统/流程的接口、软硬件前提条件、安全措施。

【如何实施】

• 系统清单字段建议：系统名称/编号、版本、供应商、部署环境、GAMP 分类、SIA 结论、所属业务流程、数据完整性关键性、验证状态、系统所有者/流程所有者、上线与退役日期；

• 关键系统描述（System Description）建议以系统框图+说明文字呈现；随系统变更同步更新；

• 清单每年复核（可与第 11 章周期性评估联动），新增/退役系统及时增删。

【检查要点与常见缺陷】

• 清单陈旧：新增系统未入账、退役系统仍挂账；

• 清单只列"大系统"，嵌入式软件、电子表格等小系统遗漏；

• 关键系统无系统描述，或描述与实际部署不符（架构已改但文档未更新）。

4.4 用户需求规格（URS）

4.4 User Requirements Specifications should describe the required functions of the computerised system and be based on documented risk assessment and GMP impact. User requirements should be traceable throughout the life-cycle.

【条款意图】

URS 应描述系统的必需功能，其形成要基于文件化的风险评估与 GMP 影响分析；用户需求要在整个生命周期内**可追溯**（需求→设计→测试→验收，双向追溯）。

【如何实施】

• URS 按"功能需求+法规与数据完整性需求+非功能需求（性能、可用性、安全）"组织，需求编号（URS-001…）以便追溯；

• URS 起草前完成系统影响评估（SIA）与 GMP 影响分析，URS 引言注明依据；

• 建立需求追溯矩阵（RTM）：每条需求映射到设计/配置项与测试项；测试完成后反向核查每条需求均有验证；

• UR 变更走变更控制，追溯矩阵同步更新。

【检查要点与常见缺陷】

• URS 事后补写（系统已上线再"回忆"需求），无批准日期链；

• UR 与测试脱节：测试脚本内容与 URS 无关，RTM 缺失或做表面文章；

• URS 只写功能不写数据完整性需求（审计追踪、权限、备份）。

4.5 供应商质量体系评估

4.5 The regulated user should take all reasonable steps, to ensure that the system has been developed in accordance with an appropriate quality management system. The supplier should be assessed appropriately.

【条款意图】

企业（受监管用户）有责任采取合理步骤确认系统是按恰当的质量管理体系开发的（开发过程受控），并对供应商进行适当评估。"适当"的程度由系统关键性与供应商风险决定（与 3.2 呼应）。

【如何实施】

• COTS 软件：索取供应商 ISO 9001/ISO 27001 认证、CSV 相关资质、开发与测试规范证据；

• 定制/自研系统：评估供应商软件开发质量管理（需求管理、编码规范、测试、版本控制、缺陷管理）；

• 供应商评估结论文件化：评估方式（问卷/审计）、范围、结论、后续跟进。

【检查要点与常见缺陷】

• 对供应商"完全信任"：无任何评估证据，仅凭销售承诺；

• 评估报告无明确结论，或高风险的定制系统与低风险系统用同一浅层评估。

4.6 定制/自研系统的全生命周期评估

4.6 For the validation of bespoke or customised computerised systems there should be a process in place that ensures the formal assessment and reporting of quality and performance measures for all the life-cycle stages of the system.

【条款意图】

定制/自研系统（GAMP 第 5 类及深度定制系统）的软件质量责任在开发过程本身，企业应建立流程，对系统全生命周期各阶段的质量与性能指标进行正式评估与报告。

【如何实施】

• 按软件生命周期（需求→设计→编码→单元/集成/系统测试→发布）分阶段评审并留下评估报告；

• 制定开发质量指标（缺陷密度、测试覆盖率、关键缺陷关闭率）并定期汇总报告；

• 明确企业内部对定制系统开发过程的监督角色（QA/CSV 工程师参与关键评审）；

• 源代码、构建产物、版本管理手段（如代码仓库）纳入受控管理。

【检查要点与常见缺陷】

• 定制系统只做了"黑盒验收测试"，开发过程无任何质量证据；

• 代码无版本管理、无评审记录，出问题无法回溯。

4.7 测试方法与测试场景

4.7 Evidence of appropriate test methods and test scenarios should be demonstrated. Particularly, system (process) parameter limits, data limits and error handling should be considered. Automated testing tools and test environments should have documented assessments for their adequacy.

【条款意图】

验证必须展示恰当的测试方法与测试场景证据——测试不是"能跑就算过"：应专门考虑系统（过程）参数边界、数据边界（最大/最小/非法值）与错误处理（异常输入、异常中断时的行为）；使用自动化测试工具与独立测试环境时，其充分性（工具本身可信、环境与生产一致/隔离）要有文件化评估。

【如何实施】

• 测试脚本覆盖：正常路径 + 边界值（参数上下限、数据量上限）+ 非法输入/错误场景（越权操作、无效数据、断电/中断恢复）；

• 数据完整性相关测试：审计追踪记录正确性、防篡改、数据溢出/覆盖行为；

• 自动化测试工具（如接口测试工具、回归脚本）使用前评估其可信性（已验证/经确认）；测试环境与生产环境的差异（版本、配置、数据）记录并评估影响；

• 测试结果留痕：原始数据、截图、输出文件归档。

【检查要点与常见缺陷】

• 只有"happy path"测试，无边界与错误场景；

• 测试在测试库进行，测试环境无管理（谁都能改数据）、与生产差异未评估；

• 自动化测试工具未经验证即用于验证结论。

4.8 数据迁移验证

4.8 If data are transferred to another data format or system, validation should include checks that data are not altered in value and/or meaning during this migration process.

【条款意图】

数据迁移（换系统、换格式、系统升级/退役时的数据转移）必须验证：迁移过程中数据的**值**与**含义**均不被改变——即不仅数量一致，内容、单位、关联关系、元数据语义都要保持一致。

【如何实施】

• 制定数据迁移方案：迁移范围、源/目标格式、映射规则、数据清洗规则、迁移工具、验证策略；

• 迁移验证（比对）：抽样比对+全量统计比对（记录数、关键字段、校验和哈希）、数据映射正确性抽查、目标系统数据可读性与功能可用性确认；

• 关注元数据与语义：单位换算、时间戳时区、枚举值映射、父子记录关联、签名/审计追踪关联是否保留；

• 迁移结果出具报告，确认数据完整性（ALCOA+）在迁移后仍满足。

【检查要点与常见缺陷】

• 只比对"条数不变"，不核对内容与含义（字段错位、单位变化、时间丢失）；

• 迁移脚本无验证、迁移后旧系统数据直接被删；

• 没有迁移报告或报告无结论。

第 5 章　数据（Data）

从本章起进入"运营阶段（Operational Phase）"。第 5~9 章围绕数据完整性展开：数据交换、准确性检查、数据存储、打印输出、审计追踪。

5. Computerised systems exchanging data electronically with other systems should include appropriate built-in checks for the correct and secure entry and processing of data, in order to minimize the risks.

【条款意图】

与其他系统进行电子数据交换的系统（如 LIMS↔ERP、DCS↔MES、仪器↔CDS、系统↔云平台），应内置恰当的检查机制，确保数据被正确、安全地输入与处理，以最小化传输与处理过程中的风险。重点是接口处的数据完整性——传输不丢失、不改变、不被截获篡改、不因格式差异而语义变化。

【如何实施】

• 接口设计内置校验：传输校验（校验和/哈希、报文长度验证）、字段级校验（格式、范围、必填项）、事务完整性（提交/回滚、幂等处理）；

• 电子传输失败处理：重传机制、失败告警、失败日志（时间/内容/原因），传输失败不得静默丢数据；

• 接口验证纳入系统验证：接口测试覆盖正常传输、异常数据、断线重连、并发/大数据量场景；

• 传输链路安全：加密传输（如 TLS）、身份认证（API 密钥/证书）、传输日志留存；

• 对数据交换语义进行文档化管理：数据字典（字段定义、单位、枚举值）在两端系统一致，防止"值对但含义错"。

【检查要点与常见缺陷】

• 系统间传输无校验：断传/错传无感知，事后比对才发现数据缺失；

• 接口无日志或日志周期短，追溯困难；

• 两端数据字典不一致（单位/编码/时区），数据值相同但含义改变——属于典型数据完整性缺陷。

第 6 章　准确性检查（Accuracy Checks）

6. For critical data entered manually, there should be an additional check on the accuracy of the data. This check may be done by a second operator or by validated electronic means. The criticality and the potential consequences of erroneous or incorrectly entered data to a system should be covered by risk management.

【条款意图】

对**人工输入的关键数据**，必须有额外的准确性检查：要么由第二人复核（双人复核），要么由经验证的电子手段校验（如范围检查、逻辑校验、格式校验、二次输入比对）。哪些数据算"关键"、错误输入会带来什么后果，由风险管理覆盖——即检查力度由数据关键性决定。

【如何实施】

• 识别关键人工输入点：批放行关键参数（温湿度读数、检验结果临界值、称量数据）、直接影响放行/处置决策的手工录入；

• 选择复核方式：双人复核（录入+复核双签，复核记录留痕）或电子校验（双次输入比对、范围/逻辑校验、与源系统比对）；

• 电子校验手段本身需经验证（"validated electronic means"）：校验规则的正确性应有测试证据；

• 复核记录可追溯：复核人、复核时间、复核结果留痕（与审计追踪关联）；

• 对非关键数据避免过度复核，复核范围与力度与风险相称。

【检查要点与常见缺陷】

• 关键数据单人输入无复核（尤其检验结果、批记录关键参数）；

• "双人复核"无记录或复核人形同虚设（只签名不核对）；

• 电子校验规则未经验证或规则放水（范围设过宽失去校验意义）。

第 7 章　数据存储（Data Storage）

7.1 Data should be secured by both physical and electronic means against damage. Stored data should be checked for accessibility, readability and accuracy. Access to data should be ensured throughout the retention period.

7.2 Regular back-ups of all relevant data should be done. Integrity and accuracy of back-up data and the ability to restore the data should be checked during validation and monitored periodically.

【条款意图】

①数据须通过物理与电子双重手段防损坏；已存数据应检查可访问性、可读性、准确性；整个**保留期内**必须保证可访问（数据保留期常长于系统生命周期，如批记录数据长期保存）；②所有相关数据应**定期备份**；备份数据的完整性与准确性、以及**恢复能力**（能把数据恢复回来）应在验证时检查并定期监控。

【如何实施】

• 存储防护：物理（机房环境、UPS、防火防水、介质冗余 RAID）与电子（访问控制、防病毒、加密、权限隔离）双重防护；存储介质损坏或老化监测；

• 定期检查可访问性/可读性/准确性：抽样读取存档/在线数据，确认可读、内容准确（尤其介质换型、系统升级后）；

• 备份策略：明确备份范围（数据库、文件、配置、审计追踪）、方式（完整/增量）、频率（按数据关键性与变更频率定，关键系统建议每日）、介质与存放位置（异地/离线一份）；

• 恢复验证：验证阶段执行恢复演练证明可恢复；运营期定期（如每年）执行恢复测试，恢复时长满足业务要求（RTO）；备份日志与监控（备份失败告警、未被注意的静默失败）；

• 保留期：与注册文件/法规要求的记录保存期限对齐（如批记录法定保存期），过期数据按规程处置。

【检查要点与常见缺陷】

• 只备份、从不恢复验证——"备份成功"不等于"能恢复"（检查员最常抓的点）；

• 备份介质与生产同机房/无异地副本，机房事故即数据全损；

• 备份无人监控：连续备份失败数周无人发现；

• 保留期满数据未按规程处置，或未到期数据被提前删除。

第 8 章　打印输出（Printouts）

8.1 It should be possible to obtain clear printed copies of electronically stored data.

8.2 For records supporting batch release it should be possible to generate printouts indicating if any of the data has been changed since the original entry.

【条款意图】

①系统应能输出电子存储数据的清晰打印副本——电子记录不能只存在于屏幕上；②对支持**批放行**的记录，打印件应能显示数据自原始输入以来是否被修改（即打印时能反映记录的完整性状态，配合审计追踪）。

【如何实施】

• 打印功能纳入验证：打印格式清晰完整（标题、时间、页码、系统标识）、内容与电子记录一致；

• 批放行支持性记录的打印模板，应包含/可追溯修改标识（如打印件标注"数据已被修改、见审计追踪"或提供修改历史附页）；

• 规定打印件在放行/审核场景的使用要求（如 QP 放行审核电子数据+打印件的一致性）；

• 保留打印功能在系统升级后的回归确认（打印输出经常因报表组件升级而回归失败）。

【检查要点与常见缺陷】

• 打印件与屏幕显示不一致或打印格式残缺（缺页、无时间戳）；

• 批放行记录打印件无法看出数据曾被修改——电子放行审核依赖"看不见的修改历史"；

• 重大升级后打印功能回归失效未发现。

第 9 章　审计追踪（Audit Trails）

9. Consideration should be given, based on a risk assessment, to building into the system the creation of a record of all GMP-relevant changes and deletions (a system generated "audit trail"). For change or deletion of GMP-relevant data the reason should be documented. Audit trails need to be available and convertible to a generally intelligible form and regularly reviewed.

【条款意图】

基于风险评估，应考虑在系统中构建对**全部 GMP 相关变更与删除**的记录（系统生成的审计追踪）；GMP 相关数据的变更/删除应记录**原因**；审计追踪须可用、可转换为通用可读形式（如 PDF/CSV），并**定期审核**。

【如何实施】

• 设计：URS 中明确审计追踪需求；审计追踪覆盖创建、修改、删除、打印、导出、登录/注销、权限变更等 GMP 相关事件；记录字段：操作人、时间戳（日期+时间）、操作类型、前后值（修改类）、原因；

• 防篡改：审计追踪为系统生成，普通用户不可编辑/删除/关闭；管理员访问审计追踪的权限受限并自身被记录（防止"管理员删审计"）；

• 可读性：审计追踪可导出为通用格式（PDF/Excel/CSV）并含检索功能，日常与检查场景均可查阅；

• 定期审核：建立审计追踪审核计划——审核频率（建议关键系统定期，如每月）、审核内容（异常操作、删除/修改事件、非常规时间活动）、审核角色（独立于被审核操作人员）、审核记录与发现问题跟踪；

• 原因字段管理：修改/删除时强制填写原因，审核时抽查原因合理性（防止"手误"万能理由）。

【检查要点与常见缺陷】

• 审计追踪存在但从未被审核——"有功能无监督"，检查员重点关注；

• 管理员权限可关闭/篡改审计追踪；

• 审计追踪与业务记录分离存储、无法关联（记录改了查不到对应审计项）；

• 删除操作无原因或原因千篇一律；审计导出格式不可读。

第 10 章　变更与配置管理（Change and Configuration Management）

10. Any changes to a computerised system including system configurations should only be made in a controlled manner in accordance with a defined procedure.

【条款意图】

对计算机化系统的任何变更——**包括系统配置的变更**——都必须在受控方式下按既定程序执行。配置变更往往最易被忽视（觉得"只是改个参数"），条款明确将其纳入变更管理。

【如何实施】

• 建立计算机化系统变更控制程序：变更申请→影响评估（功能、数据完整性、接口、验证状态）→批准→实施→测试/回归→更新文档（验证文档、系统描述、清单）→关闭；

• 配置管理：维护配置项清单（硬件、软件版本、参数配置、接口配置），记录当前基线；配置变更与代码/版本变更同等受控；

• 变更分类：按影响大小分级（如：重大架构变更/常规功能变更/配置微调/运维类变更），不同级别走不同审批路径；

• 变更后评估验证状态：判断是否需要再验证（全验证/部分回归/仅文档更新），结论文件化；

• 变更记录与验证文档联动（与 4.2 呼应）：验证期间的变更纳入验证文档。

【检查要点与常见缺陷】

• 配置参数修改（如权限设置、报告模板、方法参数）不走变更控制；

• 打补丁/升级直接实施，无影响评估与回归测试；

• 变更后验证文档/系统描述未同步更新（文档与实际漂移）；

• 无配置基线：说不清系统当前版本与配置状态。

第 11 章　周期性评估（Periodic Evaluation）

11. Computerised systems should be periodically evaluated to confirm that they remain in a valid state and are compliant with GMP. Such evaluations should include, where appropriate, the current range of functionality, deviation records, incidents, problems, upgrade history, performance, reliability, security and validation status reports.

【条款意图】

计算机化系统应**定期评估**，以确认系统仍处于验证状态且符合 GMP（验证不是一次性的——系统在日常使用中会因变更、事件、环境变化而"漂移"）。评估内容（如适用）：当前功能范围、偏差记录、事件、问题、升级历史、性能、可靠性、安全性、验证状态报告。

【如何实施】

• 制定周期性评估计划：评估频率（建议按风险定，关键系统至少每年；可结合系统清单复核）、评估范围、评估小组（业务+IT+QA）、输出报告；

• 评估输入：系统清单变更、本周期内偏差/事件/问题清单与关闭情况、升级与补丁记录、权限审查结果、备份恢复演练结果、性能监控数据（响应时间、故障率）、审计追踪审核发现、用户反馈；

• 评估结论：系统是否仍处于验证状态；发现的问题转 CAPA 或变更控制；更新验证状态并记录；

• 事件驱动的评估：重大事件、重大变更、体系要求变化后按需触发补充评估。

【检查要点与常见缺陷】

• 周期评估"走过场"：只签个名，未实质收集数据；

• 评估间隔过长或与系统风险不匹配（高故障系统与稳定系统同频）；

• 评估发现的问题无跟踪闭环（CAPA 未落实）。

第 12 章　安全（Security）

12.1 Physical and/or logical controls should be in place to restrict access to computerised system to authorised persons. Suitable methods of preventing unauthorised entry to the system may include the use of keys, pass cards, personal codes with passwords, biometrics, restricted access to computer equipment and data storage areas.

12.2 The extent of security controls depends on the criticality of the computerised system.

12.3 Creation, change, and cancellation of access authorisations should be recorded.

12.4 Management systems for data and for documents should be designed to record the identity of operators entering, changing, confirming or deleting data including date and time.

【条款意图】

①必须有物理和/或逻辑控制，将系统访问限制在**授权人员**范围——防未经授权进入的手段包括：钥匙、通行卡、带密码的个人代码、生物识别、限制进入计算机设备与数据存储区域；②安全控制的强度与系统关键性成正比（关键系统更严）；③访问授权的**创建、变更、取消**（账号生命周期）都要有记录；④数据与文档管理系统应设计为能记录操作者身份（谁输入、修改、确认、删除数据）及日期时间——即所有数据操作可追溯到具体个人。

【如何实施】

• 逻辑访问控制：个人账号+强密码策略（长度/复杂度/定期更换）；角色权限矩阵（最小权限）；管理员账号独立且受控；禁止共享账号；默认密码强制修改；

• 物理访问控制：机房/服务器区域门禁（钥匙/刷卡/生物识别）、记录进出；终端设备屏幕锁；数据存储介质物理保管；

• 账号生命周期管理：账号申请-审批-开通记录；人员转岗/离职及时变更或销号（HR 与 IT 流程联动）；定期（建议季度/半年）账号权限复核并留记录；

• 身份记录设计：系统设计层面确保所有数据操作带操作者身份+日期时间（底层不可关闭），打印/导出亦带操作信息；

• 安全控制分级：按系统关键性定义安全基线——关键系统（放行、生产控制）执行强控制；支持性系统可适度简化，但数据完整性与追溯要求不降低。

【检查要点与常见缺陷】

• 共享账号/通用管理员账号——数据操作无法定位到人（最严重问题之一）；

• 离职人员账号未及时销户（且曾拥有关键权限）；

• 密码策略薄弱（无复杂度要求、长期不换）、默认密码未改；

• 权限审查无记录或从不执行；

• 系统无操作者身份记录机制（只记录"系统"不记录"人"）。

第 13 章　事件管理（Incident Management）

13. All incidents, not only system failures and data errors, should be reported and assessed. The root cause of a critical incident should be identified and should form the basis of corrective and preventive actions.

【条款意图】

**所有事件**都应报告并评估——不仅是系统故障和数据错误，还包括异常操作、可疑活动、超预期行为等；关键事件必须识别**根本原因**，并以此为基础制定纠正与预防措施（CAPA）。

【如何实施】

• 定义事件范围与分级：系统宕机/性能异常/数据错误/数据丢失/异常操作/安全事件（入侵尝试、账号异常）等；按对 GMP 活动影响分级（关键/一般）；

• 事件报告通道：用户可便捷报告（不因"怕麻烦"隐瞒），记录事件时间、现象、影响范围、发现人；

• 事件调查：关键事件开展根因分析（5-Why、鱼骨图等），区分直接原因与根本原因；

• CAPA：根因→纠正措施（恢复/补救）+ 预防措施（防止再发）→ 责任人与时限→ 有效性验证；

• 事件趋势分析：定期汇总事件数据（频次、类型、系统分布），异常趋势预警，并与第 11 章周期性评估联动。

【检查要点与常见缺陷】

• 只报系统故障不报数据错误/可疑操作——"数据错误不可接受所以不记录"的悖论；

• 事件处理只做"重启恢复"，不做根因分析、无 CAPA；

• 事件记录分散/缺失（口头处理不留痕）；

• CAPA 无跟踪、无有效性验证。

第 14 章　电子签名（Electronic Signature）

14. Electronic records may be signed electronically. Electronic signatures are expected to:

a. have the same impact as hand-written signatures within the boundaries of the company,

b. be permanently linked to their respective record,

c. include the time and date that they were applied.

【条款意图】

电子记录可以电子签名。电子签名须满足三要素：①在公司边界内与手写签名具有同等效力（流程上等同于签字批准/复核）；②与其对应的记录**永久关联**（签名不可被移动/复制到其他记录）；③包含**应用签名的时间与日期**。

【如何实施】

• 电子签名实现：通常为个人唯一账号+密码（或生物识别）+签名事件记录；签名要素（签字人身份、时间戳、签名含义/动作类型）与记录绑定存储；

• 签名含义明确：不同签名动作（如"录入""复核""批准""放行"）在系统中区分并定义其意义；

• 签名与记录绑定验证：验证阶段测试——签名后修改记录内容，签名应失效/可见（记录被改动后签名状态可察），签名不可转移到其他记录；

• 同名同效：电子签名流程上与纸质签字同等受控——签名即承担责任，纳入授权与培训管理；

• 电子签名使用规程：明确哪些场景使用电子签名、签名规则（连续签名、防歧义）、争议处置。

【检查要点与常见缺陷】

• 电子签名与记录可分离（如签名仅是一个可复制的图片/字段）；

• 签名无时间戳或时间可篡改；

• 签名含义不清：一个"签名"同时代表录入与批准，无法区分责任；

• 电子签名账号共享（失去签名的个人责任属性）。

第 15 章　批放行（Batch Release）

15. When a computerised system is used for recording certification and batch release, the system should allow only Qualified Persons to certify the release of the batches and it should clearly identify and record the person releasing or certifying the batches. This should be performed using an electronic signature.

【条款意图】

当系统用于记录批认证与批放行时：①系统必须**只允许质量受权人（QP）**认证/放行批次；②系统必须清楚标识并记录实际放行/认证人员；③放行动作必须使用**电子签名**执行。

【如何实施】

• 放行资格控制：系统中 QP 角色权限唯一且与授权文件（QP 任命书）一致；非 QP 账号无放行操作权限（含"代放行"路径）；

• 放行记录要素：放行批次号、QP 身份（个人账号）、电子签名时间戳、放行状态与后续状态流转（如从"待放行"到"已放行"不可逆或留痕）；

• 电子签名执行放行：放行=QP 电子签名事件，与批记录/放行报告永久关联（呼应第 14 章）；

• 权限变更受控：QP 账号的授予/撤销走专门审批并记录（与 12.3 衔接）；QP 离任及时收权；

• 放行状态的可追溯性：系统支持随时回溯——某批次何时被谁放行、基于哪些电子数据。

【检查要点与常见缺陷】

• 放行操作可由非 QP 执行（如管理员代操作、权限未收紧）；

• 放行未使用个人电子签名（共用账号放行，责任无法定位）；

• QP 授权与系统角色不一致（人员已换但系统权限未同步更新）。

第 16 章　业务连续性（Business Continuity）

16. For the availability of computerised systems supporting critical processes, provisions should be made to ensure continuity of support for those processes in the event of a system breakdown (e.g. a manual or alternative system). The time required to bring the alternative arrangements into use should be based on risk and appropriate for a particular system and the business process it supports. These arrangements should be adequately documented and tested.

【条款意图】

对支撑关键过程的计算机化系统，必须为系统故障情形准备**连续性保障**（如人工流程或替代系统）；启用替代安排所需的时间应基于风险确定、与特定系统及其支撑的业务过程相称；替代安排须**充分文件化并测试**。

【如何实施】

• 识别关键系统与关键过程：放行、生产控制、检验数据、环境监测相关系统优先；

• 制定业务连续性/灾难恢复预案（BCP/DRP）：替代方案（人工纸质流程/备用系统/异地恢复）、启动条件与授权、切换步骤、恢复正常流程；

• 定义恢复目标：RTO（多长时间内必须恢复可用）与 RPO（最多可丢失多少数据）按业务风险确定；

• 替代安排文件化：人工替补流程写成可执行 SOP 并培训相关岗位（平时用得少更需演练）；

• 定期测试：演练/模拟故障，验证替代安排可用性与切换时间符合预期；测试记录与改进措施；

• 硬件冗余与维护：关键系统服务器/网络冗余、SLA 保障，降低故障概率本身。

【检查要点与常见缺陷】

• 无业务连续性预案，系统故障只能"等修复"；

• 预案存在但从未测试——检查时现场演练即暴露问题；

• 人工替代流程无 SOP/未培训（紧急时没人会操作）；

• RTO/RPO 未定义或与业务实际需求不匹配。

第 17 章　归档（Archiving）

17. Data may be archived. This data should be checked for accessibility, readability and integrity. If relevant changes are to be made to the system (e.g. computer equipment or programs), then the ability to retrieve the data should be ensured and tested.

【条款意图】

数据可以归档（从在线系统移出长期保存）。归档数据应检查**可访问性、可读性、完整性**；当系统发生重大变化（如更换计算机设备或程序）时，必须确保并**测试**归档数据的检索能力——防止"系统退役之日，即是历史数据不可读之时"。

【如何实施】

• 区分"备份"与"归档"：备份=灾难恢复的副本（短期、可覆盖），归档=法规保留的长期数据（按保存期限管理）；

• 归档策略：归档范围（满足法规/注册保存期限）、格式（优先开放/标准格式，避免依赖特定商用软件）、介质（长期可靠，定期抽样验证可读）、存储位置；

• 归档验证：归档后抽样检查可访问性/可读性/完整性；系统升级/更换/退役前，专项测试归档数据检索与导出；

• 元数据与上下文：归档时保留记录关联（审批、签名、审计追踪、批次关联），确保日后能还原记录原貌；

• 归档数据管理与访问控制：归档库同样受权限管理；查阅归档数据遵循记录管理规程并留痕。

【检查要点与常见缺陷】

• 系统退役后归档数据无法读取（依赖旧软件/旧硬件无人维护）；

• 归档只是"导出文件堆在盘里"，无索引、无抽样验证、无访问管理；

• 归档丢失关联元数据，记录上下文不可还原（签名/审计追踪/批次关联断链）；

• 把备份当归档：备份介质循环覆盖，历史数据未达保存期即被覆盖。

术语表（Glossary）——关键术语实操注解

以下术语采用 Annex 11 官方定义，并附实操注解；其余定义请以原指南（ICH Q7 Glossary）为准。

Application（应用程序）

Software installed on a defined platform/hardware providing specific functionality

实操注解：安装在特定平台/硬件上、提供特定功能的软件（如 LIMS、CDS、MES）。实操要点：应用需"验证"；GAMP 软件分类用于确定验证深度。

Bespoke / Customized computerised system（定制/自研系统）

A computerised system individually designed to suit a specific business process

实操注解：为特定业务流程单独设计的系统（GAMP 第 5 类）。实操要点：软件生命周期全过程受控（4.6 条），开发质量证据留存。

Commercial off-the-shelf software（商业现货软件，COTS）

Software commercially available, whose fitness for use is demonstrated by a broad spectrum of users

实操注解：市场在售、经广泛用户群体验证适用性的软件（如通用办公软件、数据库）。实操要点：验证聚焦配置与使用环境（3.3/4.5 条）；随附文档需受监管用户审阅。

IT Infrastructure（IT 基础设施）

The hardware and software such as networking software and operation systems, which makes it possible for the application to function

实操注解：使应用程序得以运行的基础软硬件（网络、操作系统、服务器、虚拟化/云平台等）。实操要点：基础设施做"确认（qualification）"而非应用级验证；按 ISPE IT 基础设施指南管理。

Life cycle（生命周期）

All phases in the life of the system from initial requirements until retirement including design, specification, programming, testing, installation, operation, and maintenance

实操注解：从初始需求到系统退役的全部阶段（设计/规格/编程/测试/安装/运行/维护）。实操要点：验证文档覆盖生命周期"相关步骤"（4.1）；需求全程可追溯（4.4）。

Process owner（流程所有者）

The person responsible for the business process

实操注解：对业务流程负责的人——业务需求的代言人，决定"系统要做什么"。实操要点：URS 与验收的主导角色；流程变更的发起者。

System owner（系统所有者）

The person responsible for the availability, and maintenance of a computerised system and for the security of the data residing on that system

实操注解：对系统可用性、维护及系统内数据安全负责的人。实操要点：与流程所有者分离；对系统的技术状态与数据安全负总责。

Third party（第三方）

Parties not directly managed by the holder of the manufacturing and/or import authorisation

实操注解：不受持有生产/进口许可的企业直接管理的各方（供应商、服务商、数据处理方等）。实操要点：正式协议明确职责（3.1 条）；内部 IT 部门"视同第三方"管理。

附注：本指南与相关方法论的关系

本指南是对 Annex 11 条款的"做什么+怎么做"解读。在执行层面，行业通常借助以下方法论将条款落为具体活动（引用仅为实践参考，非 Annex 11 强制要求）：

• GAMP 5（第二版）：软件分类（1~5 类）、验证 V 模型、供应商评估与 IT 基础设施控制（含云/SaaS 场景）；

• ISPE GAMP IT Infrastructure Control & Compliance（第二版）：IT 基础设施确认的具体方法；

• PIC/S PI 041（受 GMP 监管的计算机化系统）：数据完整性检查员期望；

• WHO TRS 996 Annex 5（数据完整性指南）/ WHO TRS 1053 相关章节：数据完整性（ALCOA+）要求；

• ICH Q9（质量风险管理）：风险管理方法学基础；

• ICH Q10（药品质量体系）：与质量体系要素（变更、CAPA、周期性评审）的衔接。