Quem busca segurança da informação na prefeitura costuma querer uma coisa concreta: uma política de segurança da informação, a PSI, para aprovar por decreto. É um bom começo, mas a PSI sozinha é um papel. O que protege o município é a política ligada a um inventário do que precisa ser protegido, a uma classificação dos riscos e a um responsável que acompanhe tudo isso ao longo do tempo.
Este artigo percorre essa cadeia: política, risco, serviço crítico e rotina.
A política ainda falta na maior parte das prefeituras
O Estudo Tecnologia, da Ana Smart Solutions (setembro de 2026), cruzou as respostas dos 644 municípios paulistas ao i-Gov TI, exercício 2024:
- 55,1% (355 de 644) não têm política de segurança da informação.
- 65,5% não designaram encarregado de dados pessoais.
- 78,6% não regulamentaram a Lei de Governo Digital.
Entre os 289 municípios que declaram ter política, as respostas aos quesitos seguintes indicam quanto dela chega à prática, sempre como declaração do município:
| Quesito do i-Gov TI | Declaram que sim |
|---|---|
| Política de backup formalmente obrigatória | 244 de 289 (84,4%) |
| Inventário atualizado de ativos de TIC | 237 de 289 (82,0%) |
| Identificam riscos de TIC segundo a família ISO/IEC 27000 | 135 de 289 (46,7%) |
| Plano de continuidade de serviços de TIC | 135 de 289 (46,7%) |
São respostas autodeclaradas. Dizer que existe política de backup não prova que alguma cópia foi restaurada em teste, e a base do estudo mede declaração, e não funcionamento.
O que uma política enxuta costuma cobrir
Não existe modelo único, e o texto deve partir da realidade do município. Como ponto de partida, uma política enxuta costuma tratar de:
- Escopo e responsáveis: a quem se aplica, e quem responde por ela.
- Controle de acesso: quem acessa o quê, com que perfil, e como se retira o acesso de quem sai.
- Backup e restauração: o que se copia, onde fica a cópia, e com que frequência a restauração é testada.
- Continuidade: o que fazer quando um serviço crítico para.
- Incidentes: como se registra, a quem se comunica e quem decide.
- Dados pessoais: ligação com o encarregado e com a LGPD.
- Revisão: quando o texto e os riscos são reavaliados.
O Decreto 10.540/2020, que trata do SIAFIC, atribui ao Poder Executivo a definição das políticas de acesso e de segurança da informação aplicáveis aos Poderes e órgãos do ente. Para o município, a política de segurança deixa de ser tema só de TI, já que o sistema contábil serve a todos.
Do risco ao serviço crítico
Uma política só funciona sobre uma lista do que importa. O primeiro passo é um inventário mínimo, que cabe em uma tabela.
| Serviço crítico / Processo crítico | Sistema que o sustenta | Fornecedor e contrato | Vencimento | Responsável interno | Backup testado | Plano de contingência |
|---|---|---|---|---|---|---|
| Arrecadação | ||||||
| Folha | ||||||
| Saúde | ||||||
| Educação | ||||||
| Atendimento ao cidadão |
Preencher essa tabela já é um diagnóstico: as células vazias mostram onde a prefeitura depende de algo que não conhece.
O segundo passo é classificar o risco de cada linha: qual o impacto se o serviço ou o processo parar, qual a probabilidade, e qual o tempo máximo aceitável de interrupção. Uma matriz de riscos referenciada à ISO 27005 e à ISO 31000, com mapa de calor, organiza essa classificação.
As duas normas têm papéis diferentes. A ISO 27005 trata do risco de segurança da informação. A ISO 31000 é mais ampla: vale para toda a organização, e não apenas para a segurança da informação. Por isso o DIRECITY GOV usa a ISO 31000 como base para estruturar todo o Plano Estratégico Diretor de Tecnologia e Cidade, com a ISO 27005 como referência específica para os riscos de informação. O risco de um serviço ou processo crítico parar é tratado com a mesma lógica do risco de qualquer outra frente do plano.
O terceiro passo é transformar o resultado em ações do plano, com dono e prazo: política de segurança, plano de continuidade, designação do encarregado, teste de backup, calendário de vencimentos.
Seis perguntas de autodiagnóstico
Todo prefeito, secretário ou controlador interno pode fazer estas perguntas hoje:
- Quais sistemas sustentam os serviços e processos críticos, e quem responde por cada um?
- Quando vence cada contrato de tecnologia, e o que acontece no dia seguinte?
- Existe política de segurança da informação aprovada e conhecida?
- O último backup foi restaurado em teste?
- Quem é o encarregado de dados pessoais e o que ele já entregou?
- O PDTI vigente está publicado, datado e em execução?
Se três ou mais respostas forem "não sei", a dependência é invisível.
A política e o plano
Um PDTI vivo é o lugar onde política, sistemas, contratos, riscos e responsáveis se encontram. O DIRECITY GOV conduz a elaboração do plano a partir de fontes oficiais, com validação dos envolvidos. Acompanhamento de prazos, riscos e evidências deve ser descrito conforme as funcionalidades documentadas para a versão atual do produto, sem pressupor alertas ou atualizações automáticas não confirmadas.
O risco continua existindo, mas deixa de chegar de surpresa.
O artigo sobre o quanto a cidade depende de tecnologia mostra o tamanho da dependência que essa política precisa proteger.
Perguntas frequentes
O que uma prefeitura precisa para começar a política de segurança da informação?
De um responsável, de um inventário dos sistemas que sustentam os serviços críticos e de uma política enxuta aprovada por ato formal. O texto pode ser curto, desde que tenha dono e revisão.
Qual a diferença entre a ISO 27005 e a ISO 31000?
A ISO 27005 trata do risco de segurança da informação. A ISO 31000 trata da gestão de riscos de toda a organização, e serve de base para estruturar o plano inteiro.
Ter política de backup basta?
Não. A política diz o que deve ser feito. É o teste de restauração que mostra se a cópia funciona.
Fontes
- Estudo Tecnologia, Ana Smart Solutions, setembro de 2026, com base nas respostas ao i-Gov TI, exercício 2024, exportação oficial do TCE SP.
- Correlação entre quesitos i-Gov TI, normas ISO e responsabilidades do SIAFIC, Ana Smart Solutions, setembro de 2026.
- Decreto 10.540/2020, SIAFIC.