개인정보 유출 신고 72시간 대응: 판정표·타임라인·신고서식 템플릿

새벽 3시, DB에서 12만 건이 빠져나갔다 — 시계는 이미 돌고 있다

고지: 본문은 2026년 8월 기준 개인정보 보호법 및 같은 법 시행령 해석을 바탕으로 작성한 실무 초동 판단용 문서입니다. 조문은 개정될 수 있고, 사고의 구체적 사실관계에 따라 결론이 달라집니다. 실제 대응 시에는 반드시 법률 검토를 병행하십시오.

사고 대응 중인 담당자가 가장 먼저 오해하는 지점부터 정정하겠습니다.

72시간은 "조사 완료 기한"이 아닙니다. "1차 통지·신고 기한"입니다.

포렌식이 안 끝났어도, 유출 건수가 확정되지 않았어도, 원인을 못 밝혔어도 72시간은 흘러갑니다. 개인정보위의 최근 제재 흐름을 보면 신고 지연 자체를 별도의 위반 행위로 판단하는 경향이 뚜렷합니다. 즉 "정확한 조사 결과를 담아 한 번에 신고하려다 늦었다"는 항변은 감경 사유가 되기 어렵습니다. 확인된 범위만이라도 먼저 신고하고, 나머지는 추가 신고로 보완하는 것이 정석입니다.

또 하나. GDPR의 72시간과 국내 규정은 다른 제도입니다. 두 규정 모두 72시간이라는 숫자를 쓰기 때문에 혼동이 잦은데, 통지 대상·기산점·면제 요건이 각각 다릅니다. 국내 사고라면 국내 조문 기준으로 판단하고, EU 정보주체가 섞여 있다면 두 제도를 중복 적용 대상으로 놓고 별도 검토해야 합니다.

'인지 시점'이란 정확히 언제인가

72시간의 기산점은 "유출을 알게 된 때"입니다. 실무에서 이 시각을 언제로 잡느냐가 지연 여부를 가르는 핵심입니다.

법적 '인지'로 볼 여지가 큰 트리거 4가지:

경계선은 이렇게 잡습니다. "의심 정황 ≠ 인지"이지만, "확인을 미루는 것"은 인지 회피로 불리하게 해석될 수 있습니다. 알림을 받고 3일간 방치했다가 확인했다면, 기산점을 3일 뒤로 주장하기 어렵습니다.

실무 팁 — 인지 시각을 못 박아 기록하십시오.

• 티켓 시스템에 [유출의심] 티켓을 열고 최초 코멘트에 UTC/KST 시각을 함께 기록
• 알림 원본(SIEM 스크린샷, 메일 헤더, 제보 원문)을 티켓에 첨부
• "누가 언제 무엇을 근거로 유출이라 판단했는가" 한 문장을 남길 것
• 로그 시각과 티켓 시각이 어긋나면 NTP 동기화 상태부터 확인 → 로그 신뢰성 소명에 직결

로그 보존과 시각 정합성에 자신이 없다면 에러 로그 분석 3단계 프로세스에서 정리한 수집·보존 원칙을 먼저 점검하시길 권합니다.

30초 판정표: 통지 / 신고 / 불필요 3분기

판정 축은 3개뿐입니다.

1. 유출 규모 — 1건 이상인가, 1천명 이상인가
2. 정보 유형 — 고유식별정보 / 민감정보 / 계정정보(ID+비밀번호) / 일반 개인정보
3. 암호화 여부 — 암호화되어 있는가, 복호화 키가 함께 유출되었는가

핵심 원칙 두 가지를 먼저 기억하십시오.

• 정보주체 통지는 규모와 무관합니다. 1건이 유출돼도 통지 의무는 발생합니다.
• 신고(개인정보위·KISA)는 규모·유형 요건에 따라 갈립니다.

[표 1] 조합별 판정표

