최초 인증을 준비하는 조직에서 일정이 늘어지는 이유는 비슷합니다. 문서를 먼저 만들고 운영을 나중에 맞추려 하기 때문입니다.
1. 인증 범위를 먼저 확정한다
범위가 흔들리면 이후 모든 산출물이 다시 만들어집니다. 서비스 단위, 조직 단위, 자산(서버·네트워크·개인정보 처리 시스템) 단위로 경계를 그리고, 경계 밖 시스템과의 연계 지점을 목록화하는 것이 첫 작업입니다. 범위를 넓게 잡으면 심사 부담이 커지고, 너무 좁게 잡으면 실제 위험이 빠진 인증이 됩니다.
2. 문서보다 운영 기록이 먼저다
심사에서 확인하는 것은 "정책이 있는가"가 아니라 "정책대로 운영된 기록이 있는가"입니다. 접근권한 검토 이력, 변경 승인 기록, 백업 복구 시험 결과처럼 시간이 쌓여야 생기는 증적은 나중에 만들 수 없습니다. 준비 초기에 이런 활동을 먼저 시작해야 일정이 줄어듭니다.
3. 위험평가는 형식이 아니라 판단이다
자산 목록에 숫자만 채운 위험평가는 심사에서 반드시 질문을 받습니다. 위협·취약점 식별의 근거, 위험도 산정 기준, 수용 가능한 위험 수준(DoA)의 결정 주체가 설명 가능해야 합니다. 기술 취약점 진단 결과가 위험평가에 반영되어 있는지도 자주 확인되는 지점입니다.
4. 기술 진단과 관리체계를 분리하지 않는다
관리체계 컨설팅과 취약점 진단을 별도로 진행하면, 진단에서 나온 취약점이 위험평가와 조치 계획에 반영되지 않는 경우가 많습니다. 심사에서는 통과하더라도, 실제 침해 경로는 그대로 남습니다.
준비 체크리스트
- 인증 범위와 경계 연계 지점 목록이 문서로 존재한다
- 정책·지침이 실제 업무 절차와 일치한다(현실과 다른 조항이 없다)
- 최근 6개월 이상의 운영 기록(권한 검토·변경 관리·로그 점검)이 남아 있다
- 기술 취약점 진단 결과가 위험평가와 조치 계획에 연결되어 있다
- 개인정보 처리 흐름도가 최신 시스템 구성과 일치한다
인증 의무 대상 여부와 준비 기간은 조직 상황에 따라 다릅니다. 현재 상태를 기준으로 필요한 작업만 정리해 보고 싶다면 상담을 요청해 주세요.