IT 일반통제

이 페이지에서 다루는 것

- IT 일반통제는 IT 환경 전체의 데이터 무결성을 받쳐주므로, 개별 응용 통제를 신뢰하려면 먼저 ITGC가 작동해야 한다. - 접근통제(누가 무엇을 할 수 있는지), 변경관리(예상 못한 소프트웨어 수정), 운영 보안(백업, 재해복구). 이 네 영역에 직무 분리까지 더해 보면 거의 모든 지적이 여기에서 나온다. - 금감원 감리 지적의 다수는 개발자가 프로덕션에 직접 접근하거나, 데이터 수정 로그가 아예 없는 경우다.

작동 방식

ISA 315.A132는 IT 환경이 재무 보고 프로세스의 신뢰성에 직접 영향을 미칠 때 IT 일반통제 평가를 요구한다. 통제는 세 가지 범주로 나뉜다.

접근통제는 누가 어떤 시스템에 들어갈 수 있고, 그 권한이 직무 분리에 따라 제한되는지를 다룬다. 개발자는 테스트 환경에서만 작업해야 하고, 프로덕션의 재무 데이터 변경은 제한된 관리자만 수행할 수 있어야 한다. 권한 모니터링이 없으면 한 사람이 거래를 입력하고 승인하고 기록까지 수정하는 상황이 가능해지는데, 이러면 감사 증거 자체가 무너진다.

변경관리는 소프트웨어 수정, 구성 변경, 데이터 구조 업데이트가 통제되고 검증되어야 함을 뜻한다. 예상하지 못한 변경이 끼어들면 감사 증거의 기초가 훼손된다. ISA 315.A132(c)는 시스템 변경이 감사 증거와 일관되는지 확인할 것을 요구한다.

운영 보안은 데이터 백업, 재해복구 계획, 접근 로그 보존을 포함한다. 기술적 실패와 의도적 변조 양쪽으로부터 재무 데이터를 보호하는 마지막 방어선이다.

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

클라이언트: 독일 기반 화학 제조업체, 2024 회계연도, 매출 €87M, IFRS 보고.

상황: 회사의 자동 구매 발주 시스템이 월 100만 유로 이상 거래를 처리한다. 감사인이 이 시스템의 자동화 통제를 신뢰하려면 기초 ITGC부터 평가해야 한다.

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 관리자가 프로덕션 데이터에 접근하고, 변경을 승인하고, 접근 로그까지 삭제할 수 있으면 통제가 없는 것과 같다. ISA 315.A132(a)는 "감사인이 신뢰할 수 있는 구분"을 요구한다. 신뢰는 제한된 접근 그룹과 독립적인 모니터링을 동시에 의미한다.

- 변경 기록의 부재: 일부 소규모 회사는 공식적 변경 관리 프로세스가 없다. 개발자가 필요할 때마다 코드를 고치고 프로덕션에 배포한다. 변경 지시서, 테스트 기록, 승인 증거가 없다. ISA 315.A132(c)에서 요구하는 "변경이 승인되고 테스트되었다는 증거"가 없으면 자동화 통제는 신뢰 불가다. 제 경험상 이게 가장 흔한 지적사항이다.

- 감사 로그 무시: 재무 데이터 변경은 누가, 언제, 무엇을 변경했는지 기록되어야 한다. 회계 시스템 대부분이 이 기능을 가지고 있지만, 조직은 로그를 보관하지 않거나 비활성화한다. "우리 직원들은 좋은 사람들이라 데이터를 수정할 일이 없다"는 가정은 감사 위험을 통제하지 않는다. 솔직히 모든 팀이 같은 문제로 깨진다. ISA 315.A132(b)는 운영 보안 통제를 명시적으로 요구한다.

관련 용어

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

UI 라벨

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