기준이 '유출 확인'에서 '유출 가능성'으로 옮겨졌습니다
지금까지 많은 조직이 침해 사고를 다루는 방식은 비슷했습니다. 이상 징후를 발견하면 내부에서 원인을 분석하고, 실제로 개인정보가 외부로 나갔는지 확정한 다음에야 통지 절차를 시작했습니다. 확정 전 통지는 불필요한 혼란을 만든다는 판단이 깔려 있었습니다.
문제는 이 관행이 규제 방향과 점점 어긋난다는 점입니다. 개인정보 보호법상 유출 통지·신고는 유출 등을 알게 되었을 때 72시간 이내에 이뤄져야 하는데, 여기서 '알게 된 시점'은 유출 사실을 최종 확정한 시점이 아닙니다. 유출이 있었다고 볼 만한 정황을 인지한 시점에 이미 시계는 돌아가기 시작합니다. 조사에 2주가 걸렸다는 사정은 통지 지연을 정당화해 주지 않습니다.
실무에서 조직이 겪는 딜레마는 두 방향입니다.
어느 쪽도 사고가 터진 다음에 즉흥적으로 조율할 수 있는 문제가 아닙니다. 어떤 정황을 통지 검토 대상으로 볼 것인지, 판단 기준선을 사전에 문서로 정해두는 작업이 사실상 유일한 해법입니다. 예를 들어 "권한 밖 계정이 개인정보 테이블을 1건이라도 조회한 흔적" 같은 기준은 명확하고, "관리자 계정에서 평소보다 많은 다운로드가 있었다" 같은 기준은 모호합니다. 모호한 기준은 사고 당일에 반드시 논쟁을 만듭니다.
통지 판단을 가능하게 하는 시스템 요건
기준을 세워도 시스템이 답을 주지 못하면 소용이 없습니다. 다음 네 가지를 점검해 보시기 바랍니다.
1. 로그가 실제로 남아 있는가
많은 조직이 "로그는 남고 있습니다"라고 답하지만, 실제로 확인해 보면 애플리케이션 접속 로그만 있고 조회·다운로드 단위 로그는 없는 경우가 흔합니다. 접속 기록은 누가 들어왔는지만 알려줄 뿐, 무엇을 얼마나 봤는지는 알려주지 않습니다. 통지 판단에는 후자가 필요합니다.
최소한 다음이 기록되어야 합니다.
2. 최소한의 탐지 규칙
정교한 UEBA 도입 이전에도, 규칙 3~5개만으로 대부분의 실사고 정황이 걸립니다.
3. 보존 기간과 무결성
개인정보 처리시스템의 접속기록은 최소 1년(고유식별정보·민감정보를 처리하거나 5만 명 이상 정보주체의 개인정보를 처리하는 경우 2년) 이상 보관해야 합니다. 여기서 자주 놓치는 것이 무결성입니다. 운영 서버 로컬 디스크에만 로그가 있고 운영자가 삭제·수정할 수 있다면, 사고 후 재구성에 대한 신뢰를 얻기 어렵습니다. 별도 수집 서버로의 전송, 쓰기 전용 스토리지, 해시 기반 위·변조 검증 중 하나는 갖춰져 있어야 합니다.
4. 영향받은 정보주체를 빨리 뽑을 수 있는 구조
72시간 안에 답해야 하는 질문은 결국 "누가, 어떤 항목이 노출됐는가"입니다. 개인정보가 여러 테이블에 흩어져 있고 식별자 연결이 불완전하면 이 질문에 며칠이 걸립니다. 조회 로그에 결과 레코드의 식별자 범위가 남아 있으면 산출 시간이 시간 단위로 줄어듭니다.
CPO 책임과 조직 프로세스 정비
개인정보 보호책임자(CPO)의 독립성과 역할이 강화되면서, 통지 여부 판단이 실무자 개인의 부담으로 남아 있는 구조는 위험합니다. 최소한 다음이 정해져 있어야 합니다.
협력사·클라우드·SaaS 경유 사고도 같은 무게로 다뤄야 합니다. 수탁사에서 사고가 나도 위탁자의 통지 의무는 사라지지 않습니다. 계약서에 인지 후 24시간 내 위탁자 통보 의무와 담당자 연락처, 로그 제공 범위를 명시해 두지 않으면, 정작 사고가 났을 때 수탁사 회신을 기다리다 시간을 다 씁니다.
과징금 리스크를 낮추는 실질 투자
과징금 산정에서 사후 대응만큼이나 크게 평가받는 것이 사전 통제의 존재 여부입니다. 사고 자체를 100% 막을 수는 없지만, 통제가 설계·운영되고 있었다는 사실은 감경 요소로 작동합니다.
오래된 시스템에서 반복적으로 발견되는 취약점은 대체로 정해져 있습니다.
투자했다는 사실은 증빙으로 남아야 의미가 있습니다. 권한 검토 회의록, 분기별 계정 정리 이력, 취약점 점검 보고서, 교육 이수 기록을 날짜와 함께 보관하시기 바랍니다.
90일 점검 로드맵
전면 재구축 없이도 실행 가능한 순서를 제안합니다.
1단계 (1~30일) — 흐름도와 보유 현황 재확인
어떤 시스템이 어떤 개인정보를 보유하는지 목록화합니다. 대상은 운영 DB만이 아니라 백업, 로그 저장소, 데이터 웨어하우스, 협력사 전송분까지 포함합니다. 이 단계에서 "쓰지 않는데 남아 있는 데이터"를 파기하는 것만으로 위험 범위가 크게 줄어듭니다.
2단계 (31~60일) — 로그와 탐지 보완
조회·다운로드 로그를 추가하고, 앞서 언급한 탐지 규칙 3~5개를 적용합니다. 완벽한 SIEM이 아니어도 알림 채널만 붙이면 됩니다.
3단계 (61~90일) — 통지 시나리오 훈련
가상의 정황을 놓고 실제로 타이머를 켜 봅니다. 탐지부터 통지문 초안까지 몇 시간이 걸리는지 측정하면, 남은 병목이 기술인지 의사결정인지 분명해집니다.
우선순위는 명확합니다. 로그와 계정 통제가 접근 통제 고도화보다 먼저입니다. 무슨 일이 있었는지 설명하지 못하는 상태가 가장 큰 리스크이기 때문입니다.
POLYGLOTSOFT가 도와드립니다
POLYGLOTSOFT는 레거시 시스템을 전면 교체하지 않고도 규제 요구사항을 충족시키는 접근을 택합니다. 개인정보 흐름도 작성과 보유 현황 진단, 조회·다운로드 로그 계층 추가, 탐지 규칙 설계, 통지 프로세스 문서화까지 단계적으로 지원합니다. 구축 이후에는 유지보수(SM) 플랜을 통해 로그 모니터링과 정기 점검을 이어가며, 감사 대응에 필요한 증빙을 축적해 드립니다. 시스템 진단이 필요하시면 [문의하기](https://polyglotsoft.dev/ko/support/contact)로 연락해 주시기 바랍니다.