반응형
개인정보 보호에서 보유기간 준수는 기본이라고 말하지만, 막상 운영을 들여다보면 가장 자주 틀어지는 영역이 보유·파기다.
“파기 정책이 있다”와 “실제로 파기된다”는 다르다.
특히 서비스가 커질수록 개인정보가 한 곳에만 있지 않기 때문에, 보유기간은 더 어려워진다.
개인정보는 DB에만 있지 않다
실무에서 보유·파기를 어렵게 만드는 건 데이터의 분산이다.
- 운영 DB
- 로그(접속/행위/오류)
- 백업/스냅샷
- 데이터 레이크/분석 플랫폼
- 고객센터 티켓/첨부파일
DB에서 지웠는데 분석 환경에 남아 있거나, 백업에 남아 있으면 “완전한 파기”라고 말하기 어렵다.
보유기간은 목적별로 쪼개야 실행된다
하나의 개인정보라도 목적이 다르면 보유기간이 달라진다.
- 서비스 제공 목적
- 분쟁 대응 목적
- 법정 보관 목적
- 보안 감사 목적(접속 기록)
그래서 실무적으로는 “항목 기준”이 아니라 “목적 기준”으로 보유기간을 쪼개고, 저장소도 가능하면 분리하는 편이 안전하다.
파기 자동화가 안 되면 결국 누락된다
보유기간은 사람이 기억해서 지키기 어렵다.
그래서 파기는 가능하면 자동화가 맞다.
- 기간 도래 데이터 배치 삭제
- 파기 대상 식별 로직(탈퇴/휴면/미접속)
- 파기 로그(언제, 무엇을, 얼마나) 기록
- 예외 처리(법정 보관 데이터 분리 보관)
여기까지 잡히면 “정책이 실행되는 구조”로 넘어간다.
개인정보 영향평가에서 보는 포인트
영향평가 관점에서 보유·파기를 볼 때는 아래를 자주 확인한다.
- 보유기간 산정 근거(목적/법정근거/업무근거)
- 파기 방법(논리삭제/물리삭제/암호화 키 파기 등)
- 백업 데이터의 파기 정책(주기/보관기간)
- 로그 보관과 파기(접근권한, 최소수집)
- 파기 증빙(배치 결과, 로그, 리포트)
마무리
보유기간은 문구가 아니라 운영이다.
정책을 썼다면, 그 정책이 돌아가도록 구조를 만들고 기록을 남겨야 한다.
개인정보 담당자든 보안 담당자든, 결국 이런 “실행되는 통제”를 만들 수 있는 사람이 강하다고 느낀다.
반응형