표의 3·4행 "건수 무관" 부분은 시행령의 구체 기준이 개정 이력이 있는 영역입니다. 최종 판단 전 개인정보위 최신 고시·해설서 확인이 필요합니다. 확정 문구로 사내 규정에 박아넣지 마시고, "확인 필요" 주석과 함께 운영하십시오.

헷갈리는 경계 사례 4개

① 암호화됐지만 키 서버가 함께 털린 경우 암호화는 방어수단이지 면제 사유가 아닙니다. 복호화 키가 같은 침해 범위 안에 있었다면 평문 유출과 동일하게 판정하십시오(표 7행). "AES-256으로 암호화되어 있었음"만 신고서에 쓰고 키 관리 상태를 누락하면 나중에 더 불리해집니다.

② 솔트 없는 해시 비밀번호 단순 MD5/SHA-1 해시는 레인보우 테이블로 사실상 복원 가능합니다. 계정정보 유출로 판정하고 통지 시 비밀번호 즉시 변경을 안내하는 것이 안전한 처리입니다. 솔트+느린 해시(bcrypt/Argon2) 적용 여부와 알고리즘·반복 횟수를 문서에 기록하십시오.

③ 내부 직원의 무단 열람(외부 반출 없음) "열람만 했고 반출은 없다"는 주장은 로그로 입증되어야만 성립합니다. 다운로드·화면 캡처·개인 메일 발송 로그를 전수 확인하기 전까지는 유출 가능성을 열어두고 판정하십시오. 이 유형의 탐지 체계가 없다면 내부자 위협 탐지 시스템 구축 방법을 참고해 사후 보완 과제로 잡아두는 것이 좋습니다.

④ 이메일 참조(CC) 오발송 가장 흔하고 가장 과소평가되는 사고입니다. 수신자 목록에 개인정보(이메일 주소 자체가 개인정보)가 노출된 것이므로 유출로 판정합니다. 회수 기능 성공 여부, 수신자에게 삭제 요청한 기록을 반드시 남기십시오.

판정 결과를 문서로 남겨야 하는 이유

추후 조사에서 "왜 신고하지 않았는가"를 소명해야 할 때, 판정 시점의 근거가 남아 있어야 합니다. 결과적으로 판정이 틀렸더라도, 합리적 근거로 성실히 판단한 기록은 감경 요소로 작동할 여지가 있습니다. 반대로 기록이 없으면 "판단조차 하지 않았다"로 읽힙니다.

• 판정표 적용 결과를 PDF로 출력, 판정 시각·판정자·CPO 서명 포함
• 근거가 된 로그 조회 화면 스크린샷 첨부
• 사고 전용 보안 폴더에 보관, 접근 이력 남기기

72시간 타임라인: 0h → 24h → 72h → 이후

[표 2] 구간별 타임라인

산출물 관리 규칙

문서를 만들어놓고 관리하지 않으면 없는 것과 같습니다. 다음 3가지를 고정하십시오.

• 서명자: ①③⑦⑨⑫는 CPO 서명 필수. ④⑤⑥은 보안팀장, ⑧⑩은 실무 담당자 서명 후 CPO 확인.
• 보관 위치: 사고 전용 폴더 1곳에 통합 보관. 개인 PC·개인 메일함 분산 보관 금지.
• 접근 통제: 대응 조직 구성원만 접근, 접근 이력 로깅. 조사 대응 시 "누가 언제 문서를 수정했는가"를 제시할 수 있어야 합니다.

증거 보존에서 가장 자주 발생하는 실수는 조사한다며 원본 서버에 직접 로그인해 파일을 뒤지는 것입니다. 접근 시각·atime이 오염되고 메모리 상주 증거가 사라집니다. 차단 조치와 증거 보존은 동시에, 그러나 별개 절차로 진행하십시오.

신고 채널과 서식 — 빈칸 채우기 템플릿 3종

신고 경로

