본문 바로가기

개인정보 유출 및 침해사고 신고 체계, 유출 ‘가능성’ 단계 통지 의무화 대응

728x90

개인정보보호법 개정안 국회 통과 (2026.02.12)

핵심 변경사항

• 과징금 상한 대폭 상향 — 매출액 3% → 최대 10%
• 적용 조건: 3년 이내 반복 위반 또는 1,000만명 이상 피해 시
• 고의·중과실 또는 대규모 반복 침해 대상
• 유출 "가능성"만으로도 통지 의무화 — 초기 대응 강화
• CEO의 개인정보 보호 최종책임 명시
• CPO 역할·권한 강화 및 독립성 보장
• ISMS-P 인증 의무화 — 공공·민간 중요 개인정보처리자 대상
• 통지 항목에 손해배상 청구 안내 포함
시행 시기: 공포 후 6개월 (2026년 8월경 예상)
시사점
• 침해사고 발생 시 재무적 리스크가 크게 증가했으므로, 사전 예방 투자의 정당성이 더욱 강화됩니다.
• 유출 "가능성" 단계에서도 통지가 필요하므로, 탐지·대응 프로세스의 신속성이 더 중요해졌습니다.

과징금 상한 상향 → “사고 1건”이 아니라 “반복/대규모/중과실”의 재무 리스크화

  • 실무적으로는 재발방지·관리체계 부실(로그 미보존, 권한통제 미흡, 암호화/분리보관 부재, 사고대응 지연 등)이 “중과실” 해석으로 연결될 수 있어 증빙 중심 운영이 중요해집니다.

유출 “가능성” 단계 대응 강화 → “확정 전” 커뮤니케이션/신고 체계가 필요

  • 이제는 기술팀이 “확인 중”인 상태에서도 법정 타임라인이 움직일 수 있으므로,
    ① 탐지 → ② 1차 영향평가 → ③ 법무/CPO 판단 → ④ 신고/통지 초안 준비동시에 돌아가야 합니다.

CEO 최종 책임/CPO 독립성 → “보고 라인·결재 SLA”가 통제항목이 됨

  • 사고 발생 시 “누가, 언제, 어떤 근거로” 의사결정 했는지 결재선·회의록·상황일지가 곧 방어 자료가 됩니다.

ISMS-P 의무 확대 → “인증” 자체보다 사고 대응·로그·권한·위탁관리 등 통제가 실제로 돌아가는지

  • 유출/침해 대응이 문서만 있고 훈련이 없다면, 사고 시점에 바로 드러납니다. (훈련/테이블탑/증적이 핵심)

신고 체계의 큰 그림: “유출 신고”와 “침해사고 신고”는 별개 트랙

개인정보 유출 통지·신고(개인정보보호법)

  • 개인정보처리자는 유출등(분실·도난·유출)을 “알게 된 때” 지체 없이 정보주체 통지해야 하고, 통지 항목도 법에 열거돼 있습니다.
  • 또한 시행령은 특정 요건에 해당하면 72시간 이내 보호위원회 신고를 규정합니다.

포인트: “확정”이 아니라 “알게 된 때”(인지 시점) 기준으로 타임라인을 잡는 게 안전합니다.

침해사고 신고(정보통신망법 트랙: KISA)

  • 침해사고 신고는 “발생을 알게 된 때부터 24시간 이내” 신고가 원칙이며, 지연/미신고 시 과태료 근거까지 안내되어 있습니다.
  • KISA 신고 절차는 “신고서 작성(유형/기업정보/사고현황/대응현황 등) → 사실확인 → 접수 완료” 흐름으로 안내됩니다.
  • KISA는 “개인정보 유출 신고와 침해사고 신고를 각각 접수”해야 한다고 안내합니다.

개인정보 유출사고 신고 관점(72h 트랙) – 실무 표준 운영

“알게 된 때”를 내부적으로 어떻게 정의할 것인가

