行业人士整理 EU GMP 附录 11 计算机化系统国内实践汇总讨论稿（Part1）

原则

This annex applies to all forms of computerised systems used as part of GMP regulated activities. A computerised system is a set of software and hardware components which together fulfil 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 受监管活动一部分使用的所有形式的计算机化系统。计算机化系统是由软件和硬件组件共同构成的、用以实现特定功能的集合。应用程序应经过验证；IT 基础架构应经过确认。当计算机化系统替代人工操作时，不应导致产品质量、工艺控制或质量保证的降低，也不应增加工艺过程的整体风险。

适用性方面，本条界定的范围不限于生产工艺与控制系统，还包括质量体系系统、仓储物流系统，乃至支撑上述系统运行的技术基础架构。判断标准是是否作为 GMP 受监管活动的一部分，而非系统的物理形态或部署方式。中国 GMP 计算机化系统附录第六条与此对应：计算机化系统验证包括应用程序的验证和基础架构的确认，其范围与程度应当基于科学的风险评估。

系统定义方面，原文将计算机化系统定义为软件加硬件。业界普遍认为该表述偏窄，研讨中与会者一致引用 PIC/S 的通行定义：计算机化系统由软件、硬件、对应的流程与相关人员共同构成。

验证与确认的分层方面，原文将质量活动按其对象性质分为两类：流程与工艺走验证，设备与基础架构走确认。行业已形成的通行做法是：

• 简单 IT 基础架构（交换机等）：一份 IQ 即可，核心是记录并控制型号与版本。

• 复杂 IT 基础架构（超融合平台、私有云控制台）：IQ 加针对关键功能的 OQ，如验证可正常生成虚拟机。

• 三类系统：URS 加 DQ、IQ、OQ，PQ 可选。

• 四类、五类系统：采用标准验证模型，五类另需集成测试。

与会企业普遍采用以 IQ 为主、按需叠加 OQ 的基础架构确认策略。某企业 6 至 7 个站点采用同一策略，通过欧盟 GMP 与 FDA 审计均未被挑战；另一企业资源受限，亦按同类策略执行。行业反馈明确不建议照搬 ISPE 的基础架构确认指南，其过于复杂、实用性不高，且会显著增加工作量与纸质文件负担。

基础架构确认的范围可按数据流判定：数据流经过的 IT 基础架构即为 GMP 相关。以网络为例，核心层必然承载 GMP 数据，判为 GMP；汇聚层按所在楼栋性质区分，GMP 生产楼与办公楼不同；接入层按交换机实际用途区分，专用于办公的接入交换机与 GMP 用途不同；服务器等基础架构同理，逐层判定。

企业还应建立计算机化系统清单，并逐条标注系统功能、软件分类、所属业务流程、数据完整性关键性；对清单中每个系统界定系统边界 —— 哪些组件属于应用、哪些属于 IT 基础架构，并分别纳入验证计划或确认计划。

替代原则方面，末两句通常合并表述为电子化替代人工不得降低质量保证水平、不得引入新的风险（中国 GMP 附录第二条表述为"应当确保不对产品的质量、过程控制和其质量保证水平造成负面影响，不增加总体风险"），涉及产品质量、工艺控制、质量保证三个不得下降的维度，以及工艺过程的整体风险不得增加。其落地应在设计阶段而非仅在变更控制中做结构化评估，并产出结构化结论：质量三要素是否下降、整体风险是否上升。

行业观察到两种失败模式：其一是完全不改，线下流程原封不动搬到线上，导致上线后系统自身负担极重；其二是大改，流程重构过度，导致系统控制力反而下降。关键判断点是线下原有的控制点搬到线上后，线上更高级的技术控制能否等效替代线下的人工控制；若可，方可移除线下控制环节。

从检查实践看，检查员对 IT 基础架构确认的关注点是有没有做，而非颗粒度有多细，有粗有细均可接受。系统清单不完整在官方审计中较少因此落缺陷，落缺陷的点通常集中在控制环节。较易被忽视而风险较高的一种情形是：电子化替代人工后，原纸质复核环节被直接取消且无等效控制，造成质量保证实质降低 —— 该情形在审计现场不常被直接发现，但在上线电子化系统的过程中极易发生，是行业自评中公认的高风险点。

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 管理范围。输出为该系统是否属 GMP 系统。

• 第二层，软件分类分级：按 GAMP 5 一、三、四、五类，或以数据维度融合输出三、四、五类。输出为验证活动的深度与形式。

• 第三层，功能风险评估（FRA ）：逐条功能或逐条 URS 评估风险，配套控制措施。输出为风险级别与控制措施。

近年另流行以数据为维度再做一次融合，如 ECA 分析设备指南采用数据重要性与系统复杂性两个维度判定，最终输出三、四、五类；某企业即以该模型开展计算机化系统验证与测试。

就系统影响性评估（SI）与计算机化系统验证（CSV）的关系，会上呈现两种并行做法。其一为融合，设备与计算机化系统评估使用同一套 SIA，优点是流程简洁、无重复工作，代价是判定基准需兼顾设备属性与数据属性。其二为拆分，验证侧一份 SI 采用直接影响、间接影响、无影响的判定，判硬件是否属 GMP 系统；CSV 侧另有一份 SI，会上称 CSI，以数据为导向，参考 GAMP 5 及 PIC/S 相关指南，判定其数据是否支持批放行，进而决定是否属于计算机化系统并开展风险评估。拆分的优点是判定基准各自纯粹、结论清晰，代价是流程繁琐、工作重复，尤其对设备类系统。采取拆分做法的企业正在考虑改造为接续的单一流程，以消除重复。

与设备、仪器评估的衔接，另一企业的做法是：设备、仪器与计算机化系统的风险评估分开进行，但通过联动衔接 —— 在 SIA 或仪器 ABC 评估时，通过特定问题链接触发是否进入计算机化系统初评，识别该设备、仪器是否产生电子数据或具备相应功能；若触发，则进入计算机化系统评估，评估相应模块并输出验证活动。最终须明确管控维度：按设备、仪器做确认并进入设备仪器清单，还是联动计算机化系统初评并输出验证活动，进入计算机化系统清单管控。

行业常用的评估模板与量化工具包括以下几类：

• 三维 checklist 模型：以患者安全、数据完整性、产品质量三个维度逐个评估点打分，按得分落区间，汇总为系统整体风险的中、高、低。

• GxP 相关性评估与 GxP 关键性评估分离：先评相关性，即是否受 GxP 管；再评关键性，涉及批放行、产品放行、最终产品精制等步骤者判为 GxP 关键系统。关键性的用途之一是确定定期回顾周期 —— GxP 关键系统 2 年、非关键系统 3 年。

• 功能风险评估的两个模板：一是部件、功能维度，先提炼部件与功能，评是否关键，再逐级往下；二是 URS 逐条维度，按 URS 一条一条评。为避免 URS 撰写不全导致遗漏，在评估表末尾增设栏目"URS 中未提及，但属法规要求且会影响产品质量、数据完整性或安全的功能"。

