개인정보 유출 신고 절차: 발견부터 72시간 대응 타임라인

개인정보 유출이 의심되면 유출을 알게 된 때부터 72시간 안에 두 가지를 해야 합니다. 하나는 이용자(정보주체)에게 알리는 통지, 다른 하나는 개인정보보호위원회에 하는 신고입니다. 신고는 개인정보보호위원회 유출신고 사이트(brss.pipc.go.kr)에서 하고, 접수는 위원회가 지정한 전문기관인 한국인터넷진흥원(KISA)이 맡습니다. 신고 대상은 ① 1천 명 이상의 개인정보가 유출된 경우, ② 민감정보나 고유식별정보가 유출된 경우, ③ 외부에서 불법 접근해 유출된 경우입니다. 해킹으로 유출됐다면 피해 인원이 적어도 신고 대상이 됩니다.

2026년 9월 11일부터 시행된 개정 개인정보 보호법과 시행령으로 기준이 한층 엄격해졌습니다. 유출이 최종 확인되지 않았더라도 객관적으로 유출 가능성이 높다고 합리적으로 판단되면 72시간 안에 이용자에게 통지해야 합니다. 랜섬웨어 같은 위조·변조·훼손도 신고·통지 대상에 들어갑니다. 서비스가 정보통신망법상 정보통신서비스 제공자라면 해킹 같은 침해사고는 24시간 안에 과학기술정보통신부나 KISA에 따로 신고해야 합니다. 두 시계는 별개로 돌아갑니다.

이 글은 조문 해설보다 실무 순서에 초점을 둡니다. 보안 담당자가 따로 없는 소규모 스타트업이 사고 당일부터 무엇을 어떤 순서로 해야 하는지 시간대별로 정리했습니다. 법령 해석이 애매한 지점은 개인정보보호위원회의 유출 등 대응 안내서 원문과 법률 자문으로 꼭 확인하시기 바랍니다.

먼저 판단할 것: 신고 대상인가, 시계는 언제 시작됐나

사고 대응에서 가장 흔히 놓치는 부분은 "알게 된 때"를 늦게 잡는 것입니다. 대표에게 보고된 시점이나 원인 분석이 끝난 시점이 아니라, 담당자가 이상 징후를 유출 또는 유출 가능성으로 인식한 시점부터 시계가 돈다고 보고 움직이는 편이 안전합니다. 정보통신망법의 침해사고 신고도 2024년 개정 이후 보안 담당자 같은 관계자가 알게 된 시점이 기준이라고 보도된 바 있습니다.

판단 기준은 아래와 같습니다.

질문	예라면
외부에서 불법 접근한 흔적이 있는가	인원과 상관없이 위원회 신고 대상이고, 침해사고 24시간 신고도 검토
1천 명 이상 영향이 있는가	위원회 신고 대상
주민등록번호 같은 고유식별정보나 건강 정보 같은 민감정보가 포함됐는가	위원회 신고 대상
유출이 확정되지 않았지만 접근 흔적은 있는가	유출 가능성 통지 대상인지 검토(72시간)
1만 명 이상의 개인신용정보가 유출됐는가(상거래기업·법인)	신용정보법에 따른 신고 대상

신고 대상이 아니더라도 이용자 통지 의무는 그대로 남습니다. 신고는 규모나 유형으로 거르지만, 통지는 유출된 이용자 모두에게 해야 한다는 점을 기억해 두세요. 신고하지 않으면 개인정보 보호법 제75조 제2항 제18호에 따라 3천만 원 이하의 과태료가 부과될 수 있습니다. 개정법에서는 법정 기한 안에 신고·통지를 하지 않고 피해 확산 방지 조치도 하지 않으면 과징금이 최대 30%까지 가중됩니다. 반대로 조기 탐지와 신속한 신고·통지는 감경 사유로 반영됩니다. 빨리 알리는 쪽이 법적으로도 유리합니다.

0~2시간: 격리하고, 지우지 말고, 기록하기

