2026년 개정 개인정보 보호법 — 개발팀이 바꿔야 할 것

한 문장 결론

2026.9.11.부터 유출이 확정되지 않은 “가능성” 단계에서도 72시간 이내 통지 의무가 생겼고 위조·변조·훼손도 통지 대상이 되었으므로, 개발팀은 탐지·영향 범위 산정·통지 파이프라인을 “확정 전” 단계부터 작동하도록 고쳐야 합니다. 개인정보 보호 인증 의무화는 2027.7.1. 시행 예정이며 현재 의무가 아닙니다.

적용 조건과 예외

시행일 구분

항목	조문	시행·적용	현재 의무인가
유출등 통지 범위 확대(위조·변조·훼손 포함), 통지 항목 추가	제34조제1항	2026.9.11. 이후 유출등을 알게 된 경우부터 (부칙 제2조제1항)	예
유출등 가능성 통지(신설)	제34조제2항	2026.9.11. 이후 가능성을 알게 된 경우부터 (부칙 제2조제2항)	예
피해 최소화 대책(회수·삭제 등 확산 방지 포함)	제34조제3항	2026.9.11. 이후 유출등이 된 경우부터 (부칙 제2조제3항)	예
유출등 신고	제34조제4항	2026.9.11. 이후 알게 된 경우부터 (부칙 제2조제1항)	예
사업주·대표자 책임	제30조의3	2026.9.11.	예
보호책임자 이사회 의결·신고, 업무 확대	제31조	2026.9.11. (기존 지정자 신고는 시행령 부칙 제2조에 따라 시행일부터 6개월 이내)	예
반복·중대 위반 과징금(매출액 10%)	제64조의2제2항	2026.9.11. (호별 적용례는 부칙 제3조)	예
과징금 감경	제64조의2제6항, 시행령 제60조의2제5항	2026.9.11.	예
보호책임자 관련 과태료	제75조제2항제14호의2~제14호의4	2026.9.11.	예
개인정보 보호 인증 의무화	제32조의2제1항 단서	2027.7.1. 시행 예정	아니오
인증 미취득 과태료	제75조제2항제15호	2027.7.1. 시행 예정	아니오

개정 이유(법제처 제공 제개정이유 요지)

대규모 유출사고가 잇따르면서 ① 반복적·중대한 침해에 대한 과징금 강화 ② 사업주·대표자 책임 명확화 ③ 보호책임자 권한·독립성 강화 ④ 일정 규모 이상 처리자의 인증 의무화 ⑤ 유출 가능성 통지제 도입을 목적으로 한다고 설명합니다.

과징금 적용례 (부칙 제3조)

• 제2항제1호(3년 내 반복): 시행 이후 발생한 위반으로 과징금 처분을 받은 뒤 다시 같은 호 위반을 한 경우부터
• 제2항제2호(1천만명 이상 피해): 시행 당시 종료되지 아니한 위반행위에도 적용
• 제2항제3호(시정조치 불이행 후 유출등): 시행 이후 시정조치 명령을 받은 경우부터

실제 법적 근거

제34조(개인정보 유출등의 통지·신고) — 개발 영향이 가장 큰 변경

• “유출등”의 정의 확대: 개정 전 제34조는 분실·도난·유출을 통지 대상으로 했으나, 개정법은 제23조제2항에서 “분실·도난·유출·위조·변조 또는 훼손”을 “유출등”으로 정의하고 제34조가 이를 사용합니다. 데이터 **무결성 침해(변조)와 가용성 침해(훼손)**도 통지 대상입니다.
• 제1항 통지 항목 (7개): ① 항목 ② 시점과 경위 ③ 피해 최소화를 위해 정보주체가 할 수 있는 방법 등 구체적인 정보 ④ 대응조치 및 피해 구제절차 ⑤ 신고 접수 담당부서·연락처 ⑥ 손해배상(제39조)·법정손해배상(제39조의2) 청구, 분쟁조정(제43조) 등 법적 권리와 행사 방법(신설) ⑦ 대통령령 사항(신설)
• 제2항 가능성 통지(신설): 개인정보의 유형, 영향, 위험 정도를 고려해 대통령령으로 정하는 가능성을 알게 되면 가능성이 있는 모든 정보주체에게 지체 없이 알려야 합니다.

