DPA, 데이터 처리 지역, 하위 처리자
Didit은 기본적으로 EU 내에서 데이터를 처리하며, 엔터프라이즈 계약에서는 국가 내 처리도 가능합니다. DPA, TOM, 그리고 조달 심사에서 묻는 질문에 대한 답을 안내합니다.
기본적으로 EU에서 처리되며, 아일랜드의 AWS에서 이루어집니다. 국내 처리는 엔터프라이즈 계약에서 가용성에 따라 제공됩니다. DPA와 SLA는 공개되어 있고 이미 귀하가 동의한 약관의 일부입니다. 귀사 양식의 상호 서명된 DPA, SLA 또는 MSA는 선불 크레딧 계약과 함께 제공됩니다. TOMs 문서는 요청 시 제공됩니다.
#데이터가 처리되는 위치
기본적으로 검증 데이터는 EU 내 아일랜드(eu-west-1)의 AWS 인프라에서 처리·저장됩니다. 생체 인식 작업도 같은 리전에서 실행됩니다.
국가 내 처리, 즉 특정 관할권을 위한 현지 데이터 처리 지역 설정은 가능 여부와 계약 조건에 따라 엔터프라이즈 계정에서 제공됩니다. 특정 지역이 필요하다면 현재 어떤 지역이 가능한지 직접 문의하고 서면으로 답변을 받으세요. 가능한 지역은 계속 바뀌며, 조달 심사에서는 설명이 아니라 증빙을 원하는 종류의 사안입니다.
자주 묻는 질문이라 분명히 밝혀 둘 리전이 하나 있습니다. 어떤 플랜에도 러시아 처리 리전은 없으므로, 데이터를 러시아 연방 내에 보관해야 한다는 요건은 충족할 수 없습니다.
의무가 현지 처리가 아니라 현지 저장이라면, 대부분의 고객이 사용하는 패턴은 처리 후 삭제입니다. Didit으로 검증을 실행하고, 웹훅으로 결과를 받고, 필요한 것을 자국의 자체 인프라에 저장한 뒤, 바로 Didit에서 세션을 삭제하는 방식입니다. 세션 및 개인 데이터 삭제를 참고하세요.
"데이터는 어디에서 처리되나요?"와 "생체 인식 호출은 어디에서 처리되나요?"는 답이 다를 수 있으므로 각각 별도로 확인할 가치가 있습니다. 생체 인식 작업의 처리 지역에 대한 의무가 있다면, 저장에 대한 일반적인 답변을 받아들이지 말고 이를 구체적으로 문의하세요.
#DPA 받기
이미 가지고 계십니다. 데이터 처리 부속서(DPA)는 조직이 가입 시 동의한 비즈니스 이용약관의 부속서 2이고, 서비스 수준 계약(SLA)은 부속서 1입니다. 둘 다 별도로도 공개되어 있으며(비즈니스 약관, Data Processing Addendum, Service Level Agreement), 무료 및 종량제 플랜에서 귀하와 Didit 간의 제28조 계약입니다. GDPR 제32조가 요구하는 기술적·조직적 조치(TOMs) 문서는 NDA 없이 Didit 담당자에게 요청하면 받을 수 있습니다.
종량제에 없는 것은 상호 서명된 사본입니다. 계약은 동의된 대로의 공개 약관이며, 감사인이 요구하면 지원팀이 조직의 동의 날짜를 확인해 드릴 수 있습니다. 컴플라이언스 파일에 서명된 MSA, 귀사 양식의 DPA, 협상된 SLA가 필요하다면, 이는 2,000 USD부터 시작하는 선불 크레딧 계약과 함께 제공되며 만료되지 않는 크레딧으로 전환됩니다. 법인명, 서명자 이메일, 설립 국가를 준비해 Didit 담당자에게 요청하세요.
- 약관 및 정책에서 DPA와 서명된 계약서를 확인할 수 있습니다.
- 애플리케이션 설정은 조직 전체 설정과는 별개입니다.
조직이 서명된 사본이 아니라 동의한 약관에 의존한다면, 어떤 버전에 언제 동의했는지 정확히 확인해 달라고 지원팀에 요청하세요. 사실에 대한 질문이고 사실적인 답이 있으며, 감사인이 요구하는 것도 바로 그 답입니다.
#하위 처리자
Didit의 하위 처리자는 두 곳입니다.
| 하위 처리자 | 역할 | 수신 데이터 |
|---|---|---|
| AWS EMEA SARL(eu-west-1, 아일랜드) | 클라우드 인프라 | 모든 처리가 여기서 실행됩니다 |
| Google Maps Platform(Google Cloud EMEA Ltd) | 주소 증명 전용 지오코딩 | 검증 중인 주소 텍스트. 신분증 확인, 라이브니스, 얼굴 매칭에는 관여하지 않으며 생체 데이터나 문서 데이터를 받지 않습니다 |
어느 쪽을 통해서도 데이터가 EEA를 벗어나지 않습니다. 구속력 있는 목록과 변경 통지 절차는 DPA에 있습니다. 이 표는 현재의 답이고, 컴플라이언스 팀이 의존해야 할 문서는 DPA입니다.
#보안 설문지에 답하기
보안 심사에서 요구하는 내용의 대부분은 이미 문서로 존재합니다. 설문지가 묻는 순서대로 대략 나열하면 다음과 같습니다.
| 요구 사항 | 존재하는 문서/근거 |
|---|---|
| 통제에 대한 독립 감사 | SOC 2 Type 2 보고서, NDA 하에 제공 |
| 정보보안 인증 | ISO/IEC 27001, 클라우드용 27017 및 27018 포함 |
| 전송 및 저장 시 암호화 | TLS 1.3 및 AES-256 |
| 생체 인식 위변조 방지 테스트 | ISO/IEC 30107-3 기반 iBeta Level 1 PAD |
| 침투 테스트 | 정기적인 제3자 테스트 및 시정 조치 추적 |
| 데이터 처리 약관 | DPA 및 TOM |
| 보관 및 삭제 | 1개월부터 10년까지 설정 가능한 보관 기간, API를 통한 삭제 |
| 감사 추적 | 모든 API 활동에 대한 365일 감사 로그 |
발급일이 포함된 전체 인증 목록은 인증 및 컴플라이언스를 참고하세요.
#이 페이지가 대신 약속할 수 없는 사항
조달 과정에서 나오는 일부 질문은 기술적인 것이 아니라 계약상의 문제이며, 정직한 답은 그것이 협상된 계약서에 담겨야 한다는 것입니다.
- 삭제에 대한 계약상 보증, 그리고 이를 뒷받침하는 감사 가능한 추적 기록이나 정기 인증
- GDPR 기준 시계 외의 침해 통지 기한, 예를 들어 호주의 신고 가능한 데이터 침해 평가 기간
- 지역별 호스팅 로드맵과 그에 따른 일정
- 귀사가 해당된다고 생각하는 보관 의무
이런 사항은 각각 Didit 담당자에게 가져가 계약서에 답을 담으세요. 도움말 페이지에서 설명하는 약속은 계약이 아니며, 이를 계약처럼 취급하는 것은 우리가 아니라 귀사에 위험이 됩니다.
#사용자로부터의 삭제 요청
귀사의 사용자는 귀사의 정보 주체이며, 삭제 요청은 컨트롤러인 귀사에게 옵니다. 귀사는 이를 직접 처리할 수단을 가지고 있습니다. 콘솔이나 API에서 세션을 삭제하면 즉시 되돌릴 수 없이 처리됩니다. 세션과 개인 데이터 삭제하기를 참고하세요.
프로세스를 end-to-end로 자동화해야 한다면, 즉 귀사 제품에서의 요청이 이곳의 삭제를 트리거하도록 해야 한다면, 이는 삭제 엔드포인트와 귀사 자체 워크플로를 결합하는 방식이며 이미 널리 쓰이는 패턴입니다.