개인정보 보호 요건을 충족하는 비즈니스 시스템 설계

개인정보보호법 B.E. 2562(2019)는 태국 내 개인의 개인정보를 수집, 이용 또는 공개하는 조직에 적용됩니다. 이 법은 데이터를 처리하는 목적과 방법을 결정하는 개인정보 처리자(컨트롤러)와 처리자를 대신해 처리하는 수탁자(프로세서)를 구분하며, 개인정보보호위원회(PDPC)가 감독합니다. 이 법은 처리의 법적 근거, 정보주체의 권리, 보안 의무, 기록 보관 의무, 침해 통지 요건을 규정합니다.

이 가이드는 정보 제공용이며 법률 자문이 아닙니다. 법률, 하위 규정, PDPC 지침은 수시로 변경되므로, 귀사 조직에 어떻게 적용되는지는 개인정보 보호 책임자나 법률 자문을 통해 확인하십시오. 이하 내용은 엔지니어링 관점입니다. 법이 조직에 어떤 일을 할 수 있어야 한다고 요구하는 경우, 이 가이드는 시스템이 이를 위해 무엇을 갖추어야 하는지 설명합니다.

동의가 근거인 경우, 시스템은 특정인이 특정 용도에 대해 특정 문구로, 특정 시점에, 어떤 방식으로 동의했는지 보여 줄 수 있어야 합니다. 동의 기록에는 정보주체의 식별자, 목적, 정보주체가 본 고지문 또는 동의 문구의 버전, 타임스탬프, 채널(웹 양식, 앱, 스캔한 서면, 전화), 양식 ID 같은 증빙을 저장하십시오. 동의 문구의 모든 버전을 보관하십시오. 이후에 수정된 문구를 가리키는 기록은 아무것도 증명하지 못합니다.

동의 철회는 동의만큼 쉬워야 하며, 해당 동의에 따라 처리한 모든 시스템에 반영되어야 합니다. 동의를 한 번 복사하고 잊어버리는 플래그가 아니라, 하위 시스템(마케팅 플랫폼, 뉴스레터 발송 시스템, 분석 파이프라인)이 사용 시점에 확인하는 중앙 상태로 설계하십시오. 당사 웹사이트의 뉴스레터가 이 방식의 작은 예입니다. 이메일을 통한 이중 동의 확인, 모든 메일에 포함된 수신 거부 링크, 발송 전에 적용되는 수신 제외 목록으로 구성됩니다.

동의가 모든 경우에 적절한 근거는 아닙니다. 급여 지급을 위한 직원 정보 처리나 구매 상품 배송을 위한 고객 정보 처리는 계약이나 법적 의무에 근거합니다. 이러한 경우에 동의를 요청하면 조직이 지킬 수 없는 철회권이 생겨납니다. 근거를 정확히 선택하면 동의 기록은 줄어들고 더 의미 있게 됩니다.

법은 적절한 보안 조치를 요구합니다. 시스템 측면에서 이는 최소 권한에서 출발합니다. 즉, 각 역할이 업무에 필요한 필드만 볼 수 있는 역할 기반 접근 제어입니다. 소유자/관리자/멤버/뷰어 모델은 워크스페이스의 기반으로 적절하지만, 비즈니스 애플리케이션에는 대개 더 세분화된 역할이 필요합니다. 예를 들어 창고 담당자는 배송 주소는 보되 신분증 번호는 볼 수 없어야 하고, 고객 지원 담당자는 카드 번호의 마지막 네 자리만 볼 수 있고 전체 번호는 절대 볼 수 없어야 합니다. 어떤 클라이언트도 우회할 수 없도록 API 계층에서 적용하는 필드 수준 마스킹은 개인정보와 민감정보 필드에 대해 충분히 들일 만한 노력입니다.

최소화는 수집 단계와 모든 사본에 적용됩니다. 목적에 필요한 필드만 수집하십시오. 운영 환경의 개인정보를 테스트 및 개발 환경에 복사하지 말고, 테스트 데이터를 생성하거나 익명화하십시오. 내보내기와 대량 다운로드는 필요한 역할로 제한하고 모든 건을 기록하십시오. 이 모든 것을 강력한 인증이 보호합니다. 조직의 ID 제공업체를 이용한 싱글 사인온, 2단계 인증, 지원되는 경우 패스키, 데이터 민감도에 비례한 세션 시간 제한이 이에 해당합니다.

조직이 이용하는 수탁자(호스팅, 이메일, 분석, AI 서비스)와는 동일한 기준을 준수하도록 하는 계약을 체결해야 하며, 아키텍처에서는 각 수탁자에게 어떤 개인정보가 전달되는지 명확히 드러나야 합니다.