실무에서 분쟁이 생기는 지점이 여깁니다. 다음처럼 내부 기준을 명문화해두면 좋습니다.

  • 인지(알게 된 때) 후보 이벤트
    • DB/스토리지에 대한 비인가 접근 로그 확인
    • 개인정보가 있는 테이블/버킷에서 대량 조회·대량 다운로드·외부 전송 정황
    • 외부 유출 정황(다크웹/피싱/제3자 제보) 수신
    • 악성코드 감염 + 개인정보 저장영역 접근 가능성 확인
내부 정의(예시)
“개인정보가 포함된 시스템에서, 비인가 접근 또는 외부 반출의 정황이 합리적으로 인정되는 최초 시점”을 ‘알게 된 때’로 본다.

통지(정보주체) 구성요소

법 제34조는 통지에 포함할 항목을 명시합니다. (유출 항목, 시점/경위, 정보주체가 할 수 있는 조치, 처리자의 대응/구제절차, 담당부서/연락처 등)

300x250

개정안 취지상(사용자 제공 내용 포함) “손해배상 청구 안내”도 통지 템플릿에 반영되도록 정책/서식을 바꿔야 합니다.

72시간 신고(보호위원회) 준비물(현장 체크)

시행령 기준(72시간) 자체는 법·시행령 체계에 근거가 있으므로, 실제 운영에서는 아래를 “초기 6시간 안에” 확보하는 것을 표준으로 둡니다.

  • (필수) 사고 개요: 최초 탐지 시각, 탐지 경로, 영향 시스템
  • (필수) 개인정보 범주: 어떤 데이터(계정/연락처/주문/결제/식별정보 등)
  • (필수) 영향 범위 추정: 레코드/계정 수(추정치라도)
  • (필수) 조치 현황: 차단/격리/패치/계정잠금/키회전 등
  • (필수) 재발방지 계획(초안): 원인 가설 + 단기/중기 조치

침해사고 신고 관점(24h 트랙) – “가능성 단계 신고가 권장되는 이유”

KISA 안내 기준으로 24시간은 “발생을 알게 된 때부터”로 안내됩니다.
여기서 실무 포인트는, “발생”을 법원이 100% 확정으로만 보지 않는다는 점(통상적 해석/감독 실무) 때문에 합리적 의심 단계에서 신고하는 편이 안전하다는 것입니다.

KISA 신고서 작성 항목이 의미하는 것

KISA는 신고 단계에서 사고유형 선택, 기업/신고자 정보, 사고현황, 대응현황 등을 기입하도록 안내합니다.
즉, “확정된 RCA(근본원인)”까지 요구하는 구조가 아니라,

  • 현재까지 파악된 사실
  • 대응 중인 조치
  • 추가 업데이트 예정
    을 전제로 하는 폼입니다.

“개인정보 유출 신고”와 “침해사고 신고” 동시 운영

KISA는 두 신고를 각각 접수해야 한다고 명시합니다.
따라서 내부 표준은 이렇게 잡는 게 깔끔합니다.

  • 침해사고(24h): 해킹/악성코드/비인가 접근 “사건” 자체를 KISA 트랙으로
  • 개인정보 유출(72h): 개인정보가 유출됐거나 유출 가능성이 큰 경우를 PIPC 트랙으로(통지 포함)

“실제 유출이 아닌 가능성만으로도” 신고/통지하는 운영 모델

등급화(권장) – 가능성 단계의 의사결정 프레임

실제로는 “가능성”이 너무 넓어서 혼선이 생깁니다. 아래처럼 3단계로 나누면 판단이 빨라집니다.

  • L1(의심): 이상징후만 있음(오탐 가능성 큼)
    예) WAF 차단 급증, 단일 계정 로그인 실패 폭증
  • L2(강한 의심): 비인가 접근/권한탈취 정황 + 개인정보 영역 접점
    예) 관리자 세션 탈취 흔적 + DB 쿼리 로그 급증
  • L3(유출 개연성 높음): 외부 반출 정황 또는 외부 유통 증거
    예) 대량 다운로드/외부 전송, 다크웹 게시 제보

