같은 규모인데 어떤 조직은 6개월 만에 심사를 받고, 어떤 조직은 1년 반이 걸립니다. 무엇이 이 차이를 만들까요? 문서를 얼마나 갖췄느냐보다 지금 남아 있는 운영 기록과 범위가 정해졌는지가 기간을 가릅니다. 컨설팅을 부르기 전에 아래부터 확인해 보세요.
“아니오”가 많아도 괜찮습니다. 일정을 현실적으로 잡는 데 필요한 정보일 뿐입니다.
채워서 가져오시면 첫 미팅을 자료 요청부터 시작하지 않아도 됩니다.
A. 범위
- 인증을 받을 서비스와 조직의 경계가 문장으로 적혀 있다. “회사 전체”는 범위가 아닙니다. 어느 서비스의 어느 조직까지인지 문장으로 나와야 합니다.
- 범위 안 자산 목록(서버·네트워크·애플리케이션·개인정보 처리 시스템)이 최신이다.
- 범위 밖 시스템과의 연계 지점이 파악되어 있다. 심사에서 거의 빠짐없이 묻는 지점입니다. 연계 구간이 비어 있으면 범위를 아무리 좁혀도 소용이 없습니다.
- 클라우드·SaaS 사용 현황이 목록화되어 있다.
B. 문서
- 정보보호 정책·지침이 존재한다.
- 그 문서의 내용이 실제 업무 절차와 일치한다. 여기서 “아니오”라면 새로 쓰는 일보다 안 지키는 조항을 걷어내는 일이 먼저입니다.
- 문서에 제정·개정 이력과 승인 흔적이 남아 있다.
- 담당자가 바뀌어도 찾을 수 있는 위치에 보관되어 있다.
C. 운영 기록 — 기간이 가장 크게 갈리는 항목
정책 문서는 급하면 몇 주 안에 정비할 수 있습니다. 반면 접근권한 검토 기록은 검토를 한 번 돌려야 생기고, 반기마다 하기로 정했다면 그 반기를 기다려야 합니다. 아래에서 비어 있는 항목은 준비 기간에 그만큼 얹힌다고 보시면 됩니다.
- 최근 접근권한 검토를 수행하고 기록을 남긴 적이 있다.
- 변경 관리(시스템 변경 요청·승인·적용) 기록이 남아 있다.
- 접속기록을 보관하고, 주기적으로 점검한 흔적이 있다.
- 백업 복구 시험을 수행하고 결과를 기록한 적이 있다.
- 보안 교육을 실시하고 참석 기록이 있다.
- 취약점 점검을 수행하고 조치 결과를 기록한 적이 있다.
D. 위험평가
- 위험평가를 수행한 적이 있고, 산정 기준이 문서로 있다.
- 수용 가능한 위험 수준(DoA)을 누가 결정했는지 설명할 수 있다.
- 위험평가 결과가 조치 계획으로 이어졌고 이행 상태를 추적하고 있다.
- 기술 취약점 진단 결과가 위험평가에 반영되어 있다. 진단과 관리체계를 다른 업체가 맡으면 이 연결이 자주 끊깁니다.
E. 개인정보 (ISMS-P를 받는 경우)
- 개인정보 처리 흐름(수집→저장→이용→제공/위탁→파기)이 그려져 있다.
- 수집 항목별 법적 근거를 설명할 수 있다.
- 위탁·재위탁 현황이 목록화되어 있고 계약서에 필수 조항이 있다.
- 국외이전(해외 클라우드·SaaS 포함) 현황이 파악되어 있다.
- 처리방침이 현재 실제 처리와 일치한다.
F. 조직과 일정
- 보안 담당자가 지정되어 있고, 업무 시간이 확보되어 있다. 겸직이어도 됩니다. 다만 “아무도 없음”이면 컨설턴트가 대신 결정할 수 없는 일들이 계속 미뤄집니다.
- 경영진이 의사결정에 참여할 수 있다(위험 수용 결정 등).
- 시스템 담당 조직이 인터뷰와 조치에 협조 가능하다.
- 목표 심사 시점이 정해져 있다면, 그 날짜가 고정인지 조정 가능한지 안다.
결과를 어떻게 읽을까
C(운영 기록)에서 “아니오”가 셋 이상이면 문서부터 손대지 마세요. 기록이 쌓이기 시작해야 전체 일정이 줄어듭니다. A(범위)에 “아니오”가 하나라도 있으면 순서는 더 단순합니다. 범위를 먼저 닫습니다. 그러지 않으면 정책도 위험평가도 두 번 만들게 됩니다.
채운 목록을 그대로 붙여서 보내 주시면 첫 회신에서 기간과 순서를 훨씬 구체적으로 짚어 드릴 수 있습니다.
의무 대상인지 아닌지부터 애매하시면 매출 규모와 이용자 수, 업종을 함께 적어 보내 주세요.
어느 조문 때문에 그렇게 판단했는지까지 밝혀서 답을 드립니다.