# Contratos com prestadores de serviços de TI: regular com clareza as obrigações de segurança

> O que um contrato com agência, alojamento ou prestador de TI deve regular sobre segurança: atualizações, reinício, avisos, registos, acessos e saída.

Fonte: https://phpsos.de/pt/blog/dienstleistervertrag-sicherheit/  
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:** Um contrato com um prestador de TI não deve mencionar a segurança apenas de passagem, mas regulá-la de forma concreta: quem atualiza que componentes, em que prazo e com que comprovativo, como se informa sobre falhas críticas, quem colabora num incidente, como os registos são conservados e os acessos geridos e o que acontece na saída. Esta página dá indicações gerais e não constitui aconselhamento jurídico; os contratos são verificados por um advogado.

## A pergunta que o PHP2Shell colocou: quem é responsável?

Em 21 de outubro de 2026, às 16 h, hora alemã, o projeto PHP publicou os patches. O BSI (Gabinete Federal Alemão para a Segurança da Informação) recomendou a atualização imediata ou, onde isso não fosse possível, retirar temporariamente os servidores web da rede. Em muitas empresas começou depois não o trabalho, mas a procura da responsabilidade. A agência remeteu para o fornecedor de alojamento, o fornecedor de alojamento para o contrato, e no contrato dizia “manutenção por tempo despendido”.

Estas lacunas contratuais não são um caso isolado. Muitos contratos com agências e prestadores foram celebrados quando se tratava de construir um site, não da sua operação segura ao longo de anos. Uma falha crítica no runtime do PHP, que não afeta nem o CMS nem o código da aplicação, cai então facilmente entre todas as cadeiras.

## O que um contrato com prestador de TI deve regular sobre segurança

A visão geral seguinte indica os pontos que se revelaram importantes na prática. Não substitui uma verificação jurídica, mas ajuda a reconhecer lacunas no contrato existente.

| Ponto de regulação | O que deve ficar registado | Relação com o PHP2Shell |
|---|---|---|
| Âmbito da prestação | Que camadas são tratadas: sistema operativo, runtime PHP, servidor web, CMS, plugins, código próprio | O runtime PHP faltava muitas vezes na enumeração |
| Prazos de atualização | escalonados por gravidade, com regra de exceção para emergências | falha crítica com CVSS v4.0 9,2 |
| Reinício e comprovativo | as atualizações só se consideram concluídas após o reinício de todos os processos, com prova escrita | ficheiros novos, por si só, não fecham a falha |
| Informação | notificação ativa em caso de falhas críticas, com avaliação e plano | muitos clientes tiveram de perguntar por si |
| Colaboração em incidentes | apoio na análise, preservação, recuperação, interlocutor | busca de vestígios após o patch |
| Registos | tipo, conservação, entrega a pedido | a imprensa especializada aconselhou a guardar registos a partir de 20/10 |
| Acessos | contas pessoais, autenticação de dois fatores, lista de todos os acessos | quem tinha, afinal, acesso? |
| Subcontratantes | quem mais está envolvido, informação em caso de mudança | o fornecedor do fornecedor de alojamento |
| Fim de vida do software | aviso com antecedência antes do fim do suporte, plano de migração | o PHP 8.2 termina a 31 de dezembro de 2026 |
| Saída | entrega de dados, documentação e acessos, retirada de direitos | mudança após um incidente |

## Prazos e comprovativos: os pontos que mais contam

Os prazos são o cerne. Uma formulação como “em tempo útil” não ajuda em caso grave. Acorde prazos separados por gravidade e defina por que critério a gravidade é medida, por exemplo a classificação do fabricante ou do BSI. Para situações excecionais deve valer uma regra de emergência: quem está contactável, quem decide se um sistema é temporariamente retirado da rede e como é faturado o esforço adicional.