권장 트리거

  • 침해사고 신고(KISA): L2 이상이면 “선신고 + 추후 정정” 운영이 안전
  • 유출 통지/신고(PIPC): L3에 근접하거나, L2라도 영향이 대규모로 추정되면 즉시 준비 착수

이 접근은 “늦음 리스크(법정기한 초과)”를 줄이고, “오탐 리스크(불필요 신고)”는 정정/종결로 관리하는 방식입니다.

실제 유출이 아닌 것으로 확인되었을 때: “취소(철회)·정정·종결” 실무 절차

중요한 점부터 말하면, 현장에서는 보통 ‘완전 취소 버튼’ 개념보다는 ① 정정/추가 보고(업데이트) + ② 종결 처리 요청(오탐 판정 근거 제출) + ③ 내부 증적 보관으로 처리하는 경우가 많습니다.

공통 원칙(두 트랙 모두)

  1. 초기 신고는 유지(당시 합리적 근거가 있었다는 점을 남김)
  2. 오탐/미유출 결론이 나면 “정정/추가 보고”로 상태 업데이트
  3. 근거자료(타임라인, 로그, 포렌식 결과, 영향평가 보고서)를 첨부/보관
  4. 외부 커뮤니케이션(고객 통지/공지)이 이미 나갔다면 정정 공지 기준도 함께 운영

6-2. 침해사고(KISA) – 오탐 종결 흐름(권장 표준)

KISA 신고는 “사실확인” 단계가 포함된 절차로 안내됩니다.
따라서 오탐 결론 시 다음처럼 움직이면 실무적으로 매끄럽습니다.

  • (1) 오탐 결론 보고서 1장 요약
    • 탐지 이벤트
    • 분석 결과(침해 없음)
    • 영향 범위(0 또는 비개인정보 영향)
    • 재발방지(탐지 룰 튜닝/자산 설정 개선 등)
  • (2) KISA에 “정정/추가 정보 제출”
    • 기존 신고번호/접수정보 기준으로 “결론 업데이트”
  • (3) 종결 요청
    • “침해사고로 판단되지 않음” 또는 “사고 미발생(오탐)”으로 종결 의사 전달
  • (4) 내부 증적 보관
    • 24h 의무 준수 근거(인지 시점, 신고 시각)까지 포함

“24시간” 의무는 안내상 엄격하게 제시되어 있으므로, 오탐이어도 “늦게 신고”보다는 “신고 후 종결”이 방어에 유리한 편입니다. (실무 관행)

개인정보 유출(PIPC) – 오탐/미유출 시 정정 운영

  • 법 제34조는 ‘유출등이 되었음을 알게 되었을 때’ 통지를 규정하고, 시행령은 72시간 신고를 규정합니다.
  • 미유출 결론이 나면, 초기 판단 근거(“알게 된 때”의 합리성)를 유지하면서
    • 보호위원회 신고 내용 정정/추가 제출
    • 고객 통지를 이미 했다면 정정 통지(오탐/영향 없음, 문의 채널 유지)
    • 내부적으로는 “왜 가능성 판단이 나왔고, 왜 오탐이었는지”를 재발방지로 연결

침해사고 대응 프로세스 표준안(초안 템플릿)

아래는 “가능성 단계 신고/통지”까지 포함한 표준 운영 프로세스입니다.

역할(R&R) 표준

  • Incident Commander(IC): 보안팀장/보안책임자(상황 총괄)
  • Tech Lead: 인프라/개발/플랫폼(차단·복구 총괄)
  • Forensics/IR: 로그·포렌식·IOC 관리
  • CPO/Privacy: 유출 판단, 통지/신고 문구 검토
  • Legal: 리스크 평가, 대외 문구, 계약/위탁사 이슈
  • Comms/CS: 고객 공지/콜센터 스크립트
  • CEO 보고 라인: 정기 브리핑 SLA

