개인정보 파기와 사본

운영 시스템에서 삭제한 뒤에도 백업, 메일, 로컬 파일, 위탁사에 남을 수 있는 사본을 포함해 파기를 설계하는 방법을 다룹니다.

삭제 버튼이 파기의 끝은 아닙니다

업무 시스템에서 고객 기록을 삭제했지만 같은 자료가 담당자의 다운로드 폴더와 메일 첨부에 남아 있을 수 있습니다. 저는 파기를 하나의 기능이 아니라 여러 저장 위치를 정리하는 과정으로 봅니다.

개인정보는 수집 이후 가공, 전달, 백업 과정에서 복제됩니다. 운영 데이터베이스만 기준으로 보유기간을 관리하면 주변 사본은 주인을 잃습니다. 흐름도와 보유기간표를 연결해야 하는 이유입니다.

백업은 장애 복구를 위해 일정 기간 세대별로 보관됩니다. 개별 정보만 골라 지우기 어려운 구조도 있습니다. 그렇다고 백업을 파기 대상에서 빼도 된다는 뜻은 아닙니다. 복원 목적 외 접근을 제한하고, 정해진 주기가 지나면 덮어쓰거나 삭제되도록 관리해야 합니다.

복원 시험을 할 때도 주의가 필요합니다. 오래된 백업을 복원하면 이미 파기된 개인정보가 운영 환경으로 되살아날 수 있습니다. 복원 후 최신 파기 상태를 다시 반영하는 절차가 있어야 합니다.

담당자가 삭제 작업을 했다는 보고와 실제로 대상 정보가 남아 있지 않다는 확인은 다릅니다. 저는 대상 범위, 실행 일시, 사용한 방법, 예외, 확인 결과를 구분해 기록합니다. 위탁사가 처리한 정보라면 파기 요청뿐 아니라 이행 여부도 확인합니다.

보존 의무가 있는 정보는 다른 자료와 분리해 목적 외 사용을 막습니다. 모든 데이터를 한꺼번에 지우는 것도, 보존을 이유로 계속 열어 두는 것도 적절하지 않습니다. 파기는 데이터마다 남아야 할 이유와 없어져야 할 시점을 구분하는 일입니다.