Uma Política de Segurança da Informação (PSI) é o documento que define regras, responsabilidades e controles mínimos para proteger dados e sistemas (ex.: MFA, backups, patching, resposta a incidentes). Ela só funciona quando vira processo aplicável, com exceções controladas, auditoria e revisão periódica — não um PDF “pra inglês ver”.

O que é uma PSI e por que sua empresa precisa de uma (agora)?

PSI é o “contrato operacional” de segurança entre diretoria, TI e usuários: o que pode, o que não pode, quem aprova, como medir e o que fazer quando der ruim.

Sem PSI, o que acontece é previsível:

  • cada área decide “no feeling” (ex.: liberar acesso, USB, app, compartilhamento)

  • o service desk vira porta de entrada (“reseta minha senha aí rapidinho”)

  • incidentes viram improviso (tempo perdido = impacto maior)

Exemplo real do mundo: ataques como o da MGM (2023) foram associados à engenharia social no service desk (vishing), o que reforça a importância de política + procedimento forte de validação de identidade e reset de senha.

PSI é só compliance? O que muda quando a PSI é “de verdade”?

Uma PSI “de verdade” tem 3 características:

  1. É específica (regras claras, sem texto genérico demais)

  2. É executável (tem dono, fluxo de exceção, checklists e métricas)

  3. É auditável (logs, evidências e periodicidade de revisão)

O NIST reforça que resposta a incidentes e melhoria contínua precisa ser integrada à operação — e a PSI é a base para isso (principalmente quando conecta regras a playbooks).

O que uma Política de Segurança da Informação precisa ter (checklist mínimo)

Se a sua PSI não cobre estes blocos, ela vai falhar no primeiro incidente sério:

  • Escopo e objetivos

  • Papéis e responsabilidades (RACI)

  • Gestão de identidade e acesso (MFA, privilégios mínimos, contas admin separadas)

  • Uso aceitável (e-mail, internet, software, USB, home office/BYOD)

  • Proteção de endpoints (EPP/EDR, atualizações, hardening)

  • Gestão de vulnerabilidades e patches (SLA por criticidade)

  • Backup e continuidade (inclui teste de restauração)

  • Logs e monitoramento (o que logar e por quanto tempo)

  • Resposta a incidentes (fluxo e acionamento)

  • Terceiros/fornecedores (acesso, cláusulas e rastreabilidade)

  • Conscientização (awareness)

  • Exceções + sanções + revisão periódica

Dica de campo: se não existe processo de exceção, o usuário “cria exceção na prática” — e a política morre.

Exemplo de Política de Segurança da Informação (modelo prático) — para copiar e adaptar

Abaixo vai um exemplo enxuto e aplicável. Ele é inspirado em estruturas clássicas de governança e também no modelo público de PSI do Gov.br, que é uma boa referência para organização de seções.

1) Objetivo

Estabelecer diretrizes para proteger a confidencialidade, integridade e disponibilidade das informações da [EMPRESA], reduzir riscos de incidentes (phishing, ransomware, vazamentos) e padronizar processos de segurança.

2) Escopo

Aplica-se a: colaboradores, terceiros e parceiros; estações/notebooks/servidores; rede; nuvem; e-mail; sistemas; dados (incluindo pessoais conforme LGPD, quando aplicável).

3) Papéis e responsabilidades (RACI)

  • Diretoria: aprova a PSI e patrocina prioridade/recursos

  • TI/Sec: implementa controles, monitora, responde incidentes

  • Gestores: aprovam acessos e garantem adesão do time

  • Usuários: cumprem regras e reportam suspeitas

4) Identidade e acesso

  • MFA obrigatório para e-mail, VPN, painéis administrativos e contas privilegiadas

  • Contas administrativas separadas das contas de uso diário

  • Privilégio mínimo por função (RBAC)

  • Reset de senha com validação forte (processo formal do service desk)

Por que isso importa (experiência real): ataques com engenharia social ao service desk mostram que “reset fácil” vira porta de entrada.