타임라인 기반 표준(권장 SLA)

  • T+0~1h: 탐지/티켓 생성, 초기 분류(L1/L2/L3), 증거보존 시작
  • T+1~4h: 격리/차단, 영향 자산 식별, 1차 영향평가(추정치)
  • T+4~12h: 신고/통지 트리거 결정(법무/CPO), 초안 작성
  • T+24h 이내: (해당 시) KISA 침해사고 신고
  • T+72h 이내: (해당 시) PIPC 유출 신고(시행령 기준)
  • T+3~7d: RCA/재발방지, 대외 커뮤니케이션 마무리, 종결/정정 처리

프로세스 플로우(텍스트 다이어그램)

[탐지] → [분류 L1/L2/L3] → [증거보존(로그/메모리/디스크/계정)]
   → [격리/차단] → [1차 영향평가(PII 접점? 외부반출?)]
      → (L2+) [KISA 선신고 + 추후 정정]  (24h 트랙)
      → (L3 or 대규모) [PIPC 신고/정보주체 통지 준비] (72h 트랙)
         → [조사 심화/포렌식]
            → [유출 확정]  → [정식 통지/추가 신고/공급망 포함]
            → [미유출(오탐)] → [정정/종결 + 내부 재발방지]

내부 보안 정책 개정 가이드(이번 개정안 반영 포인트)

반드시 고쳐야 하는 문서(최소 6종)

  1. 침해사고 대응 정책/지침(정의·역할·보고 SLA)
  2. 개인정보 유출 대응 지침(인지 기준, 72h, 통지 항목 템플릿)
  3. 대외 커뮤니케이션 정책(공지/FAQ/CS 스크립트 승인 체계)
  4. 로그 보존/증거보존 정책(법적 방어용 증적)
  5. 권한관리 정책(관리자 계정/DB 접근/키관리)
  6. 위탁사/협력사 보안관리 지침(공급망 사고 대응 포함)

조항에 넣어야 하는 “문구” 핵심(예시)

  • “알게 된 때” 정의(내부 기준)
  • L1/L2/L3 분류 및 각 단계별 신고/보고 트리거
  • CEO/CPO 보고 SLA(예: L2 이상 2시간 내 1차 보고)
  • “선신고 후 정정/종결” 원칙 및 증빙 요건(타임라인, 로그, 분석보고서)

문서 템플릿(필수)

  • 상황일지(타임라인)
  • 영향평가표(개인정보 유형/대상/추정 건수/근거)
  • 신고/통지 초안(버전 관리)
  • 오탐/미유출 종결보고서(1~3p)

법무 협업 체크리스트(실무용)

“초기 6시간” 법무 체크(결정 지연 방지)

  • 이 사건이 침해사고 신고 대상인지(24h 트랙)
  • 개인정보가 개입됐는지(PII 접점) / 통지 의무 가능성(34조 항목)
  • “알게 된 때”를 무엇으로 잡을지(증거 기반)
  • 공지/언론 대응 필요 여부(2차 피해 유발 방지)
  • 수사기관 신고/협조 필요성(사안별)

고객 통지 문구 검토 포인트(분쟁 예방)

  • “확정된 사실”과 “추정”을 문장으로 분리
  • 정보주체가 할 수 있는 조치(비밀번호 변경/2FA/피싱 주의 등) 포함
  • 문의 채널(담당부서/연락처) 명시
  • 향후 업데이트 약속(예: 조사 완료 시 추가 안내)

오탐(미유출) 정정 시 법무 체크

  • 초기 신고/통지의 “합리적 근거”가 문서로 남아있는가
  • 정정 공지 시 오해 소지(축소/은폐로 보일 표현) 제거
  • 종결보고서에 기술적 근거(로그/포렌식 결과)가 포함됐는가

“사내 표준” 배포용 패키지(문서 4종)

  1. 침해사고 대응 표준절차서(SOP) v1
  2. 유출/침해 신고·통지 템플릿(초안/정정/종결)
  3. 정책 개정 체크리스트(조항 매핑표)
  4. 법무/커뮤니케이션 승인 플로우차트
728x90
그리드형(광고전용)

댓글