시행령 — 통지·신고의 구체 기준

조문	내용
제39조제1항	유출등을 알게 되었을 때 서면등의 방법으로 72시간 이내 통지. 긴급 조치가 필요하거나 천재지변 등 부득이한 경우 사유 해소 후 즉시
제39조제2항	항목·시점·경위를 확인하지 못했으면 확인된 내용과 제3호~제6호 사항을 우선 통지, 추가 확인 즉시 통지
제39조제3항	연락처를 알 수 없는 등 정당한 사유가 있으면 홈페이지 30일 이상 게시로 갈음
제39조의2제1항	가능성 통지 대상: ① 개인정보처리시스템·업무용 기기에 불법적인 접근이 발생해 유출등이 의심되나 정보주체를 특정하기 곤란한 경우(불법 접근을 알게 된 때) ② 일부 개인정보가 제3자에 의해 거래되는 등 유출이 확인되어 다른 정보주체의 정보도 유출되었을 수 있는 경우(해당 사실을 알게 된 때)
제39조의2제2항	가능성 통지 사항: 가능성 있는 항목, 의심 시점·경위, 법 제34조제1항제3호~제5호, 확정 시 추가 통지하겠다는 사실
제39조의3	가능성을 안 때부터 72시간 이내 통지. 기한 내 실제 유출 확인 시 제34조제1항 통지로 갈음. 유출되지 않았음을 확인하면 즉시 그 사실도 통지. 연락처 불명 시 홈페이지 30일 이상 게시
제40조제1항	신고 대상: 1천명 이상, 민감정보·고유식별정보, 외부 불법 접근에 의한 유출등. 72시간 이내 보호위원회 또는 한국인터넷진흥원에 신고. 회수·삭제로 권익 침해 가능성이 현저히 낮아지면 신고하지 않을 수 있음

제30조의3, 제31조 — 조직 책임

• 제30조의3: 사업주 또는 대표자는 최종적인 책임자로서 전문 인력과 충분한 예산 지원 등 총괄적인 관리 조치를 실효성 있게 해야 합니다. 수탁자에게도 준용됩니다(제26조제8항).
• 제31조: 제1항 업무가 “처리 및 보호”를 “총괄해서 담당”하는 것으로 바뀌었고, 제3항에 따라 시행령 제32조제3항 기준(예: 연간 매출액등 1,800억원 초과이면서 5만명 이상 민감·고유식별정보 또는 100만명 이상 개인정보 처리, 재학생 2만명 이상 대학, 상급종합병원, 공공시스템운영기관)에 해당하면 이사회 의결과 보호위원회 신고(사유 발생일부터 6개월 이내)가 필요합니다. 제4항 업무에 전문 인력 관리·예산 확보, 대표자·이사회 보고가 추가되었습니다.
• 항 번호 이동: 종전 제31조제3항제9항이 제4항제10항이 되었습니다. 내부 문서·코드 주석에서 조문 번호를 인용했다면 갱신이 필요합니다.

제64조의2 — 과징금

• 제1항: 전체 매출액의 3% 이내(매출액 산정 곤란 시 20억원 이내). 제1항제9호는 유출등이 된 경우이나 제29조 안전조치를 다한 경우는 제외.
• 제2항(신설): 반복·중대 위반은 10% 이내(산정 곤란 시 50억원 이내).
• 제5항: 고려 사항에 “암호화 등 안전성 확보 조치 이행 노력”, “피해 회복 및 확산 방지 조치 이행 여부” 등이 있습니다.
• 제6항(신설): 보호 투자 등 대통령령 사유가 있으면 감경한다(고의·중과실 제외). 시행령 제60조의2제5항은 투자 규모·비율·지속성, 대표자 책임 이행, 보호책임자 조직 등을 고려해 보호위원회 고시 기준을 충족하는 경우로 정합니다. 고시 내용은 확인하지 못했습니다(review-required).