• 风险管理模型的选择：按 ICH Q9 的框架（风险识别、分析、评价、控制、评审）建立企业质量风险管理规程；CSV 板块可采用 FMEA 模型，并与公司统一的风险管理规程衔接。某企业即在同一规程下分设不同板块与小组，CSV 板块采用 FMEA。

风险文档应随生命周期维护。大变更发生时应重新评估，行业存在两种做法：一是对既有 URS 与 RA 升版，并对升版内容做补充确认；二是另起草一份新的风险评估文件。在定期回顾中，应回顾既往风险结论是否仍然成立，并检查验证文档能否与质量体系的 QRM 框架有效衔接。

关于风险控制措施的闭环，多数企业在评估出控制措施后，会紧接着再评一次、把风险优先级直接降到低即结束。推荐的改进是：把这一后半段拆出，作为独立的风险评估回顾阶段，置于 PQ 完成之后、RTM 之前；对验证与 PQ 未能降到可接受水平的风险项，逐项加备注说明后续控制，包括补充文件支持、纳入定期巡检，或正式强制接受并说明理由。

组织与人力方面，真正到位的风险识别需要 SME、质量验证（QV）、业务 owner 与 QA 多方参与。行业反馈：只有达到一定规模的企业（约 2000 人以上）才会组织团队把设计与流程逐条评审一遍，通常需要一周以上的评审会；普遍困境是无法让所有相关人脱产参与每一个风险点的讨论，评估团队参与度不足是漏项的主要来源。

验证职能的组织模式直接影响风险评估的分工。打散模式将 IT 类流程化系统归 IT、QC 检验仪器归 QC（采用 USP <1058> 方法论，近年已细化为 A1–A2、B1–B3、C1–C3）、生产与自控类归生产与自控团队，各团队自配验证人员、自评自管，前提是 system owner 团队足够专业，对人员能力要求更高。集中模式则在国内曾普遍设立专职 QV（质量验证部）统管全公司验证，2023 至 2024 年起大范围优化，将验证执行下沉至各业务板块，QA 只做审核。特别提示：OT（运营技术）类系统不宜强制套用 GAMP 的 IT 分类，工艺类系统宜发展本领域的方法论。

检查层面，官方审计对验证过程中输出的 RA 关注度较低，甚至对 RA 与后续 4Q 是否对应也不甚关注；常见审计场景是企业提供 4Q 文件、检查员指哪一页看哪一页，欧洲、美国、非洲审计情况类似。例外场景是：当某项控制是通过流程控制而非技术控制实现时，检查员可能调阅 RA，核对为何选择流程控制而非技术控制。行业自评的常见缺陷方向有二：风险维度只评产品质量风险，忽略数据完整性与业务连续性风险维度；功能风险评估的失效场景设定主观性强，与功能本身风险关联不足。

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.

流程所有者、系统所有者、质量授权人与 IT 等相关人员之间应密切合作。所有人员应具备与其所承担任务相适应的资质、访问级别和明确的职责。

本条分两个层面。跨职能协作层面，明确列举了四类必须紧密合作的角色：流程所有者（Process Owner，PO）、系统所有者（System Owner，SO）、质量受权人（Qualified Person，QP）与 IT 部门。个人层面，资质、访问级别与明确的职责三者必须匹配，且与所分配的任务相称。中国 GMP 计算机化系统附录第五条与此对应：应当明确所有使用和管理计算机化系统人员的职责和权限，并接受相应的使用和管理培训。

关于 Qualified Persons 的理解，会上指出存在两种解读：可理解为具备资质的人员，也可理解为质量受权人。结合本条与 PO、SO、IT 并列的上下文，宜按角色理解，即质量授权人。

落地层面，应对每一个 GxP 系统建立角色与职责矩阵，至少明确流程所有者与系统所有者。通用划分原则是 PO 归业务、SO 归技术（IT、自控、工程），但各企业定义不同，需以本企业文件为准。组织规模与系统类型带来三类变体：小规模组织中 PO 与 SO 可以为同一人；单部门使用的实验室系统默认部门负责人即为 SO，此时 SO 与 BPO（业务流程所有者）为同一人；跨部门使用的大型设施类系统则分别指定独立的 SO 与 BPO，并设置正式的角色任命流程。落实时点是：在系统引入并启动验证之时，即须将 PO 与 SO 落实到具体人员。

就系统管理员与业务角色的分工，会上呈现两种并行模式。IT 主导模式中，信息化系统的主要管理者为 IT 角色，IT 主导 SOP 起草与流程梳理、业务部门参与；系统操作 SOP、主数据维护、权限、应急等由业务部门的系统管理员负责，IT 只负责技术层面的基础架构与供应商沟通。该模式的风险是业务部门参与度不足，一线操作人员基本不参与文档输出。业务主导模式中，发变更与起草 SOP 由业务部门执行，技术文档与管理规程由 IT 起草。该模式的风险是业务人员对权限、数据审计跟踪、备份恢复理解不深，SOP 里写了却难以落地，遇技术问题仍须拉 IT 与自控共同解决。

实践共识是：制度上把角色与职责逐条写清，实操中保留协作弹性。会上原话意译为："不要把边界画得太清晰、不要把部门墙立得太明确，大家在相互协助的前提下管理计算机化系统会更好一些。"

资质与培训方面，应按岗位设计培训矩阵，用户操作规程培训必须纳入；系统所有者与 IT 应接受系统管理与 GMP 的技术培训，实务反馈是，若 IT 未接受相关培训，会拒绝执行相应操作，这本身构成一道有效的内控措施；验证人员应接受 CSV 方法论培训；QP 应了解电子记录与数据完整性要求；培训须有记录并做效果评价。

针对上万份 SOP 如何确保人人受训，一种培训闭环做法是：新系统上线时，将该系统 SOP 的培训要求加入相应岗位的 job code；以 job code 推送培训任务，相关人员自动收到培训任务；系统放行前，由各部门协调员确认相关人员已完成培训；确认完成后，方可提交账号申请单。

访问权限应按最小权限分配，管理员角色独立于业务角色；角色权限与岗位匹配，操作员只能执行其职责所需的功能，普通用户不得持有管理或配置权限，权限授予须经审批。中国 GMP 附录第十四条亦要求：应当就进入和使用系统制订授权、取消以及授权变更的操作规程。

临时高阶权限的控制方法是：为同一岗位配置两个不同角色；当确需涉及参数修改等高阶权限时，由业务人员提交账号申请，写明做什么事、用哪个角色、开通时间、结束时间、执行内容，IT 按需开通，到期立即关闭。如此既保留了为何持有此权限的理由，也留下了可追溯的申请记录。

权限策略还应差异化：生产设备、检验仪器等业务系统的权限分配必须严格遵循最小特权原则；流程管理类系统（如文档管理系统、质量管理系统）可适当放开权限，否则实际使用中会出现过多掣肘。

