Desenvolvimento de Software em Conformidade com o RGPD: Um Guia Prático para Empresas do Reino Unido e da UE

Todas as semanas falamos com empresas que desenvolveram o seu software sem pensar seriamente no RGPD, e agora estão a pagar por isso — por vezes em honorários jurídicos, por vezes em rearquitetura de emergência, e ocasionalmente em coimas da ICO. A conversa começa normalmente com uma frase que aprendemos a reconhecer: "Sabemos que precisamos de tratar da nossa conformidade, só ainda não tivemos oportunidade."

Essa "oportunidade" raramente surge de forma natural. A conformidade não chega como um item de sprint programado. Chega sob a forma de uma violação, uma carta regulatória, um questionário de due diligence de um cliente empresarial que a equipa comercial precisa de responder em quarenta e oito horas, ou um titular de dados a ameaçar ação legal por dados que não consegue eliminar. Quando o RGPD se torna urgente, já é caro.

A razão pela qual adaptar a conformidade a posteriori é tão doloroso é que o RGPD não é um conjunto de políticas que se anexa a uma aplicação em funcionamento. É uma disciplina de design. Afeta o esquema da sua base de dados, a sua arquitetura de registo, as suas escolhas de serviços de terceiros, o design da sua API, os seus fluxos voltados para o utilizador e os processos internos da sua equipa. Cada um desses aspetos é mais fácil de acertar no início de um projeto do que corrigir após o facto.

Na Cyberbeak, incorporamos a privacidade nos nossos projetos de software desde a primeira semana de descoberta. Este guia explica exatamente o que isso significa na prática — os conceitos legais traduzidos em decisões de engenharia, os padrões que tornam a conformidade sustentável e os erros que vemos com mais frequência nas bases de código que chegam à nossa mesa para trabalho de remediação.

---

RGPD numa Frase

O Regulamento Geral sobre a Proteção de Dados (UE 2016/679) é a lei de proteção de dados que se aplica a qualquer organização que trate dados pessoais de pessoas na UE ou no Reino Unido, independentemente de onde essa organização esteja sediada. Se tiver utilizadores na UE ou no Reino Unido, aplica-se a si.

Em termos práticos, exige seis coisas:

• Base jurídica — cada ato de tratamento de dados pessoais deve ter uma justificação legal.
• Transparência — as pessoas devem ser claramente informadas sobre que dados recolhe e por quê.
• Minimização de dados — só pode recolher dados necessários para a finalidade declarada.
• Direitos — os titulares têm o direito de aceder, corrigir, apagar e exportar os seus dados.
• Segurança — deve proteger os dados pessoais com medidas técnicas e organizacionais adequadas.
• Responsabilidade — deve ser capaz de demonstrar a conformidade, não apenas afirmá-la.

A coima máxima por uma infração grave é de 20 milhões de euros ou 4% do volume de negócios anual global — o que for mais elevado. A ICO (a autoridade reguladora do Reino Unido) e as autoridades de supervisão da UE demonstraram estar dispostas a aplicar esses valores. A British Airways foi multada em 20 milhões de libras. A Amazon foi multada em 746 milhões de euros. Estes não são casos extremos de multinacionais imprudentes; as pequenas e médias empresas também são alvo de fiscalização, e o dano à reputação resultante de uma notificação pública de execução pode ser mais prejudicial do que a própria coima.

---

Privacidade por Design: O Que Significa na Prática

A privacidade por design está diretamente escrita no Artigo 25.º do RGPD. Não é uma orientação opcional — é uma obrigação legal. O regulamento exige que a proteção de dados seja considerada no momento de conceber sistemas e processos, não como uma reflexão posterior.

Os sete princípios fundamentais da privacidade por design, traduzidos em decisões de engenharia, são os seguintes:

1. Proativo, Não Reativo

Conceber para a privacidade antes de ocorrer um problema. Em termos de software: realizar uma Avaliação de Impacto sobre a Proteção de Dados (AIPD) durante a fase de descoberta, antes de qualquer linha de código ser escrita, para qualquer funcionalidade que envolva tratamento em larga escala de dados sensíveis.

