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

發(fā)布時間：2024-04-10 瀏覽次數(shù)：2779次

在我們與客戶的交流中，經常會遇到關于應該叫“IT基礎架構確認”還是“IT基礎架構驗證”的討論。

首先我們認為叫什么都可以，叫“IT基礎架構確認”可以，叫“IT基礎架構驗證”也可以。

我們理解這個問題被關注的原因：在制藥領域的法規(guī)中，對IT基礎架構的要求表述為“infrastructure should be qualified”，而對計算機化系統(tǒng)的要求則更為明確，即必須進行驗證（validated）。而在制藥行業(yè)中，“qualify / 確認”與“validate / 驗證”是兩個概念。

“qualify / 確認”在制藥行業(yè)中通常指的是對設備或系統(tǒng)的特定屬性進行檢查和核實的過程。這包括設計確認（DQ）、安裝確認（IQ）、運行確認（OQ）和性能確認（PQ）等步驟。DQ是對設備的設計是否符合預期用途和用戶需求的確認；IQ則是對設備或系統(tǒng)安裝后是否符合設計要求的確認；OQ是對設備或系統(tǒng)在運行狀態(tài)下各項功能是否正常的確認；PQ則是通過模擬實際生產環(huán)境來驗證設備或系統(tǒng)的性能是否滿足預期。

“validate / 驗證”在制藥行業(yè)中不僅涵蓋了“確認”的各個環(huán)節(jié)，還涉及了更為復雜的流程和活動。它包括了風險評估、起草設計/配置規(guī)范、確認、總結與報告（含RTM）等多個方面。

叫“確認”或者“驗證”都可以，但不能因為“infrastructure should be qualified”的表述，就認為可以只做狹義的“Q”。“infrastructure should be qualified”里的“qualified”實際上涵蓋了確認和驗證的過程。無論是基于指南的要求，比如ISPE Good Practice Guide IT Infrastructure Control and Compliance，還是基于我們應對監(jiān)管方審計的實際經驗，對IT基礎架構都需要進行基于風險的驗證，而不是狹義的確認。

例如，我們做過的一個IT基礎架構驗證項目，被EMA的審計官挑戰(zhàn)沒有做歷史密碼重用限制的測試，雖然這是一個商用成品的標準功能。最后翻出風險評估報告，依據(jù)風險評估結果給審計官解釋此功能為低風險功能，已在風險評估中說明僅需要做參數(shù)配置的IQ、無需做OQ，才得到認可。在該案例中，沒有風險評估就要被開發(fā)現(xiàn)項了。

從另外一個角度講，不做風險評估，把所有功能全測一遍不就可以了？是的，可以這樣做，但這是嚴重的*費，對于IT基礎架構，IQOQ的測試應重點關注到“可配置”的部分，而不是基本功能全測一遍。實際上我們見過一些第三方驗證公司做的驗證就有這種本末倒置的做法：基本功能測了一大推，而一些受參數(shù)配置影響的功能反而沒有做測試，也沒有識別為控制項，更談不上后續(xù)的控制了。

另外，即使選擇將基本功能全測一遍而不做風險評估，也逃不過制定設計/配置說明，因為IT基礎架構除了“確認”還要“控制”，只做了狹義的“確認”，而沒有基于合規(guī)、風險、運維效率等考量點，制定出設計/配置說明作為控制基線，其被“確認”的狀態(tài)是不可維持的。

綜上，叫“驗證”沒問題，因為實際上就是做的驗證而非狹義的確認；叫確認也沒關系，但要干完驗證的活。

?

上一條：如何對虛擬化平臺進行計算機化系統(tǒng)確認/驗證？

下一條：如何對備份系統(tǒng)進行計算機化系統(tǒng)驗證/確認？