[CISA 이론 정리 - 2장] 06 IS 부서에서의 직무 분리

1. 직무 분리의 일반 원칙

(1) 의의

① 직무 분리(Separation of duties, segregation of functions)는 조직 통제의 핵심이다.

② 직무 분리가 미흡하면 부적절한 자산 사용, 재무제표 조작, 데이터 변조/수정 위험이 증가한다.

③ 일반적으로 다음과 같은 세 가지 원칙을 준수해야 한다.

(2) 자산의 보관(custody)

① 각각의 데이터 세트는 이를 보호하고 보관할 주된 책임이 있는 부서, 즉 데이터 소유 부서가 정의되어야 한다.

② 특정 데이터의 소유 부서는 해당 데이터의 수명 주기를 관리한다.

③ 데이터 소유 부서의 장을 데이터 소유자(data owner)라고 한다.

④ 데이터 소유자는 소관 데이터를 보호하고 무결성을 유지할 책임이 있다.

⑤ 한편 자산의 보관 책임은 IT 부서에 일정 부분 위탁한다.

⑥ 데이터가 데이터 센터(= 전산실)에 물리적으로 보관되기 때문이다.

⑦ 데이터 소유자는 데이터의 보안 수준과 내용 범주를 결정한다.

⑧ 그리고 이를 근거로 해당 데이터에 접근할 사용자의 범위가 결정된다.

⑨ 데이터 접근 범위에 대한 결정은 데이터 소유자가 할 수도 있고 일정한 규칙에 따라 자동으로 이루어질 수도 있다.

(3) 거래의 승인(authorization)

① IT부서가 지원하는 고객 부서를 사용자 부서(user departments)라고 한다.

② 한편 특정 거래 승인을 하는 사용자 부서를 프로세스 소유 부서라고 한다.

③ 그리고 프로세스 소유 부서의 장을 프로세스 소유자(process owner)라고 한다.

④ 컴퓨터 시스템으로 처리되는 거래에 대한 승인 권한은 프로세스 소유 부서에 있다.

⑤ 다시 말해 IS/IT부서는 임의로 비즈니스 거래를 개시하거나 처리하지 않는다.

⑥ 입력 데이터의 무결성을 확인하고 거래 처리 결과를 검토할 책임도 소유 부서에 있다.

⑦ 다만 자동화된 시스템이 사용자 부서의 승인 없이 거래가 처리하도록 설계할 수는 있다.

⑧ EDI 시스템과 연계된 자동 발주 시스템이 한 가지 사례이다.

⑨ 하지만 이 경우도 프로세스 소유 부서가 해당 거래의 자동 처리 기준을 사전에 승인한다.

⑩ 따라서 거래의 승인 권한은 여전히 소유 부서에 남는다고 할 수 있다.

(4) 거래의 기록(record)

① 시스템을 통해 처리된 기록은 수작업 또는 자동화된 루틴을 통해 기록된다.

② 시스템에 의해 처리된 거래들을 시간 순으로 기록한 파일을 거래 파일(transaction file) 거래 로그(transaction log), 거래 저널(transaction journal)이라고 한다.

③ 거래 파일은 회계 장부 중 거래 분개장(transaction entry)에 해당하는 기능을 한다.

④ 다양한 형태의 거래 기록은 부정/오류를 적발하거나 마스터 파일 복구에 사용한다.

⑤ 마스터 파일은 회계 장부 중 총계정 원장(general ledger)에 해당한다.

⑥ 오늘날 거래 기록은 함부로 수정하거나 삭제하지 못하도록 철저히 보호해야 한다.

⑦ 이를 위해 거래를 WORM(Write Once Read Many) 드라이브에 저장하기도 한다.

⑧ WORM이란 1회 기록만 가능하고 수정/삭제는 불가능한 광학 디스크이다.

⑨ 또한 거래 기록을 복사하여 안전한 장소에 보관해 두어야 한다.

⑩ 어떤 경우에는 거래 기록을 안전한 제3의 장소에 실시간으로 기록하기도 한다.

⑪ 원격 저널링(Remote journaling)이라는 기법이 한 가지 사례이다.

2. IS 부서에서의 직무 분리 원칙

(1) 사용자 부서와 IT 부서의 직무 분리

① 전통적인 정보 처리 환경인 오프라인 배치(offline batch) 환경에서는 사용자 부서와 IT 부서는 분리되어야 하였다.

