개인정보 손해배상책임보험 의무가입 기준과 스타트업 준비

결론부터 말하면, 2026년 11월 현재 시행령 기준으로는 전년도(법인은 직전 사업연도) 매출액등이 10억 원 이상이고, 전년도 말 기준 직전 3개월 동안 저장·관리한 정보주체 수가 일일평균 1만 명 이상이면 개인정보 손해배상책임 보장 의무 대상입니다(개인정보 보호법 제39조의7, 시행령 제48조의7). 의무 대상이면 보험·공제에 가입하거나 준비금을 적립해야 합니다. 최저가입금액은 매출과 정보주체 수 구간에 따라 5천만 원에서 10억 원까지입니다.

공공기관, 공익법인, 등록된 비영리민간단체는 제외됩니다. 소상공인이 일정 요건을 갖춘 수탁자에게 처리를 위탁한 경우, 그리고 다른 법률에 따라 이미 같은 범위를 보장하는 보험 등에 가입한 경우도 제외됩니다. 개인정보보호위원회는 2025년 3월 의무 대상을 "매출액 1,500억 원 이상, 정보주체 100만 명 이상"으로 좁히는 합리화 방안을 발표했습니다. 다만 이 글을 쓰는 시점까지 시행령 개정이 공포·시행됐는지는 확인하지 못했습니다. 2026년 10월 보도도 여전히 현행 기준을 전제로 하고 있습니다. 따라서 지금은 현행 기준으로 판단하고, 개정 공포 여부를 국가법령정보센터에서 다시 확인하는 것이 안전합니다.

이 글은 보험 상품 비교가 아니라 개발·운영팀이 직접 해야 하는 일을 다룹니다. 정보주체 수를 DB에서 어떻게 세는지, 보험사 질문서에 어떤 증빙으로 답하는지, 실제 유출이 났을 때 안전조치 이행 여부가 배상과 어떻게 연결되는지를 정리합니다.

의무 대상 판단: 두 조건과 제외 사유

시행령 제48조의7 제1항은 아래 두 요건을 모두 갖춘 자를 "가입대상개인정보처리자"로 정합니다.

1. 전년도(법인은 직전 사업연도) 매출액등 10억 원 이상
2. 전년도 말 기준 직전 3개월간 개인정보가 저장·관리되고 있는 정보주체 수가 일일평균 1만 명 이상
   • 해당 연도에 영업양수·분할·합병 등으로 개인정보를 이전받았다면 이전받은 시점에 1만 명 이상인지로 판단합니다.

판단할 때 실무에서 자주 헷갈리는 부분은 다음과 같습니다.

• 매출 기준은 회사 전체입니다. 개인정보를 다루는 서비스의 매출만 보는 것이 아닙니다. 초기 스타트업은 정보주체가 수십만 명이어도 매출 10억 원 미만이면 대상이 아닙니다.
• 기준 시점이 매년 바뀝니다. 올해 대상 여부는 작년 실적으로 정해집니다. 연초 결산이 끝나면 다시 판단해야 합니다.
• B2B SaaS도 대상이 될 수 있습니다. 고객사 담당자 계정, 고객사의 최종 사용자 데이터를 "저장·관리"하고 있다면 산정 범위를 따져봐야 합니다. 수탁자로서 처리하는 데이터의 산정 방식은 계약 구조에 따라 해석이 달라질 수 있습니다. 애매하면 법무 검토를 받는 편이 좋습니다.

정보주체 수 산정: DB에서 실제로 세는 법

산정 기준은 방문자 수(UV)나 페이지뷰가 아니라 "저장·관리되고 있는" 정보주체 수입니다. 해설 자료들은 탈퇴·휴면 회원이라도 다른 법령에 따라 보관 중이면 포함되고, 임직원 정보는 제외된다고 안내합니다. 그래서 users 테이블의 활성 회원 수만 세면 실제보다 적게 나오는 경우가 많습니다.

흔한 잘못된 산정

-- 잘못된 예: 활성 회원만, 그것도 오늘 기준 한 시점만 센다
SELECT COUNT(*) FROM users WHERE status = 'ACTIVE';