2. Privacidade como Configuração Predefinida

O comportamento predefinido do sistema deve ser a opção mais protetora da privacidade. Os utilizadores não devem ter de tomar medidas para proteger a sua privacidade — devem ter de tomar medidas para a reduzir. Em termos de software: os e-mails de marketing são opt-in e não opt-out; os cookies de análise estão desativados até serem aceites; as funcionalidades de partilha social não estão pré-ativadas.

3. Privacidade Incorporada no Design

A privacidade não é uma camada por cima da arquitetura — faz parte dela. Em termos de software: o seu modelo de dados separa as informações pessoalmente identificáveis dos dados transacionais desde o início; os seus microsserviços são delimitados de forma que apenas os serviços que necessitam de PII possam aceder a elas; a sua infraestrutura de registo remove ou anonimiza os identificadores antes de escrever em armazéns de registos centralizados.

4. Funcionalidade Total

A privacidade não deve ter custos para a funcionalidade. Não deve ter de escolher entre um produto útil e um produto em conformidade. Em termos de software: a análise anonimizada pode ainda fornecer informações significativas sobre o produto; a personalização baseada em consentimento pode ainda oferecer uma boa experiência ao utilizador.

5. Segurança de Ponta a Ponta

Proteção para todo o ciclo de vida dos dados. Em termos de software: encriptação em repouso, encriptação em trânsito, eliminação segura quando os dados já não são necessários, e não apenas na camada de aplicação — também na camada de base de dados e de armazenamento.

6. Visibilidade e Transparência

Os utilizadores devem poder ver que dados detém sobre eles e o que faz com eles. Em termos de software: um portal de self-service para pedidos de acesso de titulares, uma política de privacidade clara e precisa, e registos de auditoria que a equipa de conformidade possa efetivamente ler.

7. Respeito pela Privacidade do Utilizador

Coloque os interesses do utilizador em primeiro lugar. Em termos de software: as políticas de retenção de dados são aplicadas pela aplicação, e não deixadas para limpeza manual; a eliminação propaga-se por todos os sistemas, incluindo cópias de segurança e caches.

---

Base Jurídica para o Tratamento de Dados

Esta é a área onde mais frequentemente vemos incompreensões fundamentais em projetos de software — não porque os programadores sejam negligentes, mas porque os conceitos legais têm consequências técnicas que são fáceis de ignorar.

O RGPD define seis bases jurídicas para o tratamento de dados pessoais. As quatro mais relevantes para a maioria dos produtos de software são:

Base Jurídica	Quando se Aplica	Implicação Técnica
Consentimento	Marketing, análise opcional, cookies não essenciais	Deve ser livremente concedido, específico, informado e inequívoco. Deve ser revogável. Requer um registo de consentimento com carimbo temporal.
Contrato	Tratamento necessário para cumprir um serviço a que o utilizador aderiu	Não é necessário consentimento separado, mas o tratamento deve ser genuinamente necessário para o contrato.
Interesse Legítimo	Análise de negócio, prevenção de fraude, segurança de rede	Requer uma Avaliação de Interesse Legítimo. Deve passar por um teste de ponderação em relação aos direitos individuais.
Obrigação Legal	Registos fiscais, verificações de combate ao branqueamento de capitais	Deve ser possível identificar a lei específica. Não pode ser utilizada como cobertura geral.

A razão pela qual escolher a base errada é um problema técnico e não apenas um problema legal:

Se depende do consentimento, mas depois trata os dados de formas para as quais os utilizadores não consentiram especificamente, precisa de obter novamente o consentimento — o que significa contactar novamente a sua base de utilizadores e potencialmente perder uma grande proporção. Se afirma interesse legítimo, mas não realizou uma Avaliação de Interesse Legítimo, poderá ter de eliminar dados já recolhidos e rearquitetar o pipeline que dependia deles.

A base jurídica também determina que direitos se aplicam. Com base no consentimento, os utilizadores têm um direito absoluto ao apagamento. Com base no contrato, o direito ao apagamento pode ser recusado se os dados ainda forem necessários para cumprir o contrato. Isto afeta se o seu fluxo de "eliminar conta" precisa de se propagar por todas as tabelas ou se pode preservar alguns registos.

