ISAE 3402 FAQ: IT 통제 테스트와 감사인이 실제로 확인하는 사항

이 글에서 얻을 수 있는 것

> 학습 목표:

ISAE 3402.39에 따라 핵심 통제를 올바르게 식별할 수 있습니다
IT 통제에 대한 적절한 테스트 절차를 설계하고 수행할 수 있습니다
통제 실패가 있을 때 사용자 감사인에게 어떤 영향을 주는지 이해할 수 있습니다
Type II 보고서에서 AFM이 검토하는 핵심 영역을 파악할 수 있습니다

핵심 통제 식별과 ISAE 3402 요구사항

핵심 통제란 무엇인가

ISAE 3402.16은 핵심 통제를 "통제 목표를 달성하기 위해 운영되어야 하는 통제"로 정의합니다. 이것은 순환적 정의처럼 보이지만 실제로는 위험 기반 접근법입니다. 통제가 실패하면 통제 목표가 달성되지 않습니다. 보상 통제가 존재하지 않거나 보상 통제만으로는 위험을 허용 가능한 수준으로 감소시킬 수 없습니다.
IT 통제에서 이것은 특히 중요합니다. 애플리케이션 통제 위에 있는 일반 IT 통제(GITC)는 여러 통제 목표에 걸쳐 퍼져 있습니다. 사용자 액세스 관리가 실패하면 승인되지 않은 변경, 데이터 조작, 보고 오류가 모두 발생할 수 있습니다.

ISAE 3402.39가 요구하는 증거

서비스 감사인은 핵심 통제에 대해 운영 효과성 증거를 확보해야 합니다. ISAE 3402.39는 이를 위해 통제가 보고 기간 동안 일관되게 적용되었음을 입증하도록 요구합니다. IT 통제의 경우 이것은 다음을 의미합니다:
ISAE 3402.A67은 자동화된 통제의 경우 통제 자체와 통제가 변경되지 않았다는 증거 모두가 필요함을 명확히 합니다.

자동화된 통제: 보고 기간 동안 통제가 변경되지 않았고 올바르게 작동했음을 확인
수동 통제: 표본 추출을 통해 통제가 지속적으로 수행되었음을 테스트
하이브리드 통제: 자동화 부분과 수동 부분 모두에 대한 증거
IT의존적 수동 통제(ITDM): ISAE 3402.A67에 따라 보고서 생성 쿼리의 무결성과 해당 보고서를 검토한 사람의 수동 승인 증거를 모두 확보해야 함. 예를 들어 급여 계산 예외 보고서를 담당자가 매주 검토하는 경우, 쿼리 로직 변경 여부와 검토 서명이 각각 별도로 문서화되어야 합니다

IT 통제 테스트 절차

일반 IT 통제(GITC) 테스트

일반 IT 통제는 네 가지 범주로 나뉩니다:

애플리케이션 통제 테스트

애플리케이션 통제는 특정 비즈니스 프로세스와 연결됩니다. 가장 일반적인 통제:
완전성 통제
정확성 통제
승인 통제

사용자 액세스 관리
테스트: 신규 사용자 승인 문서 검토, 액세스 권한 정기 검토 증거, 퇴사자 계정 비활성화 적시성 확인
문서화: "HR 시스템에서 퇴사 처리된 10명의 직원에 대해 계정 비활성화가 퇴사일로부터 1영업일 이내에 수행되었는지 확인"
프로그램 변경 관리
테스트: 변경 승인 절차, 테스트 증거, 운영 환경 이관 통제
문서화: "연간 25건의 애플리케이션 변경에 대해 승인자 서명, UAT 결과서, 이관 체크리스트 확인"
컴퓨터 운영
테스트: 백업 및 복구 절차, 작업 스케줄링, 장애 대응
문서화: "월별 백업 로그 12개월치 검토하여 자동 백업 성공률과 복구 테스트 수행 증거 확인"
논리적 보안
테스트: 패스워드 정책, 네트워크 보안, 데이터 암호화
문서화: "시스템 설정을 확인하여 패스워드 복잡성 요구사항 적용 및 90일 만료 정책 운영 확인"
자동 순번 확인, 배치 총계 검증, 인터페이스 조정
테스트 방법: 시스템에서 생성된 예외 보고서와 해결 증거 확인
입력 검증 규칙, 계산 논리, 참조 데이터 무결성
테스트 방법: 테스트 데이터를 사용한 통제 작동 확인
워크플로우 승인, 한도 초과 에스컬레이션, 권한 매트릭스
테스트 방법: 표본 거래에 대한 승인 증거 검토

