Gestão de Riscos: Como estruturar uma Política de Segurança da Informação de maneira coerente ao porte da sua empresa; a Política Principal de Segurança da Informação pode ser feita juntamente com as políticas secundárias (ou chamadas normas)? Justifique.

Para estruturar uma Política de Segurança da Informação (PSI) coerente com o porte da empresa, o caminho mais consistente é montar uma arquitetura em camadas, garantindo que o documento “principal” seja curto, estável e orientado a diretrizes, e que os detalhes operacionais fiquem em documentos complementares (normas/padrões/procedimentos). Sim, a Política Principal pode ser feita juntamente com as políticas secundárias (normas), e isso é até recomendável na implantação — desde que cada documento tenha escopo e nível de detalhe apropriados, para evitar que a política principal vire um “manual” difícil de manter.

Como estruturar de forma coerente ao porte (prático e escalável):

1. Diagnóstico proporcional ao risco e ao tamanho

• Levante ativos e processos críticos (ex.: dados de clientes, financeiro, operação, propriedade intelectual).
• Avalie requisitos regulatórios/contratuais (ex.: LGPD, PCI DSS, requisitos de clientes, auditorias).
• Defina o apetite de risco e prioridades (o que é “mínimo aceitável” agora vs. depois).

2. Modelo documental em camadas (recomendado)

• Política Principal de Segurança da Informação (nível estratégico):

  • Objetivo e princípios.
  • Escopo (quem e o que cobre: pessoas, sistemas, filiais, terceiros).
  • Papéis e responsabilidades (Diretoria, TI, Segurança, usuários, DPO/privacidade, terceiros).
  • Diretrizes de alto nível (ex.: controle de acesso, classificação da informação, gestão de incidentes, continuidade, conformidade).
  • Regras de governança: exceções, sanções, ciclo de revisão/aprovação.
  • Linguagem clara e “atemporal”, evitando detalhes técnicos.

• Normas/Políticas Secundárias (nível tático): traduzem a política em regras mais específicas.

  • Ex.: Norma de Controle de Acesso, Norma de Senhas/MFA, Norma de Backup, Norma de Uso Aceitável, Norma de Gestão de Vulnerabilidades, Norma de Criptografia, Norma de Classificação e Rotulagem, Norma de Trabalho Remoto/BYOD, Norma de Segurança em Terceiros.

• Procedimentos/Playbooks (nível operacional): passo a passo executável.

  • Ex.: procedimento de criação/revogação de acessos, playbook de resposta a incidente, procedimento de restauração de backup, rotina de patching.

• Padrões/Baselines (nível técnico): configurações mínimas.

  • Ex.: baseline de hardening Windows/Linux, configuração de firewall, EDR.

3. Adequação ao porte (o “quanto documentar” e “o quão formal”)

• Empresa pequena: pode começar com 1 PSI principal + 5 a 8 normas essenciais, mantendo procedimentos simples (às vezes em runbooks curtos). O foco é cobrir o “80/20”: acessos, backup, endpoints, e-mail, incidentes, terceiros.
• Empresa média: PSI + conjunto mais completo de normas + procedimentos por área; métricas e revisões periódicas.
• Empresa grande/regulada: PSI robusta com governança formal, comitê de segurança, gestão de riscos, auditoria, evidências, e várias normas e padrões técnicos.

4. Mecanismos de coerência (para não virar papel solto)

• Matriz de responsabilidades (RACI) e donos de cada norma.
• Controle de versões e repositório único.
• Processo de exceção (quem aprova, por quanto tempo, como mitiga).
• Treinamento e aceite (termo de ciência).
• Indicadores mínimos (ex.: % MFA, tempo de patch, taxa de incidentes, sucesso de backup/restore).

Pode fazer a Política Principal junto com as normas? Sim — com ressalvas importantes.

• Sim, porque ao escrever a política principal você precisa garantir que ela seja implementável; as normas ajudam a “aterrar” o que será exigido na prática. Isso evita uma PSI genérica e inaplicável.
• Ressalva 1 (manutenibilidade): a política principal deve mudar pouco; já normas e procedimentos mudam mais (tecnologia, ameaças, processos). Se misturar tudo em um documento único, você gera revisões constantes e aprovações burocráticas.
• Ressalva 2 (clareza): níveis diferentes (diretriz vs. regra técnica) no mesmo texto confundem o público. Diretores precisam ler a política; técnicos precisam dos padrões; usuários precisam de normas de conduta.

Conclusão: o melhor é desenvolver em paralelo (PSI principal e normas essenciais), mas publicar e manter separados, com referências cruzadas (a PSI “manda”, as normas “explicam como cumprir”). Isso garante coerência com o porte, implementação realista e facilidade de atualização.

Alternativa correta: (sem alternativas).