ISMS-P 결함사례 고찰 #3.4. 개인정보 파기 시 보호조치

3.4.1 개인정보 파기

인증기준: 개인정보의 보유기간 및 파기 관련 내부 정책을 수립하고 개인정보의 보유기간 경과, 처리목적 달성 등 파기 시점이 도달한 때에는 파기의 안전성 및 완전성이 보장될 수 있는 방법으로 지체 없이 파기하여야 한다.

 

결함사례#1

회원 탈퇴 등 목적이 달성되거나 보유기간이 경과된 경우 회원 데이터베이스에서는 해당 개인정보를 파기하였으나, CRM·DW 등 연계된 개인정보처리시스템에 복제되어 저장되어 있는 개인정보를 파기하지 않은 경우가 있다. 개인정보를 파기할 때는 수집경로에 따른 모든 보관장소에 있는 것을 파기해야 한다. DB에서는 파기했는데 연계된 시스템에 남아있는 경우에는 개인정보를 파기하지 않은 숨은 이유가 있다거나, 혹은 개인정보가 정확히 어느 어느 곳에 수집되어 저장이 되어있는지 잘 모르는 경우가 될 것이다. 전자의 범죄 의도를 제외한다면 보통은 후자일 경우가 대다수일 것이고 말이다. 이것도 결국 개인정보의 중요성에 대해 제대로 인지하고 있지 못하고 있기 때문에 발생하는 결과가 아닐까 싶다. 그저 DB에 있는 것만 삭제하면 된다고 생각했다는 것은 업무에 대해 온전히 이해하고 있지 않다는 뜻일 것이고 말이다. 개인정보를 다룰 때에는 어느 경로로 수집이 되었는지를 자신의 업무 범위 안에서 만큼은 확실히 파악하고 있어야 할 것이다. 그것이 본인을 위해서도 더욱 업무의 효율성을 올리는 일이 될 것이니 말이다.

 

결함사례#2

특정 기간 동안 이벤트를 하면서 수집된 개인정보에 대하여 이벤트가 종료된 이후에도 파기 기준이 수립되어 있지 않거나 파기가 이루어지고 있지 않은 경우가 있다. 파기 기준은 종료가 되기 전에도 이미 수립이 되어 있어야 한다. 사실상 수집을 하고자 할 때 이미 파기 기준도 수립이 되어 있어야 맞는 것이기도 하다. 파기 기준을 세운다는 것이 결코 어려운 일이 아니니 말이다. 수집과 파기는 하나의 세트처럼 인식해야 한다. 따라서 파기는 사무실 쓰레기통 비우듯 가볍게 생각할 것이 아니라, 적법하고 적절한 절차에 의거하여 진행되는 업무의 연장선으로 다뤄야 할 것이다.

 

결함사례#3

콜센터에서 수집되는 민원처리 관련 개인정보(상담이력, 녹취 등)를 전자상거래법을 근거로 3년간 보존하고 있으나, 3년이 경과한 후에도 파기하지 않고 보관하고 있는 경우가 있다. 보통 이에 대해서는 업무에 대해 제대로 인지하고 있지 못할 가능성이 크다. 그리고 콜센터 입장에서 사실상 개인정보는 주말을 제외한 평일 매일 쌓이게 되는데, 그럼 최초 개인정보를 확보한 시점에서 3년이 지났을 때는 매일 매일 파기를 해야 한다는 것을 의미한다. 그리고 이것을 단순 삭제가 아닌 적절한 절차를 거쳐 파기를 하는 것은 매일 하기에는 특정 조직들에게는 다소 귀찮고 성가신 업무일지도 모른다. 그렇기에 일괄적으로 처리하는 경우가 종종 있을 것이고, 그런 경우에 이런 결함사례에 뽑힐 수 있다. 그러나 법에 명시되어 있는 만큼 콜센터를 관리하는 조직의 장은 이 업무에 대해 이해를 하고 업무 기술서를 작성해야 할 것이다.

 

결함사례#4

