Audit trail 기능이 없는 장비, 기기, 시스템 처리 방법

QC 실험실 및 제조/생산 장비들 중에서 오래된 장비/기기 일부의 경우에는 Audit trail 기능이 전혀 없거나, 아주 부족한 기능만을 제공하는 경우가 있습니다. 당장 새로 구매할 수도 없는 상황에서 Audit trail 이 없거나 기능이 부족한 시스템, 기기, 장비들은 어떻게 처리해야 할까요? 

 

일단, DI 규정 및 Requirement 를 만족하고, Inspection/Audit 에서 주요 지적을 피하기 위해서 우선 준비/개선이 필요한 항목은 개인적으로 아래와 같습니다. 

 

1. Audit trail

Audit trail 기능 셋업/검증 + 검토 절차 수립 + 정기 검토 및 Routine 검토 운영

 

2. User privilege (SOD - Segrigation of Duties) 관리

Account 등록/운영/관리 (기준서 및 관리 서식 + 정기 검토 운영)

 

3. Data accessment control & Security

개별 Data 에 대한 접근 제한 (Desktop 바탕화면, Windows  Explorer(탐색기) Copy, rename, delete 등)

비번 설정 및 PW 갱신 주기 설정, Lockout 설정 등

 

4. Data Backup/Restoration

Data Backup (개별 file 백업, DB 백업, image backup 등) 기능 설정 및 절차 수립 + 주기적인 운영 + 복구력 검증 수행

HDD 백업, NAS 백업 + 아카이브 절차 (Tape storage 등)

 

5. CSV DI Requirement 

URS 단계에서 DI Requirement에 대항 평가 및 적용, DI Risk 가 낮게 운영될 수 있도록 기능 보완 (1-4 항목 Audit trail, User privilege, Data generation type, Data backup/restore, Security function 등) 

 

 

 

 

 

따라서,

 

Audit trail 에 대한 기능 수립과 검토 운영은 DI 정책 적용 후 최우선 과제로 고려될 수 있습니다. 

 

일단은 현재 장비/기기/시스템 (모든 종류의 데이터를 생성하는 모든 equipment 범주 포함) 들에 대한 점검을 통해 부적절한 audit trail 기능을 갖는 시스템과 Audit trail 이 없는 시스템들을 목록화했다면, 

 

이후에는 해당 시스템들을 그대로 (아무런 조치 없이) 쓸 수는 없습니다. 

불가피하게 그대로 써야하는 상황이라면, 아래 절차를 통해 그대로 써도 괜찮다는 근거(Rationale)를 만들어 두어야 합니다. (Inspection 시에 대응하기 위해서)

 

DI Risk 평가 (위험평가) 를 반드시 진행해야 하고, 평가 방법은 FMEA 방법을 주로 사용합니다. 

 

DI Risk 평가 기준에서 Acceptable 한 Risk 를 사전에 정의해야 하고 (예: High/Medium Risk는 수용할 수 없음 = 개선/조치 필요) , Low Level 수준에서 보완/개선(Remediation/Mitigation) 후에 사용할 것임을 명시할 수 있습니다.

 

 

 

 

실제 평가 진행시에는

 

Audit trail 기능이 부재함으로 인해 발생할 수 있는 DI 위험 = Risk Identification, 

 

명시된 DI Risk 사항에 대한 Level 평가 = Severity x Occurrence of possibility x Detectability,

 

를 통해 Risk Level 을 정하게 됩니다. (예: high / medium / low or 1 / 2 / 3)

 

Severity / Occurrence of possibility / Detectability에 대한 평가 기준은 사전에 정해야 하며,

데이터의 중요도/시스템의 중요도, 발생 빈도, 해당 위험 발생에 대한 검출 정도를 통해 초기 Risk를 평가하고,

High/Medium Risk Level 로 평가된 시스템에 대해서는 Mitigation 사항 (단기 or 장기)을 적용합니다. 

 

Mitigation 적용 후에 Risk 평가를 다시 진행하고, Mitigation 적용을 통해 Risk level 을 Low까지 감소시킬 수 있음을 평가함으로써 기존의 시스템을 사용하는 데 필요한 근거를 마련할 수 있습니다. 

(보통 부가적인 점검 절차나 대안의 기능, 시스템을 이용하는 것 등을 고려할 수 있으나, 가장 바람직한 것은 system 의 업그레이드 또는 적합한 기능을 갖춘 시스템을 새로 도입하는 것입니다)

 

제 경험 상 허가 규제 기관에 따라서 절차 보완을 통한 Risk 관리 근거를 accept 하는 경우도 있지만, 너무 형식적인 절차 보완 (매 분석 후 Reviewer 가 확인 후 서명하는 수준의 절차)는 결국 해당 절차 준수에 대해 manually 점검해야 하는 점 (결국 audit trail 이 없는 것과 동일하다고 보는 관점)이나 자체 부서 (QC/생산 부서 자체 수행)가 진행한다는 점 (신뢰성이 떨어짐)에서 여전히 Risk 가 있다고 보는 관점이 있었습니다. 

 

Risk 평가는 정답이 있는 것은 아닙니다. 

 

평가 기준을 세우고, 해당 평가 기준에 맞는 평가를 진행한 뒤에 초기 Risk level 이 높을 경우에는 필요한 조치 (개선)를 적용시키는 계획을 수립하고, 이후에 개선이 적용되었을 때 Low Risk 로 관리, 운영이 가능함을 문서화하는 것입니다. 

좀 더 구체적인 예시가 필요하다면 다음의 내용들을 참고해 보시기 바랍니다.