5) Uso aceitável e dispositivos

  • Proibido instalar software sem aprovação

  • USB controlado (padrão bloqueado; exceção com justificativa e prazo)

  • Home office/BYOD: requisitos mínimos (senha forte, tela bloqueada, atualização ativa)

6) Endpoints e hardening

  • Endpoint deve ter EPP/EDR gerenciado centralmente

  • Atualizações de segurança obrigatórias conforme SLA

  • Proibido desativar proteção sem exceção formal

7) Vulnerabilidades e patches (SLA sugerido)

  • Crítico: 72h–7 dias | Alto: 7–14 dias | Médio: 30 dias | Baixo: 60–90 dias

  • Prioridade máxima: serviços expostos à internet

8) Backup e continuidade

  • Estratégia de backup definida por criticidade

  • Backups offline/imutáveis para dados críticos

  • Teste de restauração mensal/trimestral com evidência

A CISA recomenda manter backups offline/criptografados e testar regularmente integridade/disponibilidade.

9) Logs e monitoramento

  • Logs de autenticação e eventos críticos retidos por [X] dias

  • Alertas classificados por severidade (S1–S4) e com SLA de triagem

10) Resposta a incidentes (fluxo mínimo)

  • Canal oficial de reporte: [Teams/ITSM/E-mail]

  • Procedimento de 60 minutos: isolar, bloquear credenciais, preservar evidências, avaliar escopo

  • Pós-incidente: lições aprendidas + backlog de correção

O NIST define o ciclo de resposta e enfatiza melhoria contínua.

11) Terceiros e fornecedores

  • Acesso temporário e rastreável (MFA)

  • Cláusulas de segurança e confidencialidade em contrato

  • Revisão periódica de acessos

12) Exceções, sanções e revisão

  • Exceções com justificativa, prazo e controles compensatórios

  • Revisão da PSI a cada [6/12] meses ou após incidentes relevantes

Como adaptar esse exemplo para a realidade da sua empresa (passo a passo)

  1. Defina escopo (quais unidades/sistemas/dados)

  2. Escolha 10 controles mínimos que serão “sem exceção” (ex.: MFA admin/remoto; backup testado)

  3. Crie o fluxo de exceção (quem aprova, prazo, compensação, evidência)

  4. Amarre com processos (onboarding/offboarding, reset de senha, mudanças, incidentes)

  5. Colete métricas (MFA coverage, patch compliance, restore success)

  6. Treine e faça ciência (assinatura/aceite)

  7. Audite e revise (cadência fixa)

Erros comuns (que deixam a PSI inútil)

  • PSI genérica demais (“copiei da internet e colei”)

  • Não ter processo de exceção

  • Não ter métricas (você não sabe se funciona)

  • Não treinar o service desk (reset de senha vira backdoor)

  • Backups sem teste (descobrir que não restaura… no dia do ransomware)

FAQ — Política de segurança da informação exemplo

1) Onde encontro um modelo confiável de política de segurança da informação?
O modelo público do Gov.br é uma boa referência estrutural para começar e adaptar ao contexto da empresa.

2) PSI precisa falar de ransomware?
Sim, pelo menos nos capítulos de backup/continuidade, resposta a incidentes, acessos e monitoramento. A CISA recomenda backups offline e testes regulares como base de resiliência.

3) Qual a diferença entre PSI e procedimento?
PSI é a regra/diretriz (“o que vale”). Procedimento é o “como fazer” (ex.: reset de senha, restore de backup, resposta a phishing).

4) Com que frequência revisar a PSI?
No mínimo anual; idealmente também após mudanças relevantes e incidentes. O NIST reforça a importância de lições aprendidas e melhoria contínua.

5) PSI ajuda na LGPD?
Ajuda muito porque define acesso, auditoria, retenção/descarte e resposta a incidentes — que são partes críticas da proteção operacional.

6) O que é “exceção” e como não virar bagunça?
Exceção deve ter justificativa, prazo, responsável e controles compensatórios. Se não existir processo, a exceção acontece “por fora” e você perde governança.