A nossa recomendação: Documente a base jurídica para cada atividade de tratamento de dados num Registo das Atividades de Tratamento (RAT) antes de as decisões de arquitetura serem tomadas. Isso irá alterar essas decisões.

---

Implementação da Gestão de Consentimento

A gestão de consentimento é a área mais visível para os utilizadores finais — e a área onde as implementações mais frequentemente não cumprem o padrão legal.

O Que Requer o Consentimento Válido

Nos termos do RGPD, o consentimento deve ser:

• Livremente concedido — o consentimento condicional (deve aceitar cookies para utilizar o site) não é consentimento válido para cookies não essenciais.
• Específico — o consentimento para análise não abrange o consentimento para segmentação publicitária.
• Informado — os utilizadores devem saber a que estão a consentir antes de o fazerem.
• Inequívoco — as caixas pré-marcadas não constituem consentimento. O silêncio não constitui consentimento.
• Revogável — retirar o consentimento deve ser tão fácil como dá-lo.

Implementação do Consentimento de Cookies

Um banner de cookies tecnicamente em conformidade deve:

1. Bloquear o carregamento de todos os scripts não essenciais até que o consentimento seja concedido — não apenas definir um cookie indicando preferência.
2. Registar o consentimento com um carimbo temporal, a versão da política de privacidade apresentada e as categorias específicas aceites.
3. Permitir consentimento granular por categoria (necessários, análise, marketing, preferências).
4. Fornecer um mecanismo para retirar o consentimento a qualquer momento.

Isso significa que a configuração do seu gestor de tags deve estar condicionada ao estado de consentimento. Se estiver a utilizar o Google Tag Manager, os scripts nas categorias de análise e publicidade só devem ser ativados após os sinais de consentimento correspondentes estarem definidos. Implementar isto incorretamente — exibindo um banner mas carregando scripts independentemente — é uma das violações mais comuns que encontramos.

Plataformas de Gestão de Consentimento

Para a maioria dos projetos, implementar a gestão de consentimento de raiz não é a escolha certa. As principais opções são:

OneTrust — de nível empresarial, altamente configurável, integra-se com a maioria dos CMPs e catálogos de dados. Adequado para organizações de maior dimensão com necessidades de consentimento complexas.

Cookiebot (agora Usercentrics) — boa opção para o segmento médio, analisa automaticamente cookies e categoriza-os, integração fácil via tag de script ou GTM.

Implementação personalizada — adequada para aplicações que têm fluxos de consentimento incomuns (por exemplo, um SaaS B2B em que o empregador do utilizador final é o responsável pelo tratamento) ou onde as plataformas existentes não se adequam aos requisitos de UX. Requer um design cuidadoso do esquema de registo de consentimento.

Centro de Preferências de Marketing

Para além dos cookies, os produtos que enviam comunicações de marketing devem implementar um centro de preferências — uma interface voltada para o utilizador onde os indivíduos podem gerir as suas preferências de comunicação. Isto precisa de ser suportado por uma base de dados que armazene:

• Estado de consentimento por canal (e-mail, SMS, notificações push)
• Carimbo temporal de cada alteração
• Origem do consentimento (formulário de registo, checkout, atualização do centro de preferências)
• As categorias específicas de marketing em que o utilizador optou

Estes dados devem ser verificados no momento do envio, não apenas no momento da recolha — o que significa que a sua lógica de envio de e-mails deve consultar o estado de consentimento atual, não depender de um sinalizador definido no registo.

---

Minimização de Dados na Prática

A minimização de dados — Artigo 5.º, n.º 1, alínea c) — é o princípio de que só deve recolher dados pessoais necessários para a finalidade específica declarada. Parece simples. Na prática, requer disciplina ativa porque a tendência natural das equipas de software é capturar o máximo de dados possível "por caso de ser útil mais tarde".

Inventário de PII e Classificação de Dados

O ponto de partida é saber que dados pessoais está efetivamente a recolher. Um inventário de PII é um catálogo estruturado de cada ponto de dados que o seu sistema trata, etiquetado com:

• O que é (nome, e-mail, endereço IP, histórico de compras, dados de saúde)
• Por que o recolhe (necessário para contrato, análise, obrigação legal)
• Onde está armazenado (que base de dados, que serviço de terceiros)
• Por quanto tempo é retido
• Quem tem acesso a ele

Este exercício frequentemente surpreende as equipas. Endereços IP em registos de servidor que ninguém pensou. Strings de user-agent a serem escritas numa base de dados juntamente com registos de conta. Endereços completos a serem armazenados para uma funcionalidade de entrega que foi descontinuada há dezoito meses.

Padrões Arquiteturais para a Minimização

Para além do inventário, a própria arquitetura deve tornar a minimização o caminho de menor resistência:

• Separe os armazéns de PII dos armazéns transacionais. Se a sua base de dados de análise fizer junções diretamente em endereços de e-mail, isso é um problema de minimização de dados. Utilize identificadores pseudónimos em pipelines de análise e mantenha a tabela de mapeamento num serviço restrito.
• Recolha no ponto de necessidade, não especulativamente. Não peça um número de telemóvel na criação de conta se os números de telemóvel só são necessários para autenticação de dois fatores — solicite-o quando o utilizador ativar a 2FA.
• Implemente a retenção em código, não em documentos de política. Uma política que diz que os dados são eliminados após dois anos não é conformidade. Uma tarefa agendada que aplica a eliminação após dois anos, com registos que o comprovam, é conformidade.

---

Direitos dos Titulares dos Dados

O RGPD concede aos titulares oito direitos. Os quatro que requerem a implementação técnica mais significativa são:

Direito de Acesso (Pedido de Acesso do Titular)

Um titular pode solicitar uma cópia de todos os dados pessoais que detém sobre ele. Tem um mês de calendário para responder. A resposta deve estar num formato comummente utilizado e legível por máquina.

Implementação técnica: Construa uma camada de agregação de dados capaz de recolher dados sobre um utilizador de cada serviço que os detenha — a sua base de dados de aplicação, a sua plataforma de análise, o seu CRM, o seu sistema de tickets de suporte — e compilá-los num export estruturado. Para a maioria das aplicações, esta é uma tarefa de engenharia não trivial, razão pela qual precisa de ser planeada na fase de arquitetura e não tratada de forma ad-hoc quando um pedido chega.

Para aplicações de grande volume, um portal de self-service para pedidos de acesso de titulares que gere o export automaticamente é tanto uma melhoria de conformidade como operacional.

Direito ao Apagamento (Direito a Ser Esquecido)

Um titular pode solicitar a eliminação dos seus dados pessoais. O direito não é absoluto — pode ser recusado quando os dados são necessários para obrigações legais, para o interesse público, ou quando o interesse legítimo prevalece sobre os direitos individuais — mas para a maioria das aplicações de consumo, um pedido de apagamento válido deve ser honrado.

Implementação técnica: A eliminação deve propagar-se por todo o lado onde os dados existem. Isso significa:

• Base de dados da aplicação (eliminação imediata ou pseudonimização dos campos de PII)
• Cópias de segurança (um processo claro para excluir registos específicos da restauração de cópias de segurança, ou um calendário de retenção de cópias de segurança que limite o tempo que os dados eliminados persistem)
• Caches (invalidação de cache na eliminação)
• Serviços de terceiros (pedidos de eliminação ao CRM, plataforma de e-mail, ferramenta de análise, sistema de suporte)
• Dados derivados (conjuntos de dados de treino de ML, agregados de análise que possam conter dados ao nível individual)

Direito à Portabilidade

Um titular pode solicitar os seus dados num formato estruturado, comummente utilizado e legível por máquina — tipicamente JSON ou CSV — com o propósito de os transferir para outro serviço.

Implementação técnica: Desenhe o seu formato de export de dados com antecedência. Deve abranger os dados fornecidos ativamente pelo utilizador (informações de conta, conteúdo que criou, preferências que definiu) e não dados inferidos ou derivados. O endpoint de export deve ser autenticado, com limite de taxa e auditado.

