개인정보 유출을 알게 됐다면 72시간 안에 무엇을 해야 합니까
고객 데이터베이스에서 평소와 다른 대량 조회 흔적을 발견한 기업이 자주 묻는 질문입니다. 기한이 언제부터 계산되는지, 유출 범위를 다 확인하지 못한 상태에서도 알려야 하는지, 해킹이 원인이면 어디에 따로 신고하는지가 쟁점입니다.
빌드업웍스 답변
빌드업웍스 엔지니어핵심 답변
개인정보처리자는 유출을 알게 된 때부터 72시간 안에 정보주체에게 통지해야 하고, 1천 명 이상이거나 민감정보·고유식별정보가 포함됐거나 외부의 불법 접근으로 유출됐다면 같은 기한 안에 개인정보보호위원회 또는 한국인터넷진흥원(KISA)에 신고해야 합니다. 유출 항목이나 경위를 다 확인하지 못했더라도 확인된 내용으로 먼저 통지·신고하고, 추가 내용은 확인되는 즉시 보완합니다. 해킹이 원인이라면 정보통신망법상 침해사고 신고(알게 된 때부터 24시간)가 별도로 적용될 수 있습니다.
- 기한은 유출을 「알게 된 때」부터 72시간입니다
- 1천 명 이상·민감정보·외부 불법 접근이면 신고 대상입니다
- 범위를 다 몰라도 확인된 내용으로 먼저 통지·신고합니다
- 해킹이 원인이면 24시간 침해사고 신고가 따로 걸릴 수 있습니다
- 2026년 9월부터 유출 「가능성」 통지 의무가 더해졌습니다
72시간은 「알게 된 때」부터 셉니다
개인정보 보호법 제34조와 시행령 제39조·제40조는 개인정보가 유출·도난·분실(법률 용어로 「유출등」)됐음을 알게 된 때부터 72시간 이내에 두 가지를 하도록 정합니다. 정보주체에게 알리는 통지와, 개인정보보호위원회 또는 한국인터넷진흥원(KISA)에 알리는 신고입니다. 통지는 원칙적으로 규모와 관계없이 해야 하고, 신고는 정해진 조건 중 하나에 해당하면 의무가 됩니다.
실무에서 먼저 정리해야 할 지점은 기산점입니다. 조사가 끝난 날이 아니라 유출 사실을 인지한 시점이 기준이므로, 보고를 받은 시각·보고한 사람·당시 확인된 내용을 그 자리에서 기록해 두어야 나중에 기한을 지켰는지 설명할 수 있습니다.
| 구분 | 통지 | 신고 |
|---|---|---|
| 받는 쪽 | 유출된 정보주체 | 개인정보보호위원회 또는 KISA |
| 기한 | 알게 된 때부터 72시간 이내 | 알게 된 때부터 72시간 이내 |
| 의무 조건 | 유출등이 된 경우(원칙) | 1천 명 이상 · 민감정보 또는 고유식별정보 · 외부의 불법적인 접근에 의한 유출 중 하나 |
| 방법 | 서면등. 연락처를 알 수 없으면 홈페이지 30일 이상 게시로 갈음 가능 | 서면등. 개인정보보호위원회 유출 신고 누리집으로도 접수 |
범위를 다 모르면 확인된 만큼 먼저 알립니다
유출 항목이나 시점·경위를 72시간 안에 다 확인하지 못하는 경우도 있습니다. 시행령은 이때 유출 사실과 그때까지 확인된 내용, 피해를 줄이기 위해 정보주체가 할 수 있는 방법, 대응 조치와 피해 구제 절차, 연락처를 우선 통지·신고하고(통지에는 법적 권리 안내도 포함), 추가로 확인되는 내용은 확인되는 즉시 보완하도록 정합니다. 조사가 끝날 때까지 기다리는 것은 허용되는 선택지가 아닙니다.
예외도 있습니다. 접속 경로 차단·취약점 보완·유출된 정보의 회수·삭제처럼 긴급한 조치가 먼저 필요한 경우에는 그 사유가 해소된 뒤 즉시 통지할 수 있습니다. 또 경로가 확인돼 회수·삭제 등으로 권익 침해 가능성이 현저히 낮아졌다면 신고하지 않을 수 있다는 단서가 있습니다. 다만 이 예외를 적용할 수 있는지는 사실관계에 따라 판단이 갈리므로 법률 검토가 필요한 지점입니다.
2026년 9월 11일부터는 의무가 하나 더해졌습니다. 시스템에 불법 접근이 있었지만 누구의 정보가 나갔는지 특정하기 어려운 경우처럼 유출 「가능성」을 알게 된 때에도 72시간 이내에 해당 정보주체에게 알리도록 법 제34조제2항과 시행령 제39조의2·제39조의3이 신설됐습니다. 이후 실제 유출이 확인되면 정식 통지로 바꾸고, 유출이 없었음이 확인되면 그 사실을 다시 알립니다.
첫 24시간에 할 일
- 인지 시각 기록누가 언제 무엇을 보고 알았는지 남깁니다. 72시간 기한의 기준점입니다.
- 확산 차단과 증거 보존을 함께침해된 계정·키를 비활성화하고 접근 경로를 막되, 서버를 지우거나 재설치하기 전에 디스크 스냅샷과 로그를 먼저 보존합니다.
- 범위 추정개인정보 접속기록·DB 감사 로그·클라우드 API 기록으로 어떤 항목이 몇 명분 나갔는지 추정합니다.
- 적용 법령 판단신고 조건 해당 여부와 정보통신망법상 침해사고 신고 대상인지를 판단합니다.
- 통지문·신고서 초안법정 기재 항목에 맞춰 확인된 것과 확인 중인 것을 구분해 씁니다.
증거 보존을 차단과 같은 단계에 둔 데는 이유가 있습니다. 급한 마음에 인스턴스를 종료하거나 로그 보관 기간이 짧은 채로 두면, 통지문에 써야 할 「유출 시점과 경위」를 끝내 확인하지 못하게 됩니다. 클라우드 환경이라면 침해된 서버를 격리용 보안 그룹으로 옮기고 스냅샷을 뜬 뒤 조사하는 순서를 권합니다.
통지문에는 법 제34조제1항이 정한 사항이 들어가야 합니다. 유출된 항목, 유출 시점과 경위, 피해를 줄이기 위해 정보주체가 할 수 있는 방법, 회사의 대응 조치와 피해 구제 절차, 신고를 받을 담당 부서와 연락처, 손해배상 청구·분쟁조정 같은 법적 권리 안내입니다. 확인되지 않은 항목은 비워 두지 말고 「확인 중」이라고 명시한 뒤 추가 통지로 채웁니다.
해킹이 원인이면 신고가 하나 더 있을 수 있습니다
개인정보 유출 신고
- 근거: 개인정보 보호법 제34조
- 주체: 개인정보처리자
- 기한: 알게 된 때부터 72시간
- 접수: 개인정보보호위원회 · KISA
침해사고 신고
- 근거: 정보통신망법 제48조의3
- 주체: 정보통신서비스 제공자
- 기한: 발생 사실을 알게 된 때부터 24시간
- 접수: 과학기술정보통신부 · KISA(보호나라)
해킹·랜섬웨어처럼 정보통신망에 대한 공격이 원인이라면 정보통신망법상 침해사고 신고(24시간 이내)가 별도로 적용될 수 있습니다. 웹사이트나 앱으로 서비스를 제공하는 기업 상당수가 「정보통신서비스 제공자」에 해당할 수 있으므로, 해당 여부는 사고가 나기 전에 확인해 두는 편이 안전합니다. 처음 신고한 뒤 추가로 확인되는 사실은 확인한 때부터 24시간 이내에 다시 신고하도록 시행령이 정하고 있습니다.
같은 조항은 이미 다른 법률에 따라 침해사고를 통지·신고했다면 이 신고를 한 것으로 본다고 정합니다. 다만 개인정보 유출 신고가 여기에 해당하는지는 사안별로 확인이 필요합니다. 2026년 10월 1일부터는 서비스 장애·기능 중단이 2시간 이상 이어지거나 이용자 정보가 유출되거나 그럴 가능성이 있는 침해사고가 나면 이용자에게 지체 없이 통지하는 의무도 시행되고 있습니다(정보통신망법 제48조의3제4항, 시행령 제58조의9). 금융·신용정보와 관련된 사고는 신용정보법 등 별도 기준이 함께 적용될 수 있습니다.
사고 전에 정해 두면 72시간이 달라집니다
- 사고 보고를 받는 사람과 대행자, 연락 순서
- 접속기록·DB 감사 로그·클라우드 API 기록의 보관 위치와 기간
- 통지문·신고서 양식과 법정 기재 항목
- 정보통신서비스 제공자 해당 여부와 침해사고 신고 경로
- 법률 자문처와 외부 포렌식 업체 연락처
사고 대응 체계를 점검할 때는 대응 계획서보다 조사에 쓸 로그가 실제로 남아 있는지를 먼저 확인하는 편이 실효적입니다. 기록이 없으면 72시간 안에 통지문에 쓸 수 있는 내용도 없습니다.
참고 자료
이어서 보기
보안 자주 받는 질문
개인정보 접속기록은 얼마나 보관하고 어떻게 점검해야 합니까
개인정보처리시스템의 접속기록은 1년 이상 보관해야 하고, 5만 명 이상의 정보주체를 처리하거나 고유식별정보·민감정보를 처리하는 시스템 등은 2년 이상 보관해야 합니다. 점검은 개정 전 고시가 월 1회 이상을 요구했고, 2026년 11월 1일 시행 개정 고시는 점검 주기·방법·사후조치 절차를 내부 관리계획으로 정해 이행하도록 합니다. 클라우드 API 로그만으로는 누가 어느 정보주체의 정보를 처리했는지가 남지 않으므로 애플리케이션 단의 기록 설계가 필요합니다.
답변 2026-10-22
보안 자주 받는 질문
랜섬웨어에 대비하려면 백업을 어떻게 바꿔야 합니까
랜섬웨어에 대비한 백업의 기준은 백업이 있느냐가 아니라, 공격자가 운영 환경의 관리자 권한을 얻었을 때도 백업을 지우거나 암호화할 수 없느냐입니다. 운영과 분리된 저장소·계정에 두고, 보존 기간 동안 누구도 삭제할 수 없는 불변(immutable) 설정을 적용하고, 실제로 복구되는지 정기적으로 시험해야 합니다. KISA는 많은 피해 기업이 백업을 하고도 같은 저장소에 보관해 함께 암호화되면서 복구에 어려움을 겪었다고 경고합니다.
답변 2026-10-22
보안 자주 받는 질문
클라우드 보안 사고로 이어지는 설정 실수에는 어떤 것이 많습니까
클라우드에서 반복해서 지적되는 설정 실수는 외부에 공개된 저장소, 필요 이상으로 넓은 권한, 코드나 설정 파일에 남은 장기 액세스 키, 인터넷 전체에 열린 관리 포트, MFA 없는 관리자 계정입니다. 공통점은 서비스가 정상적으로 동작하는 상태라 사고가 나기 전까지 드러나지 않는다는 것입니다. 계정 단위 공개 차단, 임시 자격 증명, 최소 권한을 기본값으로 두고 예외는 사유와 함께 기록하는 방식이 효과적입니다.
답변 2026-10-22
함께 보면 좋은 자료AWS 장애 대응에 필요한 역할과 기록함께 보면 좋은 자료통합 보안 서비스 범위함께 보면 좋은 자료1분 보안 태세 자가 점검댓글
답변에 덧붙일 질문이나 경험을 남겨 주세요. 빌드업웍스가 확인한 뒤 게시합니다.
댓글을 불러오는 중입니다.
궁금한 점을 편하게 남겨 주세요
영업 연락은 드리지 않습니다. 빌드업웍스 엔지니어가 영업일 2~3일 안에 답변드리고, 카카오톡·텔레그램 채팅으로도 상담하실 수 있습니다.