(법률 제21445호의 개정문·부칙과 대통령령 제36671호 현행 조문을 국가법령정보센터 원문과 대조함.)

개발자용 실무 해설

1. “확정 후 통지”에서 “의심 시점 기록”으로 바뀝니다. 가능성 통지 72시간은 불법 접근을 알게 된 때부터 셉니다. 보안 이벤트 시스템에 detected_at(최초 인지 시각)을 불변 필드로 남기지 않으면 기한 준수를 입증하기 어렵습니다.
2. 정보주체를 특정하지 못해도 “모든 가능성 있는 정보주체”에게 알려야 합니다. 침해된 시스템이 접근할 수 있었던 정보주체 범위를 빠르게 계산하는 쿼리를 미리 준비해 두세요. 이 범위 산정은 접속기록의 품질에 좌우됩니다.
3. 변조·훼손도 사고입니다. 무결성 검증(해시 체인, 감사 테이블), 백업 복구 기록이 사고 판단 근거가 됩니다.
4. 통지 템플릿을 갱신합니다. 제34조제1항제6호(손해배상·분쟁조정 안내)가 새로 들어갔습니다. 가능성 통지에는 “확정 시 추가 통지” 문구가 필요합니다(시행령 제39조의2제2항제4호).
5. “유출되지 않았음” 통지도 기능으로 만듭니다. 가능성 통지 후 유출이 아니라고 확인되면 즉시 알려야 합니다(시행령 제39조의3제3항).
6. 과징금 감경 요소는 증빙이 필요합니다. 보안 투자, 암호화, 접근통제 이행 내역을 감사 가능한 형태로 남기는 것이 실무적으로 중요해졌습니다. 구체 감경 기준은 고시 확인 전이라 review-required입니다.

권장 설계

SecurityIncident
├─ id
├─ detected_at          (불변, 최초 인지 시각 — 72시간 기준점)
├─ kind                 LEAK | LOSS | THEFT | FORGERY | ALTERATION | DAMAGE   ← "유출등" 6유형
├─ stage                SUSPECTED | CONFIRMED | RULED_OUT
├─ trigger              UNAUTHORIZED_ACCESS | THIRD_PARTY_TRADING | OTHER     ← 시행령 제39조의2제1항
├─ affected_scope_query (영향 범위 산정 쿼리 버전)
├─ subjects_estimated
├─ notices[]            {type: POSSIBILITY | BREACH | RULED_OUT, sent_at, channel, template_version}
└─ report               {required: bool, reason, submitted_at}               ← 시행령 제40조

• stage 전이를 이벤트로 남기고, SUSPECTED → CONFIRMED 전이 시 가능성 통지 대신 제34조제1항 통지를 보냅니다.
• 통지 템플릿은 버전 관리하고 7개 항목과 가능성 통지 4개 항목을 필수 필드로 검증합니다.
• 신고 필요 여부는 시행령 제40조제1항 3개 조건을 코드로 평가하되, 최종 판단은 보호책임자가 합니다.

위험한 설계

• 침해 의심 단계에서는 아무 기록도 남기지 않고 포렌식 완료 후 created_at을 인지 시각으로 사용
• 통지 대상을 “유출이 확인된 계정”으로만 한정하는 쿼리
• 변조·랜섬웨어로 인한 훼손을 “유출 아님”으로 분류해 통지 판단 절차에서 제외
• 통지 문구 템플릿을 개정 전 버전으로 유지(법적 권리 안내 누락)
• 2027.7.1. 시행 예정인 인증 의무를 현재 의무처럼 사내 문서에 기재하거나, 반대로 준비를 미룸