이 쿼리는 세 가지를 놓칩니다.

• 휴면 분리 테이블(dormant_users), 탈퇴 후 법정 보관 테이블(withdrawn_retention)
• 비회원 주문자, 상담 문의자, 이벤트 응모자처럼 users 밖에 저장된 사람
• "직전 3개월 일일평균"이라는 기간 개념

고친 산정

일별 스냅샷 테이블이 있으면 가장 정확합니다. 없으면 생성·삭제 시각으로 일별 보유 인원을 다시 계산합니다. 아래 예시는 PostgreSQL 기준이고, 전년도가 2025년이라고 가정했습니다.

-- 1) 여러 테이블에 흩어진 정보주체를 식별자 기준으로 통합
WITH subjects AS (
  SELECT phone_hash AS sid, created_at, purged_at FROM users
  UNION ALL
  SELECT phone_hash, created_at, purged_at FROM dormant_users
  UNION ALL
  SELECT phone_hash, withdrawn_at, purged_at FROM withdrawn_retention
  UNION ALL
  SELECT phone_hash, created_at, purged_at FROM guest_orders
),
-- 2) 동일인 중복 제거: 가장 이른 저장 시점 ~ 가장 늦은 파기 시점
merged AS (
  SELECT sid,
         MIN(created_at) AS first_stored,
         CASE WHEN COUNT(*) FILTER (WHERE purged_at IS NULL) > 0
              THEN NULL ELSE MAX(purged_at) END AS last_purged
  FROM subjects GROUP BY sid
),
-- 3) 2025-10-01 ~ 2025-12-31 하루씩 보유 인원 계산
days AS (
  SELECT d::date AS day
  FROM generate_series('2025-10-01'::date, '2025-12-31'::date, '1 day') d
)
SELECT ROUND(AVG(cnt)) AS daily_avg_subjects
FROM (
  SELECT day,
         (SELECT COUNT(*) FROM merged
           WHERE first_stored < day + 1
             AND (last_purged IS NULL OR last_purged >= day + 1)) AS cnt
  FROM days
) t;

주의할 점:

• 중복 제거 키(위 예시의 phone_hash)는 서비스마다 다릅니다. 키를 잘못 고르면 동일인이 여러 번 세어집니다.
• 실제로 purged_at이 기록되지 않는 시스템이 많습니다. 파기 이력이 없으면 산정도 증빙도 어렵습니다. 파기 로그 설계는 개인정보 파기 방법: 회원 탈퇴 후 DB·백업·로그 처리법을 참고하세요.
• 쿼리, 실행 일시, 결과값을 문서로 남겨 두세요. 이 숫자가 보험 가입금액 구간과 감독기관 소명의 근거가 됩니다.
• 앞으로를 위해 일별 집계를 배치로 쌓아 두면 매년 같은 계산을 반복하지 않아도 됩니다.

최저가입금액 구간

최저가입금액(준비금이면 최소적립금액)은 시행령 [별표 1의4]에 정해져 있습니다. 보험사 안내 자료를 기준으로 정리하면 다음과 같습니다.

같은 보험사 안내 페이지라도 버전마다 일부 칸(10만~100만 명, 800억 원 초과)의 표기가 달랐습니다. 계약 전에는 국가법령정보센터에서 별표 1의4 원문으로 확인하세요. 보험과 준비금을 함께 쓴다면 두 금액의 합이 최저가입금액 이상이면 됩니다(시행령 제48조의7 제4항).

최저가입금액은 하한일 뿐입니다. 2026년 10월 파이낸셜뉴스 보도에 따르면 가입 기업의 약 80%가 최저가입금액에 맞춰 계약했습니다. 같은 기사는 "상단인 10억 원이라도 배상 대상이 100만 명이면 1인당 1,000원"이라고 지적합니다. 정보주체가 많다면 가입금액을 실제 노출 규모에 맞춰 정하는 것이 합리적입니다.

미가입 시 제재와 2026년 개정법 맥락