跨职能协作机制方面，系统的重大事项（验证、变更、事件）应建立跨组织、多角色的参与评审机制；定期回顾不能由单一验证方或单一质量方独立完成，须保证业务、技术、质量三方在场。

检查层面，常见缺陷之一是系统管理员未接受对应培训，包括 GMP 培训或该系统的 SOP 培训。典型情形是 QC 在用的仪器软件，其全部 SOP 由 QC 自行编写，未定义系统管理员的职责，全公司甚至只有一份针对该软件的液相 SOP，结果导致系统缺少对应的管理 SOP、系统管理员从未接受相应培训两个后果。

其二是职责划分不清导致相互推诿，缺陷表述为"业务部门认为系统是 IT 的、IT 认为系统是业务部门的，实际无人对系统整体负责"；行业观察此类现象在北方企业较常见，南方企业较少。

其三是共享账号、管理员账号与普通账号混用，操作无法追溯到具体个人，违反 ALCOA 的首要原则 Attributable（可归属）。就监管现状而言，FDA 近两年的重点是：QA 是否拥有独立的个人账户；是否实际登录系统执行数据审核动作；数据审核审核了哪些内容。

会上另就 QA 的审核权限作了专题讨论。问题背景是：某些仪器软件中，"查看方法参数"没有独立权限，与"编辑方法"绑定；QA 需要查看参数却因此需要长期持有编辑权限，账号申请困难。就此存在两种视角：按 MHRA 指南，QA 属于利益相关方，且权限应与职责匹配，当系统设计无法拆分权限时，会上倾向的稳妥方案是 QA 首先必须拥有账户，其次审核时可要求相关人员配合，若需高阶权限则另行申请。会上并指出，该问题的真正根因往往是权限设计缺陷 —— 系统未将"查看方法参数"从"编辑方法"中拆出；若软件层面确实无法实现，则须以流程控制弥补。

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.

当使用第三方（如供应商、服务商）提供、安装、配置、集成、验证、维护（如通过远程访问）、修改或保留计算机化系统或相关服务，或进行数据处理时，生产企业与任何第三方之间必须签订正式协议，且协议应明确陈述第三方的责任。IT 部门应视同第三方。

本条的触发条件极宽：只要第三方对计算机化系统有提供、安装、配置、集成、验证、维护、修改、保留任一行为，必须有正式协议。协议的核心内容是责任划分，而不仅是商务条款。末句 IT 部门应视同第三方是容易被忽略的一句：企业内部 IT 部门，尤其是集团 IT，在承担上述活动时，应按第三方管理。中国 GMP 附录第四条与此对应：企业应当与供应商签订正式协议，明确双方责任。

落地时，行业通常以质量协议或 SLA 形式签约，明确以下要件：服务范围与责任边界，即谁负责什么；远程访问的授权范围与记录要求；变更通知义务；数据所有权与保密；响应级别；以及服务终止时的数据安排。适用对象一般是长期提供服务的服务方才会签署这类质量协议或 SLA，例如云服务商、提供验证服务或运维服务的服务商。

关于 IT 部门视同第三方，行业反馈很少如此界定；通常是集团类公司会把集团内的 IT 部门作为长期三方，与之签署 SLA。国外供应商的签约形式亦有差异：部分国外公司不愿独立签署质量协议，更倾向以补充商务合同的形式将 SLA 作为条款列入并签署；形式可变，但内容要件不可缺。就监管关注点而言，服务终止时的数据安排 —— 数据如何转交、双方各自的责任 —— 是监管最关注的一项，务必在协议中明确。

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.

供应商的能力与可靠性是选择产品或服务提供商时的关键因素。是否需要进行审计，应基于风险评估确定。

就供应商分级与相应的审计方式，多企业的实践汇总如下。其一，按软件严重性（业务流程失效的后果）、软件复杂性与新颖性加权为高、中、低：高走现场审计，中走问卷，低走文件或信息评估，资源投入由高到低。

其二，按 GAMP 5 分类（一、三、四、五类，兼顾复杂性与新颖性），实行四档管理：一类无需供应商审计；三类做基础信息评估；四类做书面审计；五类做现场审计，含考察供应商的软件开发能力。

其三，按 GAMP 5 分类的简化版：四类及以上做现场审计。该做法未综合系统本身的重要性与关键程度，企业自评应加以改进。

其四，按供应商能力导向：成熟产品（全球化公司、业内广泛使用）风险低，走问卷审计，核查其既有客户与历史验证案例；新引入供应商，尤其国内新型供应商，核查其内部软件开发控制与质量体系。某企业为引入一套新系统，专程赴供应商所在地做现场审计。

其五，专项结论：云服务必须走现场审计；国外供应商无法现场时走远程审计。

其六，一类基础架构无需供应商审计，随公司采购流程由合格供应商管理覆盖。

审计实施方面，审计时机规范上应在概念阶段即启动，但实际项目中很难在关键阶段开展；多数企业是在供应商确定、合同签署之后再开展供应商评估或审计。审计小组构成通常为 QA 主导、IT 与业务部门三方，另会邀请 IT 参与三类、四类、五类系统的评级审计，甚至共同参与现场审计。审计成果方面，应收集并保存供应商的质量体系证书，指定人员追踪证书有效期并主动索取更新文件，审计结束输出审计报告。

某企业将审计评估的输出固定为一份独立文件 ——《供应商审计风险评估》，归入验证文件体系；其流程顺序为：变更先行，变更中提出"供应商审计"行动项，填写供应商审计评估表，确定审计方式，在 URS 之前完成审计。五类系统必须先审计、后开展后续工作。

3.3

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

商业现成（COTS）产品随附的文件资料应由受监管用户审核，以确认用户需求已得到满足。

本条的审核对象是通用商业化计算机软件（COTS，中国 GMP 附录第八条表述为"通用的商业化计算机软件"）随附的用户手册、版本发布说明等文件。落地位置可以放在 DQ 中，也可以放在 IQ 确认中，但该审核环节不可省略，企业普遍会明确确认这一环节。中国 GMP 附录第八条并要求企业应当指定专人进行此项审核。适用性判断方面，商业化系统（如大型厂商的成熟软件）通常能提供白皮书、产品说明等资料，供企业逐项核对用户需求。

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.

与软件及已实施系统的供应商或开发方相关的质量体系和审计信息，应在检查员要求时予以提供。

落地做法是在协议中预先约定：供应商的质量体系与审计信息可提供给药监机构检查。若企业实际开展了供应商审计，应要求审核供应商的质量体系，并将相关资料收集齐全。中国 GMP 附录第四条亦有对应要求：企业应当基于风险评估的结果提供与供应商质量体系和审计信息相关的文件。

专题一

本节条文之外，会上另就远程访问的受控方式展开了集中讨论。行业做法可按控制强度排列。控制最强的是：本地部署系统不允许供应商远程接入，改为将数据库导出打包、审批、将输出提供给供应商、供应商在外部分析、供应商给出方案，最后由企业内部人员在自己系统上操作 —— 即以"数据出、操作留"替代远程接入。

