고객정보 파기대장은 언제, 어떤 개인정보를, 왜, 어떤 방법으로 삭제했는지를 내부적으로 남기는 기록입니다. 다만 먼저 구분해야 할 점이 있습니다. 대한민국 개인정보 보호법은 불필요해진 개인정보를 지체 없이 파기하도록 요구하지만, 모든 민간사업자에게 하나의 통일된 이름과 서식의 ‘고객정보 파기대장’을 작성하라고 정하고 있는 것은 아닙니다.
따라서 쇼핑몰, 학원, 병원, 예약업체, 상담업체, SaaS 사업자 같은 민간기업이라면 파기대장을 단순한 법정 양식으로 생각하기보다 실제 파기가 이루어졌는지 확인하고 그 과정을 추적할 수 있도록 만드는 내부 관리기록으로 이해하는 편이 정확합니다.
공공기관의 경우에는 이야기가 조금 다릅니다. 개인정보보호위원회의 표준 개인정보 보호지침은 공공기관의 개인정보파일 파기 절차와 개인정보파일 파기 관리대장 작성을 별도로 규정하고 있습니다. 민간기업이 이 서식을 참고할 수는 있지만, 이를 모든 사업자에게 그대로 적용되는 법정서식이라고 설명해서는 안 됩니다.
Table of Contents
고객정보를 파기해야 하는 시점부터 확인해야 합니다
파기대장을 먼저 만드는 것보다 중요한 것은 어떤 정보가 실제 파기 대상인지 판단하는 일입니다.
2026년 9월 25일 현재 개인정보 보호법 제21조에 따르면 개인정보처리자는 보유기간이 지나거나 처리 목적이 달성되는 등 개인정보가 불필요하게 되었을 때 해당 정보를 지체 없이 파기해야 합니다.
여기서 ‘지체 없이’는 모든 기업에 공통으로 적용되는 3일, 5일, 30일 같은 고정 숫자를 의미하지 않습니다. 정보가 더 이상 필요하지 않게 된 시점을 판단하고 불필요한 지연 없이 실제 파기 절차가 진행되도록 관리해야 한다는 의미로 보는 것이 중요합니다.
예를 들어 회원 탈퇴로 회원관리 목적이 끝났다면 일반 회원정보는 파기 대상이 될 수 있습니다. 그러나 주문·결제·분쟁 관련 기록처럼 다른 법령에 따라 일정 기간 보존해야 하는 정보가 있다면 무조건 함께 삭제해서는 안 됩니다. 회원 탈퇴 이후의 판단 기준은 회원 탈퇴 후 개인정보 삭제 시점과 법정 보관 예외에서 별도로 확인할 수 있습니다.
파기 대상과 법정 보존 대상을 먼저 나누세요
실무에서 가장 위험한 방식은 ‘오래된 고객정보’라는 이유로 한 번에 삭제하거나, 반대로 ‘혹시 필요할지 모르니까’라는 이유로 전부 남겨두는 것입니다.
파기 전에 최소한 다음 세 그룹으로 나누는 것이 좋습니다.
- 처리 목적이 끝나 파기해야 하는 개인정보
- 다른 법령에 따라 일정 기간 보존해야 하는 개인정보
- 계약·환불·민원 등 현재 진행 중인 업무 때문에 아직 필요한 개인정보
개인정보 보호법은 다른 법령에 따라 계속 보존해야 하는 개인정보를 파기하지 않는 경우 해당 정보를 다른 개인정보와 분리해 저장·관리하도록 규정합니다. 따라서 법정 보존 대상이라는 이유로 기존 고객관리 DB에 회원정보 전체를 계속 활성 상태로 남겨두는 방식은 다시 점검해야 합니다.
이 분류 결과는 개인정보 처리방침과도 연결됩니다. 개인정보 보호법 제30조는 처리방침에 개인정보의 처리·보유기간뿐 아니라 파기절차와 파기방법, 다른 법령 때문에 계속 보존하는 경우 그 보존근거와 개인정보 항목 등을 포함하도록 정하고 있습니다. 운영 문서까지 함께 정비해야 한다면 개인정보 처리방침 작성 방법을 같이 확인하는 것이 좋습니다.
고객정보 파기대장에 무엇을 적어야 할까
민간사업자가 내부 파기대장을 만든다면 목적은 서류 칸을 채우는 데 있지 않습니다. 나중에 담당자가 바뀌거나 민원이 발생했을 때도 무엇을 파기했고, 근거가 무엇이며, 실제 삭제 여부를 어떻게 확인했는지 추적할 수 있어야 합니다.
다음 항목을 기본 골격으로 사용할 수 있습니다.
| 기록 항목 | 작성 방법 |
|---|---|
| 파기 대상 | 회원 DB, 상담 신청서, 마케팅 수신목록 등 실제 데이터 묶음이나 파일을 식별할 수 있게 작성 |
| 개인정보 범위 | 이름, 연락처, 이메일, 배송지 등 파기되는 정보의 종류를 작성 |
| 파기 사유 | 보유기간 만료, 처리 목적 달성, 회원 탈퇴, 서비스 종료 등 실제 사유를 작성 |
| 파기 기준일 | 보유기간 만료일이나 처리 목적 종료일처럼 파기 사유가 발생한 시점을 기록 |
| 실제 파기일 | 삭제·파쇄 등 실제 파기 작업을 완료한 날짜를 기록 |
| 파기 방법 | 영구삭제, 덮어쓰기, 저장매체 파쇄, 종이문서 파쇄 등 실제 사용한 방법을 기록 |
| 처리 위치 | 운영 DB, CRM, 공유폴더, 종이문서함 등 파기 대상이 존재했던 위치를 구분 |
| 처리 담당자 | 파기 작업을 수행한 담당자 또는 담당 부서를 기록 |
| 확인자 | 회사의 내부 절차상 필요한 경우 파기 결과를 확인한 책임자 또는 부서를 기록 |
| 예외 사항 | 법정 보존자료, 백업 잔존, 수탁자 파기 대기 등 즉시 완전 파기가 어려운 사유를 작성 |
여기에 회사의 시스템 구조에 따라 파기 건수, 작업 티켓 번호, 백업 만료 예정일, 수탁업체 확인일 등을 추가할 수 있습니다.
고객 이름을 파기대장에 다시 잔뜩 적는 것은 피하세요
파기대장을 만들면서 새로운 개인정보 목록을 하나 더 만드는 실수도 주의해야 합니다.
예를 들어 5,000명의 탈퇴 회원을 일괄 삭제했다면 파기대장에 5,000명의 이름과 전화번호를 다시 복사할 필요가 있는지부터 검토해야 합니다. 파기했다는 사실을 증명하려고 별도의 개인정보 파일을 새로 만드는 셈이 될 수 있기 때문입니다.
가능하다면 다음처럼 파기 범위를 식별하는 방식이 더 관리하기 쉽습니다.
- 파기 배치번호: DEL-2026-09-001
- 대상: 2026년 8월 회원탈퇴 완료 계정
- 대상 건수: 327건
- 파기 항목: 이름, 이메일, 휴대전화번호, 프로필 정보
- 파기 시스템: 회원 운영 DB 및 CRM
다만 특정 정보주체의 삭제 요청 처리 여부를 개별적으로 확인해야 하는 업무라면 해당 요청과 처리 결과를 연결할 수 있는 별도 식별체계가 필요할 수 있습니다. 이 경우에도 필요 이상의 개인정보를 대장에 복제하지 않는 것이 좋습니다.
고객정보 파기대장 작성 예시
다음은 민간사업자가 내부 관리 목적으로 사용할 수 있는 간단한 예시입니다. 법에서 모든 사업자에게 요구하는 공식 서식을 재현한 것이 아니라 실무용 예시입니다.
- 관리번호: DEL-2026-09-001
- 파기 대상: 2026년 8월 회원 탈퇴 완료 계정
- 개인정보 항목: 이름, 이메일 주소, 휴대전화번호, 프로필 정보
- 대상 건수: 327건
- 파기 사유: 회원 탈퇴에 따른 회원관리 목적 달성
- 파기 대상 확인일: 2026년 9월 2일
- 실제 파기일: 2026년 9월 3일
- 파기 위치: 회원 운영 DB, CRM
- 파기 방법: 운영 데이터 삭제 후 복구되지 않도록 회사의 개인정보 파기 절차에 따라 처리
- 별도 보존: 관계 법령에 따라 보존이 필요한 거래기록은 일반 회원정보와 분리하여 보관
- 담당자: 개인정보 관리 담당자
- 결과 확인: 파기 완료 및 대상 건수 확인
- 비고: 백업 데이터는 내부 백업 보존주기 종료 후 파기 예정
회사마다 데이터 구조가 다르므로 ‘파기 방법’에는 실제 수행하지 않은 기술적 조치를 적어서는 안 됩니다. 데이터베이스 레코드 삭제, 파일 영구삭제, 저장매체 파쇄, 문서 파쇄 등 실제 작업과 기록이 일치해야 합니다.
전자파일과 종이문서는 파기 방법이 다릅니다
개인정보 보호법은 파기할 때 개인정보가 복구 또는 재생되지 않도록 조치하도록 정하고 있습니다. 시행령 제16조는 전자적 파일 형태라면 원칙적으로 복원이 불가능한 방법으로 영구 삭제하도록 하고, 종이 문서와 그 밖의 기록매체는 파쇄 또는 소각하도록 규정합니다.
개인정보의 안전성 확보조치 기준도 완전 파괴, 전용 소자장비를 이용한 삭제, 복원되지 않도록 하는 초기화 또는 덮어쓰기 등의 방법을 제시합니다.
따라서 다음과 같은 조치는 실제 파기로 보기 어려울 수 있습니다.
- 관리자 화면에서 고객 계정을 ‘탈퇴’ 상태로만 변경
- 엑셀 파일을 휴지통으로 이동한 뒤 그대로 보관
- 이메일 주소 앞에 ‘deleted’를 붙이고 원본 데이터를 유지
- 종이 신청서를 일반 폐지함에 버림
- 운영 DB에서는 삭제했지만 CRM이나 공유폴더에는 그대로 보관
화면에서 보이지 않는 것과 개인정보가 실제로 복구되지 않는 상태가 된 것은 다른 문제입니다.
파기대장은 운영 DB 한 곳만 보면 완성되지 않습니다
고객정보는 생각보다 여러 곳에 복제됩니다. 온라인 쇼핑몰 하나만 보더라도 회원 DB, 주문관리 시스템, 고객상담 프로그램, 이메일 발송 시스템, 문자 발송업체, CRM, 클라우드 저장소, 직원 PC 다운로드 파일 등에 같은 고객정보가 남을 수 있습니다.
따라서 파기대장에 ‘회원 DB 삭제 완료’라고 적기 전에 데이터가 이동하는 위치를 확인해야 합니다.
- 운영 데이터베이스
- 고객관리시스템(CRM)
- 상담·채팅 시스템
- 공유 드라이브와 업무용 PC
- 이메일·문자 발송 서비스
- 클라우드와 백업 시스템
- 외부 수탁업체의 시스템
특히 외부 업체가 회사 업무를 대신하면서 고객정보를 처리한다면 자사 시스템에서 삭제하는 것으로 끝나지 않을 수 있습니다. 개인정보 보호법상 처리위탁 구조와 관리·감독 관계를 함께 확인해야 합니다. 외부 업체의 법적 관계가 헷갈린다면 개인정보 제3자 제공과 처리 위탁의 차이를 먼저 구분하는 것이 좋습니다.
위탁계약을 운영하고 있다면 계약 종료 또는 처리 목적 달성 후 개인정보 반환·파기 절차가 실제 계약과 업무 절차에 반영되어 있는지도 확인해야 합니다. 관련 계약 구조는 개인정보 위탁계약서 작성 방법과 확인사항에서 함께 점검할 수 있습니다.
백업에 남아 있는 개인정보는 어떻게 기록할까
운영 DB에서 고객정보를 삭제했는데 백업에는 같은 정보가 남아 있는 경우가 있습니다. 특히 전체 백업 이미지나 스냅샷처럼 개별 고객 레코드 하나만 즉시 제거하기 어려운 구조가 대표적입니다.
중요한 것은 ‘백업이라서 계속 보관한다’로 끝내지 않는 것입니다. 백업의 보존주기, 접근권한, 복원 절차, 최종 삭제 시점을 파악하고 운영 시스템에서 삭제된 개인정보가 백업 복원 과정에서 다시 정상 데이터로 살아나지 않도록 통제해야 합니다.
파기대장에는 예를 들어 ‘운영 DB 파기 완료, 백업본은 접근 제한 상태이며 30일 백업 순환주기 종료 시 삭제’처럼 실제 회사의 정책을 기록할 수 있습니다. 단, 여기의 기간은 회사가 실제 운영하는 백업정책을 적어야 하며 임의의 숫자를 복사해서 사용해서는 안 됩니다.
공공기관용 파기 관리대장과 민간기업 대장은 무엇이 다른가
개인정보보호위원회의 표준 개인정보 보호지침은 공공기관이 개인정보파일을 파기할 때 파기 대상 파일을 선정하고 개인정보 보호책임자의 승인을 받아 파기한 뒤 파기 결과를 확인하고 개인정보파일 파기 관리대장을 작성하도록 규정하고 있습니다.
개인정보 포털에서 안내하는 공공기관용 관리 항목에는 개인정보파일명, 자료의 종류, 생성일, 폐기일, 폐기사유, 처리담당자, 처리부서장 등이 포함됩니다.
민간기업도 이런 구조를 참고할 수 있습니다. 다만 회사 내부 양식을 만들면서 ‘개인정보 보호법이 모든 민간기업에 이 서식을 의무화한다’고 표시하면 법적 근거를 지나치게 넓혀 해석하는 결과가 됩니다.
민간사업자의 대장은 회사 규모와 시스템에 맞게 간소화할 수 있지만, 최소한 파기 대상, 파기 사유, 실제 파기 시점, 파기 방법, 담당자, 예외사항을 나중에 확인할 수 있어야 실무적인 가치가 있습니다.
소규모 사업자는 이렇게 운영하면 관리하기 쉽습니다
고객이 수십 명 또는 수백 명인 작은 사업자가 복잡한 전산 시스템부터 만들 필요는 없습니다. 엑셀이나 사내 승인 시스템을 이용하더라도 실제 개인정보 흐름과 연결되어 있다면 관리 목적을 달성할 수 있습니다.
- 파기 예정 목록을 만듭니다. 보유기간이 끝났거나 처리 목적이 달성된 데이터 묶음을 추출합니다.
- 다른 법률의 보존 의무를 확인합니다. 즉시 삭제하면 안 되는 항목은 별도로 분류합니다.
- 파기 범위를 확정합니다. 운영 DB뿐 아니라 CRM, 공유파일, 종이문서, 외부 업체까지 위치를 확인합니다.
- 회사에서 정한 승인 또는 확인 절차를 거칩니다. 민간기업의 승인 방식은 조직에 맞게 설계하되 담당자 혼자 임의로 대량 삭제하는 구조는 피하는 편이 좋습니다.
- 실제 파기를 수행합니다. 파일 형태와 저장매체에 맞는 복구·재생 방지 방법을 사용합니다.
- 파기 결과를 확인합니다. 삭제 대상이 실제로 검색되지 않는지, 다른 시스템에 복제본이 남지 않았는지 확인합니다.
- 파기대장을 작성합니다. 날짜, 대상, 사유, 방법, 담당자와 남아 있는 예외를 기록합니다.
핵심은 ‘대장을 작성했으니 파기를 했다’가 아니라 실제 파기 작업을 확인한 뒤 그 결과를 대장에 남기는 순서입니다.
파기대장을 만들 때 자주 생기는 실수
- 탈퇴 상태 변경을 파기로 기록하는 경우: 원본 개인정보가 그대로 남아 있다면 실제 파기 여부를 다시 확인해야 합니다.
- 법정 보존정보와 일반 회원정보를 함께 남기는 경우: 필요한 정보만 분리하여 보존할 수 있는지 확인합니다.
- 파기대장에 고객 개인정보를 다시 복제하는 경우: 배치번호와 대상 건수 등으로 충분한지 먼저 검토합니다.
- 자사 서버만 확인하는 경우: CRM, 메일, 클라우드, 수탁업체 등에 복제된 데이터가 없는지 확인합니다.
- 파기 방법을 실제보다 과장해서 적는 경우: 실제 수행한 조치만 기록해야 합니다.
- 백업을 예외 없이 영구 보관하는 경우: 백업의 만료와 파기 정책을 별도로 관리합니다.
- 처리방침과 내부 절차가 서로 다른 경우: 공개된 파기절차와 실제 운영을 정기적으로 비교합니다.
자주 묻는 질문
민간사업자는 고객정보 파기대장을 반드시 작성해야 하나요?
개인정보 보호법은 불필요해진 개인정보의 파기와 안전한 파기방법 등을 규정하지만, 일반적인 민간사업자의 모든 고객정보 파기에 대해 하나의 명칭과 서식으로 된 ‘파기대장’을 일률적으로 작성하라고 정하고 있지는 않습니다. 다만 실제 파기 여부를 관리하고 입증할 수 있는 내부 기록을 남기는 것은 개인정보 관리 측면에서 매우 유용합니다. 업종별 특별법이나 별도 규정이 적용되는 사업자는 추가적인 기록 의무가 있는지도 확인해야 합니다.
엑셀로 파기대장을 작성해도 되나요?
민간사업자가 내부 관리용으로 운영하는 경우에는 문서 형식 자체보다 실제 파기 과정과 기록이 일치하는지가 중요합니다. 엑셀, 사내 전자결재, 개인정보관리 시스템 등 조직에 맞는 방법을 사용할 수 있습니다. 다만 대장 자체에 불필요한 개인정보가 포함되지 않도록 접근권한과 보관기간도 관리해야 합니다.
파기대장에 고객 이름과 전화번호를 모두 적어야 하나요?
일반적으로 파기 사실을 확인하는 목적에 필요한 범위를 먼저 판단해야 합니다. 대량 일괄 파기라면 대상 기간, 배치번호, 개인정보 종류, 건수 등으로 파기 범위를 확인할 수 있는지 검토할 수 있습니다. 불필요하게 고객 명단 전체를 다시 복제하면 파기대장 자체가 새로운 개인정보파일이 될 수 있습니다.
고객정보 파기대장은 얼마나 오래 보관해야 하나요?
일반 민간사업자의 모든 파기대장에 동일하게 적용되는 하나의 보관기간을 임의로 정해서는 안 됩니다. 적용되는 법률, 업종별 규정, 내부 관리 목적과 분쟁·감사 필요성 등을 검토해 합리적인 보관기간을 정해야 합니다. 또한 파기대장에 개인정보가 포함되어 있다면 대장 자체의 보유 필요성과 파기 기준도 함께 정해야 합니다.
결국 중요한 것은 대장보다 실제 데이터 흐름입니다
고객정보 파기대장은 개인정보 보호의 출발점이 아니라 마지막 확인 기록에 가깝습니다. 먼저 어떤 개인정보를 왜 보유하고 있는지, 보유기간이 끝났는지, 법 때문에 남겨야 할 자료가 있는지, 데이터가 어느 시스템과 외부 업체에 복제되어 있는지를 확인해야 합니다.
그다음 실제 파기를 진행하고 대상, 사유, 파기일, 방법, 담당자, 예외사항을 기록하면 됩니다. 이 구조만 제대로 잡아도 ‘계정은 삭제했지만 CRM에는 그대로 남아 있는 고객정보’나 ‘법정 거래기록을 남긴다는 이유로 회원정보 전체를 보관하는 문제’를 상당 부분 줄일 수 있습니다.
특히 개인정보 처리방침, 회원 탈퇴 절차, 위탁업체 계약, 백업정책과 파기대장은 따로 움직이는 문서가 아닙니다. 실제 고객정보가 들어와서 사용되고, 이동하고, 보존되다가 사라지는 하나의 흐름으로 연결해 관리하는 것이 핵심입니다.