• 온라인: 개인정보포털(privacy.go.kr) → 개인정보 침해/유출 관련 메뉴 → 개인정보 유출 신고. 사업자 인증 후 서식 작성·제출.
• KISA: 침해사고 관련 접수 창구를 통해 기술적 침해 신고를 병행. 개인정보 유출 신고와 침해사고 신고는 목적이 다르므로 둘 다 필요한지 확인하십시오.
• 온라인 접수 불가 시: 서면·팩스 등 대체 접수 절차가 마련되어 있습니다. 시스템 장애 등으로 온라인 접수가 안 되면 접수 시도 화면을 캡처해두고 대체 경로로 진행하십시오. "시도했으나 불가했다"는 기록이 지연 소명 자료가 됩니다.
• 접수 후 확인 사항: 접수번호, 접수 일시, 담당 부서, 추가 자료 제출 기한. 이 4가지를 접수 직후 문서화하십시오.

각 창구의 정확한 메뉴 경로와 서식 양식은 개편될 수 있습니다. 접수 직전 개인정보위 공식 안내를 확인하십시오.

[템플릿 1] 유출 신고서 기재 항목별 작성 예문

신고서는 5개 항목으로 구성됩니다. 항목마다 "나쁜 예 → 좋은 예"를 대비해 정리했습니다.

① 유출 일시 및 경위

• ❌ 나쁜 예: "최근 해킹으로 인해 개인정보가 유출된 것으로 보입니다."
• ✅ 좋은 예: "2026-08-09 02:41(KST) 웹 애플리케이션 서버의 관리자 페이지에 대한 비인가 접근이 발생, 02:41~03:15 사이 회원 DB 조회 쿼리가 실행되었습니다. 2026-08-09 03:52 SIEM 대량 조회 알림으로 인지하였습니다. 초기 침입 경로는 조사 중입니다."

{{유출 발생 일시}}에 {{시스템/자산명}}에서 {{공격 유형 또는 사고 유형}}이 발생하였으며,
{{시작 시각}}부터 {{종료 시각}}까지 {{행위 내용}}이 확인되었습니다.
{{인지 일시}}에 {{인지 경로}}를 통해 유출 사실을 인지하였습니다.
{{현재 조사 상태}}

② 유출 항목 및 규모

• ❌ 나쁜 예: "회원 정보 일부"
• ✅ 좋은 예: "유출 항목: 이름, 이메일 주소, 휴대전화번호, 암호화된 비밀번호(bcrypt). 확인된 규모: 122,431건(2026-08-10 12:00 기준 조회 로그 분석 결과). 주민등록번호·계좌정보는 해당 테이블에 저장되어 있지 않아 유출 대상에서 제외됩니다."

유출 항목: {{항목1}}, {{항목2}}, {{항목3}}
확인 규모: {{건수}}건 ({{산정 기준 일시}} 기준, {{산정 근거}})
유출되지 않은 항목: {{항목}} — {{미유출 근거}}
암호화 여부: {{알고리즘}} / 복호화 키 유출 여부: {{여부 및 근거}}

③ 정보주체가 취할 수 있는 조치

• ❌ 나쁜 예: "주의를 당부드립니다."
• ✅ 좋은 예: "동일 비밀번호를 사용하는 타 서비스의 비밀번호 즉시 변경, 당사를 사칭한 문자·메일 링크 클릭 금지, 명의도용 방지 서비스 가입 안내."

④ 사업자 대응 조치 및 피해구제 절차

• ❌ 나쁜 예: "보안을 강화하겠습니다."
• ✅ 좋은 예: "① 침해 계정 즉시 비활성화 및 전 관리자 계정 비밀번호 강제 변경(08-09 04:10 완료) ② 해당 IP 대역 차단(04:25 완료) ③ 전 이용자 세션 강제 만료(05:00 완료) ④ 피해 접수 전용 창구 개설 및 피해 확인 시 개별 구제 절차 안내."