Python/TypeScript 구현 예제

# 72시간 기한 계산과 통지 유형 결정 (법 제34조, 시행령 제39조·제39조의2·제39조의3)
from datetime import datetime, timedelta
from enum import Enum

DEADLINE = timedelta(hours=72)

class Stage(str, Enum):
    SUSPECTED = "suspected"
    CONFIRMED = "confirmed"
    RULED_OUT = "ruled_out"

def notice_deadline(detected_at: datetime) -> datetime:
    return detected_at + DEADLINE

def required_notice(stage: Stage, possibility_notice_sent: bool) -> str | None:
    if stage is Stage.CONFIRMED:
        return "breach"            # 제34조제1항 (가능성 통지에 갈음 — 영 제39조의3제2항)
    if stage is Stage.SUSPECTED:
        return "possibility"       # 제34조제2항 (영 제39조의2 요건 충족 여부는 보호책임자 판단)
    if stage is Stage.RULED_OUT and possibility_notice_sent:
        return "ruled_out"         # 영 제39조의3제3항: 즉시
    return None

def report_required(subject_count: int, has_sensitive_or_unique: bool, external_attack: bool) -> bool:
    # 시행령 제40조제1항 각 호. 단서(회수·삭제로 위험 현저히 감소)는 사람이 판단
    return subject_count >= 1000 or has_sensitive_or_unique or external_attack

// 통지 템플릿 필수 항목 검증 (법 제34조제1항 각 호)
type BreachNotice = {
  items: string[];               // 1. 항목
  whenAndHow: string;            // 2. 시점과 경위
  selfProtection: string;        // 3. 구체적인 피해 최소화 방법
  responseAndRemedy: string;     // 4. 대응조치 및 피해 구제절차
  contact: string;               // 5. 담당부서·연락처
  legalRights: string;           // 6. 손해배상·법정손해배상·분쟁조정 안내 (2026 신설)
};

export function validateNotice(n: BreachNotice): string[] {
  return (Object.entries(n) as [keyof BreachNotice, unknown][])
    .filter(([, v]) => (Array.isArray(v) ? v.length === 0 : !String(v).trim()))
    .map(([k]) => `누락: ${k}`);
}

전체 흐름은 유출 대응과 구현 예제를 참고하세요.

개발 체크리스트

• 보안 이벤트에 최초 인지 시각(detected_at)을 불변으로 기록한다
• 유출등 6유형(분실·도난·유출·위조·변조·훼손)을 사고 분류에 반영했다
• 불법 접근 시 영향 가능 정보주체 범위를 산정하는 쿼리가 준비되어 있다
• 가능성 통지, 유출 통지, “유출 아님” 통지 템플릿이 모두 있다
• 통지 템플릿에 손해배상·분쟁조정 등 법적 권리 안내(제34조제1항제6호)가 있다
• 72시간 기한 알림이 보호책임자와 대응팀에 자동으로 간다
• 내부 문서의 제31조 항 번호 인용을 개정 후 번호로 갱신했다
• 보호책임자 이사회 의결·신고 대상(시행령 제32조제3항) 해당 여부를 확인했다
• 2027.7.1. 시행 예정 인증 의무 대상 여부는 시행령 기준 확정 후 재확인하도록 일정에 등록했다 (review-required)

공식 원문 링크와 확인일

아래 “근거 구분표”와 “공식 원문 링크”를 참고하세요. 법률 제21445호의 조문·개정문·부칙·제개정이유와 시행령 제36671호 조문은 2026-10-23에 국가법령정보센터 Open API로 확인했습니다. 인증 의무 대상 기준(2027.7.1. 시행 예정), 과징금 감경 고시, 유출등 대응 안내서의 절차는 원문 대조 전이라 review-required입니다.