Audit trail (점검 기록) 확인 항목 결정

Audit trail 관리 절차를 만들 때 생각보다 많은 부분을 결정해야 합니다. 

 

 

- 검토 범위 (scope)

- 검토 주기 (period)

- 검토 주체 (responsibility)

 

*검토 주체와 주기 관련 내용은 이전글을 참고하시면 되겠습니다.

 

---

위 내용이 결정되면, 본격적으로 audit trail 검토 방법을 만들게 되는데, 

 

아래 2가지 경우가 가능합니다. 

 

1) 공통 검토 서식으로 간략히 checklist 를 만들어 운영하는 방법

 

포괄적으로 적용되도록 항목들을 체크리스트로 만들고,

해당 서식을 공용으로 사용하는 것입니다. 

 

- Data 생성 관련 : 데이터 생성 날짜/파일 정보에 문제가 없는지, 사용 이력과 생성 이력의 불일치는 없는지, 추가 생성된 데이터는 없었는지 등

- Data 처리 관련: 데이터 변경 이력은 없는지, 변경(recipe/report/raw data 등)이 있었다면 변경 사유는 기록되어 있는지 등

- Data 폐기 관련: 데이터 이동 이력은 없었는지, 데이터 삭제 이력은 없었는지 (가능한 경우)

 

2) 시스템 별 개별 서식을 만들어 실제로 검토 가능한 항목에 대해서 checklist 를 만들어 운영하는 방법

 

1)번으로 운영하다보면 시스템에 따라 Audit trail 열람 가능한 정보와 수준이 달라

검토 기록을 남기는 데 어려운 점이 발생합니다.

 

A 시스템은 Data 처리 이력을 확인할 수 없고, B 시스템은 생성 이력을 확인할 수 없다면,

각 시스템 마다 서식에 별도의 논평을 작성하거나 설명들을 작성해야합니다.

 

특히, 데이터 검토의 일부로 Audit trail 검토가 진행되는 경우, 매우 높은 빈도로 audit trail 검토가 수행되기 때문에 이러한 점이 장기적으로는 운영 상의 불편함과 inspection 시 설명도 부자연 스럽습니다. 

 

쓰는 입장에서는 참고 사용하면 되는데,

inspection 시에 1) 번 사항이 지적 받을 가능성이 있는 이유는

checklist 서식만 공용으로 사용하는 것이 아니라

보통은 audit trail 검토 방법(절차) 또한 공용 절차로 운영할 가능성이 높기 때문입니다. 

 

실제로 많은 Inspector 들이 Audit trail 검토 과정을 직접 확인하겠다는 요청이 많았습니다.

이때 Audit trail 검토 방법/절차가 너무 rough 할 경우에는 지적 받을 가능성이 높고, 

시스템 마다 S/W 가 다르고 audit trail 검토를 위한 접근 방법이 다르기 때문에 

SOP 에 해당 내용을 넣어야 한다는 지적이 있을 수 있습니다. 

 

모든 System 에 대해 Audit trail 검토 방법을

SOP 로 어떻게 만드냐고 하겠지만,

 

SOP 를 통해 절차 교육이 가능해야하고, 

작업자는 SOP 를 통해 작업이 가능해야하는 기본적인 개념으로는

각 시스템에서 운용 SOP 가 개별적으로 만들어지듯이 

Audit trail 검토 또한 System 별로 만들어 지는 것이 적절해 보입니다. 

(단, 다른 H/W 인데, 동일 S/W 를 사용한다면 이는 하나의 공통 절차로 갈음 가능하다고 생각합니다)

 

QA (or DI 부서) 에서도 정기적인 audit trail 검토가 요구되는데,

이는 개별 데이터와 연관된 activity 에 대한 검토 보다는 

특정 주기 (예: 1개월 or 3개월) 동안 System 을 포함한 compliace 준수 기준에서 

문제가 없었는지를 확인할 수 있습니다. 

 

이 때, 검토 항목으로는 아래 항목을 포함할 수 있습니다.

 

- System configuration 변경 사항 (시스템 설정 값, 속성 값 등의 변경)

- Account management 변경 사항 (사용자 추가/삭제, 권한 변경 등)

- Compliance 준수 사항 (Data 삭제/이동, 백업/복구, 날짜/시간 변경 여부 등)