ISMS-P 위험평가 방법론: 보안팀을 위한 실전 가이드
인증 심사일이 3개월 앞으로 다가왔는데, 위험평가 보고서가 아직 초안 단계라면 어떻게 접근해야 할까요? 많은 보안팀이 위험평가를 "해마다 해야 하는 문서 작업"으로 인식하지만, ISMS-P 인증기준 2.1.1(정보보호 위험관리)은 조직의 실제 위험 현황을 반영한 체계적인 프로세스를 요구합니다. 서류를 채우는 것과 프로세스를 운영하는 것은 다릅니다.
위험평가, 어디서부터 시작해야 하는가
위험평가의 출발점은 위험관리 방법론 문서화입니다. 인증기준 2.1.1은 조직이 위험평가 방법론을 직접 정의하고 경영진 승인을 받도록 명시하고 있습니다. 방법론을 정의하지 않은 상태에서 위험평가 결과물만 제출하면 심사 현장에서 즉각적인 결함 지적을 받습니다.
방법론 문서에는 최소한 다음 내용이 포함되어야 합니다.
- 위험 산출 공식: 위험도 = 자산 가치 × 위협 빈도 × 취약점 수준 (또는 조직이 정의한 산출 방식)
- 위험 수용 기준: 위험도 몇 점 이상을 수용 불가로 볼 것인지 수치로 명시
- 평가 주기: 연 1회 이상 수행, 중대한 변경 발생 시 재평가 조건 포함
방법론이 확정되어야 이후 단계의 결과물이 일관성을 가집니다.
1단계: 자산식별 — 범위를 좁혀야 깊이가 생긴다
자산식별은 "보유한 모든 자산을 목록화"하는 작업이 아닙니다. ISMS-P 인증 범위 내에서 개인정보 처리에 관여하거나 서비스 연속성에 영향을 주는 자산을 선별하는 작업입니다.
실무에서 자산 목록이 수백 줄로 늘어나는 이유는 범위 설정 없이 IT 인벤토리 전체를 붙여 넣기 때문입니다. 자산은 정보자산(DB, 파일, 로그), 시스템(서버, 네트워크 장비), 서비스, 인력, 시설 5개 유형으로 분류하고, 각 자산에 기밀성·무결성·가용성 기준으로 가치를 3~5점 척도로 산정하세요.
산출물: 자산목록 대장 (자산ID, 자산명, 유형, 담당부서, 자산가치, 개인정보 처리 여부)
2단계: 위협 및 취약점 분석 — 통계가 아닌 조직 환경 기반으로
위협 목록을 ISO/IEC 27005 부록이나 NIST SP 800-30에서 그대로 가져오는 팀이 많습니다. 하지만 심사위원은 해당 위협이 조직 환경과 실제로 연결되는지를 확인합니다.
위협 분석 시에는 조직이 최근 1~2년 내 경험한 보안 이벤트(로그 기반), 동종 업계 침해 사고 사례(KISA 침해사고 통계 등 활용), 주요 서비스의 외부 노출 경로를 기반으로 위협을 선별하세요.
취약점 분석은 기술적 취약점(모의해킹·취약점 점검 결과)과 관리적 취약점(내부 감사 결과, 이전 심사 결함 항목)을 구분해서 정리해야 합니다. 두 유형을 혼합하면 위험 처리 계획을 수립할 때 담당 부서 배정이 어려워집니다.
산출물: 위협·취약점 매트릭스 (자산별 위협-취약점 매핑 테이블)
3단계: 위험도 산정 및 수용 여부 결정
위험도를 산정했다면 경영진 보고 전에 반드시 위험 수용 기준과 대조해야 합니다. 수용 불가 위험은 위험 처리 계획(회피·감소·전가·수용)을 수립하고, 처리 방안별 담당자와 이행 기한을 명기해야 합니다.
이행 기한 없이 "추후 개선"으로 남긴 항목은 다음 심사에서 반복 결함으로 이어집니다. 기한은 인증 심사일 기준 최소 2개월 이전으로 설정하는 것이 안전합니다.
인증기준 2.1.2(위험 처리 및 모니터링)는 잔여 위험에 대한 경영진 승인도 별도로 요구합니다. 위험 수용을 결정했다면 경영진 서명이 포함된 문서를 반드시 보존하세요.
산출물: 위험평가 결과 보고서, 위험 처리 계획서, 잔여 위험 수용 승인서
실무에서 자주 발생하는 오류 2가지
① 전년도 위험평가 결과를 그대로 복사
신규 시스템 도입, 조직 변경, 서비스 개편이 있었음에도 자산목록과 위협 목록을 갱신하지 않은 경우 심사에서 형식적 운영으로 판단됩니다. 자산목록 최종 수정일이 위험평가 실시일과 일치해야 합니다.
② 위험 처리 계획과 실제 이행 간 불일치
계획서에는 "암호화 적용 예정"으로 기재했지만 심사 시점에 미이행 상태인 경우, 결함이 아닌 중결함으로 분류될 수 있습니다. 위험 처리 이행 현황은 별도 추적 대장으로 관리하고, 분기 단위로 현행화하세요.
위험평가 주기와 재평가 트리거
ISMS-P는 연 1회 이상 위험평가를 요구하지만, 다음 상황에서는 주기와 무관하게 재평가가 필요합니다.
- 신규 개인정보 처리 시스템 도입
- 클라우드 전환 또는 외부 위탁 계약 변경
- 중대한 보안 사고 발생
- 인증 범위 변경
재평가 기준을 내부 규정에 명문화해 두지 않으면, 변경이 발생했을 때 재평가 여부를 두고 팀 내 혼선이 생깁니다.
위험평가는 문서 생산이 아니라 의사결정 프로세스입니다. 위험평가 결과가 실제 보안 투자 우선순위와 연결되지 않는다면, 다음 심사에서도 같은 결함이 반복됩니다.
위험평가 방법론 수립부터 결과 보고서 작성까지 시간을 단축하고 싶다면, ComplixShield의 위험평가 자동화 기능이 프로세스 전 단계를 구조화하는 데 실질적인 도움이 됩니다.