DPAs, residência de dados e subcontratantes
A Didit processa dados na UE por predefinição, com processamento no próprio país disponível em contratos empresariais. Aqui está como obter um DPA, as TOM, e as respostas que a tua revisão de compras vai pedir.
Processamento na UE por defeito, 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 aceitou; um DPA, SLA ou MSA contra-assinado no seu próprio papel vem com um acordo de crédito pré-pago. O documento de TOMs está disponível a pedido.
#Onde os dados são processados
Por defeito, 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 correm na mesma região.
O processamento no próprio país - residência local de dados para uma jurisdição específica - está disponível para contas empresariais, sujeito a disponibilidade e contrato. Se a tua exigência for uma região específica, pergunta diretamente que regiões estão disponíveis hoje e obtém a resposta por escrito. A disponibilidade regional muda, e é exatamente o tipo de compromisso que uma revisão de compras vai querer ver evidenciado em vez de descrito.
Uma região que vale a pena afirmar sem rodeios porque é perguntada muitas vezes: não há região de processamento na Rússia, em nenhum plano, pelo que um requisito de manter os dados dentro da Federação Russa não pode ser cumprido.
Se a sua obrigação é armazenamento local e não processamento local, o padrão que a maioria dos clientes usa é processar e expurgar: corra a verificação pela Didit, receba o resultado por webhook, guarde o que precisar na sua própria infraestrutura no seu país e elimine a sessão da Didit logo a seguir. Veja eliminar sessões e dados pessoais.
"Onde são processados os dados?" e "onde são processadas as chamadas biométricas?" podem ter respostas diferentes, que vale a pena confirmar separadamente. Se a tua obrigação cobrir especificamente a região de processamento das operações biométricas, pergunta especificamente sobre isso em vez de aceitares uma resposta geral sobre armazenamento.
#Obter um DPA
Já tem um. A Adenda de tratamento de dados (DPA) é o Anexo 2 dos Termos e condições empresariais que a sua organização aceitou no registo, e o Acordo de nível de serviço (SLA) é o Anexo 1. Ambos estão publicados também em separado (Termos empresariais, Data Processing Addendum, Service Level Agreement) e são o acordo do artigo 28.º entre si e a Didit nos planos gratuito e de pagamento por utilização. O documento de medidas técnicas e organizativas (TOMs) que o artigo 32.º do RGPD espera está disponível a pedido ao seu contacto na Didit, sem NDA.
O que não existe no pagamento por utilização é uma cópia contra-assinada: o contrato são os termos publicados tal como aceites, e o suporte pode confirmar a data de aceitação da sua organização se um auditor o pedir. Se o seu dossiê de conformidade 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 2.000 USD e se converte em créditos que nunca expiram. Peça ao seu contacto na Didit, tendo à mão a sua denominação social, o e-mail do signatário e o país de constituição.
- Termos e Políticas é onde estão o DPA e os acordos assinados.
- As definições da aplicação são separadas das definições ao nível da organização.
Se a sua organização se apoia nos termos aceites e não numa cópia assinada, peça ao suporte que confirme exatamente que versão aceitou e quando. É uma pergunta factual com resposta factual, e é a que um auditor lhe pedirá.
#Subcontratantes
A Didit tem dois subcontratantes:
| Subcontratante | Função | Recebe |
|---|---|---|
| AWS EMEA SARL (eu-west-1, Irlanda) | Infraestrutura na nuvem | Todo o processamento corre aqui |
| Google Maps Platform (Google Cloud EMEA Ltd) | Geocodificação apenas para o comprovativo de morada | O texto da morada que está a ser verificada. Não participa na verificação de ID, prova de vida ou face match, e nunca recebe dados biométricos nem do documento |
Nenhum dado sai do EEE através de qualquer um deles. A lista vinculativa, e as regras de notificação de alterações, estão no DPA: esta tabela é a resposta atual, o DPA é o documento em que a sua equipa de conformidade se apoia.
#Responder a um questionário de segurança
A maior parte do que uma revisão de segurança pede existe como documento. Pela ordem aproximada em que os questionários costumam pedir:
| Vão pedir | O que existe |
|---|---|
| Auditoria independente de controlos | Relatório SOC 2 Type 2, disponível sob acordo de confidencialidade |
| Certificação de segurança da informação | ISO/IEC 27001, mais 27017 e 27018 para cloud |
| Cifragem em trânsito e em repouso | TLS 1.3 e AES-256 |
| Testes de antisuplantação biométrica | iBeta Level 1 PAD ao abrigo da ISO/IEC 30107-3 |
| Testes de penetração | Testes periódicos por terceiros, com remediação acompanhada |
| Condições de tratamento de dados | DPA e TOM |
| Retenção e eliminação | Retenção configurável de 1 mês a 10 anos; eliminação através da API |
| Registo de auditoria | Registo de auditoria de 365 dias de toda a atividade da API |
Consulta certificações e conformidade para a lista completa de credenciais com datas.
#Compromissos que esta página não pode assumir por ti
Algumas perguntas que surgem em processos de compras são contratuais, não técnicas, e a resposta honesta é que pertencem a um acordo negociado:
- Garantias contratuais sobre eliminação, sustentadas por um registo de auditoria inspecionável ou uma certificação periódica.
- Prazos de notificação de violação diferentes do prazo do GDPR - por exemplo a janela de avaliação das Notifiable Data Breaches da Austrália.
- Roteiros de alojamento regional e as datas associadas a eles.
- Obrigações de retenção que acredites que se aplicam a ti.
Traz cada uma dessas questões ao teu contacto na Didit e obtém a resposta no contrato. Uma página de ajuda que descreve um compromisso não é um compromisso, e tratar uma coisa como a outra é um risco para ti, não para nós.
#Pedidos de eliminação dos teus utilizadores
Os teus utilizadores são os teus titulares de dados, e um pedido de eliminação chega-te a ti como responsável pelo tratamento. Tens as ferramentas para atuar sobre ele diretamente: elimina a sessão a partir da consola ou da API, de forma imediata e irreversível. Consulta eliminar sessões e dados pessoais.
Se o teu processo precisar de estar automatizado de ponta a ponta - um pedido no teu produto a desencadear a eliminação aqui - isso é o endpoint de eliminação mais o teu próprio fluxo de trabalho, e é um padrão bem testado.