Direito de Retificação

Um titular pode solicitar a correção de dados pessoais inexatos.

Implementação técnica: Cada campo de PII no seu sistema precisa de um caminho de edição — o que parece óbvio mas nem sempre é verdade. Os registos de eventos imutáveis que contêm dados pessoais apresentam um desafio particular; a abordagem recomendada é a pseudonimização em vez da correção de registos históricos.

---

Residência de Dados e Subcontratantes

Uma das implicações técnicas mais significativas e subestimadas do RGPD é a restrição à transferência de dados pessoais para fora da UE/EEE (e fora do Reino Unido ao abrigo do RGPD do Reino Unido).

O Panorama Pós-Schrems II

A decisão Schrems II do Tribunal de Justiça da UE em 2020 invalidou o quadro do Escudo de Privacidade UE-EUA, que tinha sido o mecanismo jurídico que permitia a transferência de dados pessoais da UE para subcontratantes sediados nos EUA. O mecanismo de substituição são as Cláusulas Contratuais Tipo (CCT) — cláusulas contratuais pré-aprovadas que ambas as partes assinam antes de qualquer transferência ter lugar.

Na prática, isto significa que se estiver a utilizar qualquer ferramenta SaaS sediada nos EUA — uma plataforma de análise alojada nos EUA, centros de dados de um fornecedor de cloud sediado nos EUA, um CRM sediado nos EUA — precisa de:

1. Verificar se o fornecedor tem CCT disponíveis (a maioria dos grandes fornecedores tem).
2. Executar essas CCT antes de transferir dados pessoais.
3. Realizar uma Avaliação do Impacto da Transferência para verificar se as leis do país destinatário não comprometem as proteções das CCT.

Auditoria dos Seus Fornecedores de Cloud e Pilha SaaS

Uma auditoria de transferência de dados deve documentar cada serviço de terceiros para o qual a sua aplicação envia dados pessoais e, para cada um, registar:

• Mecanismo de transferência legal (CCT, decisão de adequação, derrogação)
• Localização(ões) dos centros de dados
• Subcontratantes utilizados por esse fornecedor
• Ligação ao DPA executado

Esta lista é mais longa do que a maioria das equipas espera. Considere: o seu fornecedor de alojamento, o seu CDN, o seu serviço de envio de e-mails, a sua ferramenta de monitorização de erros, a sua ferramenta de monitorização do desempenho da aplicação, a sua plataforma de suporte ao cliente, o seu CRM, a sua ferramenta de automação de marketing, o seu widget de chat em tempo real, a sua plataforma de análise e quaisquer scripts de terceiros carregados no seu front-end.

Contratos de Tratamento de Dados

Cada terceiro que trate dados pessoais em seu nome deve assinar um Contrato de Tratamento de Dados (DPA). Este é um requisito contratual ao abrigo do Artigo 28.º do RGPD, não uma mitigação de risco opcional. A maioria dos fornecedores SaaS de boa reputação tem um DPA padrão disponível no seu centro de confiança ou mediante pedido. A ausência de um DPA com um fornecedor é em si mesma uma violação de conformidade, independentemente de ter ocorrido algum incidente de dados.

---

Requisitos de Segurança ao Abrigo do RGPD

O Artigo 32.º exige que as organizações implementem "medidas técnicas e organizacionais adequadas" para garantir um nível de segurança adequado ao risco. O RGPD evita deliberadamente especificar normas técnicas exatas — mas os seguintes são amplamente entendidos como requisitos de base para a maioria das aplicações.

Encriptação

• Em repouso: Encriptação de base de dados (AES-256 é o padrão de base), cópias de segurança encriptadas, armazenamento de ficheiros encriptado. Encriptação ao nível da aplicação para campos particularmente sensíveis (dados de saúde, dados financeiros) para que os administradores de base de dados não possam lê-los em texto simples.
• Em trânsito: TLS 1.2 no mínimo, TLS 1.3 preferível. Cabeçalhos HSTS. Sem conteúdo misto. Monitorização de certificados.

