핵심 요약

  • IT 일반통제는 IT 환경 전체의 데이터 무결성을 보호하므로 개별 응용 시스템 통제를 신뢰하기 위한 전제조건입니다.
  • 접근통제(누가 무엇을 할 수 있는지), 변경관리(예상하지 못한 소프트웨어 수정), 운영 보안(백업, 재해복구)이 세 가지 핵심 영역입니다.
  • 대부분의 감리 지적은 개발자가 프로덕션 환경에 직접 액세스할 수 있거나 데이터 수정 기록이 없는 경우입니다.
  • ISA 315.A132에 따라 감사인은 IT 일반통제 평가를 자동화 통제 신뢰 결정 전에 완료해야 합니다. 순서가 뒤바뀌면 통제 의존 자체가 무효입니다.

작동 방식

ISA 315.A132는 IT 환경이 재무 보고 프로세스의 신뢰성을 직접 영향을 미칠 때 IT 일반통제의 평가를 요구합니다. 이 통제들은 세 가지 범주로 나뉩니다.
접근통제는 누가 어떤 시스템에 접근할 수 있으며 그 접근 권한이 직무 분리 원칙에 따라 제한되는지를 관리합니다. 개발자는 테스트 환경에서만 작업해야 하고, 프로덕션 환경의 재무 데이터 변경은 제한된 관리자만 수행할 수 있어야 합니다. 권한 모니터링이 없으면 한 명의 사용자가 거래를 입력하고 승인하고 기록을 수정할 수 있으며, 이는 감사 증거를 완전히 무효화합니다.
변경관리는 소프트웨어 수정, 구성 변경, 데이터 구조 업데이트가 통제되고 검증되어야 함을 의미합니다. 예상하지 못한 변경이 발생하면 감사 증거의 기초가 훼손됩니다. ISA 315.A132(c)는 시스템 변경이 항상 감사 증거와 일치하는지 확인하도록 요구합니다.
운영 보안은 데이터 백업, 재해복구 계획, 접근 기록의 보존을 포함합니다. 이들은 기술적 실패나 의도적인 변조로부터 재무 데이터를 보호합니다.

산출 사례: Koreanium 제조 Gmbh 자동 구매 시스템

클라이언트: 독일 기반 화학 제조업체, 2024 회계연도, 매출 €87M, IFRS 보고.
상황: 회사의 자동 구매 발주 시스템은 100만 유로 이상의 월간 거래를 처리합니다. 감사인이 이 시스템의 자동화 통제를 신뢰하려면 먼저 기본 IT 일반통제를 평가해야 합니다.
1단계: 접근통제 평가
감사인이 확인한 사항: (1) 개발자 4명은 테스트 환경에만 접근할 수 있고, (2) 프로덕션 환경의 구매 발주 기록 변경은 재무 담당이사만 승인할 수 있으며, (3) 모든 접근 시도는 시스템이 월별로 기록합니다.
감사 조서 기록: "IT 접근통제 매트릭스 검토. 직무 분리 원칙 준수 확인. 월간 접근 기록 샘플 검토: 무단 접근 0건."
2단계: 변경관리 평가
감사인이 확인한 사항: (1) 소프트웨어 수정은 변경 요청 양식을 통해서만 신청되며, (2) 모든 변경은 IT 담당자와 재무 담당이사 2명이 승인해야 하고, (3) 변경 후 테스트 결과를 기록합니다.
감사 조서 기록: "변경 관리 정책 및 2024년 실제 변경 6건 검토. 모든 변경이 문서화되고 승인됨을 확인. 변경과 시스템 거래 기록의 일관성 검증."
3단계: 운영 보안 평가
감사인이 확인한 사항: (1) 거래 데이터는 매일 독립적인 서버로 백업되며, (2) 재해복구 계획이 존재하고 분기별로 테스트됩니다. (3) 데이터 수정 기록(감사 로그)은 최소 3년간 보존됩니다.
감사 조서 기록: "백업 일지 12월 확인: 12/1부터 12/31까지 31개 백업 완료, 모두 성공. 재해복구 테스트 일지 2024년 2회 검토: 복구 시간 목표 4시간 대비 실제 3시간 45분. 감사 로그 샘플: 7월 거래 기록 변경 시도 0건."
결론: 세 가지 IT 일반통제 영역 모두 효과적으로 작동합니다. 따라서 감사인은 자동화된 구매 발주 통제를 신뢰할 수 있는 기초가 있습니다. 구매 발주가 자동으로 생성되고 승인되는 프로세스를 더 깊이 테스트할 수 있습니다.

감리자와 감사인이 놓치는 점

  • 직무 분리의 불완전한 구현: 많은 중견 법인이 "관리자 권한"을 너무 광범위하게 정의합니다. 한 명의 IT 관리자가 프로덕션 데이터에 접근하고, 변경을 승인하고, 접근 기록을 삭제할 수 있으면 통제가 없는 것과 같습니다. ISA 315.A132(a)는 "감사인이 신뢰할 수 있는 구분"을 요구합니다. 신뢰는 제한된 접근 그룹과 독립적인 모니터링을 의미합니다.
  • 변경 기록의 부재: 일부 소규모 회사는 공식적인 변경 관리 프로세스가 없습니다. 개발자가 필요에 따라 코드를 수정하고 프로덕션에 배포합니다. 변경 지시서, 테스트 기록, 승인 증거가 없습니다. ISA 315.A132(c)에서 요구하는 "변경이 승인되고 테스트되었다는 증거"가 없으면 자동화 통제를 신뢰할 수 없습니다. 이것이 가장 흔한 지적사항입니다.
  • 감사 로그의 무시: 재무 데이터 변경은 누가, 언제, 무엇을 변경했는지 기록해야 합니다. 많은 회계 시스템이 이 기능을 가지고 있지만 조직은 로그를 보관하지 않으거나 비활성화합니다. "우리는 좋은 직원들이므로 데이터를 수정할 필요가 없습니다"라는 가정은 감사 위험을 통제하지 않습니다. ISA 315.A132(b)는 운영 보안 통제를 명시적으로 요구합니다.

관련 용어

  • 자동화 통제 - IT 일반통제가 신뢰할 수 있을 때 감사인이 의존할 수 있는 개별 시스템 통제
  • 직무 분리 - 한 사람이 거래 입력, 승인, 기록 변경을 모두 할 수 없어야 한다는 원칙
  • 시스템 변경 관리 - 소프트웨어 수정과 업데이트가 통제되고 테스트되어야 한다는 프로세스
  • 감사 로그 - 데이터 접근 및 수정의 기록으로, 무단 변경을 감지하는 데 사용
  • ISA 315 - IT 환경을 포함한 내부통제를 평가하는 기본 감사 기준
  • ISQM 1 - IT 일반통제를 포함한 감사 품질 관리의 요구사항을 규정

UI 라벨

이 용어집 페이지는 상호작용 요소를 포함하지 않으므로 UI 라벨이 필요하지 않습니다.

실무 감사 인사이트를 매주 받아보세요.

시험 이론이 아닙니다. 감사를 빠르게 만드는 실질적인 내용입니다.

290개 이상의 가이드 게시20개 무료 도구현직 감사인이 구축

스팸 없음. 저희는 감사인이지 마케터가 아닙니다.