GLP机构IT基础架构的合规与控制

发布时间：2026-01-14 浏览次数：90次

首先，我们来回答GLP机构IT基础架构是否需要被验证/确认的问题。

从监管机构的纸面要求来说：

GLP机构的IT基础架构需要做验证或确认。OECD在2016年的文件中即要求IT基础架构需要被确认。

从前期的监管力度来说：

GLP机构的IT基础架构“不一定需要”做验证/确认。毕竟，以前一些GLP机构的IT基础架构未做验证/确认的，也通过了NMPA的GLP认证以及OECD的检查。

从监管机构的新动向看：

2025年下半年，我们从多家GLP机构得到的消息，IT基础架构确认已经是后续OECD检查的必需要求。NMPA在2025年12月发布的生物等效性试验电子化记录技术指南（试行）中，也直接要求了IT基础架构需要被确认。可以预见，无论国外还是国内的监管机构，在后续的GLP检查或认证中，都将对IT基础架构的验证/确认要求更严。

GLP机构的IT基础架构的验证/确认已经是无可逃避的工作了。

一、监管机构的纸面要求：

国内外众多法规或指南均要求IT基础架构需要被验证（Validated）或确认（Qualified），有的是直接要求IT基础架构需要被确认，有的是在计算机化系统验证的范围中覆盖到了IT基础架构。

相对GMP领域，GLP/GCP领域的官方文件对IT基础架构确认的要求提得相对稍晚，早期多数体现在间接要求。但OECD在2016年即在文件中直接要求IT基础架构需要被确认，NMPA也在最近一份文件中直接要求了IT基础架构需要被确认。

涉及GLP领域IT基础架构合规要求的法规/指南部分摘录如下：

监管机构	文件名称	原文摘录	解读
NMPA	临床试验的电子数据采集技术指导原则 2016	计算机化系统（Computerized System）：临床试验中计算机化系统不单单是指计算机运用本身。计算机化系统中的“系统”意味着一个与临床研究过程有关的各个功能性软件和硬件配置环境，包括与之相配合的人员、设备、政策和程序等。	计算机化系统不单单指计算机运用本身，IT基础架构构成计算机化系统的“硬件配置环境”，此描述相当于间接要求IT基础架构需要验证。
NMPA	药物非临床研究质量管理规范 2017	用于数据采集、传输、储存、处理、归档等的计算机化系统（或者包含有计算机系统的设备）应当进行验证。	数据传输必然涉及IT基础架构，此描述相当于间接要求IT基础架构需要验证。
OECD	Application of GLP Principles to Computerised Systems 2016	Network infrastructure should be qualified.	直接要求
NMPA	药品记录与数据管理要求（试行）2020	采用电子记录的计算机（化）系统验证项目应当根据系统的基础架构、系统功能与业务功能，综合系统成熟程度与复杂程度等多重因素，确定验证的范围与程度，确保系统功能符合预定用途。	在计算机化系统验证的范围中覆盖到了IT基础架构，间接要求IT基础架构需要验证。
NMPA	药物临床试验质量管理规范（修订稿征求意见稿） 2025	申办者、主要研究者和临床试验机构应当建立经验证的流程，确保在计算机化系统之间传输的电子数据（包括相关元数据）的可靠性、可追溯性和安全性，以及避免数据丢失或被篡改。	此段内容是相对于2020年发布的《药物临床试验质量管理规范》增加的内容。数据传输必然涉及IT基础架构，此描述相当于间接要求IT基础架构需要验证。
NMPA	药物临床试验计算机化系统和电子数据指导原则（征求意见稿）2025	所有数据传输和交换都需要预先规定。应建立规程并进行验证。	数据传输和交换必然涉及IT基础架构，此描述相当于间接要求IT基础架构需要验证。
NMPA	生物等效性试验电子化记录技术指南（试行）2025	验证应当包括应用程序的验证和基础架构的确认。	直接要求

二、监管的新动向

1）GMP与GLP/GCP监管颗粒度的差别

在国外监管机构的官网上可以查询到大量警告信提及到IT基础架构和合规问题，但基本集中在GMP领域，我们还未检索到GLP/GCP领域的。

另外，很多IT基础架构未做确认的GLP机构前期也通过了国内的GLP认证或者OECD的GLP检查。

