개인정보 유출등 대응 — 72시간 통지·신고와 탐지 자동화

한 문장 결론

유출등을 알게 된 때부터 72시간이 통지·신고 시계의 기준입니다. 확인된 내용이 부족해도 우선 통지·신고 후 추가 통지하도록 되어 있으므로, 탐지 → 영향 범위 산정 → 통지문 생성 → 발송·신고 기록까지를 미리 자동화해 두어야 합니다.

적용 조건과 예외

용어: 2026.3.10. 개정법은 “분실ㆍ도난ㆍ유출ㆍ위조ㆍ변조 또는 훼손”을 **“유출등”**으로 묶었습니다(법 제23조제2항). 외부 유출뿐 아니라 위·변조, 훼손(삭제·랜섬웨어 암호화 등)도 포함될 수 있다는 점이 설계에 중요합니다. 구체적 사례가 유출등에 해당하는지는 안내서와 법무 판단이 필요합니다(review-required).

구분	언제	누구에게	기한	근거
유출등 통지	유출등이 되었음을 알게 되었을 때	해당 정보주체 (규모 무관)	지체 없이, 72시간 이내 서면등의 방법	법 제34조제1항, 시행령 제39조제1항
우선 통지	항목(1호)·시점과 경위(2호)를 구체적으로 확인하지 못한 경우	정보주체	유출등 사실, 확인된 내용, 3~6호 사항 우선 통지, 추가 확인 즉시 통지	시행령 제39조제2항
유출등 가능성 통지	① 불법 접근으로 유출등이 의심되나 정보주체 특정이 곤란한 경우: 불법 접근을 알게 된 때 ② 일부 유출(제3자 거래 등)이 확인되어 다른 정보주체도 유출되었을 수 있는 경우: 그 사실을 알게 된 때	가능성이 있는 모든 정보주체	72시간 이내 서면등의 방법	법 제34조제2항, 시행령 제39조의2, 제39조의3
신고	① 1천명 이상 ② 민감정보 또는 고유식별정보 ③ 외부로부터의 불법적인 접근에 의한 유출등 중 하나	보호위원회 또는 한국인터넷진흥원	72시간 이내 서면등의 방법	법 제34조제4항, 시행령 제40조
노출 삭제·차단	정보통신망으로 공중에 노출된 경우 + 보호위원회 또는 한국인터넷진흥원 요청	—	요청 시 삭제·차단	법 제34조의2, 시행령 제40조의2

예외와 경계:

• 통지 지연 사유(시행령 제39조제1항 단서): 확산·추가 유출 방지를 위한 접속경로 차단, 취약점 점검·보완, 회수·삭제 등 긴급 조치가 필요한 경우, 천재지변 등 부득이한 사유가 있는 경우에는 사유 해소 후 즉시 통지할 수 있습니다.
• 통지 갈음(시행령 제39조제3항, 제39조의3제4항): 정보주체 연락처를 알 수 없는 등 정당한 사유가 있으면 인터넷 홈페이지에 30일 이상 게시해 통지를 갈음할 수 있습니다.
• 가능성 통지의 후속(시행령 제39조의3): 72시간 안에 실제 유출등을 확인하면 가능성 통지 대신 제34조제1항 통지를 하고, 가능성 통지 후 실제로 유출등이 없었음을 확인하면 즉시 그 사실을 통지합니다.
• 신고 생략(시행령 제40조제1항 단서): 유출등 경로가 확인되어 회수·삭제 등으로 정보주체 권익 침해 가능성이 현저히 낮아진 경우 신고하지 않을 수 있습니다. 이 판단은 근거와 함께 기록해 두는 편이 안전합니다.
• 적용 시점(부칙 제2조): 개정 제34조제1항·제4항은 2026.9.11. 이후 유출등을 알게 된 경우부터, 제2항(가능성 통지)은 시행 이후 가능성을 알게 된 경우부터, 제3항은 시행 이후 유출등이 된 경우부터 적용됩니다.

실제 법적 근거