⑤ 담당 부서·연락처

• 부서명, 담당자명, 직통 전화, 전용 메일 주소를 기재하십시오. 대표번호만 적으면 연락 지연으로 불성실 대응으로 비칠 수 있습니다.

[템플릿 2] 정보주체 통지 이메일

제목: [중요] {{회사명}} 개인정보 유출 사고 안내 및 조치 요청

안녕하세요, {{회사명}}입니다.

당사는 {{인지 일시}} 이용자 개인정보가 외부에 유출된 사실을 확인하였습니다.
고객님께 불편과 우려를 끼쳐드린 점 깊이 사과드립니다.

■ 유출 일시 및 경위
- 발생 추정 일시: {{발생 일시}}
- 인지 일시: {{인지 일시}}
- 경위: {{경위 요약}}

■ 유출된 개인정보 항목
- {{항목1}}, {{항목2}}, {{항목3}}
- 유출되지 않은 항목: {{미유출 항목}}

■ 고객님께서 취하실 수 있는 조치
1. {{회사명}} 계정 비밀번호를 즉시 변경해 주십시오. ({{변경 링크}})
2. 동일한 비밀번호를 사용 중인 다른 서비스의 비밀번호도 변경해 주십시오.
3. 당사를 사칭한 문자·이메일의 링크를 절대 클릭하지 마십시오.
   당사는 어떠한 경우에도 이메일로 비밀번호나 금융정보를 요구하지 않습니다.
4. 필요 시 명의도용 방지 서비스 이용을 권고드립니다.

■ 당사의 조치 사항
- {{차단 조치}} ({{완료 일시}})
- {{추가 조치}} ({{완료 일시}})
- {{재발방지 계획}}

■ 피해 구제 및 문의
- 전담 창구: {{전화번호}} (운영 시간: {{시간}})
- 이메일: {{전용 이메일}}
- 관계 기관 신고: 개인정보침해 신고센터(privacy.go.kr), 경찰청 사이버수사국

당사는 관계 법령에 따라 관계 기관에 신고를 완료하였으며,
조사 진행 상황에 변동이 있을 경우 추가로 안내드리겠습니다.

{{회사명}} 개인정보보호책임자 {{성명}} 드림

[템플릿 3] 홈페이지 공지문 (대체 통지용)

연락처를 확보하지 못한 정보주체가 있을 때, 홈페이지 게시로 통지를 갈음하는 절차입니다. 개별 통지가 가능한 대상에게는 반드시 개별 통지를 먼저 하고, 불가능한 범위에 한해 게시로 보완하는 순서를 지키십시오.

[공지] 개인정보 유출 사고 안내

게시일: {{게시 시작일}}
게시 기간: {{게시 시작일}} ~ {{게시 종료일}} (30일 이상 게시)

1. 유출 일시 및 경위
   {{발생 일시}} {{경위 요약}}

2. 유출된 개인정보 항목
   {{항목 나열}}

3. 유출 규모
   {{확인 규모}} ({{산정 기준일}} 기준, 조사 진행에 따라 변동될 수 있습니다)

4. 이용자께서 하실 수 있는 조치
   {{조치 안내}}

5. 당사의 대응 조치 및 재발방지 대책
   {{조치 내용}}

6. 피해 접수 및 문의처
   부서: {{부서명}} / 전화: {{번호}} / 이메일: {{이메일}}
   접수 가능 시간: {{시간}}

{{회사명}}
개인정보보호책임자 {{성명}}

게시 시 체크리스트

• 메인 페이지에서 1클릭 이내 도달 가능한 위치에 배치
• 로그인 없이 접근 가능
• 게시 화면 전체 캡처 + 게시 시각이 보이도록 저장
• 게시 종료 전 임의 삭제 금지 (게시 기간은 관련 규정 확인 필요)

실패 분기 3종 — 판단 → 행동 → 문서

① 72시간 내 규모가 확정되지 않았다