强度中等的做法是：允许远程接入，但走申请、审批、记录流程，尽量安排在受控窗口；开通期间由本地 IT 盯屏，防止执行非预期动作，必要时开录屏。

强度中等的事后确认型做法是：因应急维护紧急，先发邮件并抄送领导，活动完成后于当日或第二个工作日补填远程访问流程表确认，由 IT 在堡垒机中查看供应商操作录屏，在记录上体现已检查、无违规额外操作。

强度较弱的做法是：仅要求通过账号申请单填写 VPN 申请，无录屏等管控。采用该做法的企业自评这块管理比同行薄弱，理由是控不住程序员，且人员技术有限、录屏也看不懂。

实务难点在于：系统出现 bug 时，尤其对生产类企业，第一时间让供应商远程几乎是必然，很难做到规范的申请审批记录；自控类系统通常不由 IT 管理，而由自控团队管理，其处理措施一般不如 IT 团队规范，可能直接让供应商远程。就检查现状而言，该点在过往审计中从未被挑战过，也没有审计官关注这一环节。

专题二

多因素认证（MFA）：附录 11 征求意见稿及国内疫苗相关指南均提及多因素认证，故与会者就此展开讨论。行业做法可归纳为五点。

软件层面的 MFA 取决于软件本身是否设计支持，商业化标准系统若自身不带该功能，企业层面很难实现；已有企业采购到自带 MFA 的系统，采用账号加密码再加手机动态验证码的方式。

可行的实现路径主要是外部加载，即通过 VPN、硬件服务器等外部组件实现：较易实现的是账户密码加短信验证码，生物特征亦属较好实现的类别，其余方式实现难度较大。

VPN 方案的局限在于，VPN 保护的是公司内网的接入，其自身认证无法与单个业务软件直接关联。

主流理解是，本条要求能够实现从外部网络对公司内网的访问控制即可，其出发点更多是网络安全，即外部接入受控系统的可控性，而非要求每个业务软件都具备 MFA。

合规兜底路径是：若确实无法实现，可起草一份风险评估，论证在无 MFA 的情况下，通过哪些流程控制保证网络安全。

就本节整体的检查现状，会上主讲人明确表示：很少看到监管机构对计算机化系统的供应商有明确、需检查的固化流程。第 3.4 条要求"在检查员要求时提供供应商审计信息"，但据与会者过往经历与所查阅的 483 来看，检查员从未索取过该信息；审计中很少关注实施方的供应商资质；远程访问未做规范审批记录，未被挑战过；供应商评估与审计报告本身，在监管检查中几乎未被查到过。

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.

验证文档和报告应覆盖生命周期的相关步骤。生产企业应能够依据其风险评估，论证其所采用的标准、方案、可接受标准、规程和记录的合理性。

本条第一句要求验证文档的覆盖完整性，即不是只留一台设备的 IQ 与 OQ，而是覆盖系统生命周期各相关步骤；第二句是可论证性要求，与第 1 节风险管理直接呼应：标准、方案、接受标准、规程、记录都必须有风险评估作为依据。检查时可以据此追问为什么接受标准是这样定的。

生命周期的标准推进顺序为：验证计划（VP）、用户需求说明（URS）、功能规格与配置规格与设计规格（FS / CS / DS）、4Q、验证总结报告（VSR）。各企业顺序存在差异，均属常见：有企业 URS 先于 VP；有企业 URS、VP、SI 一并产出；FS、CS、DS 的先后关系各企业也不完全一致。

验证计划应说明的内容包括：验证策略的确定依据，引用 SI 结论或 GAMP 分类；验证活动与范围；角色与职责；接受标准。接受标准必须是可测试的，且明确具体参数与判定规则，模糊表述不可接受。

系统准入流程各企业不同，但变更通常先行：变更、URS（一切的起点）、计算机化系统初评、供应商评估与审计、VP 及后续。

生命周期文档的管理，基础做法是所有验证文件从初始到退役集中归档；再确认与再验证文件附验证历史章节，IQ 或 OQ 升版时关联首次验证的时间与文件，后续文件可溯源至前版，存放亦统一。进阶做法是建立验证相关文件清单或索引，记录该系统的历次版本变更、对应日期、变更编号，定期更新，在回顾周期拿出来用于验证状态回顾；系统验证相关文件亦有独立的文件生命周期管理清单。该做法严谨、值得借鉴，但工作量极大 —— 复杂系统的变更频率高时，清单的整理与编辑工作量非常可观，企业需评估人力可承受性。

4.2

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

验证文档应包含变更控制记录（如适用），以及验证过程中观察到的任何偏差的报告。

本条落地时，偏差与变更在哪个时点切换到企业体系流程，行业做法如下。会上倾向的做法是：OQ 之后的偏差与变更按企业质量体系流程执行，OQ 之前采用验证文件内自定义的简化方法论。

中间做法是：OQ 之前用项目偏差与项目变更；PQ 走自身的确认与验证流程；进入生产环境平行运行后走质量偏差。

另一种做法是验证全过程（含 OQ、PQ）均采用验证内自定义的简化流程，系统正式上线后才接入体系。

验证期间采用的简化项目偏差流程，其做法是在一份表单中定义以下栏位，不套用企业完整的偏差报告流程：当前发生的偏差描述；风险评估；简要的根本原因分析；CAPA 及 CAPA 完成方式；评价与关闭；随后并入验证文件相关资料，统一归档。

供应商参与情形下，确认期间出现偏差，要求供应商提供一份不那么正式的调查报告（若判定为系统本身问题）；生产环境平行运行阶段出现偏差，则由己方开质量偏差，并要求供应商提供其内部完整的偏差调查报告。

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.

应保有一份所有相关系统及其 GMP 功能的最新清单（台账）。对于关键系统，应保有一份最新的系统描述，详细说明其物理与逻辑布局、数据流以及与其他系统或过程的接口、任何硬件和软件的前置条件，以及安全措施。

中国 GMP 附录第七条与此对应：企业应当建立包含药品生产质量管理过程中涉及的所有计算机化系统清单，标明与药品生产质量管理相关的功能，清单应当及时更新；第十一条并要求关键系统应当有详细阐述的文件（必要时含图纸），并须及时更新。

就系统清单的字段，多企业实践的采纳情况如下。必备字段包括：系统名称与唯一标识（ID），须定义清楚；软件分类，即 GAMP 分类；系统影响性或 GxP 相关性结论；上线状态。

常见字段包括：版本号；系统概要描述与适用范围；供应商信息；部署环境（操作系统）；所属业务流程，建议同时标注业务流程所有者；流程所有者（PO）与系统所有者（SO），建议写入，以与第 2 节衔接。

采纳不一的字段包括：数据完整性关键性、数据关联性、数据风险程度，有企业按 APIC 的数据分类（关键数据、数据关联性、一至六类）标注；上线日期，多数企业有独立的上线登记表或上线放行表体现具体日期，清单中从简；退役日期，采纳较少，有企业退役后直接从清单中删除；数据的管理要求（备份周期、用户权限检查周期），有企业采纳，由数据完整性关键性评估输出日常管理要求后在清单中简述。