• 법 제34조제1항: “개인정보가 유출등이 되었음을 알게 되었을 때에는 지체 없이 해당 정보주체에게 다음 각 호의 사항을 알려야 한다.” 통지 사항은 ① 항목 ② 시점과 경위 ③ 피해 최소화를 위해 정보주체가 할 수 있는 방법 ④ 대응조치 및 피해 구제절차 ⑤ 신고 접수 담당부서·연락처 ⑥ 손해배상(제39조, 제39조의2)·분쟁조정(제43조) 등 법적 권리와 행사 방법 ⑦ 대통령령 사항입니다.
• 법 제34조제2항: 대통령령으로 정하는 “유출등의 가능성이 있음을 알게 되었을 때에는 지체 없이 유출등의 가능성이 있는 모든 정보주체에게” 알려야 합니다.
• 시행령 제39조의2제2항: 가능성 통지 사항은 가능성 있는 항목, 의심·인정되는 시점과 경위, 법 제34조제1항제3호~제5호 사항, 유출등 여부가 확정되면 추가 통지하겠다는 사실입니다.
• 시행령 제40조제2항: 신고 시 1호·2호 사항을 확인하지 못했으면 유출등 사실, 확인된 내용, 제3호~제5호 사항을 우선 신고하고 추가 확인 즉시 신고합니다.
• 시행령 제39조·제39조의3·제40조의 “서면등의 방법”은 시행령 제17조제5항에서 서면, 전자우편, 팩스, 전화, 문자전송 또는 이에 상당하는 방법으로 정의됩니다.

(법률 제21445호, 시행령 제36671호 기준. 2026-10-23 원문 대조.)

개발자용 실무 해설

1. “알게 된 때”를 기록하는 것이 시계의 시작입니다. 탐지 알림 시각, 담당자 확인 시각, 유출등 판단 시각을 각각 남깁니다. 어느 시점을 “알게 된 때”로 볼지는 안내서와 법무 판단 대상입니다(review-required). 시스템은 가장 이른 후보 시각을 기본값으로 잡고 72시간 카운트다운을 띄우는 편이 안전합니다.
2. 영향 범위 산정 쿼리를 미리 만듭니다. 침해 사고 시 “누구의 어떤 항목이 영향받았나”를 접속기록과 데이터 카탈로그로 빠르게 뽑을 수 있어야 1천명 기준, 민감정보·고유식별정보 포함 여부를 판단할 수 있습니다. → 접속기록
3. 가능성 통지는 “정보주체를 특정하기 곤란한” 경우에 쓰입니다. 예: 관리자 PC가 악성코드에 감염되었지만 무엇이 빠져나갔는지 모르는 경우. 영향 범위를 특정할 수 없으면 “가능성이 있는 모든 정보주체”가 대상이 되므로, 평소 접근 범위를 좁혀 두는 것(최소 권한)이 통지 규모를 줄입니다.
4. 훼손·위변조도 대응 시나리오에 넣습니다. 랜섬웨어로 DB가 암호화되거나 데이터가 변조된 경우도 유출등의 정의에 포함되므로, 무결성 검증과 백업 복구 절차가 대응 계획에 있어야 합니다.
5. 통지문은 템플릿 + 필수 필드 검증으로 생성합니다. 제34조제1항 7개 사항 중 빠진 필드가 있으면 발송을 막고, 확인되지 않은 항목은 “확인 중”으로 우선 통지 후 추가 통지 이력을 남깁니다.
6. 공중 노출 점검: 고유식별정보, 계좌정보, 신용카드정보가 검색엔진·공개 버킷·디버그 페이지로 노출되지 않게 하는 것이 제34조의2제1항의 의무입니다. 공개 버킷 스캔, robots/인증 누락 점검을 CI나 정기 점검에 둡니다.

권장 설계

[탐지] WAF/IDS · 접속기록 이상징후 · 버그바운티 제보 · 외부 기관 연락
   │  (detected_at 기록)
   ▼
[사고 티켓] incident: aware_at, kind(유출/위조/변조/훼손/분실/도난), status
   │  72시간 타이머 (통지·신고 각각)
   ▼
[영향 산정] affected_subjects, data_items, sensitive/unique_id 포함, external_access 여부
   │  → 신고 대상 판정 (1천명 이상 OR 민감·고유식별 OR 외부 불법 접근)
   │  → 확정 / 가능성 판정 (정보주체 특정 가능 여부)
   ▼
[통지] 템플릿 렌더링 → 필수 7개 사항 검증 → 이메일/문자 발송 → 실패 시 홈페이지 게시(30일+)
[신고] 보호위원회/KISA 신고서 초안 생성 (제출은 사람)
[추가 통지] 새로 확인된 항목 → 증분 통지 이력