판단 규모 미확정은 신고 유예 사유가 아닙니다. 확정 대기가 곧 지연입니다. 현재까지 확인된 범위를 기준으로 우선 신고하고, 이후 정정·추가 신고로 보완하는 것이 원칙입니다.

행동

1. 확실히 유출된 것으로 확인된 최소 범위를 산정 (로그로 입증 가능한 범위)
2. "조사 중이며 확대 가능성 있음"을 신고서에 명시하고 우선 접수
3. 추가 조사 완료 시각을 스스로 정하고(예: +7일) 정정 신고 일정 확보
4. 규모 확대 확인 시 즉시 추가 통지 발송

신고서에 쓸 문구 예시:

현재까지 로그 분석을 통해 확인된 유출 규모는 {{건수}}건({{기준 일시}} 기준)입니다.
다만 {{미분석 로그 범위}}에 대한 분석이 진행 중이며, 조사 결과에 따라 규모가
변동될 수 있습니다. 확정 시 지체 없이 정정 신고 및 추가 통지를 진행하겠습니다.
(조사 완료 예정: {{예정일}})

문서

• 1차 산정 근거(쿼리문·로그 범위·집계 방식) 기록
• "왜 이 시점에 확정할 수 없었는가"에 대한 기술적 사유서
• 정정 신고 완료 후 최초 신고와의 차이 대비표

② 수탁자(위탁사)에서 유출이 발생했다

판단 클라우드·SaaS 위탁 구조가 늘면서 책임 소재 논쟁이 잦습니다. 다만 실무 대응의 출발점은 명확합니다. 정보주체에 대한 통지와 관계 기관 신고의 주체는 원칙적으로 위탁자(개인정보처리자)입니다. 수탁사가 신고했으니 우리는 안 해도 된다는 판단은 위험합니다. 관리·감독 책임도 위탁자에게 남습니다(법 제26조, 2026년 8월 기준 — 구체 책임 배분은 법률 검토 필요).

행동

1. 수탁사에 즉시 서면으로 자료를 요구합니다.
   • 유출 발생·인지 일시 (수탁사 기준)
   • 자사 데이터가 포함된 범위와 항목
   • 유출된 레코드 건수 및 산정 근거
   • 수탁사의 차단 조치 내역과 완료 시각
   • 관련 접근·감사 로그 원본 또는 사본
   • 수탁사의 신고 진행 여부와 접수번호
2. 계약서 점검: 통보 의무 조항(통보 기한이 명시되어 있는가), 감사권, 로그 제공 의무, 손해배상·구상권 조항
3. 재위탁(수탁사가 다시 다른 업체에 맡긴 경우) 여부 확인 — 재위탁 승인 절차가 있었는지가 쟁점이 됩니다

문서

• 자료 요구 공문과 수탁사 회신 (수신 시각 포함)
• 계약서 해당 조항 발췌본
• 위탁 현황 목록(어떤 업체에 어떤 항목을 위탁했는지) 최신본

위탁 현황 관리 체계가 부실하면 이 단계에서 며칠이 날아갑니다. 평시 관리 항목은 2026 ISMS-P 인증 준비 체크리스트의 위탁·제3자 제공 통제 항목과 상당 부분 겹치므로 함께 정비하는 것이 효율적입니다.

③ 데이터가 해외 클라우드에 있다

판단 데이터 소재지가 해외여도 국내 개인정보 보호법상 신고·통지 의무는 그대로 적용됩니다. "미국 리전이라 국내 신고 대상이 아니다"는 성립하지 않습니다. 동시에 EU 거주자 데이터가 포함되면 GDPR 등 역외 규제가 중복 적용될 수 있습니다.

역외 규제 중복 적용 판단 기준(초동용):

• 정보주체 중 EU/EEA 거주자가 포함되어 있는가
• 해당 서비스가 EU 시장을 대상으로 제공되는가
• 캘리포니아·기타 주법, 일본·싱가포르 등 서비스 제공 국가 규제 해당 여부

