DPAs, residência de dados e suboperadores
Por padrão, a Didit processa dados na UE, com processamento no país disponível em contratos enterprise. Veja como obter um DPA, os TOMs, e respostas para o que a sua análise de compras vai perguntar.
Processamento na UE por padrão, na AWS na Irlanda. O processamento no país está disponível em contratos enterprise, sujeito a disponibilidade. O DPA e o SLA estão publicados e já fazem parte dos termos que você aceitou; um DPA, SLA ou MSA assinado pelas duas partes no seu próprio papel vem com um acordo de crédito pré-pago. O documento de TOMs está disponível sob solicitação.
#Onde os dados são processados
Por padrão, os dados de verificação são processados e armazenados na UE, em infraestrutura AWS na Irlanda (eu-west-1). As operações biométricas rodam na mesma região.
O processamento no país - residência local de dados para uma jurisdição específica - está disponível para contas enterprise, sujeito à disponibilidade e a contrato. Se a sua exigência é uma região específica, pergunte diretamente quais regiões estão disponíveis hoje e obtenha a resposta por escrito. A disponibilidade regional muda, e é exatamente o tipo de compromisso que uma análise de compras vai querer ver comprovado, não apenas descrito.
Uma região que vale dizer com clareza porque é perguntada com frequência: não há região de processamento na Rússia, em nenhum plano, então uma exigência de manter os dados dentro da Federação Russa não pode ser atendida.
Se sua obrigação é armazenamento local e não processamento local, o padrão que a maioria dos clientes usa é processar e expurgar: rode a verificação pela Didit, receba o resultado por webhook, guarde o que precisar na sua própria infraestrutura no seu país e exclua a sessão da Didit logo depois. Veja excluir sessões e dados pessoais.
"Onde os dados são processados?" e "onde as chamadas biométricas são processadas?" podem ter respostas diferentes, e vale a pena confirmar cada uma separadamente. Se a sua obrigação cobre especificamente a região de processamento das operações biométricas, pergunte especificamente sobre isso, em vez de aceitar uma resposta genérica sobre armazenamento.
#Como obter um DPA
Você já tem um. O Adendo de tratamento de dados (DPA) é o Anexo 2 dos Termos e condições comerciais que sua organização aceitou no cadastro, e o Acordo de nível de serviço (SLA) é o Anexo 1. Ambos também estão publicados separadamente (Termos comerciais, Data Processing Addendum, Service Level Agreement) e são o acordo do artigo 28 entre você e a Didit nos planos gratuito e de pagamento por uso. O documento de medidas técnicas e organizacionais (TOMs) esperado pelo artigo 32 do GDPR está disponível sob solicitação ao seu contato na Didit, sem NDA.
O que não existe no pagamento por uso é uma cópia assinada pelas duas partes: o contrato são os termos publicados conforme aceitos, e o suporte pode confirmar a data de aceite da sua organização se um auditor pedir. Se seu dossiê de compliance precisa de um MSA assinado, um DPA no seu próprio papel ou um SLA negociado, isso vem com um acordo de crédito pré-pago, que começa em US$ 2.000 e se converte em créditos que nunca expiram. Peça ao seu contato na Didit tendo em mãos sua razão social, o e-mail do signatário e seu país de constituição.
- Terms & Policies é onde ficam o DPA e os acordos assinados.
- As configurações do aplicativo são separadas das configurações de toda a organização.
Se sua organização se apoia nos termos aceitos e não numa cópia assinada, peça ao suporte que confirme exatamente qual versão você aceitou e quando. É uma pergunta factual com resposta factual, e é a que um auditor vai pedir.
#Suboperadores
A Didit tem dois suboperadores:
| Suboperador | Função | Recebe |
|---|---|---|
| AWS EMEA SARL (eu-west-1, Irlanda) | Infraestrutura em nuvem | Todo o processamento roda aqui |
| Google Maps Platform (Google Cloud EMEA Ltd) | Geocodificação apenas para o comprovante de endereço | O texto do endereço que está sendo verificado. Não participa da verificação de ID, prova de vida ou face match, e nunca recebe dados biométricos ou do documento |
Nenhum dado sai do EEE por nenhum dos dois. A lista vinculante, e as regras de notificação de mudanças nela, estão no DPA: esta tabela é a resposta atual, o DPA é o documento em que sua equipe de compliance se apoia.
#Respondendo a um questionário de segurança
A maior parte do que uma análise de segurança pede existe como documento. Aproximadamente na ordem em que os questionários costumam pedir:
| Eles vão pedir | O que existe |
|---|---|
| Auditoria independente de controles | Relatório SOC 2 Type 2, disponível sob NDA |
| Certificação de segurança da informação | ISO/IEC 27001, mais 27017 e 27018 para nuvem |
| Criptografia em trânsito e em repouso | TLS 1.3 e AES-256 |
| Testes de antifraude biométrica | iBeta Level 1 PAD sob ISO/IEC 30107-3 |
| Testes de invasão | Testes periódicos de terceiros, com correção rastreada |
| Termos de tratamento de dados | DPA e TOMs |
| Retenção e eliminação | Retenção configurável de 1 mês a 10 anos; eliminação via API |
| Trilha de auditoria | Log de auditoria de 365 dias de toda a atividade de API |
Veja certificações e conformidade para a lista completa de credenciais com datas.
#Compromissos que esta página não pode assumir por você
Algumas questões que aparecem em processos de compras são contratuais, não técnicas, e a resposta honesta é que elas pertencem a um acordo negociado:
- Garantias contratuais sobre exclusão, respaldadas por uma trilha de auditoria inspecionável ou certificação periódica.
- Prazos de notificação de violação além do prazo do GDPR - por exemplo, a janela de avaliação de Notifiable Data Breaches da Austrália.
- Roteiros de hospedagem regional e as datas associadas a eles.
- Obrigações de retenção que você acredita que se aplicam a você.
Leve cada uma dessas questões ao seu contato na Didit e obtenha a resposta no contrato. Uma página de ajuda descrevendo um compromisso não é um compromisso, e tratar uma coisa como a outra é um risco para você, não para nós.
#Solicitações de eliminação vindas dos seus usuários
Os seus usuários são os seus titulares de dados, e uma solicitação de eliminação chega até você como controlador. Você tem as ferramentas para agir sobre ela diretamente: exclua a sessão pelo console ou pela API, de forma imediata e irreversível. Veja excluindo sessões e dados pessoais.
Se o seu processo precisa ser automatizado de ponta a ponta - uma solicitação no seu produto disparando a exclusão aqui - isso é o endpoint de exclusão mais o seu próprio workflow, e é um padrão bem estabelecido.