보도에 따르면 보험 미가입 등으로 시정조치 명령을 받고도 따르지 않으면 개인정보 보호법 제75조에 따라 3천만 원 이하 과태료가 부과될 수 있습니다. 같은 기사는 개인정보위가 아직 이 사유로 과태료를 처분한 사례가 없다고 전합니다. 2026년 5월 보도에서는 정책평가 기준 가입률이 6.9%에 그쳤다고 합니다.

하지만 처분 사례가 없다는 점을 근거로 미뤄 두기는 어렵습니다. 2026년 9월 11일부터 시행된 개정 개인정보 보호법은 반복적·중대한 침해에 대한 과징금 상한을 일정 요건에서 전체 매출액의 10%로 높였습니다. 안전성 확보조치 위반 과태료도 1차 900만 원, 2차 1,800만 원, 3차 이상 3,000만 원으로 올렸습니다. 사고가 나면 보험 미가입 사실도 함께 드러납니다. 그 시점의 판단은 평소보다 엄격할 수 있습니다.

보험사 질문서에 답하기 위한 기술적 증빙

보험 가입 단계에서는 보통 회사 개요, 정보주체 수, 보안 현황을 묻습니다. 문항은 보험사마다 다릅니다. 대부분은 「개인정보의 안전성 확보조치 기준」 항목과 겹치므로, 이 기준에 맞춰 증빙을 미리 모아 두면 질문서와 감독기관 대응에 같이 쓸 수 있습니다.

"예"라고만 쓰지 말고 언제 기준으로 사실인지 보여주는 출력물을 남기세요. 예를 들어 클라우드 설정은 명령 출력을 날짜와 함께 저장합니다.

# 예시: 증빙 수집 스크립트 (조회 전용 권한으로 실행)
DATE=$(date +%F)
aws rds describe-db-instances \
  --query 'DBInstances[].{id:DBInstanceIdentifier,encrypted:StorageEncrypted}' \
  > evidence/${DATE}_rds_encryption.json
aws iam generate-credential-report >/dev/null && sleep 5
aws iam get-credential-report --query Content --output text | base64 -d \
  > evidence/${DATE}_iam_credential_report.csv   # MFA 미설정 계정 확인용

질문서 답변이 실제와 다르면 문제가 됩니다. 상법상 고지의무 위반으로 계약 해지나 보험금 지급 분쟁이 생길 수 있습니다. "관리자 MFA 적용"이라고 답했는데 실제로는 일부 계정에만 걸려 있었다면, 사고 조사에서 그대로 드러납니다. 모르는 항목은 "부분 적용"으로 정직하게 답하는 편이 낫습니다. 증빙을 정리하는 방식은 고객사 보안 점검 대응 가이드와 거의 같습니다.

실제 유출 시 보상 범위와 안전조치 이행의 관계

보험이 무엇을 대신 내 주는지는 법 구조부터 보면 이해가 쉽습니다.

• 법 제39조(손해배상책임): 정보주체가 손해배상을 청구하면 개인정보처리자가 고의·과실이 없음을 입증하지 못하는 한 책임을 면할 수 없습니다. 고의 또는 중대한 과실로 유출된 경우에는 손해액의 5배 이내 배상이 인정될 수 있습니다.
• 법 제39조의2(법정손해배상): 손해액을 입증하지 않아도 300만 원 이하 범위에서 배상을 청구할 수 있습니다.
• 제39조의7: 위 두 책임의 이행을 위해 보험·준비금을 갖추라는 조항입니다.

이 구조에서 안전조치 이행 증빙은 두 번 쓰입니다. 한 번은 "과실 없음"이나 "중대한 과실 아님"을 다툴 때, 또 한 번은 과징금·과태료 산정에서 위반 여부를 따질 때입니다. 보험은 배상금을 대신 내 주는 장치일 뿐, 과실 판단 자체를 바꿔 주지는 않습니다.

