처리 위탁 계약

회사는 개인정보를 혼자 다루지 않습니다. 메일 발송은 발송 대행 업체가, 고객 문의 응대는 상담 대행사가, 결제는 결제 대행사가 맡습니다. 그 일을 맡기려면 명단을 넘겨야 하고, 그 순간부터 우리 회사 서버 밖에 사용자 정보가 놓입니다.

문제는 사고가 난 다음에 드러났습니다. 대행사 쪽 계정이 털려 10만 명의 이메일이 새어 나가면 두 회사가 서로를 봤습니다. 맡긴 쪽은 우리는 넘겼을 뿐이라고 하고, 받은 쪽은 우리는 시킨 대로 했을 뿐이라고 합니다. 계약서를 펴 보면 업무를 성실히 수행한다는 한 줄만 있고, 어떤 항목을 넘겼는지도 누가 알릴 의무가 있는지도 적혀 있지 않습니다. 사용자는 자기 정보가 그 업체에 가 있다는 사실조차 모릅니다. 어디에 항의해야 하는지도 알 수 없습니다.

법은 이 공백을 계약으로 메우게 했습니다. 목적을 정한 개인정보처리자가 남에게 처리를 맡길 때는 무엇을 어디까지 맡기는지와 사고가 나면 어떻게 하는지를 문서로 남기라는 것입니다. 사용자에 대한 책임 자체는 여전히 맡긴 쪽에 남습니다. 그래서 이 계약은 책임을 넘기는 문서가 아니라, 맡긴 쪽이 자기 책임을 관리할 수 있게 만드는 문서입니다.

대부분의 계약서가 여덟 항목을 담습니다. 순서는 계약서마다 다르지만 빠지면 문제가 되는 것들은 같습니다.

1. 위탁 업무의 범위와 목적. 무슨 일을 맡기는지를 한정합니다. 발송 대행이면 발송이지 그 명단으로 자기 마케팅을 하는 일이 아닙니다.
2. 넘기는 개인정보 항목. 이메일만인지 이름과 전화번호까지인지를 적습니다. 여기 적힌 것 밖의 항목은 넘길 수 없습니다.
3. 보유 기간과 파기. 받은 쪽이 언제까지 갖고 있다가 어떻게 지우는지입니다. 보유 기간을 맡긴 쪽 기준에 맞춰 둬야 양쪽 기록이 어긋나지 않습니다.
4. 재위탁 제한. 받은 쪽이 다시 다른 업체에 맡기는 것을 말합니다. 상담 대행사가 야간 응대만 또 다른 회사에 넘기는 식입니다. 미리 알리고 승인을 받게 하거나, 최소한 목록을 공개하게 합니다.
5. 안전조치. 암호화해 보관할 것, 접근 권한을 담당자에게만 줄 것, 접근 기록을 남길 것처럼 받은 쪽이 지킬 보안 수준을 적습니다.
6. 사고 통지. 유출을 알게 된 뒤 몇 시간 안에 맡긴 쪽에 알릴지를 숫자로 적습니다. 맡긴 쪽은 규제 기관에 신고할 기한이 따로 걸려 있어서, 여기서 하루가 늦으면 그 기한을 못 지킵니다.
7. 점검과 감사. 맡긴 쪽이 실제로 잘 지키는지 확인할 권리입니다. 자료 제출을 요구하거나 현장 점검을 할 수 있게 해 둡니다.
8. 계약 종료 시 처리. 끝나면 넘긴 정보를 돌려받거나 지우게 하고, 지웠다는 증빙을 받습니다.

쓰는 쪽은 대개 처리를 받는 회사입니다. 수탁자 자리에 서는 회사는 고객사마다 다른 계약서를 검토할 수 없어서 표준안을 하나 만들어 웹사이트에 걸어 둡니다. SaaS 업체의 사이트 아래쪽에 있는 DPA 링크가 그것입니다. 반대로 대기업 고객은 자기 양식을 들고 와서 그걸 쓰자고 합니다. 그때는 두 문서를 나란히 놓고 다른 조항만 골라 협의합니다.

읽는 쪽은 셋입니다.

1. 고객사 법무. 재위탁 범위와 사고 통지 시한과 책임 한도를 봅니다. 도입을 막는 조항이 여기서 나오는 경우가 많습니다.
2. 파는 쪽 세일즈. 계약 막바지에 이 문서가 나오기 때문에 매출이 걸립니다. 표준안이 없으면 검토에 2주가 더 붙습니다.
3. 제품 담당자. 계약서에 적힌 하위 처리자 목록과 실제로 제품이 쓰는 외부 도구 목록이 같아야 합니다. 이 둘을 맞추는 사람이 법무가 아니라 제품 쪽인 경우가 많습니다. 어떤 도구에 어떤 값이 흘러가는지는 붙인 사람만 알기 때문입니다.

이 문서는 개인정보처리방침과도 이어집니다. 방침에는 누구에게 무엇을 맡기는지가 공개되어야 하므로, 새 업체와 계약을 맺으면 방침의 위탁 목록도 같이 바뀝니다.

"계약은 다 됐는데 DPA 검토가 남았어요. 표준안 있으세요?"

문서가 준비돼 있느냐로 일정이 2주 갈린다는 뜻입니다.

"하위 처리자 목록에 이번에 붙인 분석 도구 넣어야 해요."

실제로 쓰는 도구와 계약서 목록이 어긋나 있다는 지적입니다.

"사고 통지 24시간은 우리가 못 지켜요. 72시간으로 고쳐 주세요."

지킬 수 없는 숫자에 서명하지 않겠다는 협상입니다.

페이지덱은 첫 기업 고객 계약에서 이 문서 때문에 3주를 썼습니다. 수아가 조건 협의를 다 끝냈는데 고객사 법무가 DPA를 요구했고, 페이지덱에는 그런 문서가 없었습니다. 규원이 급하게 만드는 동안 계약은 멈춰 있었습니다.

그다음부터는 순서를 바꿨습니다. 표준안을 만들어 사이트에 걸어 두고, 제안 단계에서 먼저 보냅니다. 대신 관리해야 할 것이 하나 늘었습니다. 하위 처리자 목록입니다. 태오가 새 오류 추적 도구를 붙이면 그 도구도 사용자 정보를 보게 되므로 목록에 들어가야 하고, 목록이 바뀌면 기존 고객에게 알려야 합니다. 그래서 외부 도구를 새로 붙일 때 협력사 보안 점검과 목록 갱신을 한 묶음으로 돌리기로 정했습니다.

법무가 알아서 처리하는 문서라고 생각하기 쉽습니다. 계약서 형식이고 조항 문구가 낯설어서 제품이나 개발 쪽에서 볼 일이 없어 보입니다. 그런데 이 문서에서 가장 자주 틀리는 항목은 법률 문구가 아니라 사실관계입니다. 어떤 항목을 넘기는지, 어떤 하위 업체를 쓰는지, 데이터가 어느 나라 서버에 있는지는 코드와 인프라를 아는 사람만 답할 수 있습니다.

그대로 두면 서명한 내용과 실제 동작이 어긋난 채로 굴러갑니다. 계약서에는 세 개의 하위 처리자가 적혀 있는데 실제로는 여섯 개를 쓰고 있는 상태가 되고, 그 사실은 대개 고객사 보안 점검이나 사고 조사에서 드러납니다. 그때는 항목 하나를 빠뜨린 문제가 아니라 계약 위반으로 다뤄집니다.