部分企业另采纳验证有效期或周期性回顾日期字段，用途是触发或提醒当年度周期性回顾。

清单的维护与签批应做到三点。动态更新：由 IT 或工程部在收到上线注册表或通知单后更新电子版清单。定期签批：每季度或每年线下签批一次，核对通知单与注册表信息与清单的一致性。与定期回顾联动：清单每年复核，系统新增或退役时同步增删改。

上线注册表本身亦有用途：某企业设置正式的上线注册表，批准后才正式上线。其初衷是验证完成后部分系统或设备可能并不启用，一旦启用即涉及后续数据备份等 IT 工作量，故以上线注册表作为正式启用节点。

针对关键系统的系统描述应放在哪里，行业做法有四种承载位置。其一是放进 CS 或 FS、CS 文件：业务流程图、数据流示意图在 FS 与 CS 中必定包含，并作为系统使用过程中的文件清单加以管理；初始上线是什么设计逻辑、若涉及接口接入或与其他系统对接导致逻辑变动，则作为升版文件在变更中按生命周期文件管理。其二，以配置清单形式输出，含系统描述、拓扑图、装配图，每年复核，与周期性回顾联动。其三，对四类、五类系统，在 PQ 之前编写配置项清单，含系统描述、架构图、数据流、软件配置信息。其四，单独维护一张系统接口汇总表，列出所有系统间接口、每个接口交互的字段与信息。

另有企业提出：计算机化系统清单与验证跟踪（验证主计划）本是两件事，不必强行融合；但若企业没有验证主计划，则在清单中加验证有效期字段用以触发回顾动作，亦可行。

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 宜按三类需求组织：功能需求、法规与数据完整性需求、非功能需求；每条需求赋予编号，具备可追溯性。

关于 SI 与 URS 的先后关系，按 GAMP 5 第 2 版的要求，系统影响性评估（SI）应在 URS 起草之前完成，或与 URS 同步进行，且 SI 应已生效。会上明确阐明的理由是：用户往往并不清楚自己的原始需求，尤其涉及计算机化系统功能与数据完整性功能时，只有在 SI 完成之后，才能明确自身的用户需求是什么。

需求追溯矩阵（RTM）不是强制要求，但属强烈建议。每条需求应能映射到设计、配置与测试项；测试完成后反向核查，确认每条需求均有对应的验证，或有相应的评估说明；URS 变更应走变更控制，RTM 须同步更新。

URS 的起草责任通常按系统类型划分：大型系统或 QC 类系统，通常由实施方或厂商在前期介入时到现场做业务调研，基于调研输出初版 URS，再由公司内部各角色与 QA 参与审批，含系统功能查询与审批。已定稿的 URS 应逐条建立矩阵：每条 URS 对应的风险、对应的测试方案与测试项，以及如何挑战测试或规避测试。

URS 变更可采用简化处理：测试执行过程中发现遗漏，可对 URS 升版，不强制走企业变更流程；但升版必须有触发理由，如某个测试项失败、或测试流程未覆盖到，并写明升版理由与更新点；随后基于新增 URS 做重新评估，输出新的测试方案。

关于遗留系统（无 URS）的处理，会场曾提出提问：企业做遗留系统补充验证，没有任何用户需求文件，领导认为无需补充，这种情形会被审计落缺陷吗？会上答复是：遗留系统的 URS 必须补充，依据为 ECA 的 GMP 问答（第三版）中明确"遗留系统的 URS 是必需的"。

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 节供应商与服务商相互对应：第 3 节规定要做，本条强调要有效。义务主体是受监管用户，即企业，而非供应商：企业需采取一切合理措施确保供应商有适当的质量管理体系。

供应商的最低认证要求方面，主流要求是 ISO 9001，至少需提供质量体系证书；若供应商无质量体系证书，须由企业出具一份评估文件，论证其确有一定程度的质量管理能力；同时应能提供 CSV 验证的脱敏资料及其他相关证据。

定制与自研系统的评估亦不可省略。集团内自研或自开发系统的开发团队往往不在本工厂内，可能跨团队、跨组织，亦须评估其质量管理体系。定制开发，含接口开发，如为某系统开发接口引至 ERP，应归类为定制开发进行管控；企业通常介入并要求由第三方实施方完成开发。中国 GMP 附录第八条亦要求：在对定制的计算机化系统进行验证时，企业应当建立相应的操作规程，确保在生命周期内评估系统的质量和性能。

定制系统的供应商审计重点，除取得证书外，还须审查供应商的整个 SDLC（软件开发生命周期），包括软件开发与测试的完整流程、研发过程中的节点控制、相关文档记录；现场要求供应商展示相应记录，以核查其开发能力与质量控制水平；最终输出审计报告。

接口类开发可采用简化路径：将接口直接定义为五类系统，而五类系统须做现场审计，现场审计清单已覆盖供应商质量管理的各项要素，故无需另行补充评估。

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.

对于定制或客户化的计算机化系统，其验证应建立相应流程，确保对系统所有生命周期阶段的质量与性能指标进行正式评估并形成报告。

本条的适用对象是定制或客户化系统，即非开箱即用、需按企业需求开发或改造的系统。国内涉及的定制场景主要有三类：整包定制开发、基于成熟产品的客户化配置，以及接口开发。三类均在本条适用范围内。

全生命周期评估流程方面，行业做法是建立一套覆盖需求、设计、编码、测试、发布放行各阶段的验证流程，并在各阶段形成记录，最终产出正式的评估报告。报告的落点是把程序开发的质量与性能指标在各阶段的表现固定下来，而非只在验证结束时给一份总结。流程本身须以规程形式单独立文；对于自开发系统，即企业内部自研系统，应制定专门的开发管理规程，而不可直接套用商业软件的采购与验证模板。

版本控制方面，行业做法是把源代码以及由源码构建的产物纳入受控管理，即使用受控的代码库，构建产生的可执行版本亦须受控，确保现场运行的版本与经过测试、经批准的版本可一一对应。

US-FS 映射方面，开发过程须明确用户需求（US 或 URS）与功能规格（FS）的对应关系，逐条建立映射，这与 4.4 条需求追溯矩阵的要求相衔接。对定制系统而言尤为必要：商业软件的功能由厂商定义，而定制系统的功能由开发过程产生，若无 US-FS 映射，需求是否被实现无从核查。

缺陷处理方面，应建立明确的 Bug 或异常处理流程并保留记录，包括缺陷的登记、分级、修复、回归测试与关闭；缺陷记录同时是开发过程受控的证据。

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.

应能提供采用了适当测试方法与测试场景的证据。尤其应考虑系统（工艺）参数限值、数据限值以及错误处理。自动化测试工具与测试环境应对其适用性有形成文件的评估。

