삭제 요청이 방금 도착했습니다. 이제 어떻게 해야 할까요?

삭제 페이지를 게시하는 것은 모두가 다루는 부분입니다. 누군가 그 페이지를 사용한 후에 일어나는 일이 실제로 컴플라이언스를 지키는지를 결정하는 부분이며, 이것은 호스팅이 아니라 프로세스의 문제입니다.

요청은 어디로 도착해야 하나요?

무언가 고장 났을 때나 확인하는 받은편지함이 아니라, 사람이 며칠 안에 확인하는 곳이어야 합니다.

실패 양상은 구체적이고 흔합니다. 페이지가 아무도 읽지 않는 메일함으로 요청을 모으거나, 알림 메일이 스팸으로 가는 양식 서비스로 모읍니다. 사용자는 요청이 처리되었다고 믿습니다. 법적으로는 이제 진행 중인지도 모르는 기한을 어기고 있는 상태가 됩니다.

실용적인 규칙은 다음과 같습니다.

• 방치할 수도 있는 개인 주소는 안 됩니다. 스토어 등록정보에서 오는 지원 메일은 몰아서 옵니다. 몇 달 동안 아무것도 없다가 한꺼번에 여러 통이 옵니다.
• 놓칠 수 없는 알림이 오는 곳. 1인 개발자에게는 이메일보다 채팅 채널인 경우가 많습니다. 이메일은 무시되기 쉬운 곳이기 때문입니다.
• 가능하면 경로를 둘 이상 두십시오. 한 채널이 소리 없이 고장 나면 두 번째 채널이 필요합니다.
• 테스트하십시오. 직접 공개 페이지를 통해 요청을 제출하고 그것이 도착하는지 확인하십시오. 페이지를 변경할 때마다 다시 하십시오.

기한은 얼마나 되나요?

사용자 중 EU나 영국에 있는 사람이 있다면 GDPR의 기한이 적용됩니다. 제12조 제3항은 부당한 지체 없이, 어떤 경우에도 접수 후 한 달 이내에 응답할 것을 요구합니다. 정말로 복잡한 요청의 경우 기간을 두 달 더 연장할 수 있지만, 연장 사실을 첫 한 달 이내에 당사자에게 알려야 합니다.

개발자들이 흔히 놓치는 두 가지 세부 사항이 있습니다.

• “요청을 접수했습니다”는 응답이 아닙니다. 삭제 요청에 따라 조치했다면, 삭제가 수행되었다는 것과 무엇이 삭제되었는지를 확인해 주어야 합니다.
• 거절하더라도 답장은 해야 합니다. 한 달 이내에, 이유를 밝히고, 감독 기관에 민원을 제기하거나 사법적 구제를 구할 수 있다는 것을 알려야 합니다.

다른 규제에는 각자의 기한이 있습니다. 캘리포니아, 브라질 또는 비슷한 법이 있는 다른 곳에 사용자가 있다면, 한 달이면 어디서나 충분하다고 가정하지 말고 적용되는 규정을 확인하십시오.

실제로 무엇을 삭제해야 하나요?

계정과 그 뒤의 개인 데이터입니다. 그리고 자체 데이터베이스에서만이 아닙니다.

데이터의 위치	해야 할 일
기본 데이터베이스	삭제합니다. 소프트 삭제 후 잊어버리는 것이 아닙니다
백업	백업이 얼마나 유지되며 만료된다는 것을 방침에 정직하게 적습니다
분석 / 크래시 리포팅	벤더 자체의 삭제 API가 있으면 사용합니다
이메일 또는 CRM 도구	내보낸 목록에서 제거합니다
처리자 및 하위 처리자	삭제를 요청하고 후속 확인을 합니다. 이것은 그들이 아니라 개발자의 의무입니다
로그	보존 기간을 정하고 적용합니다

앱이 사용자 데이터 처리를 서비스 제공업체에 의존한다면, 자체 서버에서 삭제하는 것은 일의 절반일 뿐입니다. 제공업체에도 같은 일을 하도록 요청해야 합니다.

