'유출 가능성'만으로 통지해야 하는 시대 — 9·11 개정 개인정보보호법, 발주 요구사항부터 바꿔야 합니다

'유출을 확인한 뒤 통지'가 아니라 '가능성만으로 통지'입니다

개인정보보호위원회 보도자료(대한민국 정책브리핑, korea.kr, 2026.3)에 따르면 개정 「개인정보 보호법」은 2026년 3월 10일 공포되어 2026년 9월 11일 시행됩니다. 이번 개정의 무게 중심은 '유출 가능성 통지제' 신설에 있습니다. 종전에는 유출 사실이 실제로 확인된 뒤 통지·신고 의무가 발생했다면, 개정법은 유출 가능성을 인지한 단계에서 이미 정보주체에게 그 사실과 피해 최소화 정보를 지체 없이 알리도록 의무화했습니다.

이 한 문장이 서비스 설계에 미치는 파장은 생각보다 큽니다. '가능성 단계'에서 통지하려면, 무언가 이상하다는 신호를 조직이 빠르게 포착하고, 근거를 재구성하고, 대상자를 특정할 수 있어야 합니다. 로그가 없고 접근통제가 느슨하며 이상탐지가 없는 서비스는 '가능성'을 판단할 재료 자체가 없습니다. 결국 이번 개정은 컴플라이언스 부서의 문서 작업이 아니라, 지금 개발·운영 중인 시스템의 기술 요구사항을 바꾸는 사건입니다.

세 개의 축이 왜 '경영 리스크'로 연결되는가

1) 가능성 통지 — 로그·접근통제·이상탐지가 전제조건이 됩니다

'유출 가능성'을 판단하려면 먼저 무슨 일이 있었는지 되짚을 수 있어야 합니다. 누가, 언제, 어떤 데이터에, 어떤 경로로 접근했는지 남아 있지 않으면 가능성 여부도, 통지 대상 범위도 확정할 수 없습니다. 지체 없는 통지가 의무인 만큼, 사고 인지에서 대상자 특정까지의 시간이 곧 리스크가 됩니다. 로깅과 이상탐지는 이제 '있으면 좋은 것'이 아니라 통지 의무를 이행하기 위한 기반 설비입니다.

2) 대표이사 최종책임·CPO 이사회 신고 — 리스크가 경영진 테이블로 올라갑니다

개정법은 대표자(CEO)를 개인정보 처리·보호의 최종책임자로 명시해 관리·감독 의무를 부여했고, 일정 규모 이상 개인정보처리자는 CPO의 지정·변경·해제 시 이사회 의결을 거쳐 위원회에 신고하도록 했습니다(개인정보보호위원회, 2026.3). 개인정보 사고가 실무자 선에서 수습되는 사안이 아니라 이사회와 대표가 직접 책임지는 사안이 되었다는 뜻입니다. 동시에 개정법은 반복·중대한 침해에 대한 징벌적 과징금을 도입하면서, 예산·인력·설비 등 사전예방 투자를 과징금 감경 사유로 반영하는 인센티브도 함께 두었습니다. 사전에 제대로 설계에 투자했는지가 사후 처분의 크기까지 좌우하는 구조입니다.

3) ISMS-P 의무화 — 시행일은 뒤지만 준비는 지금부터입니다

공공·민간 주요 개인정보처리자에 대해 ISMS-P(개인정보보호 인증) 취득이 의무화됩니다. 다만 이 규정의 시행일은 예산 확보 기간 등을 고려해 2027년 7월 1일입니다(개인정보보호위원회, 2026.3). 시행이 뒤라고 해서 여유가 있는 것은 아닙니다. 인증 요구사항의 상당 부분이 로그 관리·접근통제·침해 대응 체계처럼 서비스 아키텍처에 녹아 있어야 하는 항목이라, 완성된 서비스에 나중에 덧붙이면 훨씬 비싸집니다. 신규개발·리뉴얼을 앞둔 발주사라면 지금 설계 단계에서 인증 요건을 요구사항으로 넣는 편이 유리합니다.

9·11 이전에 점검할 실무 체크리스트

발주사가 자사 서비스와 외주 프로젝트 양쪽에서 시행 전에 확인할 항목을 정리하면 다음과 같습니다.

• 로깅 범위: 개인정보에 접근하는 모든 경로(관리자 페이지, 내부 API, DB 직접 조회, 배치·데이터 추출)에 대해 '누가·언제·무엇을' 남기고 있는가. 로그가 위·변조되지 않도록 보관되는가.
• 접근통제: 권한이 역할 기준으로 최소화되어 있는가. 퇴사자·협력사 계정, 공용 관리자 계정이 방치되어 있지 않은가.
• 이상탐지: 대량 조회·비정상 시간대 접근·평소와 다른 대량 다운로드 같은 신호를 감지하고 알릴 수 있는가. '가능성'을 판단할 트리거가 있는가.
• 유출통지 워크플로우: 이상 신호 인지 → 영향 범위·대상자 특정 → 통지문 작성·발송 → 위원회 신고까지의 절차가 문서와 담당자, 가능하면 자동화까지 갖춰져 있는가. '지체 없이'를 실제로 이행할 수 있는가.
• 거버넌스: CPO가 지정되어 있고, 규모에 따라 이사회 의결·신고 절차를 이행할 준비가 되어 있는가. 사고 시 대표에게 언제 보고되는지 정해져 있는가.
• 외주 계약: 신규·리뉴얼 발주 요구사항(RFP)에 로깅·접근통제·이상탐지·ISMS-P 요건이 명시되어 있는가. 개발사와의 책임 분담이 계약에 정리되어 있는가.

마무리: 컴플라이언스가 아니라 요구사항입니다

이번 개정의 핵심은 '통지 시점'이 앞당겨졌다는 사실이 아니라, 그 시점을 지키기 위해 서비스가 스스로 자기 상태를 설명할 수 있어야 한다는 요구입니다. 로그가 없으면 가능성을 판단할 수 없고, 접근통제가 없으면 범위를 좁힐 수 없으며, 워크플로우가 없으면 지체 없이 통지할 수 없습니다. 그리고 그 결과는 실무자가 아니라 대표와 이사회가 책임집니다.

9월 11일은 정해진 날짜이고, 준비되지 않은 조직에게도 똑같이 찾아옵니다. 지금 개발·운영 중인 서비스, 그리고 앞으로 발주할 프로젝트의 요구사항을 이 관점에서 다시 점검할 시점입니다. FIRSTPIP은 신규개발과 리뉴얼 과정에서 이러한 요건을 설계 단계에 반영해, 시행 이후 '나중에 붙이는' 비용을 줄이는 방향을 함께 고민합니다.