本条含三层要求。其一是证据要求：测试不能只有结论，还须留下用了什么方法、覆盖了哪些场景的可展示材料。其二是测试内容的三项特别关注点：系统（工艺）参数限值、数据限值、错误处理。其三是测试环境与自动化测试工具须有书面适用性评估：测试环境应尽可能与生产环境配置等效；若采用自动化测试工具，须在使用前评估该工具本身的可信性，包括工具自身的验证状态、脚本与结果的可靠性。

测试环境与生产环境的差异管理，是本条落地时最实际的问题。对于 MES 等深度结合业务的系统，验证环境往往无法完全等同生产环境，设备连接、数据量、并发规模均不同。行业做法不是强行要求环境一致，而是交付一份差距分析文档，逐项说明验证环境与生产环境的差异、该差异对测试结论的影响，以及为弥补差异采取的补充措施，如在生产环境做有限度的确认、或以模拟数据补充覆盖。

数据审计跟踪的确认时点，会上呈现一种可显著降低重复工作的做法：把数据审计跟踪的确认后置，不必在每一轮的 OQ 中重复执行，改为对照权限清单汇总所有操作记录，一次性覆盖各角色、各功能的数据审计跟踪生成情况。这样做的前提是权限清单本身完整准确，该清单也是 4.3 条系统清单与第 2 节权限管理所要求的成果物，可复用。

SaaS 系统的追溯风险需单独提示：部分 SaaS 系统无法提供完整的验证索引矩阵（VIM），导致审计时难以远程展示、或无法追溯某一特定功能的验证过程。对应的实践取向是：在供应商选择阶段即将能否提供完整 VIM 作为准入条件之一，与第 3 节的供应商评估衔接。

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.

如果数据被转移至另一种数据格式或另一个系统，验证应包含检查，确认数据在该迁移过程中未在数值和/或含义上发生改变。

中国 GMP 附录第九条与此完全对应：数据转换格式或迁移时，应当确认数据的数值及含义没有改变。

迁移验证的检查对象是数值与含义两项是否改变，且是"和/或"，两者都须覆盖。国内实践中易被忽略的是含义：数值未被改动但含义发生变化的情形，如日期格式由"日/月"变为"月/日"、单位由 g 变为 mg、状态代码的枚举含义不同、精度被截断，在系统转换中相当常见，而单纯的数值比对无法发现。

迁移方案应包含的要件，行业做法是固定五项：迁移范围，即哪些数据、哪个时间区间、是否含历史归档数据；目标格式，即目标系统的数据结构与字段定义；映射规则，即源字段与目标字段的逐项对应关系，含类型转换与精度处理；清洗规则，即空值、重复值、非法值的处理方式；比对策略，即抽样还是全量。

比对策略的选择按数据量级与系统复杂度决定。针对复杂系统的迁移，行业常用的抽样规则有两类：一是前、中、后随机抽样，在迁移数据的时间序列前端、中段、末端各随机抽取样本比对；二是设定阈值规则，例如按数值大小、金额区间、状态类型设定阈值，对超过阈值的数据做全量比对，其余抽样。两种规则的共同目的是以可承受的工作量证明数值与含义未被改变；无论采用哪种，都应在方案中写明抽样依据，以便审计时论证其充分性。

有一处概念须予区分：新系统上线时的历史数据初始化，不完全等同于本条所指的数据迁移。初始化的关注点侧重业务连续性，即新系统上线后业务不中断所需的基础数据，以及初始数据的准确性，如期初库存、期初余额、在制品状态的正确性；而本条所约束的迁移，其核心命题是数据在跨格式、跨系统的转移过程中数值与含义是否发生变化。两者在验证深度、比对策略与文档承载上并不相同。将这一区分明确写入方案，是避免审计时被追问"为什么初始化没做全量比对"的有效做法。

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.

与其他系统进行电子数据交换的计算机化系统，应内置适当的检查机制，以确保数据的正确、安全录入与处理，从而将风险降至最低。

本条针对的是系统间电子数据交换，即接口，要求是内置检查，即校验应由系统在数据交换时自动完成，而非依赖人工事后核对。

接口验证的现状是本节国内最值得注意的一点：业内对接口验证的颗粒度普遍较浅，多数做法仅验证首尾一致性，即源系统写入一条、目标系统能读到一条，比对两端记录数量或关键字段是否一致。这与本条要求的正确且安全的录入与处理之间存在明显缺口。浅颗粒度的接口验证在上线后容易暴露三类偏差：重复写入，即网络重试或并发导致同一笔数据被写入多次；静默失败，即接口报错未上抛、数据实际未落库，但两端表面上都无异常提示；以及字段截断或类型转换错误。这三类问题的共同特征是在首尾一致性验证中不会被发现。

针对这一缺口，风险管控的前移点应在设计阶段：接口问题的根因多产生于系统设计与实现阶段，而非测试阶段抓出来的。因此在供应商设计评审时应重点确认三项能力：重发机制，即交换失败时是否重发、重发如何避免重复写入，如以业务主键或幂等标识去重；断网恢复，即网络中断期间数据的暂存与恢复后补传机制，以及补传的完整性保证；并发处理，即多客户端或多进程同时写入时的锁机制与冲突处理。这三项能力在供应商设计文档中往往不显眼，但在已上线系统中几乎无法补救。

成熟接口的稳定性方面，行业反馈较为一致：使用成熟软件且 IT 支持完善的系统，接口对接验证通过后，在实际使用中较少出现问题。这类产品的接口机制经多年迭代，上述三类风险已被产品本身消化。反之，定制开发或新引入产品的接口，即便验证通过，上线后仍需一段时间的观察。因此接口的风险分级宜与其成熟度挂钩，而非一律套用同一验证深度。

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.

对于手工录入的关键数据，应对数据的准确性进行额外核查。该核查可由另外的操作人员完成，或通过经验证的电子方式完成。错误录入或不正确录入数据的关键性及其对系统的潜在后果，应纳入风险管理。

中国 GMP 附录第十五条与此对应：当人工输入关键数据时，应当复核输入记录以确保其准确性；这个复核可以由另外的操作人员完成，或采用经验证的电子方式。

本条的三个要素是：对象，即手工录入的关键数据；方式，即由另外的操作人员复核，或采用经验证的电子方式；依据，即关键性与后果须由风险管理覆盖。

关键数据的识别是本条落地的起点。国内主流做法是把关键人工输入点界定为影响批放行或处置决定的工艺参数（CPP），即这两类数据录错会直接影响批次的放行判定，故必须做二次核查。识别结果的依据来自风险评估，与第 1 节衔接，而非凭经验罗列。

复核方式的选择上有一项重要的实践结论：经验证的电子方式仅能校验参数的有效性，无法确认数据的绝对准确性。例如系统可以校验输入是否在合法范围内、格式是否符合要求，但不能判断这个数值是否是实际操作时真实测得的。若操作者把 3.5 误输为 5.3，而两者均在合法范围内，电子校验无法发现。因此仍需要另外的操作人员人工复核以确保正确。这一结论对企业的实际含义是：不要以系统已设校验规则为由取消人工复核，尤其在支持批放行的关键数据上。

