수탁사에서 개인정보가 유출됐다면? 위탁사가 반드시 해야 할 조치
개인정보를 직접 보유하고 있는 회사에서 개인정보 유출사고가 발생하면 대응 주체가 비교적 명확하다.
그렇다면 개인정보 처리를 외부 업체에 위탁한 상황에서 수탁사의 시스템에서 개인정보가 유출됐다면 어떻게 해야 할까?
많은 기업이 "수탁사에서 발생한 사고이므로 수탁사가 신고하고 대응하면 된다"고 생각한다.
하지만 이것은 매우 위험한 접근이다.
개인정보 보호법에서는 개인정보 처리업무를 위탁한 위탁자에게도 수탁자에 대한 관리·감독 책임을 부여하고 있기 때문이다.
따라서 수탁사에서 개인정보 유출사고가 발생하면 위탁사는 단순히 사고 내용을 전달받는 수준이 아니라, 사고 확인 → 확산 차단 → 사실관계 조사 → 유출 범위 판단 → 신고·통지 검토 → 피해 최소화 → 재발방지 → 수탁사 관리·감독 개선까지 체계적으로 대응해야 한다.
1. 먼저 '수탁사 사고'라는 생각부터 바꿔야 한다
개인정보 보호법 제26조는 개인정보 처리업무를 위탁하는 경우 위탁계약에 개인정보 보호를 위한 사항을 포함하도록 하고 있다.
또한 위탁자는 수탁자가 개인정보를 안전하게 처리하는지를 교육하고, 처리 현황 점검 등 필요한 관리·감독을 해야 한다.
즉,
수탁사에서 개인정보가 유출됐더라도 위탁자의 책임이 사라지는 것은 아니다.
개인정보 보호법은 위탁자가 수탁자를 적절하게 관리·감독하도록 요구하고 있다.
따라서 사고가 발생하면 위탁사는 다음과 같은 관점으로 접근해야 한다.
"수탁사에서 발생한 사고"가 아니라
"우리 회사가 위탁한 개인정보 처리 과정에서 발생한 개인정보 침해사고"
라고 보는 것이 실무적으로 중요하다.
2. 수탁사에서 사고가 발생했다는 연락을 받았다면
가장 먼저 해야 할 일은 사고 대응 조직을 가동하는 것이다.
수탁사로부터 다음과 같은 내용을 우선 확보해야 한다.
- 사고 발생 일시
- 사고 인지 일시
- 사고 유형
- 공격 또는 유출 경로
- 공격자의 침투 경로
- 유출된 개인정보 항목
- 유출 대상 정보주체 수
- 실제 유출 여부
- 유출이 확인된 개인정보 건수
- 현재까지 확인된 피해 범위
- 공격자가 확보한 데이터
- 데이터 외부 전송 여부
- 추가 침해 가능성
- 현재 진행 중인 차단 조치
- 관계기관 신고 여부
- 수탁사의 사고 담당자 및 연락처
특히 "몇 명이 유출됐는가?"만 확인해서는 안 된다.
예를 들어 고객 10만 명의 정보가 저장된 DB에서 공격자가 1만 명의 정보를 다운로드했다면 단순히 "DB 접근 사고"로 볼 것이 아니라 실제 어떤 개인정보가 외부로 유출되었는지를 확인해야 한다.
3. 사고 초기에 가장 중요한 것은 '증거 보존'이다
사고가 발생하면 수탁사에게 무조건 시스템을 초기화하거나 서버를 재설치하도록 요구하는 것은 바람직하지 않다.
사고 원인과 유출 범위를 확인할 수 있는 증적이 사라질 수 있기 때문이다.
위탁사는 수탁사에 다음과 같은 증적을 보존하도록 요구해야 한다.
주요 증적
- 서버 및 DB 로그
- 접근 로그
- 인증 로그
- VPN 로그
- 방화벽 로그
- WAF 로그
- EDR/백신 로그
- 계정 생성·변경·삭제 로그
- 개인정보 조회 로그
- 개인정보 다운로드 로그
- 파일 접근 로그
- 관리자 작업 로그
- 네트워크 트래픽 로그
- 클라우드 감사 로그
- 공격 IP 및 IOC
- 악성코드 및 침해 흔적
- 포렌식 이미지
특히 개인정보가 실제로 외부로 전송되었는지를 확인할 수 있는 로그가 중요하다.
4. 동시에 추가 유출을 막아야 한다
사고 조사를 하는 동안에도 공격자가 계속 시스템에 접근하고 있을 수 있다.
따라서 조사와 동시에 확산 차단 조치를 수행해야 한다.
예를 들어 다음과 같은 조치가 가능하다.
- 침해 계정 비활성화
- 관리자 계정 비밀번호 변경
- API Key 및 Access Key 폐기
- 세션 강제 종료
- 의심 IP 차단
- VPN 계정 차단
- 외부 접근 제한
- 침해 서버 네트워크 격리
- 취약 서비스 차단
- 침해된 API 차단
- 악성 파일 제거
- 추가 데이터 반출 경로 차단
단, 증거 보존을 고려하여 무조건 시스템을 종료하기보다는 사고 대응 전문가와 협의하여 차단 범위를 결정하는 것이 좋다.
5. 유출 개인정보의 범위를 정확하게 파악해야 한다
사고 대응에서 가장 어려운 부분 중 하나가 바로 이것이다.
수탁사가 "개인정보 일부가 유출된 것으로 추정된다"고 보고했다고 해서 그대로 받아들여서는 안 된다.
위탁사 입장에서는 최소한 다음 사항을 확인해야 한다.
개인정보 항목
- 이름
- 전화번호
- 이메일
- 주소
- 생년월일
- ID
- 비밀번호
- 암호화된 개인정보
- 결제정보
- 계좌정보
- 신용카드정보
- 건강정보 등 민감정보
- 주민등록번호 등 고유식별정보
유출 규모
- 전체 대상자 수
- 실제 유출 확인 대상자 수
- 유출 추정 대상자 수
- 유출 파일 수
- 데이터 건수
- 데이터 용량
유출 방법
- DB 조회
- DB Dump
- 파일 다운로드
- 이메일 전송
- 클라우드 저장소 반출
- API 호출
- 화면 캡처
- 관리자 계정 탈취
- 악성코드에 의한 정보 탈취
이러한 내용을 바탕으로 실제 유출과 유출 가능성을 구분해서 판단해야 한다.
6. 개인정보 유출 신고 여부를 판단한다
개인정보 보호법 제34조는 개인정보 유출 등을 알게 된 경우 정보주체에 대한 통지와 관계기관 신고에 관한 의무를 규정하고 있다.
현재 시행령 기준으로는 다음과 같은 경우 개인정보 유출 신고 대상이 될 수 있다.
- 1천명 이상의 정보주체 개인정보가 유출된 경우
- 민감정보 또는 고유식별정보가 유출된 경우
- 개인정보처리시스템 또는 개인정보 처리에 이용되는 정보기기에 대한 외부의 불법적인 접근으로 개인정보가 유출된 경우
해당 요건에 해당하는 경우 시행령은 유출 사실을 알게 된 때부터 72시간 이내 신고하도록 규정하고 있다.
따라서 위탁사는 사고 발생 직후부터 72시간을 중요한 기준점으로 관리해야 한다.
여기서 중요한 것은,
"수탁사가 신고했으니 위탁사는 아무것도 하지 않아도 된다."
라고 판단해서는 안 된다는 것이다.
수탁자는 개인정보 보호법 제26조 제8항에 따라 일정한 개인정보처리자의 의무가 준용되고 있으며, 제34조도 준용 대상에 포함되어 있다.
따라서 사고의 법적 주체와 신고·통지 의무는 위탁 구조, 개인정보 처리 관계, 사고 유형 등을 종합적으로 검토해서 판단해야 한다.
실무적으로는 위탁사와 수탁사가 각각 무엇을 신고하고 누가 정보주체에게 통지할 것인지 사고 초기에 명확하게 결정하는 것이 중요하다.
7. 정보주체 통지는 별도로 판단해야 한다
개인정보가 유출된 경우 정보주체에게 통지할 때에는 법에서 요구하는 내용을 포함해야 한다.
현재 법령상 주요 내용은 다음과 같다.
- 유출된 개인정보의 항목
- 유출된 시점과 경위
- 피해 최소화를 위해 정보주체가 할 수 있는 방법
- 개인정보처리자의 대응조치 및 피해 구제절차
- 피해 신고 등을 접수할 수 있는 담당부서 및 연락처
개인정보 보호법 제34조가 이러한 통지사항을 규정하고 있다.
따라서 위탁사는 수탁사가 작성한 사고 보고서를 그대로 고객 통지문으로 사용하는 것보다 법적 요건을 충족하는지 별도로 검토해야 한다.
8. "아직 정확한 원인을 모른다"는 이유로 대응을 늦추면 안 된다
개인정보 유출사고에서 흔히 발생하는 문제가 있다.
"포렌식 결과가 나올 때까지 기다리겠습니다."
하지만 사고 발생 초기에는 모든 사실관계가 확인되지 않는 것이 정상이다.
예를 들어 다음과 같은 상황이 발생할 수 있다.
1일차
- DB 접근 사실 확인
- 유출 여부 불명
2일차
- 특정 계정으로 대량 조회 확인
- 일부 데이터 외부 전송 정황 발견
3일차
- 유출 데이터 항목 확인
이런 상황이라면 처음부터 모든 정보를 확인한 뒤 대응하는 것이 아니라 확인된 사실을 기준으로 단계적으로 대응해야 한다.
특히 시행령은 신고 시점에 유출된 개인정보의 구체적인 항목이나 시점·경위를 모두 확인하지 못한 경우에도 확인된 내용을 우선 신고하고, 추가 확인되는 내용을 추가 신고할 수 있도록 규정하고 있다.
9. 수탁사의 사고조사 결과를 그대로 믿어서는 안 된다
위탁사 입장에서 상당히 중요한 부분이다.
수탁사는 사고의 원인을 조사하는 당사자이면서 동시에 사고에 대한 책임이 있는 당사자일 수 있다.
따라서 위탁사가 수탁사의 최종 보고서만 받아서 사고를 종결하는 것은 바람직하지 않다.
필요하다면 다음을 요구할 수 있다.
- 원본 로그
- 포렌식 결과
- 취약점 분석 결과
- 공격 경로 분석
- 계정 사용 이력
- 데이터 접근 이력
- 데이터 반출 이력
- 침해 IOC
- 재발방지 대책
- 보안 개선 계획
- 외부 전문기관 조사 결과
사고 규모가 크거나 법적 분쟁 가능성이 높은 경우에는 독립적인 포렌식 또는 보안 전문기관을 활용하는 것도 고려할 수 있다.
10. 위탁계약서를 반드시 다시 확인해야 한다
사고가 발생한 순간에는 계약서가 상당히 중요한 증거가 된다.
특히 다음 조항을 확인해야 한다.
개인정보 보호 관련 조항
- 개인정보 처리 목적 및 범위
- 개인정보 항목
- 보유 및 파기
- 접근권한 관리
- 암호화
- 로그 관리
- 보안점검
- 취약점 점검
- 침해사고 대응
사고 발생 관련 조항
- 사고 발생 즉시 통보
- 사고 통보 방법
- 사고 통보 시간
- 사고 조사 협조
- 증적 보존
- 관계기관 조사 협조
- 정보주체 통지 협조
- 피해 보상
- 손해배상
- 사고 대응 비용
- 법률비용
- 재발방지 조치
개인정보 보호법 시행령은 위탁계약에 수탁자의 의무 위반에 따른 손해배상 등 책임에 관한 사항도 포함하도록 하고 있다.
11. 사고 이후에는 수탁사 관리·감독이 핵심이다
개인정보 유출사고가 끝났다고 해서 위탁사의 역할이 끝나는 것은 아니다.
오히려 사고 이후가 중요하다.
개인정보 보호법 제26조에 따라 위탁자는 수탁자가 개인정보를 안전하게 처리하는지 관리·감독해야 한다. 시행령 역시 개인정보 관리 현황 점검 등을 위탁계약 및 감독사항으로 규정하고 있다.
따라서 사고 이후에는 다음과 같은 사항을 점검해야 한다.
기술적 조치
- 접근권한 재정비
- MFA 적용
- 관리자 계정 분리
- 개인정보 암호화
- DB 접근통제 강화
- 외부 접근 통제
- 네트워크 분리
- WAF/IPS/EDR 강화
- 로그 수집 강화
- 이상징후 탐지 강화
관리적 조치
- 개인정보 처리절차 개선
- 개인정보 취급자 교육
- 사고 대응절차 개선
- 비상연락망 정비
- 수탁사 보안점검 강화
- 재위탁 관리 강화
- 정기적인 보안점검
- 개인정보 최소 보유
12. 사고가 발생했다면 수탁사 평가도 다시 해야 한다
이번 사고를 단순히 "사고 처리"로 끝내지 말고 수탁사 보안 수준에 대한 재평가를 실시해야 한다.
예를 들어 다음과 같이 평가할 수 있다.
|
평가 영역
|
주요 점검사항
|
|
접근통제
|
관리자 접근, MFA, 계정관리
|
|
개인정보 보호
|
암호화, 마스킹, 최소수집
|
|
로그
|
개인정보 접근·다운로드 로그
|
|
탐지
|
이상행위 탐지 및 모니터링
|
|
취약점
|
취약점 진단 및 조치
|
|
사고대응
|
사고 탐지 및 보고체계
|
|
재위탁
|
재수탁사 관리
|
|
인력
|
개인정보취급자 교육
|
|
물리적 보안
|
IDC/사무실 접근통제
|
|
클라우드
|
IAM, 보안그룹, 저장소 접근통제
|
평가 결과에 따라
개선 요구 → 개선 확인 → 재점검 → 계약 유지 여부 판단
의 절차로 진행할 필요가 있다.
13. 특히 재위탁 여부를 확인해야 한다
실무에서 자주 놓치는 부분이다.
예를 들어 위탁사가 A업체에 개인정보 처리를 맡겼는데 A업체가 다시 B업체의 클라우드나 솔루션을 사용하고 있다면 실제 개인정보가 어디까지 전달됐는지를 확인해야 한다.
현재 개인정보 보호법은 수탁자가 위탁받은 개인정보 처리업무를 제3자에게 다시 위탁하려는 경우 위탁자의 동의를 받도록 규정하고 있다.
따라서 사고 발생 시 다음을 확인해야 한다.
위탁자 → 수탁자 → 재수탁자
구조에서
- 개인정보가 어느 시스템에 저장됐는지
- 누가 접근했는지
- 어느 업체가 처리했는지
- 어느 국가에서 처리했는지
- 누가 데이터를 보유하고 있었는지
- 재위탁 승인이 있었는지
를 확인해야 한다.
14. 사고대응 프로세스를 하나의 흐름으로 만들면
수탁사 개인정보 유출사고에 대한 위탁사의 대응 프로세스는 다음과 같이 구성할 수 있다.
① 사고 접수
↓
② 위탁사 CISO/CPO/개인정보 담당자 보고
↓
③ 비상대응체계 가동
↓
④ 추가 유출 차단
↓
⑤ 증적 보존
↓
⑥ 수탁사 사고조사
↓
⑦ 유출 개인정보 항목·규모 확인
↓
⑧ 정보주체 영향평가
↓
⑨ 개인정보 유출 신고 여부 판단
↓
⑩ 정보주체 통지 여부 판단
↓
⑪ 관계기관 대응
↓
⑫ 피해 최소화 조치
↓
⑬ 원인 및 책임 분석
↓
⑭ 수탁사 개선조치 요구
↓
⑮ 재발방지 대책 수립
↓
⑯ 수탁사 재평가 및 계약 개선
15. 위탁사가 사고 발생 직후 확인해야 할 핵심 질문
실제 사고가 발생했다면 다음 질문부터 시작하면 된다.
사고 확인
- 언제 발생했는가?
- 언제 발견했는가?
- 누가 발견했는가?
- 현재도 공격이 진행 중인가?
개인정보
- 어떤 개인정보인가?
- 몇 명의 정보인가?
- 실제 유출인가?
- 유출 가능성인가?
- 민감정보 또는 고유식별정보가 포함됐는가?
공격
- 공격자는 어떻게 접근했는가?
- 어떤 계정을 사용했는가?
- 개인정보에 접근했는가?
- 데이터를 외부로 반출했는가?
- 추가 피해 가능성이 있는가?
대응
- 추가 유출을 차단했는가?
- 로그를 확보했는가?
- 포렌식을 진행했는가?
- 관계기관 신고가 필요한가?
- 정보주체 통지가 필요한가?
수탁사
- 계약상 사고 통보 의무를 준수했는가?
- 보안조치를 제대로 이행했는가?
- 재위탁이 있었는가?
- 이전에 동일한 취약점이 지적된 적이 있는가?
- 재발방지 대책은 무엇인가?
16. 가장 중요한 것은 '수탁사 책임'과 '위탁자 책임'을 분리해서 생각하지 않는 것이다
수탁사에서 개인정보 유출이 발생했다고 해서 위탁사가 책임에서 자유로워지는 것은 아니다.
개인정보 보호법은 위탁자에게 수탁자의 개인정보 처리에 대한 관리·감독 의무를 부여하고 있고, 수탁자에 대해서도 개인정보 보호법의 일부 규정을 준용하고 있다.
따라서 사고 발생 후 위탁사가 단순히
"수탁사에서 발생한 사고이므로 수탁사가 알아서 처리한다."
라고 대응하는 것은 적절하지 않다.
위탁사는 자신의 개인정보 보호 거버넌스 관점에서 사고를 관리하고, 수탁사의 사고 대응을 통제·감독하는 역할을 해야 한다.
17. 2026년 9월 11일부터 달라지는 부분도 주의해야 한다
현재 2026년 8월 24일 기준으로 개인정보 보호법에는 2026년 3월 개정된 내용 중 일부가 아직 시행 전이다.
2026년 9월 11일부터 제26조와 제34조의 개정 내용이 시행될 예정이다.
특히 제34조 개정에 따라 유출 통지 내용이 확대되고, 일정한 경우 개인정보 유출 가능성을 알게 된 경우에도 정보주체에게 피해 최소화 정보를 알리는 체계가 추가된다.
따라서 기업은 지금부터 수탁사 계약서와 사고대응 절차를 점검할 필요가 있다.
마무리
수탁사 개인정보 유출사고에서 위탁사가 가장 경계해야 할 것은 "수탁사에서 발생한 사고니까 수탁사가 알아서 처리하면 된다"는 생각이다.
개인정보를 외부에 위탁했다고 해서 위탁자의 책임까지 외부로 이전되는 것은 아니다.
오히려 위탁사는 수탁사의 개인정보 처리에 대해 적절한 관리·감독을 수행했는지, 사고 발생 시 신속하게 피해를 차단하고 필요한 신고·통지 등의 조치를 했는지, 그리고 사고 이후 재발방지 대책을 제대로 이행했는지를 관리해야 한다.
결국 수탁사 개인정보 유출사고 대응의 핵심은 다음 한 문장으로 정리할 수 있다.
"수탁사가 사고를 해결하는 것이 아니라, 위탁사가 수탁사와 함께 사고를 통제하고 책임 있게 관리해야 한다."
개인정보보호위원회도 현재 「개인정보 유출 등 사고대응 매뉴얼(2024.3. 개정)」을 제공하고 있으므로, 기업의 실제 사고대응 프로세스를 구축할 때 함께 참고하는 것이 좋다.
실무적으로는 평상시 수탁사 계약서에 '사고 발생 즉시 통보', '증적 보존', '조사 협조', '정보주체 통지 협조', '관계기관 대응', '손해배상 및 비용 부담', '재발방지 조치'를 명확히 규정해 두는 것이 가장 중요하다.
핵심 정리
수탁사 사고 발생 → 즉시 보고 → 추가 유출 차단 → 증적 보존 → 유출 범위 확인 → 신고·통지 판단 → 피해 최소화 → 원인 분석 → 수탁사 개선 → 재발방지 → 수탁사 재평가
이 흐름을 사전에 개인정보 침해사고 대응 프로세스로 만들어 두어야 실제 사고가 발생했을 때 법적 대응과 보안 대응을 동시에 수행할 수 있다.
※ AI 활용하여 작성하였습니다.