IT基础架构确认 or IT基础架构验证？

在我们与客户的交流中，经常会遇到关于应该叫“IT基础架构确认”还是“IT基础架构验证”的讨论。

首先我们认为叫什么都可以，叫“IT基础架构确认”可以，叫“IT基础架构验证”也可以。

我们理解这个问题被关注的原因：在制药领域的法规中，对IT基础架构的要求表述为“infrastructure should be qualified”，而对计算机化系统的要求则更为明确，即必须进行验证（validated）。而在制药行业中，“qualify / 确认”与“validate / 验证”是两个概念。

“qualify / 确认”在制药行业中通常指的是对设备或系统的特定属性进行检查和核实的过程。这包括设计确认（DQ）、安装确认（IQ）、运行确认（OQ）和性能确认（PQ）等步骤。DQ是对设备的设计是否符合预期用途和用户需求的确认；IQ则是对设备或系统安装后是否符合设计要求的确认；OQ是对设备或系统在运行状态下各项功能是否正常的确认；PQ则是通过模拟实际生产环境来验证设备或系统的性能是否满足预期。

“validate / 验证”在制药行业中不仅涵盖了“确认”的各个环节，还涉及了更为复杂的流程和活动。它包括了风险评估、起草设计/配置规范、确认、总结与报告（含RTM）等多个方面。

叫“确认”或者“验证”都可以，但不能因为“infrastructure should be qualified”的表述，就认为可以只做狭义的“Q”。“infrastructure should be qualified”里的“qualified”实际上涵盖了确认和验证的过程。无论是基于指南的要求，比如ISPE Good Practice Guide IT Infrastructure Control and Compliance，还是基于我们应对监管方审计的实际经验，对IT基础架构都需要进行基于风险的验证，而不是狭义的确认。

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

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

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

综上，叫“验证”没问题，因为实际上就是做的验证而非狭义的确认；叫确认也没关系，但要干完验证的活。