블록체인 등 기술적 특성으로 인하여 목적이 달성된 개인정보의 완전 파기가 어려워 완전파기 대신 익명처리를 하였으나, 익명처리가 적절하게 수행되지 않아 일부 개인정보의 재식별 등 복원이 가능한 경우가 있다. 언제나 파기를 할 때에는 복원이 불가능한 방식으로 수행해야 한다. 파기가 불가능해 어쩔 수 없이 익명처리를 하더라도 복권 불가능의 내용은 그대로 유지가 되어야 한다. 애초에 복원이 가능하다면 그것은 파기가 수행되었다고, 익명처리가 수행되었다고 볼 수가 없다.

 

3.4.2 처리목적 달성 후 보유 시 조치

인증기준: 개인정보의 보유기간 경과 또는 처리목적 달성 후에도 관련 법령 등에 따라 파기하지 않고 보존하는 경우에는 해당 목적에 필요한 최소한의 항목으로 제한하고 다른 개인정보와 분리하여 저장·관리하여야 한다.

 

결함사례#1

탈퇴회원 정보를 파기하지 않고 전자상거래법에 따라 일정기간 보관하면서 Flag값만 변경하여 다른 회원정보와 동일한 테이블에 보관하고 있는 경우가 있다. Flag를 변경했다고 해서 달라지는 것은 없다. 그저 업무적으로 분리가 된 것처럼 보일 뿐이지, 동일한 테이블에 있는 것은 결국 마찬가지이다. 회원 정보를 완전파기하려는 것은 개인정보 유출의 가능성 자체를 없애고자 하는 의도가 있는 것인데, 결국 동일한 테이블에 남긴다는 것은 유출의 가능성을 남기는 일이 되는 일이다. Flag값을 변경했다는 것은 결국 다시 되돌릴 수도 있다는 말이 된다. 그저 눈가리고 아웅하는 일이나 다름 없으므로, 확실하게 분리하여야 할 것이다.

 

결함사례#2

전자상거래법에 따른 소비자 불만 및 분쟁처리에 관한 기록에 대해 관련 법적 요건을 잘못 적용하여 3년이 아닌 5년간 보존하도록 정하고 있는 경우가 있다. 이 내용도 그렇지만, 특히나 해당 법령이 개정되었을 때 이것을 놓쳐서 즉각적으로 반영하지 않아 결함사례로 뽑히는 사례도 있다. 법의 내용에 대해서는 개정이 되는지 확인할 필요가 있다. 또한, 본인이 담당하는 업무를 인수인계 받아서 맡게 되었을 때는 법의 적용을 받는 업무일 경우 전임자를 무작정 신뢰하는 것보다는 한 번 법의 내용을 충실히 따르는지 확인할 필요가 있다. 개인적으로도 지침을 한 번씩 따져가며 확인하는 것을 선호하는데, 그 과정에서 잘못된 것을 바로잡을 수도 있지만, 업무에 대한 이해도를 높일 수 있는 일이기도 하기 때문이다.

 

결함사례#3

분리 데이터베이스를 구성하였으나 접근권한을 별도로 설정하지 않아 업무상 접근이 불필요한 인원도 분리 데이터베이스에 자유롭게 접근이 가능한 경우가 있다. 기껏 분리를 했는데 접근권한을 설정하지 않았다면 분리한 이유가 무엇이 있겠는가? 분리를 안 한 경우와 똑같은 취급을 받더라도 할 말이 없다. 접근권한은 언제나 최소권한으로 엄격하게 설정하는 것을 원칙으로 삼아야 한다.

 

결함사례#4

탈퇴회원 정보를 파기하지 않고 전자상거래법에 따라 계약 또는 청약철회, 대금결제 및 재화 공급에 관한 기록을 분리하여 보존하였으나, 전자상거래법에 따른 보존의무가 없는 선택정보까지 과도하게 보존한 경우가 있다. 선택정보는 보통 서비스의 기능 실현에 있어 필수적으로 요구되는 정보가 아니다. 그렇기에 굳이 과도하게 보존할 이유가 없다. 보존해야 하는 내용은 법에서 설명하는 정도만 하면 되는 일이다. 굳이 귀찮다고 저장되어 있는 정보 모두를 보관하지 말고, 법에서 소개하는 필수적인 내용만 저장하도록 해야 할 것이다.