위험한 설계

• 탐지 시각·판단 시각 기록 없이 슬랙 대화로만 대응
• 영향 범위를 못 정했다는 이유로 72시간을 넘겨 통지 보류(우선 통지 규정 미활용)
• 통지문에 손해배상·분쟁조정 등 법적 권리 안내(6호)를 빠뜨림
• 백업·로그·분석 환경 유출은 “운영 DB가 아니니까” 대응 범위에서 제외
• 신고 생략 판단(회수·삭제 완료)을 근거 기록 없이 결정
• 공개 S3 버킷이나 디버그 엔드포인트에 계좌번호·주민등록번호가 노출되는 구조

Python/TypeScript 구현 예제

# 신고 대상·기한 판정 (시행령 제39조, 제40조 기준). 최종 판단은 사람이 한다.
from dataclasses import dataclass, field
from datetime import datetime, timedelta

DEADLINE = timedelta(hours=72)

@dataclass
class Incident:
    aware_at: datetime                 # 유출등을 알게 된 때 (법무 확인)
    affected_count: int | None         # None = 정보주체 특정 곤란
    has_sensitive_or_unique_id: bool
    external_illegal_access: bool
    confirmed: bool                    # False = 가능성 단계
    items: list[str] = field(default_factory=list)

def assess(i: Incident) -> dict:
    must_report = i.confirmed and (
        (i.affected_count or 0) >= 1000
        or i.has_sensitive_or_unique_id
        or i.external_illegal_access
    )
    return {
        "notice_type": "유출등 통지(제34조①)" if i.confirmed else "유출등 가능성 통지(제34조②)",
        "notify_by": i.aware_at + DEADLINE,
        "report_required": must_report,
        "report_by": i.aware_at + DEADLINE if must_report else None,
        "preliminary_notice": not i.items,  # 항목·경위 미확인 → 우선 통지
    }

// 통지문 필수 사항 검증: 법 제34조제1항 1~6호가 비어 있으면 발송 차단
type BreachNotice = {
  items: string[] | '확인 중';
  timeAndCause: string | '확인 중';
  selfProtection: string;      // 3호
  responseAndRemedy: string;   // 4호
  contact: string;             // 5호
  legalRights: string;         // 6호: 손해배상·법정손해배상·분쟁조정 안내
};

export function validateNotice(n: BreachNotice): string[] {
  const missing: string[] = [];
  for (const k of ['selfProtection', 'responseAndRemedy', 'contact', 'legalRights'] as const) {
    if (!n[k]?.trim()) missing.push(k);
  }
  return missing; // 1·2호는 '확인 중'으로 우선 통지 가능(시행령 제39조②), 3~6호는 필수
}

전체 예제는 구현 예제를 참고하세요.

개발 체크리스트

• 사고 티켓에 탐지 시각, “알게 된 때”, 판단 근거가 남는다
• 통지·신고 72시간 타이머와 담당자 알림이 있다
• 접속기록과 데이터 카탈로그로 영향 정보주체·항목을 산정하는 쿼리가 준비되어 있다
• 신고 대상 판정(1천명 이상, 민감정보·고유식별정보, 외부 불법 접근)이 자동 계산된다
• 가능성 통지 → 확정 통지 / 미유출 통지 전환 흐름이 있다
• 통지문 템플릿이 제34조제1항 1~6호를 모두 포함하고, 미확인 항목은 우선 통지 후 추가 통지한다
• 연락처 불명 대상자를 위한 홈페이지 30일 이상 게시 절차가 있다
• 위·변조·훼손(랜섬웨어 등) 시나리오가 대응 계획에 포함되어 있다
• 공개 버킷·검색 노출 점검이 정기적으로 돈다(제34조의2)
• 유출등 대응 계획이 내부 관리계획(고시 제4조제1항제14호)에 반영되어 있다
• 개인정보 유출등 대응 안내서 최신판으로 판단 기준을 확인했다 (review-required)

공식 원문 링크와 확인일

아래 “근거 구분표”와 “공식 원문 링크”를 참고하세요. 법 제23조·제34조·제34조의2·부칙과 시행령 제39조~제40조의2는 2026-10-23에 국가법령정보센터 Open API로 현행 원문을 확인했습니다. 「개인정보 유출등 대응 안내서」의 판단 기준과 통지문 예시는 원문 대조 전이라 review-required입니다.