整体上看，在过往的认证或检查中，就IT基础架构合规这点上，GLP/GCP领域的监管GMP更松一些。

但，这是历史了。

2）监管的新动向

2025年下半年，我们从多个准备通过OECD检查的GLP机构了解到，IT基础架构确认已经是后续OECD检查的必需要求。

结合NMPA在最新的文件中明确要求了IT基础架构需要被确认，推测国内的GLP认证或检查也将严格要求IT基础架构需要被确认。

GLP机构IT基础架构确认已经是不得不做的工作了。

三、GLP机构如何实现IT基础架构的合规与控制

IT基础架构的合规与控制整体上包含两个部分：

1）验证/确认；

2）运维过程中的控制。

如何做IT基础架构的确认/验证？

首先，官方文件中的直接描述均是“IT基础架构需要被确认”。

但如果狭义地理解这个“确认”，反而会增加“确认”的工作量，同时会使后续运维过程中很难实现“控制”。我们见过一些理解存在偏差的确认文件，仅仅一台交换机的IOQ就长达几十页。

无论是基于“合规与控制”的本质要求，还是基于ISPE指南 IT Infrastructure Control and Compliance，或者基于我们应对监管方审计的实际经验，IT基础架构确认的概念更接近于传统意义上理解的验证，除了IQ、OQ，IT基础架构确认的输出还包括URS、DS、CS，作为后续运维过程中控制的基线。

例如，我们做过的一个IT基础架构验证项目，被EMA的审计官挑战没有做历史密码重用限制的测试，虽然这是一个商用成品的标准功能。最后翻出风险评估报告，依据风险评估结果给审计官解释此功能为低风险功能，已在风险评估中说明仅需要做参数配置的IQ、无需做OQ，才得到认可。在该案例中，没有风险评估就要被开发现项了。

从另外一个角度讲，不做风险评估，把所有功能全测一遍不就可以了？是的，可以这样做，但这是严重的浪费，对于IT基础架构，IQOQ的测试应重点关注到“可配置”的部分，而不是基本功能全测一遍。实际上我们见过一些第三方验证公司做的验证就有这种本末倒置的做法：基本功能测了一大推，而一些受参数配置影响的功能反而没有做测试，也没有识别为控制项，更谈不上后续的控制了。

另外，即使选择将基本功能全测一遍而不做风险评估，也逃不过制定设计/配置说明，因为IT基础架构除了“确认”还要“控制”，只做了狭义的“确认”，而没有基于合规、风险、运维效率等考量点，制定出设计/配置说明作为控制基线，其被“确认”的状态是不可维持的。

如何做IT基础架构的控制？

IT基础架构的单个硬件及其软件大多可划做一类，但这些单个设备需要依据用户需求及设计规范进行配置才能集成为IT基础架构。

IT基础架构的控制必须具备两个要素：

1）必须有URS、DS、CS作为后续运维过程中控制的基线；

2）配套的管理规程或标准操作规程。

URS、DS、CS撰写的质量直接决定后续运维阶段能否持续保持IT基础架构处于合规状态。同时，这些文件将直接决定后续IT运维人员的工作效率，这些文件的颗粒度掌握不好将成倍增加IT运维人员后续的工作量。

因为IT基础架构确认做得不好导致运维过程中无法控制的局面不少见。一些机构，先是做了IT基础架构的确认，为了迎接监管机构的检查而进行的内审中发现大量合规问题，而不得不重新对IT基础架构进行确认。其原因整体上可以归纳为三条：

1）关键的设计、配置和功能未识别到并记录，导致后续运维过程中变更不受控；

2）不重要的配置项在文档中记录得过于详细，导致运维过程中稍有变动就需要走流程并修改文档，不可避免地造成很多疏漏或错误；

3）IT基础架构管理规程或标准操作规程可执行性低。

关于我们

武汉点风信息科技有限公司，具有丰富的IT基础架构验证/确认，IT质量管理体系建立/优化项目经验。

我们的项目经验：

覆盖国内外；

涵盖GMP、GLP、GCP、GSP；

项目类型包括新建基础架构的验证，已投入运行基础架构的回顾性验证，已验证基础架构的补充验证、变更验证和重新验证。