② 오프라인 배치 환경에서는 데이터 입력은 오프라인으로 이루어지고, 입력된 데이터는 배치 단위로  처리되며, 처리된 결과는 종이로 인쇄된 보고서로 출력하여 배포된다. 

※ 온라인 배치(Online batch) 처리 방식을 메모 업데이팅(memo updating) 또는 메모 포스팅(memo posting)이라고도 한다.

③ 오프라인 배치 환경에서 사용자 부서는 시스템의 개발, 구입, 운영에 관여할 수 없었다.

④ 하지만 오늘날에는 EUC(End User Computing)로 인해 이 원칙이 상당히 깨졌다.

⑤ EUC란 최종 사용자들이 필요한 소프트웨어를 직접 구입 또는 개발하는 실무이다.

⑥ 예를 들어 최종 사용자들이 시중에서 판매하는 패키지 소프트웨어를 직접 구입하거나 스프레드시트 프로그램으로 데이터를 처리한다.

⑦ OLRT(On Line Real Time) 환경에서도 사용자가 IT 부서의 개입 없이 업무를 처리한다.

⑧ EUC와 OLRT 환경에서의 데이터 보호와 백업은 상당 부분 사용자가 수행한다.

(2) 개발과 운영의 직무 분리

① 전통적 IT 환경에서는 시스템 개발과 운영(입력/처리/출력)은 철저히 분리했다.

② 이러한 원칙은 지금도 여전히 강조되고 있다.

③ 따라서 프로그래머와 운영자는 겸임해서는 안 된다.

④ 하지만 여러 기업에서 IS 인적 자원의 부족으로 인해 자주 개발과 운영이 겸임된다.

⑤ 이럴 경우 적절한 보완 통제(compensating controls)가 구현되어야 한다.

(3) 입출력과 처리의 분리

① 과거 배치 처리 환경에서는 데이터 입출력 업무를 처리 업무와 분리하였다.

② 예를 들어 데이터 입출력은 데이터 통제 그룹이, 데이터 처리는 운영자가 수행하였다.

③ 하지만 OLRT 환경에서는 사용자가 직접 데이터를 입력한다.

④ 이런 경우 사용자는 시스템 인터페이스를 통해 거래 처리를 직접 명령하며 결과를 출력한다.

3. 직무 분리 완화에 따른 보완 통제

① 직무 분리는 예방 통제이며 적발 통제나 교정 통제보다 선호된다.

② 하지만 IS 직원이 부족한 경우에는 직무 분리의 원칙을 어기게 된다.

③ 이럴 경우 다음과 같은 보완 통제를 고려할 수 있다.

(1) 감사 증적(Audit trails)및 거래 로그

① 감사 증적이란 거래를 재구성하고 추적할 수 있는 모든 단서를 가리킨다.

② 매출 송장(invoice), 영수증,검수 보고서 등은 모두 감사 증적이다.

③ 직무 분리가 미흡한 조직에서는 다양한 감사 증적과 거래 로그로 적발 통제를 보강할 수 있다.

④ 거래 로그는 앞에서 설명한 바와 같이 거래 파일,거래 저널이라고도 한다.

(2) 예외 보고와 차이 수정

① 일정한 규모를 벗어나거나 비일상적으로 수행하는 예외적인 거래는 반드시 경영진에게 보고해야 한다.

② 경영진은 모든 예외적 거래에 대한 적절한 검토와 처리가 있었는지 검토해야 한다.

③ 또한 거래 담당자는 처리 및 출력 과정에서 거래 잔액 비교(balancing)를 수행해야 한다.

④ 이때 차이가 발생하면 원인을 찾아내어 적절히 수정(reconciliation)해야 한다.

⑤ 이러한 실무는 오류와 부정을 시기적절하게 발견하여 수정할 수 있도록 도와 준다.

(3) 감독자 검토 및 주기적 감사

① 프로세스 소유자는 주기적으로 소관 거래의 처리 거래를 검토해야 한다.

② 이를 통해 부정과 오류의 존재 여부를 파악하고 적절한 조치와 수정을 해야 한다.

③ 또한 제3자에 의한 주기적 검토 또는 감사도 수행해야 한다.

④ 이를 통해 객관적 입장에서 중요한 오류와 부정을 적발하도록 도움을 받을 수 있다.