무엇을 보관해도 되나요?

명시된 이유가 있는 일부 항목입니다. 흔한 것들은 다음과 같습니다.

• 결제 및 세금 기록. 보통 법에 따라 몇 년간 보관합니다.
• 삭제 자체의 기록. 삭제가 이루어졌음을 보여 줄 수 있어야 합니다.
• 사기 또는 악용 표시. 정당한 이유가 있고 그 사실을 밝힌 경우입니다.
• 익명화된 집계 데이터. 실제로 재식별이 불가능한 경우입니다.

누가 묻기 전에, 이 중 어떤 것이 해당되는지 보존 기간과 함께 개인정보처리방침에 적으십시오. 요청이 온 순간에 결정하다 보면 과도하게 약속하거나 즉흥적으로 처리하게 됩니다.

답장에는 무엇을 써야 하나요?

짧고, 구체적이고, 날짜가 있어야 합니다.

3월 3일에 삭제 요청을 접수했습니다. 귀하의 계정과 그에 연결된 개인 데이터는 삭제되었습니다. 세금 목적상 7년간 보관해야 하는 청구서와 이 요청의 기록은 보관하고 있습니다. 그 밖에 남아 있는 것은 없습니다.

이것이 규정을 충족하는 응답입니다. “완료 ✅“는 아무것도 확인해 주지 않으므로 충족하지 않습니다.

기록 남기기

양이 얼마든 기록을 남기십시오. 누가 요청했는지, 언제, 무엇을 삭제했는지, 무엇을 왜 보관했는지, 언제 답장했는지입니다. “삭제했습니다”는 주장이고, 날짜가 적힌 목록은 증거입니다. 그리고 요청을 잊은 지 오래된 뒤에 규제 기관이 요구하는 것이 바로 증거입니다.

이것은 요청을 흩어진 이메일이 아니라 구조화된 곳에 보관해야 하는 이유이기도 합니다. 답장을 모아 둔 폴더는 기록이 아닙니다.

위의 모든 내용에 대한 한 가지 단서

이 페이지는 프로세스를 설명할 뿐, 개발자의 법적 의무를 설명하는 것이 아닙니다. 어떤 규제가 적용되는지는 사용자가 어디에 있는지와 앱이 무엇을 하는지에 따라 달라지고, 기한과 예외는 규제마다 다르며, 예시 답장의 보존 기간은 그대로 복사할 수 있는 수치가 아니라 예시입니다. 삭제 요청을 어느 정도 이상 처리하거나, 앱이 건강 데이터, 금융, 아동과 관련된다면, 이것을 자신만의 서면 절차로 만들어 줄 변호사의 한 시간은 그만한 가치가 있습니다.

AppFoyer가 여기서 하는 일

저희는 페이지를 호스팅하고, 요청을 감사 기록으로 저장하며, 설정한 채널로 알려 드립니다. 모든 요금제에서는 이메일로, 유료 요금제에서는 Telegram이나 Slack으로도 보내며, 개발자의 자격 증명이 아니라 저희 자체의 봇과 앱을 통해 보냅니다. 대시보드는 각 요청을 done → archive → delete(완료 → 보관 → 삭제) 워크플로로 관리하므로, 위에서 말한 기록은 따로 만들 필요 없이 이미 갖추게 됩니다.

저희가 하지 않는 일, 그리고 했다고 주장하지 않을 일이 두 가지 있습니다. 저희는 최종 사용자에게 절대 연락하지 않으며, 개발자의 시스템에서 무엇도 삭제하지 않습니다. 저희는 그 시스템에 접근할 수 없습니다. 삭제, 답장, 보존에 관한 결정은 개발자의 몫입니다. 그것이 요구사항이 실제로 요구하는 것이며, 어떤 호스팅 페이지도 이를 대신할 수 없습니다.

공식 출처

• Understanding Google Play’s app account deletion requirements — Google Play 고객센터
• Right to erasure — 영국 정보위원회(ICO), 규제 기관 자체의 안내
• GDPR Article 12와 Article 17 — 기한과 권리 자체