Uma política de segurança da informação estabelece o que a organização protege, quem decide e quais as regras que devem orientar os sistemas e as pessoas. O resultado útil é um documento aprovado, ligado a procedimentos executáveis e a evidências de aplicação. Uma lista de boas intenções não explica quem remove uma conta, autoriza uma exceção ou decide como continuar a trabalhar quando uma aplicação fica indisponível.
Este guia apresenta uma estrutura e um exemplo preenchido para preparar a política da empresa. A sequência começa no âmbito e nos riscos, passa pelas responsabilidades e termina na verificação. Os exemplos são hipotéticos e devem ser adaptados aos serviços, dados e dependências reais da organização.
Distinguir política, procedimento e configuração
A política define a regra: os acessos devem corresponder às funções e ser retirados quando deixam de ser necessários. O procedimento descreve como uma chefia pede um acesso, quem o aprova e quem o executa. A configuração aplica essa decisão numa ferramenta concreta. Os três níveis devem ser coerentes, mas não precisam de ficar no mesmo documento.
Esta separação evita que a política fique desatualizada cada vez que muda um ecrã de administração. Também permite demonstrar uma falha precisa: a regra pode estar correta, mas o processo de saída não chegar ao administrador da aplicação. A cartografia dos sistemas de informação ajuda a identificar todas as aplicações a que a regra tem de chegar.
O artigo 32.º do RGPD exige medidas técnicas e organizativas adequadas ao risco, incluindo aspetos de confidencialidade, integridade, disponibilidade, recuperação e avaliação da eficácia. Não fixa um título obrigatório nem um número universal de páginas para esta política. RGPD, artigos 24.º e 32.º.
Usar referenciais com o seu âmbito correto
O Quadro Nacional de Referência para a Cibersegurança do CNCS apresenta recomendações organizadas em identificação, proteção, deteção, resposta e recuperação. Pode ajudar a organizar a política e a verificar domínios esquecidos. A sua utilização como referência não dispensa a análise dos deveres legais e setoriais que incidam sobre a entidade. CNCS: Quadro Nacional de Referência para a Cibersegurança.
Quando a verificação prevista inclui simular um ataque, formalize o âmbito e as regras do teste de intrusão: sistemas autorizados, condições de paragem e responsável por aceitar as correções.
Uma empresa pode também aproveitar métodos de autoridades de outros países, desde que identifique a sua origem e não transforme recomendações estrangeiras em obrigações portuguesas. Por exemplo, a CNIL descreve a importância de explicar regras aos utilizadores e formar quem concebe ou mantém ferramentas. Trata-se de orientação da autoridade francesa, útil como referência prática. CNIL: envolver e formar os utilizadores.
Primeiro passo: delimitar o que a política abrange
Indique entidades, instalações, trabalhadores, prestadores e sistemas abrangidos. Inclua serviços contratados e trabalho à distância quando existam. Evite escrever apenas “todos os sistemas”: a equipa deve conseguir relacionar o âmbito com uma lista atual de aplicações e responsáveis.
Num exemplo hipotético, uma empresa de serviços inclui o correio eletrónico, a gestão de clientes, a faturação, os computadores portáteis e o arquivo em papel. A aplicação de um parceiro, utilizada por três colaboradores, é identificada como dependência externa. O seu proprietário continua responsável por conhecer as condições de acesso e por coordenar alterações com o fornecedor.
Classifique a informação de forma utilizável. Uma escala simples pode distinguir informação pública, interna e restrita, com exemplos de tratamento para cada classe. Uma ficha de cliente não deve tornar-se pública por ter sido enviada a um fornecedor. A classificação determina medidas e destinatários; não altera, por si, a natureza pessoal dos dados.
Segundo passo: identificar riscos e medidas existentes
Escolha cenários que afetem os objetivos da organização e os direitos das pessoas. Uma conta comprometida pode permitir acesso a documentos de clientes; um portátil perdido pode expor ficheiros locais; uma falha do fornecedor pode impedir o pagamento de salários. Para cada cenário, descreva a consequência, a proteção existente e a lacuna observada.
Não confunda ausência de evidência com ausência de risco. Se a equipa afirma que existem cópias de segurança, peça a identificação do serviço abrangido e o resultado de uma recuperação. Se diz que todas as contas têm autenticação reforçada, confirme as exceções e as contas técnicas. O modelo de medidas técnicas e organizativas permite registar essas diferenças.
A prioridade depende da gravidade, probabilidade, exposição e capacidade de resposta. Uma medida barata e rápida pode ser prioritária quando elimina um acesso indevido já identificado. Um projeto complexo pode exigir fases, mas a política deve indicar como o risco será limitado durante a implementação.
Terceiro passo: atribuir decisões e execução
Separe quem aprova a política, quem coordena a segurança e quem executa cada regra. O encarregado de proteção de dados aconselha e controla a conformidade dentro das suas funções; a responsabilidade pelas decisões da organização não deve ser transferida para ele. O dossiê de responsabilidade no RGPD ajuda a conservar o rasto das decisões.
| Decisão ou tarefa | Responsável no exemplo | Evidência esperada |
|---|---|---|
| Aprovar âmbito e meios | Direção | Versão aprovada e recursos atribuídos |
| Definir regras de acesso | Responsável de TI e donos das aplicações | Matriz de perfis e circuito de aprovação |
| Acompanhar riscos para titulares | EPD, na sua função consultiva | Parecer e resposta à recomendação |
| Executar entradas e saídas | RH e administrador da aplicação | Pedido, aprovação e confirmação de execução |
| Aceitar uma exceção temporária | Dono do risco com aprovação prevista | Motivo, medida compensatória e data de revisão |
A mesma pessoa pode desempenhar várias tarefas numa equipa pequena. Isso não elimina a necessidade de distinguir decisões nem de verificar conflitos de funções. Quando não existe substituto interno, defina como a organização obtém apoio em férias ou indisponibilidade.
Quarto passo: escrever regras verificáveis
Uma regra de acesso pode dizer: “Cada utilizador recebe uma conta individual e apenas os perfis aprovados para a sua função; os acessos são revistos quando muda de funções e retirados no fim da necessidade.” A frase identifica o comportamento esperado. O procedimento associado fixa os contactos, a ferramenta e a prova de execução.
A política de palavras-passe e autenticação desenvolve a gestão de credenciais, a autenticação multifator e a recuperação de contas. A política de logs de segurança explica quais os eventos necessários, quem os consulta e como são tratados os alertas. A política geral remete para estes documentos sem repetir configurações que mudam frequentemente.
Para informação restrita, especifique canais de partilha autorizados e condições de acesso. A cifragem de dados pessoais exige também decisões sobre chaves, recuperação e quem pode ver o conteúdo. Não basta escrever “todos os dados são cifrados” quando há exportações em folhas de cálculo fora da aplicação protegida.
Exemplo preenchido: partilha de documentos com um cliente
A empresa do exemplo identifica que os colaboradores enviam documentos restritos por ligações abertas. A regra aprovada passa a exigir destinatários autenticados, acesso limitado à tarefa e remoção da partilha quando termina a necessidade. O dono do processo mantém a lista de serviços autorizados e uma alternativa para destinatários que não conseguem usar o canal habitual.
A implementação inclui uma alteração à configuração, uma instrução curta para os utilizadores e a revisão das ligações existentes. A aceitação é feita com duas contas de ensaio: o destinatário autorizado consegue abrir o documento e uma conta externa não autorizada não consegue. Também se testa uma ligação depois de revogada.
A decisão fica registada assim: “Partilhas abertas de documentos restritos desativadas; exceções apenas por aprovação do responsável do processo, com destinatário identificado e prazo definido. Revisão das ligações antigas atribuída ao administrador. Resultado do ensaio guardado no registo de implementação.” O exemplo mostra uma decisão completa, sem pressupor funcionalidades de um produto específico.
Quinto passo: ligar incidentes e continuidade
A política deve indicar como comunicar uma suspeita, quem recebe o alerta e quem decide a resposta. Um utilizador não tem de qualificar juridicamente uma violação antes de pedir ajuda. Deve saber a quem comunicar um envio incorreto, um acesso inesperado ou a perda de um equipamento.
O plano de continuidade de atividade define os serviços prioritários e o funcionamento mínimo durante uma interrupção. A política de segurança deve assegurar que os procedimentos de emergência também respeitam limites de acesso e confidencialidade. Criar uma cópia informal de toda a base de clientes para “continuar a trabalhar” pode introduzir um novo problema.
O processo de resposta deve distinguir contenção, investigação e avaliação das obrigações de notificação. O procedimento de violação de dados existente deve ser ligado à política, com contactos e substitutos atualizados. Uma crise não é o momento adequado para descobrir que a caixa de correio de emergência pertence a alguém que saiu da empresa.
Sexto passo: aprovar, explicar e acompanhar
Apresente à direção o texto, os riscos ainda abertos, as medidas por executar e os recursos necessários. Uma aprovação sem meios pode deixar exigências impossíveis de cumprir. Registe separadamente o que já funciona e o que ainda é um compromisso com data e responsável.
A política de utilização dos recursos informáticos traduz as regras que afetam diretamente os utilizadores: partilha, instalação de aplicações, proteção de equipamentos e comunicação de incidentes. A formação deve usar exemplos reais da atividade, com instruções para agir. Pedir uma assinatura demonstra receção, mas não prova que a configuração foi aplicada ou que a pessoa consegue seguir o procedimento.
Sétimo passo: verificar e rever
Escolha evidências observáveis: uma saída de trabalhador concluída em todas as aplicações, uma recuperação de ficheiro, um alerta analisado e uma exceção reavaliada. A revisão deve procurar diferenças entre a política e a prática, atribuindo a cada diferença uma decisão concreta.
Defina eventos de revisão, como uma nova aplicação, uma alteração de fornecedor, um incidente ou uma mudança de atividade. Um calendário periódico pode complementar esses eventos, sem os substituir. Na versão seguinte, registe o que mudou, porquê e quais os procedimentos afetados, para que a organização consiga aplicar a decisão em vez de apenas arquivar mais um documento.