첫 두 시간의 목표는 피해 확산을 막되 증거는 보존하는 것입니다. 급한 마음에 서버를 다시 만들거나 로그를 정리하면 나중에 유출 범위를 산정할 근거가 사라집니다.

사고 기록 문서 열기: 인지 시각, 인지한 사람, 최초 징후를 분 단위로 적습니다. 이 문서가 나중에 신고서의 "유출 시점과 경위"가 됩니다.
접근 차단: 유출 경로로 의심되는 API 키, 관리자 계정, DB 자격 증명을 회전(rotate)합니다. 취약한 엔드포인트는 삭제하지 말고 기능 플래그나 WAF 규칙으로 막습니다.
로그 스냅샷: 웹 서버, 애플리케이션, DB 감사 로그, 클라우드 감사 로그(CloudTrail 등)를 읽기 전용 저장소로 복사합니다. 로그 로테이션 주기가 짧다면 즉시 보존 기간을 늘립니다.
디스크·DB 스냅샷: 침해된 인스턴스는 종료하지 말고 스냅샷을 뜬 뒤 네트워크를 격리합니다.

로그 보존은 평소 설정이 사고 당일의 성패를 가릅니다. 흔한 문제는 로그가 너무 빨리 지워지거나, 남아 있어도 "누가 무엇을 조회했는지" 알 수 없는 경우입니다.

// 취약한 예: 요청 경로만 남아 영향받은 이용자를 특정할 수 없다
app.use((req, res, next) => {
  console.log(`${req.method} ${req.path}`);
  next();
});

// 개선한 예: 주체·대상·결과를 구조화해 남기고, 개인정보 원문은 기록하지 않는다
app.use((req, res, next) => {
  res.on("finish", () => {
    logger.info({
      ts: new Date().toISOString(),
      actorId: req.user?.id ?? null,      // 요청한 계정
      ip: req.ip,
      method: req.method,
      route: req.route?.path,             // /api/orders/:id
      targetId: req.params.id ?? null,    // 조회된 리소스
      status: res.statusCode,
      bytes: Number(res.getHeader("content-length") ?? 0),
    });
  });
  next();
});

접속기록 보관 기간과 항목은 안전성 확보조치 기준에서 정하고 있으니, 평소 설정은 개인정보 안전성 확보조치 기준, 개발자가 구현할 항목을 참고해 미리 맞춰 두세요.

2~24시간: 유출 범위 산정과 침해사고 신고

이 구간에서는 누구의, 어떤 항목이, 언제부터 언제까지 노출됐는지를 좁힙니다. 처음부터 정확한 숫자가 나올 필요는 없습니다. "최대 범위"를 먼저 잡고 근거가 생길 때마다 줄여 나가는 방식이 현실적입니다.

예를 들어 주문 조회 API의 권한 검사 누락(IDOR 취약점)이 원인이라면, 위에서 남긴 구조화 로그로 "본인 것이 아닌 리소스를 조회한 요청"을 뽑을 수 있습니다.

-- 의심 기간 동안 타인의 주문을 성공적으로 조회한 요청 집계
SELECT l.actor_id,
       COUNT(DISTINCT l.target_id) AS leaked_orders,
       MIN(l.ts) AS first_seen,
       MAX(l.ts) AS last_seen
FROM access_logs l
JOIN orders o ON o.id = l.target_id
WHERE l.route = '/api/orders/:id'
  AND l.status = 200
  AND l.ts BETWEEN '2026-10-20' AND '2026-10-27'
  AND o.user_id <> l.actor_id
GROUP BY l.actor_id
ORDER BY leaked_orders DESC;

여기서 나온 target_id를 주문의 user_id로 다시 매핑하면 통지 대상자 목록이 됩니다. 응답에 포함된 필드(이름, 연락처, 주소 등)를 코드에서 확인해 유출 항목을 확정합니다.

범위를 좁히는 동안 병행할 일이 있습니다.