电子化复核的实践方面，主流做法是在支持批放行的系统 URS 中明确要求：系统的打印件或报表须具备修改标识，即能显示该数据自原始录入后是否被改动过，以及可追溯的审核留痕功能，即谁在何时审核、结论为何。这一要求与第 8.2 条直接对应，换言之，第 6 节的复核要求要真正电子化落地，须在第 8.2 条所要求的打印输出能力上先做 URS 约束，两节应合并考虑。

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.

数据应通过物理和电子两种方式加以保护，以防损坏。应对存储的数据检查其可访问性、可读性和准确性。在整个保存期内应确保数据的可访问性。

本条要求物理加电子双重防护，并规定三项须定期检查的属性：可访问性、可读性、准确性。这三项不是一次性的，而隐含周期性检查的义务，与第 11 节定期评估衔接。中国 GMP 附录第十九条亦要求：必须采用物理或者电子方法保证数据的安全，以防止故意或意外的损害；日常运行维护和系统发生变更时，应当检查所存储数据的可访问性及数据完整性。

末句"整个保存期内应确保可访问"是国内实践中较易落空的一项：数据本身保存住了，但读取数据所需的旧版软件、旧版操作系统或旧版授权已不可得，实质等同于数据不可访问。应对方式是在系统退役或供应商终止支持前，评估并锁定读取手段，包括保留可运行的旧环境、导出为中性格式、或取得长期读取授权。

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.

应对所有相关数据进行定期备份。备份数据的完整性与准确性、以及数据还原能力，应在验证期间检查并定期监控。

中国 GMP 附录第十九条要求建立数据备份与恢复的操作规程，定期对数据备份，且备份数据应当储存在另一个单独的、安全的地点。

备份策略与频率方面，国内主流做法是按关键性分级：明确备份范围、备份类型（全量或增量）与频率；关键系统建议每日备份，非关键系统可按季度备份；备份介质须异地、离线各存放一份。离线介质的意义在于隔离勒索软件等逻辑破坏，异地存放则应对场地级灾难，两者不可相互替代。仅做在线副本或同机房备份，虽满足定期备份的字面要求，但在本条防止损坏的意图下是不充分的。

还原测试的规范是本节最易出问题之处。行业做法要求还原测试在异机或虚拟环境中进行。其反面案例是：直接在生产环境或验证环境中清空数据库、再导入备份以验证还原 —— 该做法本身构成严重的操作风险，一旦还原失败即造成数据实质丢失，且测试过程本身会破坏原始数据，无法证明还原后数据与备份一致。此种做法应予避免。还原测试应记录测试时间、备份来源、目标环境、还原结果与数据一致性核对结论，并按本条定期监控的要求形成周期。

循环存储机制的应对是一项国内特有的实践议题：部分小仪器（如部分小型分析仪器、老旧设备）采用循环擦除即循环存储的数据存储方式，新数据写入时覆盖最旧的数据，导致数据保存期无法满足要求。应对办法有两条并行：一是缩短人工复核确认的频次，即在数据被覆盖前完成复核与确认，使其进入受控记录；二是及时备份归档，即在覆盖发生前把数据导出到受控存储。两条并用，本质上是以流程的密度弥补设备能力的不足。此类设备在采购时应将是否支持完整数据留存作为选型条件，从源头避免问题。

备份与归档的区分同样需要明确，两者不可混同管理。备份用于容灾，目标是系统或数据损坏后能快速恢复运行，可覆盖、可滚动、保存周期短；归档用于长期保存，目标是满足保存期要求，不可覆盖、保存周期长。由此在管理要求上也应分开：介质寿命管理方面，归档介质须定期检查寿命并迁移，备份介质则按批次轮换；复写频率方面，备份介质可重复使用，归档介质不得复写。大型系统的实践是把二者分列于不同的 SOP，各设责任人与周期。

8.1

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

应能够获得电子存储数据的清晰打印副本。

中国 GMP 附录第十九条亦有对应要求：以电子数据为主数据时，为满足质量审计的目的，存储的电子数据应当能够打印成清晰易懂的文件。

打印功能应纳入验证范围，这是本节落地的首要一点：打印不被视为附带的办公功能，而是本条明确要求的系统能力，故须在 URS 与测试中覆盖。验证内容至少包括：打印格式清晰完整，即列宽、字体、分页、关键字段不截断；打印内容与电子记录一致，即无遗漏、无格式转换导致的信息丢失。打印模板的升版须受控管理，因为模板变更会改变输出内容，如增删字段、改变列顺序，须走变更控制并重新确认，否则会出现同一记录在不同时间打印出不同内容的情形。

导出与打印的风险是一项具体的检查发现：部分工控机通过调用 Windows 打印功能实现数据导出，该路径可能导致用户访问到未受保护的桌面文件夹，用户可在该文件夹中直接对导出文件进行修改、替换，构成数据完整性缺陷。这类问题的根因是系统设计时把导出实现为操作系统级的文件操作，绕过了应用层的权限与审计控制。应对方向有二：一是由系统提供受控的导出通道，导出动作留数据审计跟踪、输出至受控目录；二是若无此能力，则在 URS 中提出改造要求，并以流程控制作为过渡，即导出文件须与电子记录核对后方可使用。

展示副本的多样性方面，不必强求全部纸质打印：对于复杂数据结构或非关系型数据库承载的电子数据，纸质打印往往既不可读也不完整，此时可通过屏幕可读的方式，即在受控环境下查看并留证，以及数据审计跟踪截图作为展示副本并完成验证。这一做法承认了本条"清晰的打印副本"在不同数据结构下的可实现程度差异，其替代手段须同样满足清晰、完整、与电子记录一致的实质要求。

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.

对于支持批放行的记录，应能够生成打印件，标明自原始录入以来是否有任何数据被更改。

中国 GMP 附录第十八条、第二十二条与此相关：电子数据与纸质打印文稿同时存在时，应当有文件明确规定主数据；采用计算机化系统放行产品时，系统应当能明示和记录放行产品人员的身份。

本条是对支持批放行的记录的专门要求：不仅能打印，还须在打印件上标明数据自原始录入后是否被更改过。该项与第 6 节"支持批放行的系统应在 URS 中明确要求打印件或报表具备修改标识及可追溯的审核留痕"是同一要求的两个侧面：第 6 节从复核角度提出，本条从输出角度提出，实践中应在同一份 URS 中一次性写清，避免两处各写一半。

技术实现上，该能力依赖系统能够保留原始录入值并提供修改标识，如以标记、脚注或对照栏显示原值与现值，本质上是第 9 节数据审计跟踪在打印输出上的呈现。因此若系统的数据审计跟踪能力不足，本条的要求也无法单独满足 —— 第 6、8.2、9 三节构成一条链，宜合并评估。

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 相关数据的更改或删除，应记录其原因。数据审计跟踪应可获取，并能够转换为通常可理解的形式，且应定期审核。

