[CISA 이론 정리 - 1장] 8. 감사 세부 절차 및 기법 (2/2)

3) 준거성 테스트(= 통제 테스트)

(1) 분석적 검토 절차(ARP: Analytical Review Procedure)

분석적 검토 절차는 감사 전체 단계에서 두루 사용된다.

규정 위반을 시사하는 잠재적 지표를 발견하여 준거성 테스트 노력을 집중한다.

(2) 검사(Inspection), 관찰, 조사(examination),

IT 감사인이 물리적 자산 상태, 업무 수행 활동 등을 실제로 검사, 관찰, 조사한다.

조직의 정책 및 절차에 따라 자산이 보호/사용되며 업무 활동이 수행되는지 판단한다.

(3) 질의(Inquiry) 및 재수행(re-performance)

통제 절차의 숙지하고 있는지 질의하고 특정 유형의 업무를 다시 수행해 보게 요청한다.

규정과 다르게 업무를 수행할 경우 실제로 따르고 있는 절차를 확인할 때도 사용한다.

(4) 추적(Tracing)

거래의 승인 및 규정 준수 여부를 판단하기 위해 거래 처리 과정을 따라가면 검토한다.

준거성 테스트 목적의 추적 조사는 일반적으로 거래 처리 순서의 역방향으로 이루어진다.

(5) 코드 비교(Code comparison)

사용 중인 프로그램을 승인 받은 버전과 비교하여 불법 변경 여부를 판단한다.

승인 받은 코드와 사용 중인 코드의 타임 스탬프나 해시 값을 비교하여 변경 여부를 판단한다.

(6) 속성 샘플링(Attribute sampling)

전체 거래 중 일부를 선택하여 관련 정책 및 절차의 오류율(=위반율)을 추정한다.

기대 오류율(=감사인이 사전 예상하는 오류율)이 높으면 더 많은 거래를 추출하여 조사한다.

표본 오류율(=표본에서 발견된 오류율)을 근거로 모집단의 오류율을 추정한다.

추정한 모집단의 오류율이 허용 가능 오류율을 초과할 경우 통제 절차를 불신한다.

(7) 2차 통제 위험 평가

다양한 준거성 테스트 결과를 근거로 통제 운영의 효과성을 평가한다.

통제 위험이 크게 나타나면 입증 테스트 노력을 높이고, 낮으면 입증 테스트 노력을 낮춘다.

4) 입증 테스트

(1) 분석적 검토 절차(ARP: Analytical Review Procedure)

분석적 검토 절차는 감사 전체 단계에서 두루 사용된다.

잠재적 오류, 부정, 위험의 존재를 시사하는 지표를 발견하여 입증 테스트 노력을 집중한다.

(2) 개괄적 검토(Scanning)

정보의 전체 내용 및 관련 수치를 개괄적으로 검토하면서 오류, 누락, 중복을 찾아 본다.

전체 정보를 빠른 속도로 훑어 보면서 확연하게 잘못된 수치나 정보를 적발한다.

(3) 재계산(Recalculation)

실무자가 처리한 결과를 IT 감사인이 다시 수행하여 수치를 상호 비교한다.

GAS(범용 감사 소프트웨어)를 사용하는 병행 시뮬레이션도 일종이 재계산 기법이다.

(4) 조회(Confirmation)

거래처에 특정 거래 사실의 존재 여부 및 관련 항목, 수치, 금액 등을 질의하여 검증한다.

채권 또는 채무 잔액의 정확성 및 완전성을 검증한다.

(5) 추적(Tracing)

거래의 완전성, 존재성, 일관성을 검증하기 위해 거래 처리 과정을 따라가면서 검토한다.

거래 처리 및 정보 생성 순서와 방향이 같으면 순방향 추적, 다르면 역방향 추적이라 한다.

(6) 코드 검토(Code review)

프로그래밍 능력이 있는 감사인이 프로그램 소스 코드의 무결성을 검토한다.

소스 코드에 문법 오류, 코딩 표준 위반, 부정 코드 등이 존재하는지 검토한다.

(7) 변량 샘플링(Variable sampling)

거래의 완전성, 존재성, 일관성을 검증하기 전체 거래 중 일부를 선택한다.

표본 거래를 검사하여 정확한 수치를 확인한 후 전체 거래의 정확한 수치를 추정한다.

5) 보고 및 후속 조치

(1) 보고서 초안 전달

IT 감사인의 의견이 담긴 보고서 초안을 작성하여 피감부서의 장에게 제공한다.

발견 사항 및 감사인의 의견에 대해 검토하고 동의 여부 등의 의견을 묻는다.

시정 조치가 필요한 경우 그 내용 및 일정 계획을 문의한다.

피감부서의 장이 위험을 용인하기로 결정할 경우 감사인은 이를 문서화한다.

이 경우 시정 조치 계획은 필요 없으며 감사인은 추후 감사에서 이를 문제시하지 않는다.

이사회 또는 경영진 구성 등 중요한 상황 변화가 생기면 해당 사안을 다시 언급할 수 있다.

(2) 종료 회의(Exit conference)

피감부서와 감사팀이 감사 보고서에 포함될 내용에 관해 논의하고 동의를 구한다.

시정 조치 계획에 대해 또는 위험을 감수할 것인지에 대해 공식적 답변을 구한다.

피감부서가 발견 사항과 의견에 동의하지 않는다면 타당한 근거를 요청한다.

(3) 보고

감사 의견, 발견 사항, 피감부서의 의견, 시정 조치 계획 등을 포함하는 보고서를 완성한다.

피감부서가 감사 보고서의 내용에 동의하지 않으면 보고서에 의견과 근거를 포함한다.

현장 작업 완료 및 종료 회의 이후 중요한 변경 사항이 있을 경우 최종 보고서에 반영하다.

피감부서의 장, CEO 등을 포함하여 적절한 수령자들에게 최종 보고서를 배포한다.

고위 임직원들을 위한 요약 보고서를 포함하는 것이 좋다.

최종 보고서 배포 이후 중요한 변경 사항이 있을 경우 교정본을 후속 제공해야 한다.

(4) 만족도 조사

IT 감사를 마친 뒤에는 감사에 대한 피감부서의 만족도 및 의견을 피드백 받는다.

만족도 조사는 필수적인 과정은 아니지만 향후 감사 품질 개선에 참고할 수 있다.

(5) 후속 조치

피감부서가 계획한 시정 조치를 이행하였고 문제가 해결됐는지 확인하고 결과를 보고한다.