# Subcontratação de dados quando prestadores acedem a servidores

> Manutenção remota, patches, perícia forense: o que um contrato de subcontratação nos termos do Art. 28 RGPD regula quando prestadores acedem ao servidor.

Fonte: https://phpsos.de/pt/blog/auftragsverarbeitung-serverzugriff/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Em resumo:** Se um prestador de TI acede a servidores onde existem dados pessoais, é em regra necessário um contrato de subcontratação (em alemão AVV) nos termos do Art. 28 do RGPD. Estabelece que o prestador atua apenas segundo instruções, preserva a confidencialidade, adota medidas de segurança adequadas, só envolve outros parceiros com autorização e notifica as violações de dados sem demora. Celebre o AVV antes de ocorrer a emergência. Esta página é informação geral e não constitui aconselhamento jurídico.

## Quando é preciso depressa, falta muitas vezes o contrato

Na semana após o PHP2Shell, muitas empresas recorreram a ajuda externa com urgência. Um administrador devia atualizar o PHP, uma agência reiniciar os processos, uma equipa forense verificar registos. Para isso, externos obtiveram acesso a servidores onde existem contas de clientes, encomendas e dados de formulários. A pergunta sobre em que base de proteção de dados isso aconteceu só se colocou muitas vezes depois.

É compreensível, pois em caso de emergência conta a rapidez. Mas é evitável. Com algumas preparações, é possível conciliar as duas coisas: ajuda rápida e uma base correta.

## Quando é necessário um AVV com o prestador de TI

Há subcontratação quando um prestador trata dados pessoais por conta e segundo instruções de um responsável pelo tratamento. Em servidores web, basta muitas vezes para isso a mera possibilidade de acesso: quem trabalha com direitos de root num servidor pode ler a base de dados com dados de clientes, mesmo que não o pretenda.

Situações típicas com acesso ao servidor são:

- manutenção corrente e atualizações por agência ou casa de sistemas,
- operação do servidor por um fornecedor de alojamento com serviços geridos,
- ajuda de emergência, limpeza e recuperação após um ataque,
- investigação forense com cópias de suportes de dados e registos,
- monitorização, em que dados de registo fluem para o prestador.

Também as intervenções curtas contam. Uma sessão remota com partilha de ecrã, em que um técnico “só dá uma vista de olhos”, pode mostrar-lhe dados de clientes. Uma exportação da base de dados enviada por correio eletrónico para deteção de erros é uma transmissão. Precisamente estas ocasiões decorrem muitas vezes sem base, porque não são vistas como um projeto.

Se num caso concreto existe subcontratação ou outra configuração, quem avalia é o seu encarregado da proteção de dados. O importante é fazer a pergunta, antes de os acessos serem atribuídos.

## O que o Art. 28 RGPD exige no contrato

O Art. 28, n.º 3, do RGPD indica conteúdos obrigatórios. Além do objeto, da duração, da natureza e da finalidade do tratamento, dos tipos de dados e das categorias de titulares, o subcontratante tem de se comprometer, entre outras coisas, com os seguintes pontos. A coluna da direita mostra o que isso significa na prática em acessos ao servidor.

| Obrigação segundo o Art. 28, n.º 3 | Significado prático no acesso ao servidor |
|---|---|
| a) Tratamento apenas mediante instrução documentada | Encomenda por escrito, por exemplo por ticket: o que exatamente deve ser feito |
| b) Confidencialidade das pessoas envolvidas | apenas pessoas comprometidas e conhecidas por nome recebem acesso |
| c) Medidas nos termos do Art. 32 | contas pessoais, autenticação de dois fatores, ligações cifradas |
| d) Condições para outros subcontratantes | parceiros forenses ou de alojamento apenas com autorização |
| e) Apoio nos direitos dos titulares | colaboração quando o acesso ou o apagamento afeta o servidor |
| f) Apoio nos Art. 32 a 36 | participação na segurança, na notificação e na avaliação de impacto |
| g) Apagamento ou devolução após a conclusão | cópias, imagens e exportações são apagadas ou devolvidas |
| h) Comprovativos e verificações | registos dos acessos, informação sobre as medidas |