中国 GMP 附录第十六条与此对应：计算机化系统应当记录输入或确认关键数据人员的身份；只有经授权人员，方可修改已输入的数据；每次修改已输入的关键数据均应当经过批准，并应当记录更改数据的理由；应当根据风险评估的结果，考虑在计算机化系统中建立数据审计跟踪系统。其术语章（第二十四条）给出正式定义：数据审计跟踪是一系列有关计算机操作系统、应用程序及用户操作等事件的记录，用以帮助从原始数据追踪到有关的记录、报告或事件，或反向追溯。

本条要素较多，可拆为五项：基于风险评估决定数据审计跟踪的覆盖范围；覆盖所有 GMP 相关的更改与删除；更改或删除须记录原因；数据审计跟踪可获取并可转换为通常可理解的形式；定期审核。

数据审计跟踪的需求提出应在 URS 中完成，行业做法是在 URS 中明确三件事：覆盖范围，即哪些操作（录入、修改、删除、审批、导出）、哪些数据字段须留痕；防篡改机制，即数据审计跟踪记录本身不可被编辑或删除，其技术实现与验证方式；可读格式，即须能以人可理解的形式导出，而非以二进制或加密形式存放。日常审核方面，行业做法是建立审核计划，明确审核周期、审核人、审核范围，并对记录中的修改原因做合理性抽查，而非仅确认审核动作已执行。

新旧值记录缺失的应对是国内实践中一个具体且常见的问题：部分老旧分析软件不支持记录新旧值，即数据审计跟踪只显示某字段被修改，但不显示改前与改后的值。对此类系统的应对是以流程补充：要求在配套的日志本中详细写明修改缘由，并保留原始记录，如原始打印件或原始数据文件，使修改前后的事实可通过人工记录对照还原。这一做法是设备能力不足时的补偿措施，其前提是流程本身受控，即日志本纳入受控记录管理、定期审核其完整性。

修改原因填写的管理是本条在 FDA 检查中的焦点：强制用户填写修改原因是 FDA 的关注重点，检查中会实际查看系统是否强制填写、以及用户填了什么。国内实践中普遍存在的问题是：系统提供了过于简单的选项，如"录入错误"下拉项，用户全选同一项，导致原因字段事实上失去信息量。行业采取的规范做法有两条：一是移除过于简单的选项，或将其细化到可区分的程度；二是定期抓出通用理由，即统计高频出现的修改原因，对使用方进行宣讲，促使其填写真实原因。本条与数据完整性 ALCOA 原则中的同步与原始要求相关：修改原因的填写时点应紧随修改动作，而非事后补填。

基础架构

为应用程序提供平台使其实现功能的一系列硬件和基础软件，如网络软件和操作系统（中国 GMP 计算机化系统附录术语章定义）。文中 IT 基础架构即指此。

数据审计跟踪

一系列有关计算机操作系统、应用程序及用户操作等事件的记录，用以帮助从原始数据追踪到有关的记录、报告或事件，或反向追溯（中国 GMP 计算机化系统附录术语章定义）。

电子数据

也称数据电文，指以电子、光学、磁或者类似手段生成、发送、接收或者储存的信息（中国 GMP 计算机化系统附录术语章定义）。

电子签名

电子数据中以电子形式所含、所附用于识别签名人身份并表明签名人认可其中内容的数据（中国 GMP 计算机化系统附录术语章定义）。

数据完整性

指数据的准确性和可靠性，用于描述存储的所有数据值均处于客观真实的状态（中国 GMP 计算机化系统附录术语章定义）。

计算机化系统生命周期

计算机化系统从提出用户需求到终止使用的过程，包括设计、设定标准、编程、测试、安装、运行、维护等阶段（中国 GMP 计算机化系统附录术语章定义）。

应用程序

安装在既定的平台/硬件上，提供特定功能的软件（中国 GMP 计算机化系统附录术语章定义）。

SIA（System Impact Assessment）

系统影响性评估：判定系统对产品质量与患者安全的影响等级，分为直接、间接、无影响，直接影响者纳入 GxP 管理范围。

SI / CSI

验证侧的 SI（System Impact）与 CSV 侧的 SI，后者以数据为导向，参照 GAMP 5 与 PIC/S 相关指南。

GAMP 5 分类

一类为基础架构软件，三类为标准与现成软件，四类为可配置软件，五类为定制软件。

URS（User Requirements Specification）

用户需求说明。

US / FS

User Specification（用户规格）与 Functional Specification（功能规格）；US 与 URS 在部分企业通用，开发过程中须建立二者的逐条对应关系。

RTM（Requirements Traceability Matrix）

需求追溯矩阵。

FRA / FI

功能风险评估（Functional Risk Assessment / Functional Impact）。

ERES

电子记录与电子签名（Electronic Records and Electronic Signatures）。

ALCOA / ALCOA+

数据完整性原则，即 Attributable 可归属、Legible 清晰、Contemporaneous 同步、Original 原始、Accurate 准确，另加 Complete、Consistent、Enduring、Available。

PO / SO / BPO

Process Owner（流程所有者）、System Owner（系统所有者）、Business Process Owner（业务流程所有者）。

QP

Qualified Person（质量授权人）。

COTS

Commercial Off-The-Shelf，即中国 GMP 附录第八条所称"通用的商业化计算机软件"。

SLA

Service Level Agreement（服务级别协议）。

QV

Quality Validation（质量验证部，国内企业常见职能设置）。

OT

Operational Technology（运营技术，如自控与工控系统，与 IT 相对）。

SDLC

Software Development Life Cycle（软件开发生命周期）。

MFA

Multi-Factor Authentication（多因素认证）。

VIM

Validation Index Matrix（验证索引矩阵），将验证活动与其证据文件建立索引的材料。

CPP / NKP

Critical Process Parameter（关键工艺参数）与关键物料属性；国内实践中被界定为关键人工录入数据的主要对象。

CAPA

Corrective and Preventive Action（纠正与预防措施）。

4Q

DQ 设计确认、IQ 安装确认、OQ 运行确认、PQ 性能确认。

VP / VSR

Validation Plan（验证计划）与 Validation Summary Report（验证总结报告）。

循环存储

部分小仪器的数据存储机制，新数据写入时覆盖最旧数据，导致保存期不足，须以流程补偿。

还原测试

Restore Test，验证备份数据可用性的测试，应在异机或虚拟环境中进行。

PIC/S 计算机化系统与数据完整性指南

会上引用了 PIC/S 的相关指南，表述为 PI 011 与 PI 041 两种编号。具体出处以 PIC/S 原文为准，建议引用前核对。

ECA

ECA Academy（欧洲合规学院），其 GMP 问答系列被会上引用为遗留系统 URS 要求的依据。

USP <1058>

美国药典分析仪器确认章节，采用 A、B、C 分类，近年细化为 A1–A2、B1–B3、C1–C3。

MHRA

英国药品与健康产品管理局。