침해사고 24시간 신고: 외부 공격이 원인이고 정보통신서비스 제공자에 해당하면 KISA 침해사고 신고(privacy.kisa.or.kr 등 KISA 안내 채널)를 진행합니다. 보도에 따르면 개정 정보통신망법은 정보가 불완전해도 우선 신고하고, 이후 확인된 내용을 보완 신고하는 절차를 두고 있습니다.
원인 차단 배포: 권한 검사 추가 같은 핫픽스를 배포하고, 배포 시각을 사고 기록에 남깁니다.
외부 지원 요청: 원인이 불분명하거나 침해 흔적이 넓다면 KISA 기술 지원이나 외부 포렌식 업체 투입을 이 시점에 결정합니다.

24~72시간: 이용자 통지와 위원회 신고

통지 문안에 들어갈 내용

개인정보보호위원회가 안내하는 신고 항목은 아래 여섯 가지이며, 통지문도 이 항목을 기준으로 쓰면 빠뜨릴 일이 줄어듭니다. 개정법에서는 분쟁조정 신청 방법과 손해배상 청구 방법도 통지 항목에 추가됐습니다.

유출된 개인정보 항목
유출 시점과 경위
피해를 최소화하기 위해 이용자가 할 수 있는 방법
회사의 대응 조치와 피해 구제 절차
피해 신고·상담 부서와 연락처
분쟁조정·손해배상 청구 방법

[예시 서비스] 개인정보 유출 사실 안내

안녕하세요, 예시 서비스(example.com)입니다.
2026년 10월 25일 14시경 주문 조회 기능의 권한 검사 오류로 일부 고객님의
주문 정보가 다른 이용자에게 노출된 사실을 확인했습니다.

1. 유출 항목: 이름, 휴대전화 번호, 배송지 주소, 주문 상품명
   (결제 카드 번호와 비밀번호는 포함되지 않았습니다)
2. 유출 시점과 경위: 2026.10.20 ~ 2026.10.25, 주문 조회 API 권한 검사 누락
3. 회사 조치: 10월 25일 16시 해당 기능 차단 및 수정 배포, 관계기관 신고
4. 고객님께 권하는 조치: 배송·결제를 사칭한 문자나 전화에 주의해 주시고,
   의심 연락은 아래 창구로 알려 주세요.
5. 피해 구제: 피해 신고 접수 후 개별 안내, 개인정보 분쟁조정위원회
   분쟁조정 신청 및 손해배상 청구 방법 안내 링크
6. 문의: 개인정보 보호 담당 [email protected] / 02-000-0000

불편과 걱정을 끼쳐 드려 진심으로 사과드립니다.

문안을 쓸 때는 사실만, 확인된 범위만 적습니다. "피해는 없을 것으로 보입니다" 같은 단정은 피하고, 아직 확인 중인 부분은 "확인 중이며 추가로 안내하겠다"고 적습니다. 유출 가능성 단계에서 통지했다면 조사 결과가 나온 뒤 결과를 다시 알리는 것이 이용자 신뢰에 도움이 됩니다.

신고서 제출

원칙: brss.pipc.go.kr에서 온라인으로 신고합니다.
예외: 해외 사업자라서 국내 휴대폰 인증이 안 되거나 시스템 장애가 있을 때만 이메일([email protected])로 신고서 양식을 보냅니다.
금융권: 은행·증권·보험 같은 금융기관이나 신용정보회사는 금융감독원 안내를 따릅니다.

신고서의 "피해 최소화 대책·조치 및 결과" 항목에는 2~24시간 구간에 한 조치를 시각과 함께 적습니다. 72시간 안에 모든 것이 확정되지 않았다면 확인된 내용으로 먼저 신고하고 이후 보완하는 편이 기한을 넘기는 것보다 낫습니다.

72시간 이후: 재발 방지와 기록 정리

신고와 통지가 끝나도 사고 대응은 끝나지 않았습니다. 위원회 조사에서는 원인이 제거됐는지, 같은 유형의 취약점이 다른 곳에 남아 있지 않은지를 보게 됩니다.