Igualmente importante é o comprovativo. No PHP2Shell, o número de versão apresentado dizia muitas vezes pouco, porque as distribuições e os fornecedores de alojamento aplicam correções como backport. Uma prova fiável indica o estado do pacote, o momento da instalação e o reinício de todos os processos PHP. Que indicações contam exatamente é descrito em [Confirmação da atualização PHP do alojamento: como perguntar pelo estado do patch](https://phpsos.de/pt/ratgeber/hoster-patch-status-erfragen/). Inclua estas indicações como conteúdo obrigatório no contrato.

> **Dica:**
> Peça ao prestador uma matriz de tarefas para o contrato: uma linha por componente, uma coluna por tarefa, um nome em cada célula. As lacunas saltam logo à vista, muito antes do próximo aviso.

## Acessos, subcontratantes e saída

Os prestadores precisam de acessos, e são precisamente estes um caminho de ataque frequente. Regule que cada pessoa recebe uma conta própria, que a autenticação de dois fatores é obrigatória onde a técnica o permita e que pode, a qualquer momento, pedir uma lista atualizada de todos os acessos. Os colaboradores do prestador que saiam têm de ser removidos de todos os sistemas em tempo útil.

Se o próprio prestador trabalhar com parceiros, por exemplo um centro de dados ou uma equipa forense especializada, deve saber-se. Se um desses parceiros tratar dados pessoais, acrescem obrigações de proteção de dados. Mais sobre isto no artigo [Subcontratação de dados quando prestadores acedem a servidores](https://phpsos.de/pt/blog/auftragsverarbeitung-serverzugriff/).

A saída é o que mais se esquece na celebração do contrato. Registe que, no fim do contrato, dados, configuração, documentação e credenciais são entregues por completo, todos os acessos do prestador são retirados e isso é confirmado por escrito. Sobretudo após um incidente, uma mudança ordenada é de outro modo difícil.

## Verificar contratos existentes: como proceder

Não tem de renegociar todos os contratos. Um procedimento pragmático chega para começar:

1. Reunir todos os contratos com agências, fornecedores de alojamento e prestadores de TI que digam respeito a sites ou servidores.
2. Comparar cada contrato com a tabela acima e assinalar os pontos em aberto.
3. Abordar por escrito junto do prestador as lacunas mais importantes, começando pelo âmbito da prestação, os prazos e o comprovativo.
4. Registar os resultados como acordo complementar e mandá-los verificar juridicamente.
5. Integrar a matriz de tarefas no plano de emergência.

Para a administração, este passo é também uma questão de diligência. Quem regula claramente as responsabilidades e documenta as decisões está em melhor posição se mais tarde forem feitas perguntas. Antecedentes sobre isto em [Responsabilidade da gerência por vulnerabilidades de segurança informática](https://phpsos.de/pt/compliance/geschaeftsfuehrer-haftung/). A divisão típica de tarefas em servidores com assistência é descrita em [Servidor gerido: esclarecer a responsabilidade](https://phpsos.de/pt/server/managed-server/).

## Como ajuda concretamente a PHP SOS?

- Lemos os seus contratos e descrições de serviços existentes do ponto de vista técnico e assinalamos que componentes e tarefas faltam.
- Elaboramos uma matriz de tarefas para todos os sites e servidores, que pode acordar com os seus prestadores.
- Formulamos os requisitos técnicos de prazos, comprovativos e vias de comunicação, que o seu advogado pode incorporar no contrato.
- Onde ninguém é responsável, assumimos nós as tarefas através de um [contrato de manutenção de segurança](https://phpsos.de/pt/leistungen/security-wartungsvertrag/) com âmbito claramente descrito.

**Conclusão:** Um bom contrato não evita uma falha de segurança, mas evita que, em caso grave, se perca tempo com a pergunta sobre a responsabilidade. Esta página é informação geral e não constitui aconselhamento jurídico.


## Perguntas frequentes

**Um prestador de TI tem de aplicar atualizações de segurança sem encomenda?**  
Depende do contrato. Sem regulação clara, é muitas vezes controverso se as atualizações fazem parte da prestação devida. Por isso, o contrato deve registar expressamente quem atualiza que componentes e em que prazo. Para a avaliação jurídica em cada caso é competente um advogado.

**Preciso, além disso, de um contrato de subcontratação (AVV)?**  
Se o prestador tratar dados pessoais por conta de outrem ou lhes puder aceder, é em regra necessário um contrato de subcontratação nos termos do Art. 28 do RGPD. Não substitui o contrato de prestação de serviços, complementa-o. Esclareça-o com o seu encarregado da proteção de dados.

**Que prazos para atualizações de segurança são habituais?**  
Não há valores fixos. Faz sentido um escalonamento por gravidade, por exemplo prazos separados para falhas críticas, graves e restantes. É importante que os prazos estejam por escrito e incluam uma regra de exceção para emergências como o PHP2Shell.

**O que acontece aos acessos quando o contrato termina?**  
O contrato deve regulá-lo: devolução ou eliminação de dados, entrega de credenciais e documentação, retirada de todos os acessos do prestador e uma confirmação disso.

## Fontes

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI](https://www.bsi.bund.de/)
- [php.net: versões suportadas](https://www.php.net/supported-versions.php)