Além disso, o Art. 33, n.º 2, do RGPD exige que o subcontratante notifique de imediato o responsável pelo tratamento de uma violação de dados de que tome conhecimento. Num prestador que acabou de investigar um servidor comprometido, isso não é uma formalidade: é muitas vezes o primeiro a ver indícios de uma fuga de dados. O prazo e o restante processo da notificação à autoridade de controlo são explicados em [Dever de notificação segundo o RGPD: 72 horas após o incidente](https://phpsos.de/pt/compliance/dsgvo-meldepflicht-72-stunden/).

## Organizar os acessos em conformidade com a proteção de dados

Um AVV assinado é a base. Se as promessas são cumpridas decide-se na prática quotidiana. Estes passos provaram ser úteis:

1. **Acessos próprios e pessoais** para cada pessoa do prestador, nunca contas de administração partilhadas. Como os proteger está em [Configurar a autenticação de dois fatores para acessos de administração](https://phpsos.de/pt/ratgeber/zwei-faktor-admin/).
2. **Limitar no tempo:** desativar os acessos de uma intervenção após a conclusão, rever regularmente as contas permanentes.
3. **Registar:** gravar os inícios de sessão e os comandos das contas do prestador, para que se possa saber quem fez o quê.
4. **Trabalhar com minimização de dados:** copiar para análises apenas os dados necessários, guardar as cópias cifradas, registar o local de armazenamento e a data de eliminação.
5. **Documentar a conclusão:** acessos retirados, cópias apagadas ou entregues, confirmação por escrito.

> **Importante:**
> Uma investigação forense gera muitas vezes imagens completas de servidores, incluindo todos os dados de clientes. Regule de antemão onde estão essas imagens, quem lhes acede e quando são apagadas, sem pôr em risco a preservação de provas.

## Celebrar o AVV antes da emergência

O melhor momento para o AVV é um dia calmo. Identifique os prestadores que devem atuar em caso de emergência, ou seja, o fornecedor de alojamento, a agência e, se for caso disso, uma equipa de tratamento de incidentes e perícia forense, e celebre os contratos com eles antecipadamente. Registe também que outros parceiros o prestador pode empregar.

Guarde os contratos assinados onde está o plano de emergência e anote na lista de contactos com quem existe um AVV. As restantes obrigações de segurança, por exemplo prazos de atualização e comprovativos, pertencem ao contrato de prestação de serviços; mais sobre isto em [Contratos com prestadores de serviços de TI: regular com clareza as obrigações de segurança](https://phpsos.de/pt/blog/dienstleistervertrag-sicherheit/). Para todas as questões jurídicas, o seu encarregado da proteção de dados e um advogado são os interlocutores certos.

## Como ajuda concretamente a PHP SOS?

- Esclarecemos antes do primeiro acesso que dados existem nos sistemas afetados e acordamos o enquadramento com o seu encarregado da proteção de dados.
- Trabalhamos com acessos pessoais e registados e documentamos cada intervenção de forma rastreável.
- Identificamos os parceiros especializados que envolveríamos, por exemplo, para [perícia forense informática](https://phpsos.de/pt/leistungen/it-forensik/), para que possa decidir antecipadamente.
- Após a conclusão de uma [resposta a incidentes](https://phpsos.de/pt/leistungen/incident-response/), confirmamos por escrito a retirada dos acessos e a eliminação ou entrega de todas as cópias.

**Conclusão:** A proteção de dados e a ajuda rápida não se excluem quando a base está definida de antemão. Um AVV com os prestadores para o caso grave faz parte de toda a prevenção de emergências. Esta página é informação geral e não constitui aconselhamento jurídico.


## Perguntas frequentes

**Toda a manutenção remota é uma subcontratação?**  
Não automaticamente. O decisivo é se o prestador trata dados pessoais por conta de outrem ou lhes pode aceder. Em servidores web com contas de clientes, encomendas ou formulários, isso acontece quase sempre. O enquadramento em cada caso é feito pelo seu encarregado da proteção de dados.

**Posso celebrar um AVV ainda durante um incidente?**  
É possível, mas sob pressão de tempo falta muitas vezes a calma para uma verificação. É melhor celebrar o AVV antecipadamente com os prestadores que devem atuar em caso de emergência. Assim, o trabalho pode começar de imediato.

**O prestador tem de me informar se detetar uma violação de dados?**  
Sim. Nos termos do Art. 33, n.º 2, do RGPD, o subcontratante notifica o responsável pelo tratamento, sem demora injustificada, de uma violação de dados pessoais, logo que dela tenha conhecimento. A notificação à autoridade de controlo continua a ser da responsabilidade do responsável pelo tratamento.

**O prestador pode recorrer a outros parceiros, por exemplo para perícia forense?**  
Nos termos do Art. 28, n.º 2, do RGPD, apenas com autorização escrita prévia do responsável pelo tratamento, que pode ser específica ou geral. Em caso de autorização geral, o prestador tem de informar sobre alterações, para que possa opor-se.

## Fontes

- [RGPD Art. 28: subcontratante](https://dsgvo-gesetz.de/art-28-dsgvo/)
- [RGPD Art. 33](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)