행동

1. 사고 발생 리전과 데이터 소재 리전을 정확히 특정 (다중 리전 복제 여부 포함)
2. 클라우드 로그 확보 — 감사 로그 보존 기간이 짧으면 최우선으로 내보내기
   • 로그 보존 기간이 90일 등으로 제한된 서비스가 많으므로 즉시 별도 스토리지로 export
   • 로그 수집 체계가 없다면 AWS CloudWatch 모니터링·알람·로그 수집 실전에서 다룬 보존 설정을 사후 보완 과제로 등록
3. 클라우드 사업자의 보안 사고 대응(IR) 창구에 정식 티켓 제기 — 지원 플랜에 따라 대응 속도가 다르므로 심각도(Severity)를 정확히 설정
4. 공동 책임 모델(Shared Responsibility) 상 책임 경계 확인 — 사업자 인프라 문제인지, 자사 설정 오류(공개 버킷·과대 권한)인지 구분

문서

• 리전·계정·리소스 식별자 목록
• 클라우드 IR 티켓 번호와 사업자 회신 내용
• 로그 export 결과물의 해시값과 보관 위치
• 역외 규제 적용 여부에 대한 법률 검토 의견서

제재 기준과 감경 요소, 그리고 오늘 만들어둘 것

위반 유형별 제재 정리

과태료·과징금의 구체 금액과 요율은 조문 개정 및 부과 기준 고시에 따라 달라집니다. 본문에 확정 수치를 적지 않은 이유입니다. 개인정보위 공식 자료로 반드시 직접 확인하십시오.

감경 요소로 거론되는 것들

• 자진 신고 및 신속한 신고·통지 이행
• 침해 확산 방지를 위한 즉각적 기술 조치
• 정보주체 피해 구제를 위한 실질적 노력(전담 창구, 보상 절차)
• 평시 안전조치 이행 증적(암호화, 접근통제, 로그 관리)
• 조사 협조의 성실성

가중 요소

• 신고·통지 지연 또는 은폐
• 동일·유사 사고의 반복 발생
• 기본적 안전조치의 부재(평문 저장, 접근통제 미비)
• 자료 제출 거부·비협조

오늘 만들어둘 3가지

사고 당일에 만들면 늦습니다. 지금 30분만 투자하십시오.

① 인지 시각 기록 양식 티켓 템플릿으로 등록해두면 됩니다. 필드는 5개면 충분합니다 — 인지 일시(KST), 인지 경로, 최초 인지자, 판단 근거 요약, 첨부 증적.

② 판정표 사내 버전 위 [표 1]에 자사가 실제로 보유한 정보 항목을 매핑해 다시 만드십시오. "우리 회사는 어떤 테이블에 어떤 등급의 정보가 있는가"가 판정 속도를 결정합니다. 정보 항목 인벤토리가 없으면 판정에 하루가 소요됩니다.

③ 통지문 초안 사전 승인 [템플릿 2]와 [템플릿 3]을 자사 문안으로 다듬어 법무·홍보 사전 승인까지 받아두십시오. 사고 당일에 문구를 협의하면 반나절이 사라집니다. 플레이스홀더만 채우면 발송할 수 있는 상태로 보관하는 것이 목표입니다.

다시 한번 고지합니다. 본문의 판정표와 타임라인은 실무 초동 판단을 돕기 위한 자료입니다. 조문 해석과 최종 판단은 사안별 사실관계에 따라 달라지며, 반드시 법률 전문가의 검토를 병행하십시오. 조문·고시는 2026년 8월 이후 개정되었을 수 있습니다.

자주 묻는 질문 (FAQ)