보상 범위는 약관 기준입니다. 한 보험사의 상품 안내를 보면 기본 담보는 개인정보의 "우연한" 유출·분실·도난 등으로 생긴 법률상 손해배상금과 소송·변호사 비용입니다. 원인 조사, 통지, 콜센터 같은 위기관리 비용은 특약으로 붙습니다. 임원의 고의·범죄행위로 생긴 손해, 보험 개시일 전에 발견된 사고는 보상하지 않습니다. 이 안내 페이지에는 "안전조치 미이행"을 면책 사유로 적은 문구가 없었습니다. 그래도 공개된 면책 목록은 "주요" 사항일 뿐이므로 약관 전문을 확인해야 합니다.

과징금은 기본 담보가 아닌 경우가 많습니다. 개인정보위는 2025년 방안에서 분쟁조정 합의금이 보장 범위에 포함된다는 점을 약관에 명시하고, 일부 상품에만 있는 과징금 특약을 넓히겠다고 밝혔습니다. 가입할 때 다음 세 가지를 확인하세요.

• 분쟁조정 합의금이 보상 대상에 들어가는가
• 과징금 특약이 있는가, 한도는 얼마인가
• 수탁사(클라우드·외주 개발사) 과실로 생긴 유출도 보상하는가

스타트업 실행 체크리스트

• 작년 매출액등 10억 원 이상인지 재무팀과 확인
• 위 SQL처럼 전년도 10~12월 일일평균 정보주체 수 산정, 쿼리와 결과 문서화
• 휴면·탈퇴 보관·비회원 데이터 테이블 목록 정리
• 별표 1의4 원문으로 최저가입금액 구간 확인, 실제 규모에 맞게 가입금액 결정
• 보험 또는 준비금 중 선택(병행 시 합산액 확인)
• 안전성 확보조치 항목별 증빙을 날짜와 함께 수집
• 약관에서 분쟁조정 합의금, 과징금 특약, 수탁사 사고, 면책 사유 확인
• 매년 결산 직후 대상 여부 재판단, 시행령 개정 공포 여부 확인

ISMS-P를 준비 중이라면 증빙 대부분이 겹칩니다. 순서는 ISMS-P 준비, 스타트업 개발팀은 언제 무엇부터 할까를 참고하세요.

자주 묻는 질문

매출 기준을 넘었지만 회원이 9천 명입니다. 대상인가요?

아닙니다. 두 요건을 모두 갖춰야 합니다. 다만 휴면·탈퇴 보관 회원과 비회원 주문자까지 합치면 1만 명이 넘는 경우가 많으니, 저장·관리 기준으로 다시 세어 보세요.

개정안대로 1,500억 원·100만 명으로 바뀌면 지금 가입은 소용없나요?

개정이 시행되기 전까지는 현행 기준이 적용됩니다. 의무가 사라져도 유출 사고의 배상책임은 그대로입니다. 개인정보위도 비대상 기업의 자발적 가입을 지원하겠다고 밝혔습니다.

보험에 들면 유출 사고 때 과징금도 해결되나요?

기본 담보는 대개 법률상 손해배상금과 소송비용입니다. 과징금은 별도 특약이 있어야 하며, 특약이 있는 상품도 일부입니다. 안전조치 위반에 따른 행정 제재는 보험으로 피할 수 없다고 보는 편이 맞습니다.

정리

• 현행 기준은 전년도 매출액등 10억 원 이상이면서 직전 3개월 일일평균 정보주체 1만 명 이상이며, 최저가입금액은 5천만~10억 원입니다.
• 정보주체 수는 UV가 아니라 휴면·탈퇴 보관·비회원을 포함한 "저장·관리" 기준으로, 일일평균을 내서 근거와 함께 남깁니다.
• 보험은 배상금을 대신 내 줄 뿐입니다. 과실 판단과 과징금·과태료는 안전조치 이행 증빙으로 결정됩니다.
• 대상 축소 개정안은 아직 시행이 확인되지 않았으니, 현행 기준으로 준비하고 매년 다시 확인하세요.

정보주체 수 산정이나 안전조치 증빙 정리를 직접 하기 어렵다면 무료 분석 신청으로 현재 상태를 점검받아 볼 수 있습니다.