IT基礎架構确認 or IT基礎架構驗證？

在我們與客戶的(de)交流中，經常會遇到關于應該叫“IT基礎架構确認”還(hái)是“IT基礎架構驗證”的(de)討(tǎo)論。

首先我們認爲叫什(shén)麽都可(kě)以，叫“IT基礎架構确認”可(kě)以，叫“IT基礎架構驗證”也(yě)可(kě)以。

我們理(lǐ)解這(zhè)個(gè)問題被關注的(de)原因：在制藥領域的(de)法規中，對(duì)IT基礎架構的(de)要求表述爲“infrastructure should be qualified”，而對(duì)計算(suàn)機化(huà)系統的(de)要求則更爲明(míng)确，即必須進行驗證（validated）。而在制藥行業中，“qualify / 确認”與“validate / 驗證”是兩個(gè)概念。

“qualify / 确認”在制藥行業中通(tōng)常指的(de)是對(duì)設備或系統的(de)特定屬性進行檢查和(hé)核實的(de)過程。這(zhè)包括設計确認（DQ）、安裝确認（IQ）、運行确認（OQ）和(hé)性能确認（PQ）等步驟。DQ是對(duì)設備的(de)設計是否符合預期用(yòng)途和(hé)用(yòng)戶需求的(de)确認；IQ則是對(duì)設備或系統安裝後是否符合設計要求的(de)确認；OQ是對(duì)設備或系統在運行狀态下(xià)各項功能是否正常的(de)确認；PQ則是通(tōng)過模拟實際生産環境來(lái)驗證設備或系統的(de)性能是否滿足預期。

“validate / 驗證”在制藥行業中不僅涵蓋了(le)“确認”的(de)各個(gè)環節，還(hái)涉及了(le)更爲複雜(zá)的(de)流程和(hé)活動。它包括了(le)風險評估、起草(cǎo)設計/配置規範、确認、總結與報告（含RTM）等多(duō)個(gè)方面。

叫“确認”或者“驗證”都可(kě)以，但不能因爲“infrastructure should be qualified”的(de)表述，就認爲可(kě)以隻做(zuò)狹義的(de)“Q”。“infrastructure should be qualified”裏的(de)“qualified”實際上涵蓋了(le)确認和(hé)驗證的(de)過程。無論是基于指南(nán)的(de)要求，比如ISPE Good Practice Guide IT Infrastructure Control and Compliance，還(hái)是基于我們應對(duì)監管方審計的(de)實際經驗，對(duì)IT基礎架構都需要進行基于風險的(de)驗證，而不是狹義的(de)确認。

例如，我們做(zuò)過的(de)一個(gè)IT基礎架構驗證項目，被EMA的(de)審計官挑戰沒有做(zuò)曆史密碼重用(yòng)限制的(de)測試，雖然這(zhè)是一個(gè)商用(yòng)成品的(de)标準功能。最後翻出風險評估報告，依據風險評估結果給審計官解釋此功能爲低風險功能，已在風險評估中說明(míng)僅需要做(zuò)參數配置的(de)IQ、無需做(zuò)OQ，才得(de)到認可(kě)。在該案例中，沒有風險評估就要被開發現項了(le)。

從另外一個(gè)角度講，不做(zuò)風險評估，把所有功能全測一遍不就可(kě)以了(le)？是的(de)，可(kě)以這(zhè)樣做(zuò)，但這(zhè)是嚴重的(de)浪費，對(duì)于IT基礎架構，IQOQ的(de)測試應重點關注到“可(kě)配置”的(de)部分(fēn)，而不是基本功能全測一遍。實際上我們見過一些第三方驗證公司做(zuò)的(de)驗證就有這(zhè)種本末倒置的(de)做(zuò)法：基本功能測了(le)一大(dà)推，而一些受參數配置影(yǐng)響的(de)功能反而沒有做(zuò)測試，也(yě)沒有識别爲控制項，更談不上後續的(de)控制了(le)。

另外，即使選擇将基本功能全測一遍而不做(zuò)風險評估，也(yě)逃不過制定設計/配置說明(míng)，因爲IT基礎架構除了(le)“确認”還(hái)要“控制”，隻做(zuò)了(le)狹義的(de)“确認”，而沒有基于合規、風險、運維效率等考量點，制定出設計/配置說明(míng)作爲控制基線，其被“确認”的(de)狀态是不可(kě)維持的(de)。

綜上，叫“驗證”沒問題，因爲實際上就是做(zuò)的(de)驗證而非狹義的(de)确認；叫确認也(yě)沒關系，但要幹完驗證的(de)活。