실무 예시

한국정보시스템 주식회사 (연매출 850억 원)가 대형 은행들에 온라인 뱅킹 플랫폼을 제공합니다. Type II 보고서를 위해 핵심 IT 통제를 식별하고 테스트해야 합니다.
1단계: 통제 목표 설정
통제 목표 1: 거래 처리의 완전성과 정확성을 보장
통제 목표 2: 고객 데이터의 기밀성과 무결성을 보호
문서화: 경영진 인터뷰와 프로세스 워크스루를 통해 2개 통제 목표 확정
2단계: 핵심 통제 식별
GITC-01: 운영자 권한 월 단위 검토 (핵심)
GITC-02: 애플리케이션 변경의 3단계 승인 (핵심)
AC-01: 거래 한도 초과 시 자동 차단 (핵심)
AC-02: 일별 배치 총계 조정 (핵심)
문서화: 각 통제에 대해 통제 실패 시 영향 분석과 보상 통제 평가 수행
3단계: 테스트 설계
GITC-01: 12개월간 월별 권한 검토 보고서 12건 확인
GITC-02: 연간 프로그램 변경 47건 중 25건 표본 추출
AC-01: 한도 초과 시나리오 5건에 대한 시스템 동작 확인
AC-02: 250영업일 중 25일 표본 추출하여 배치 조정 증거 검토
문서화: 표본 추출 방법론과 예상 편차율 문서화
4단계: 테스트 수행 결과
GITC-01: 예외 없음 (12/12 적시 수행)
GITC-02: 1건 예외 (긴급 변경 시 사후 승인)
AC-01: 예외 없음 (5/5 정상 차단)
AC-02: 예외 없음 (25/25 적시 조정)
문서화: 발견된 1건 예외에 대한 근본 원인 분석과 경영진 대응 방안 확인
결론: GITC-02의 1건 예외는 통제 설계는 적절하나 운영 효과성에 결함이 있음을 나타냅니다. 이는 Type II 보고서에 예외로 보고되어야 하며, 사용자 감사인은 이 영역에서 보상 통제를 평가해야 합니다.

실용적 체크리스트

통제 매트릭스 검토 시: 각 통제가 실패할 경우 어떤 위험이 현실화되는지 구체적으로 기술했는가? "데이터 무결성" 같은 일반적 표현이 아닌 "승인되지 않은 결제 처리" 같은 구체적 위험을 명시한다.
GITC 테스트 범위: 자동화된 통제의 경우 보고 기간 동안 통제가 변경되지 않았음을 확인하는 증거를 확보했는가? 시스템 로그, 변경 관리 기록, IT 책임자 확인서를 조합한다.
애플리케이션 통제 표본: ISAE 3402.A69에 따라 수동 통제는 연간 발생 빈도에 따른 적절한 표본 크기를 사용했는가? 일별 통제는 최소 25건, 주별 통제는 최소 5건이다.
예외 처리 문서화: 발견된 모든 예외에 대해 사용자 감사인이 필요로 하는 정보가 포함되었는가? 예외의 성격, 발생 빈도, 근본 원인, 보상 통제 여부를 명시한다.
관리 소견서 작성: Type II 보고서에서 예외가 보고된 경우 경영진의 대응 계획과 예상 완료 일정이 구체적으로 기재되었는가? "개선하겠다"가 아닌 "2024년 6월까지 시스템 업그레이드 완료"와 같은 구체적 약속이다.
가장 중요한 확인사항: 핵심 통제로 분류된 IT 통제에 대해 운영 효과성 테스트를 수행했으며, 사용자 감사인이 의존할 수 있는 수준의 확신을 제공할 수 있는가?

자주 발생하는 실수

표면적 테스트: 사용자 액세스 검토 문서가 존재하는지만 확인하고 실제 검토 품질은 평가하지 않음. 검토 과정에서 발견된 예외사항과 해결 과정까지 확인해야 함
보상 통제 과대평가: 핵심 통제의 예외를 발견했을 때 보상 통제로 충분하다고 결론 내림. 보상 통제도 테스트하여 효과성을 입증해야 하며, 여전히 예외로 보고해야 함