개인정보는 목적상 필요하거나 법률이 요구하는 기간 동안만 보관할 수 있습니다. 이를 데이터 범주별로 기간과 법적 또는 업무상 사유를 명시한 보존 일정으로 만드십시오. 예를 들어 회계 기록은 세법이 요구하는 기간 동안, 입사 지원자 정보는 채용 결정 후 정해진 기간 동안 보관하고, 비활성 고객 계정은 정해진 비활성 기간이 지나면, 고객 지원 채팅 기록은 정해진 기간이 지나면 정리합니다. 그런 다음 이 일정을 자동화하십시오. 누군가 1년에 한 번 스크립트를 실행해야만 작동하는 보존 정책은 통제 장치가 아닙니다.

삭제가 기술적으로 어떻게 이루어지는지 정하십시오. 소프트 삭제는 데이터를 보이지 않게 할 뿐 실제로는 남겨 두므로, 완전 삭제나 익명화 전의 짧은 유예 기간으로만 허용됩니다. 익명화는 통계는 유지하면서 식별자를 제거하거나 되돌릴 수 없게 변환하므로, 조직은 개인을 식별하는 정보 없이 업무 이력을 보관할 수 있습니다. 백업도 똑같이 다루어야 합니다. 백업의 보관 기간을 정하고, 암호화 여부를 확인하며, 복원된 데이터에도 백업 이후에 이루어진 삭제가 반영되도록 하십시오.

정보주체는 조직이 자신에 관해 어떤 정보를 보유하고 있는지 문의하고, 사본 제공과 정정을 요청하며, 삭제를 요구하고, 처리에 반대하거나 처리 제한을 요청하고, 동의를 철회할 수 있습니다. 개인정보 처리자는 법률과 규정이 정한 기간 내에 조치해야 합니다. 시스템 요건은 교육받은 직원이 엔지니어의 도움 없이 이러한 요청을 처리할 수 있는 수단입니다. 모든 모듈에서 특정인의 레코드를 빠짐없이 찾고, 개인정보를 읽기 쉬운 형식으로 내보내며, 감사 기록을 남기면서 필드를 정정하고, 준수해야 하는 보존 규칙에 따라 삭제나 익명화를 실행할 수 있어야 합니다(고객이 삭제를 요청했다고 해서 청구서를 삭제할 수는 없으며, 기록된 법적 근거에 따라 보존할 수 있습니다).

요청 기록을 남기십시오. 누가 언제 요청했는지, 신원을 어떻게 확인했는지, 무엇을 조치했고 언제 완료했는지 기록합니다. 이 기록은 법규 준수를 입증하는 동시에 어느 절차가 지연되는지 보여 줍니다.

감사 로그는 누가 언제 어떤 데이터에 무엇을 했는지 기록합니다. 로그인, 권한 변경, 개인정보 조회 및 내보내기, 수정 및 삭제, 설정 변경이 이에 해당합니다. 감사 로그는 작업이 이루어지는 시점에 애플리케이션이 기록해야 하며, 쓰기 권한을 제한하여 업무 데이터와 분리해 저장하고, 신중하게 정한 기간 동안 보존해야 합니다. 같은 데이터베이스에 같은 관리자가 관리하는 로그는 내부자로부터 아무런 보호도 제공하지 못합니다.

로그는 존재하는 것만으로는 부족하며 실제로 쓸모가 있어야 합니다. 사람별·레코드별로 검색할 수 있어야 하고, 정기적으로 검토하며, 대량 내보내기나 업무 시간 외 접근 같은 비정상 패턴에는 알림이 발생해야 합니다. 감사 로그 자체에도 개인정보가 포함되므로 보존 일정에 포함해야 합니다.

이 법은 개인정보 처리자가 개인정보 침해를 인지한 경우, 권리와 자유에 위험을 초래할 가능성이 낮은 경우를 제외하고, 지체 없이 그리고 가능하면 인지 후 72시간 이내에 PDPC에 통지하도록 요구합니다. 위험이 큰 경우에는 영향을 받은 정보주체에게도 알려야 합니다. 72시간은 금세 지나갑니다. 시스템 측면의 대비는 탐지 능력, 즉 무단 접근을 드러낼 수 있는 로깅과 모니터링, 그리고 어떤 데이터가 누구에 관해 어느 기간 동안 영향을 받았는지 신속하게 파악할 수 있는 능력입니다.

조직 측면의 대비는 문서화된 사고 대응 절차입니다. 누구에게 가장 먼저 알리는지, 누가 위험을 평가하는지, 누가 통지문을 작성하는지, 누가 고객과 소통하는지를 정하고, 조직이 사용하는 각 언어로 템플릿을 미리 준비합니다. 실제 침해 상황에서 런북을 처음 사용하는 일이 없도록 매년 현실적인 시나리오로 모의 훈련을 실시하십시오.