Pseudonimização

Substituir informações diretamente identificadoras por identificadores pseudónimos sempre que possível — particularmente em pipelines de análise, ficheiros de registo e bases de dados de relatórios. Isto não elimina as obrigações ao abrigo do RGPD (os dados pseudónimos continuam a ser dados pessoais ao abrigo do RGPD), mas reduz significativamente o impacto de uma violação.

Controlos de Acesso

• Controlo de acesso baseado em funções com princípios de menor privilégio.
• Autenticação multifator para todo o acesso interno a sistemas de produção.
• Revisões regulares de acesso — particularmente quando os membros da equipa mudam de funções ou saem.
• Separar os ambientes de produção e desenvolvimento, sem PII de produção em sistemas de desenvolvimento.

Registo de Auditoria

Um registo de auditoria abrangente regista quem acedeu ou modificou dados pessoais, quando, de onde e porquê. Serve dois propósitos: permite a deteção de violações e demonstra responsabilidade perante os reguladores. O próprio registo deve ser protegido contra adulterações.

Deteção de Violações e a Regra das 72 Horas

O Artigo 33.º exige a notificação à autoridade de supervisão (a ICO para organizações do Reino Unido, a autoridade competente da UE para organizações da UE) no prazo de 72 horas após tomar conhecimento de uma violação de dados pessoais, quando a violação seja suscetível de resultar em risco para os titulares.

Isto significa que a sua monitorização de segurança deve ser capaz de detetar violações rapidamente — a deteção lenta e a escalada interna lenta irão consumir essa janela de 72 horas. O seu processo de resposta a incidentes deve incluir uma avaliação formal de se uma violação cumpre o limiar de notificação.

---

RGPD do Reino Unido Pós-Brexit

Após o Brexit, o Reino Unido deixou de estar sujeito ao RGPD da UE. Em vez disso, o RGPD do Reino Unido — que é o RGPD da UE transposto para a lei do Reino Unido com algumas modificações — aplica-se às organizações que tratam dados pessoais de pessoas no Reino Unido.

Na prática, o RGPD do Reino Unido e o RGPD da UE são substancialmente idênticos na maioria dos aspetos. Os mesmos princípios, os mesmos direitos, as mesmas bases jurídicas e níveis de coima semelhantes aplicam-se. As principais diferenças práticas são:

• A ICO (Information Commissioner's Office) é a autoridade de supervisão para o RGPD do Reino Unido, e não as autoridades de supervisão da UE.
• A UE concedeu ao Reino Unido uma decisão de adequação, o que significa que os dados pessoais da UE podem fluir para o Reino Unido sem CCT (à data de redação — as decisões de adequação podem ser revogadas).
• As organizações do Reino Unido que também tratam dados de residentes da UE devem cumprir tanto o RGPD do Reino Unido como o RGPD da UE, e podem precisar de nomear um representante na UE.
• As CCT do Reino Unido (denominadas Acordo Internacional de Transferência de Dados ou IDTA) diferem no formato das CCT da UE, embora as proteções substantivas estejam alinhadas.

Para a maioria das empresas do Reino Unido, as obrigações práticas do dia a dia são quase idênticas às exigidas pelo RGPD da UE. A complexidade surge para empresas que operam em ambas as jurisdições — particularmente aquelas com utilizadores tanto do Reino Unido como da UE, ou aquelas que utilizam subcontratantes sediados na UE.

---

Erros Comuns de RGPD em Projetos de Software

Estes são os padrões que vemos mais frequentemente quando revemos bases de código existentes em busca de lacunas de conformidade:

Armazenar mais dados do que a finalidade declarada exige. Formulários de registo que pedem data de nascimento "para personalização" mas nunca a utilizam. Integrações de CRM que sincronizam todos os campos do utilizador, independentemente de o CRM precisar de todos eles. O hábito de recolher dados especulativamente está profundamente enraizado na cultura de produto e requer resistência ativa.

Sem políticas de retenção de dados aplicadas em código. A política de privacidade diz que os dados são retidos durante três anos. A base de dados tem registos que remontam a oito anos sem qualquer tarefa de eliminação à vista. Um documento de política que não é aplicado pela aplicação não é conformidade — é responsabilidade.

Scripts de terceiros esquecidos a transferir dados para os EUA. Uma equipa de marketing adiciona um widget de chat em tempo real. Um programador adiciona uma ferramenta de mapa de calor. Outro programador adiciona um tipo de letra de terceiros. Nenhum destes aparece no registo de DPA. Cada um está a transferir endereços IP dos utilizadores — e potencialmente muito mais — para um servidor sediado nos EUA sem mecanismo de transferência legal e sem ser bloqueado pelo sistema de gestão de consentimento.

Contratos de Tratamento de Dados em falta com fornecedores de cloud. A AWS, a GCP e a Azure têm DPAs disponíveis e a maioria dos clientes executa-os automaticamente na criação de conta. Mas os serviços complementares — uma ferramenta de monitorização de nicho, um fornecedor de e-mail especializado, uma pequena plataforma de feedback de clientes — frequentemente ficam sem DPAs executados simplesmente porque ninguém pensou em pedir.

Confundir consentimento com qualquer interação. Continuar a enviar e-mails de marketing porque um utilizador "não cancelou a subscrição" não é consentimento. Tratar o registo de conta como consentimento para análise não é consentimento. Estes padrões eram comuns antes do RGPD e ainda são comuns hoje.

Sem processo para pedidos de acesso de titulares. Quando chega um pedido de acesso, alguém precisa de ser capaz de reunir todos os dados detidos sobre um indivíduo em todos os sistemas dentro de um mês. Se não existir um processo definido e nenhum mecanismo técnico para o fazer, o primeiro pedido será simultaneamente não conforme e operacionalmente caótico.

---

Como Construímos Software em Conformidade com o RGPD na Cyberbeak

A privacidade por design está incorporada na forma como gerimos cada projeto, e não tratada como uma auditoria de última fase.

Durante a descoberta, realizamos um exercício de mapeamento de fluxo de dados para cada produto — documentando que dados pessoais serão recolhidos, onde serão armazenados, que serviços de terceiros os receberão e qual será a base jurídica para cada atividade de tratamento. Isto normalmente revela decisões que precisam de ser tomadas antes do início do trabalho de arquitetura: se utilizar uma ferramenta SaaS sediada nos EUA ou uma alternativa europeia, como estruturar o modelo de consentimento, se é necessária uma AIPD.

Para projetos que envolvam tratamento de alto risco — dados de saúde, dados financeiros, perfilagem em larga escala, dados sobre crianças — realizamos uma Avaliação de Impacto sobre a Proteção de Dados formal antes do início do desenvolvimento. A AIPD documenta os riscos, as medidas mitigadoras e o risco residual, e é revista por quem ocupa o papel de DPO para o cliente (ou podemos providenciar essa função como serviço).

Durante a arquitetura, concebemos a separação de PII, o registo de auditoria e a retenção de dados no modelo de dados desde o início. Documentamos o Registo das Atividades de Tratamento à medida que avançamos, para que reflita o que o sistema realmente faz e não o que alguém escreveu num documento de política.

Durante o desenvolvimento, os fluxos de consentimento são construídos segundo o padrão legal — não como uma adição cosmética de última hora. A funcionalidade de pedido de acesso de titulares e de apagamento é delimitada como uma funcionalidade de primeira classe, não como um processo manual. As integrações de terceiros são avaliadas quanto à conformidade com a transferência de dados antes de serem adicionadas à base de código.

Durante a entrega, fornecemos ao cliente um RAT completo, um diagrama de fluxo de dados e documentação de todos os subcontratantes terceiros e do respetivo estado de DPA — não porque sejamos obrigados a fazê-lo, mas porque um cliente que compreende a sua postura de conformidade tem muito menos probabilidade de introduzir violações após a entrega.

Não somos advogados, e trabalhamos em conjunto com consultores jurídicos para clientes que necessitam de pareceres legais formais. Mas a implementação técnica da conformidade com o RGPD é claramente uma disciplina de desenvolvimento de software, e é uma que levamos a sério.

---

Perguntas Frequentes

Uma pequena startup precisa de se preocupar com o RGPD?

Sim — o RGPD aplica-se a qualquer organização que trate dados pessoais de indivíduos da UE ou do Reino Unido, independentemente da dimensão ou receita da organização. Não existe isenção para pequenas empresas. Existem alguns requisitos mais leves para organizações de menor dimensão (com menos de 250 trabalhadores, pode haver obrigações reduzidas de Registo das Atividades de Tratamento em alguns casos), mas as obrigações centrais — base jurídica, transparência, minimização de dados, segurança e direitos — aplicam-se universalmente. A ICO publicou notificações de execução contra pequenas empresas e trabalhadores independentes.

Quais são as coimas por violações do RGPD?

Existem dois níveis. O nível inferior aplica-se a violações de obrigações como registos de consentimento, requisitos de subcontratantes de dados e avisos de privacidade — coimas até 10 milhões de euros ou 2% do volume de negócios anual global. O nível superior aplica-se a violações dos princípios fundamentais do RGPD — base jurídica, minimização de dados, direitos dos titulares dos dados e transferências internacionais — coimas até 20 milhões de euros ou 4% do volume de negócios anual global. A ICO tem a sua própria estrutura de coimas equivalente ao abrigo do RGPD do Reino Unido, com um teto de 17,5 milhões de libras ou 4% do volume de negócios global.

Utilizar AWS (ou GCP ou Azure) é compatível com o RGPD?

Os principais fornecedores de cloud investiram fortemente na infraestrutura de conformidade com o RGPD e todos oferecem Contratos de Tratamento de Dados e a possibilidade de escolher regiões de centros de dados na UE. Utilizar a AWS na região de Frankfurt com um DPA executado e CCT para qualquer transferência fora do EEE é compatível com o RGPD. Utilizar a AWS sem um DPA executado, ou tratar dados pessoais da UE numa região dos EUA sem um mecanismo de transferência legal, não é. O fornecedor de cloud é um subcontratante; é o responsável pelo tratamento; ambos têm obrigações e ambos devem documentar devidamente a relação.

Precisamos de um Encarregado de Proteção de Dados?

Um EPD é obrigatório ao abrigo do Artigo 37.º para autoridades públicas, organizações cujas atividades principais envolvam monitorização sistemática em larga escala de indivíduos, e organizações cujas atividades principais envolvam tratamento em larga escala de dados de categoria especial (sensíveis). Para muitas empresas estas condições não se aplicam, e um EPD não é legalmente obrigatório — embora ainda seja frequentemente boa prática nomear alguém com responsabilidade pela proteção de dados. Em caso de dúvida, a ICO publicou orientações sobre quando é necessário um EPD.

O que significa o RGPD do Reino Unido para o nosso negócio pós-Brexit?

Se tiver apenas utilizadores do Reino Unido e tratar dados pessoais exclusivamente no Reino Unido, o RGPD do Reino Unido aplica-se e a ICO é o seu regulador. Se tiver também utilizadores da UE, o RGPD da UE aplica-se adicionalmente, e poderá precisar de um representante na UE. As transferências do Reino Unido para a UE são permitidas ao abrigo da decisão de adequação da UE para o Reino Unido (que deve ser monitorizada para alterações). As transferências da UE para o Reino Unido são igualmente permitidas. As organizações do Reino Unido que transferem dados para países terceiros fora do Reino Unido precisam de utilizar os mecanismos de transferência próprios do Reino Unido — o IDTA ou o Aditamento às CCT da UE — em vez das CCT da UE diretamente.

---

Se está a construir um novo produto e quer acertar no RGPD desde o início — ou se tem uma aplicação existente que necessita de uma revisão de conformidade — podemos ajudar. O nosso processo de descoberta inclui mapeamento de fluxo de dados e uma avaliação de privacidade por design como padrão, e trabalhámos com empresas em fintech, healthtech, comércio eletrónico e SaaS B2B para construir sistemas que são simultaneamente genuinamente úteis e genuinamente conformes.

Entre em contacto connosco para discutir o seu projeto.