Q1. '인지 시점'은 정확히 언제로 잡아야 하나요? A. 유출 사실을 알게 된 때입니다. 실무적으로는 "정상 업무가 아닌 데이터 유출임을 확인한 시각"으로 잡고, 그 근거(알림 원문, 로그 조회 결과)를 함께 기록합니다. 단순 의심 정황은 인지로 보기 어렵지만, 확인을 의도적으로 미루면 인지 회피로 불리하게 해석될 수 있습니다.

Q2. 72시간에 주말·공휴일이 포함되나요? A. 일반적으로 유출 통지·신고 기한은 역일(calendar hours) 기준으로 흘러간다고 보고 대응하는 것이 안전합니다. 금요일 밤 사고는 월요일 아침이 이미 60시간 경과 시점입니다. 주말 온콜 체계와 CPO 비상 연락망을 반드시 갖춰두십시오. 기한 계산의 법적 해석은 사안별로 법률 검토가 필요합니다.

Q3. 1천명 미만이면 신고하지 않아도 되나요? A. 규모 요건만 보면 그렇게 볼 여지가 있으나, 고유식별정보·민감정보·계정정보가 포함되거나 외부 해킹에 의한 유출이면 건수와 무관하게 신고 대상이 될 수 있습니다. 그리고 정보주체 통지는 1건이어도 의무입니다. 규모만으로 판단하지 마십시오.

Q4. 암호화되어 있었으면 통지·신고가 면제되나요? A. 자동 면제로 보기 어렵습니다. 암호화는 안전조치 이행 증적이자 피해 완화 요소로 작동하지만, 복호화 키가 함께 유출되었거나 알고리즘이 취약하면(솔트 없는 MD5 등) 사실상 평문 유출과 동일하게 취급됩니다. 암호화 알고리즘, 키 관리 방식, 키 유출 여부를 함께 소명해야 합니다.

Q5. 통지 대상의 연락처를 모를 때는 어떻게 하나요? A. 개별 통지가 가능한 대상에게는 먼저 개별 통지하고, 연락처 미확보 범위에 대해 홈페이지 공지 게시로 통지를 갈음합니다([템플릿 3] 참고). 이때 "왜 개별 통지가 불가능했는지"에 대한 근거(연락처 미보유 건수, 반송 로그)를 남겨야 합니다. 게시 위치·기간 요건은 관련 규정을 확인하십시오.

Q6. 수사기관이 수사 중이니 공개를 미뤄달라고 하면 보류할 수 있나요? A. 수사 협조를 이유로 공개 방식·내용을 조정할 여지는 있으나, 통지·신고 의무 자체가 소멸한다고 단정하기 어렵습니다. 반드시 수사기관의 요청을 서면으로 확보하고, 그 사실을 개인정보위에 알린 뒤 법률 검토를 거쳐 결정하십시오. 구두 요청만 믿고 보류했다가 지연 책임을 지는 사례가 가장 위험합니다.

Q7. 신고 후 조사에서 유출 규모가 더 늘었습니다. 어떻게 하나요? A. 지체 없이 정정·추가 신고를 하고, 새로 확인된 정보주체에게 추가 통지를 발송합니다. 최초 신고 시 "조사 중이며 변동 가능"을 명시해두었다면 대응이 훨씬 수월합니다. 최초 신고와 정정 신고의 차이를 대비표로 정리해 문서화하십시오. 규모 증가 자체보다 정정을 미루는 것이 더 불리하게 작용합니다.

Q8. 통지 비용과 문의 대응 인력은 어떻게 준비해야 하나요? A. 대량 통지는 이메일·SMS 발송 비용과 발송 인프라 한도가 병목이 됩니다. 수만 건 이상이면 발송 서비스의 일일 전송 한도를 미리 확인해두십시오. 문의 대응은 통지 발송 직후 24~48시간에 집중되므로, 그 구간에 인력을 배치하고 FAQ 스크립트를 사전 작성해 응대 편차를 줄이는 것이 핵심입니다. 응대 내용은 로그로 남겨 추후 소명 자료로 활용합니다.