동일 패턴 전수 점검: 원인이 권한 검사 누락이었다면 리소스 ID를 받는 모든 API를 점검합니다. 한 곳에서 생긴 실수는 대개 다른 곳에도 있습니다.
탐지 규칙 추가: 한 계정이 짧은 시간에 서로 다른 리소스 ID를 대량 조회하면 알림이 가도록 설정합니다.
자격 증명 최종 정리: 사고 기간에 노출됐을 수 있는 키와 토큰을 모두 회전했는지 목록으로 확인합니다.
사후 보고서 작성: 타임라인, 원인, 영향 범위, 조치, 남은 과제를 한 문서로 남깁니다. 비난 없는(blameless) 형식으로 써야 다음 사고 때 사람들이 숨기지 않고 빨리 보고합니다.
대응 계획 문서화: 이번에 실제로 걸린 시간을 기준으로 연락망, 신고 계정, 통지 템플릿을 미리 준비해 둡니다.

사고 전에 미리 준비할 체크리스트

사고 당일에 처음 하면 시간이 가장 많이 걸리는 일들입니다. 평소에 10분씩만 투자해 두세요.

유출신고 사이트 접속 방법과 신고 담당자(대표 또는 개인정보 보호책임자) 지정
접속기록·감사 로그 보관 기간 확인과 별도 저장소 백업
로그에 계정 ID, 대상 리소스 ID, 응답 코드가 남는지 확인
이용자 연락처를 기준으로 한 일괄 통지 수단(이메일·문자·앱 푸시) 확보
통지문·홈페이지 공지 템플릿 초안
외부 포렌식·법률 자문 연락처
우리 서비스가 정보통신서비스 제공자로서 침해사고 24시간 신고 대상인지 사전 확인

자주 묻는 질문

유출 인원이 10명뿐이어도 신고해야 하나요?

원인이 외부의 불법 접근(해킹)이거나 민감정보·고유식별정보가 포함됐다면 인원과 상관없이 신고 대상입니다. 내부 실수로 일반 정보가 소수에게 노출된 경우라면 신고 대상이 아닐 수 있지만, 이용자 통지는 해야 합니다.

유출인지 아직 확실하지 않은데 72시간을 기다려도 되나요?

개정법에서는 불법 접근이 있었지만 대상자를 특정하기 어렵거나, 일부 유출이 확인돼 다른 이용자도 유출 가능성이 있는 경우에 유출 가능성을 안 때부터 72시간 안에 통지하도록 하고 있습니다. "확정될 때까지 기다린다"는 접근은 더 이상 안전하지 않습니다.

개인정보 유출 신고와 KISA 침해사고 신고는 같은 건가요?

다릅니다. 개인정보 유출 신고는 개인정보 보호법에 따라 개인정보보호위원회(유출신고 사이트)에 하는 것이고, 침해사고 신고는 정보통신망법에 따라 과학기술정보통신부나 KISA에 하는 것입니다. 해킹으로 개인정보가 유출됐다면 두 가지가 모두 필요할 수 있고, 기한도 각각 72시간과 24시간으로 다릅니다.

정리

유출 또는 유출 가능성을 안 때부터 72시간 안에 이용자 통지와 위원회 신고를 마치고, 해킹이라면 침해사고 24시간 신고를 따로 챙깁니다.
첫 두 시간은 격리와 로그 보존, 24시간까지는 범위 산정, 72시간까지는 통지와 신고라는 순서를 기억하면 됩니다.
기한 안에 확인된 사실로 먼저 알리고 이후 보완하는 편이 법적으로도, 이용자 신뢰 측면에서도 낫습니다.
사고 당일의 속도는 평소 로그 설계와 템플릿 준비가 결정합니다. 우리 서비스의 로그와 권한 구조를 직접 점검하기 어렵다면 무료 분석 신청으로 점검을 받아볼 수 있습니다.