# Plano de diagnóstico — Governança de TI e da Informação

> **Modelo didático e adaptável.** Nenhum controle deve ser implementado somente porque consta aqui. Um diagnóstico exige acesso autorizado, participação dos responsáveis, avaliação jurídica quando pertinente e aprovação formal. Não registrar senhas, tokens ou dados pessoais desnecessários neste documento.

## Identificação e controle de versão
| Campo | Preencher |
|---|---|
| Empresa / unidades / áreas | [organização e limites] |
| Patrocinador | [direção responsável] |
| Responsável por tecnologia | [nome/cargo] |
| Dono da informação | [papel e área] |
| Data da descoberta | [AAAA-MM-DD] |
| Versão / estado | [0.1 / rascunho] |
| Aprovação / revisão seguinte | [pessoas e datas] |

## 1. Problema, objetivos e limites
- Que incidente, risco, retrabalho ou dependência levou ao diagnóstico?
- Quem sente o impacto? Qual efeito observável e qual a frequência?
- Quais sistemas, pastas, documentos, processos, unidades e fornecedores estão no escopo?
- Quais informações ou ambientes não podem ser examinados sem autorização adicional?
- Que regras legais, contratuais ou setoriais podem incidir? Validar com responsáveis competentes.
- Qual nível mínimo de segurança, disponibilidade e recuperação a organização precisa?

## 2. Entrevistas e evidências de descoberta
| Stakeholder | Pergunta principal | Fonte de evidência | Pendente de validação |
|---|---|---|---|
| Diretoria | Quem aceita riscos e prioriza investimentos? | [reunião, decisão] | |
| RH | Como entram, mudam de função e saem colaboradores? | [processo documentado] | |
| TI | Como acessos, ativos, mudanças e backups são geridos? | [inventário, logs] | |
| Áreas operacionais | Como arquivos e dados circulam? | [fluxo observado] | |
| Privacidade/jurídico | Que tratamento de dados é permitido e por quanto tempo? | [política, contrato] | |

## 3. Inventário e criticidade
| Ativo / serviço / acervo | Proprietário | Finalidade | Criticidade | Dependência | Retenção / backup |
|---|---|---|---|---|---|
| [Google Drive compartilhado / SharePoint] | | | | | |
| [Sistema / servidor Windows ou Linux] | | | | | |
| [Conta corporativa / integração] | | | | | |

Descrever processos atuais (**AS-IS**) antes de propor mudanças (**TO-BE**). Classificar com o proprietário, não por suposição.

## 4. Governança da informação
- **Classificação:** categorias proporcionais (ex.: público, uso interno, confidencial, restrito) e responsáveis.
- **Ciclo de vida:** criação → revisão → uso → compartilhamento → retenção → descarte.
- **Acesso:** pessoa, função, justificativa, aprovação, revisão e revogação; tratamento de exceções.
- **Ferramentas:** regras para Drive compartilhado, SharePoint, Teams, Microsoft 365 ou Workspace condicionadas à licença e contexto.
- **LGPD:** finalidade, dados pessoais, base legal, direitos, contratos, encarregados e retenção definidos com a organização, não inferidos por TI.

## 5. Governança de tecnologia
| Controle | Estado atual | Risco | Responsável | Ação proposta | Evidência do aceite |
|---|---|---|---|---|---|
| Gestão de identidades e MFA | | | | | |
| Inventário de ativos e software | | | | | |
| Atualização e vulnerabilidades | | | | | |
| Gestão de mudanças e rollback | | | | | |
| Logs e resposta a incidentes | | | | | |
| Backup, restauração e continuidade | | | | | |
| Gestão de fornecedores e contratos | | | | | |

## 6. Resiliência e continuidade
| Serviço crítico | Impacto de interrupção | RTO proposto | RPO proposto | Responsável | Evidência de restauração |
|---|---|---|---|---|---|
| [nome] | [impacto] | A definir com negócio | A definir com negócio | | |

Backups realizados **não** comprovam recuperação. Documentar ensaios de restore, retenção, segregação, revisão de alertas e planos de resposta a incidentes.

## 7. Decisões, priorização e execução
| ID | Decisão / requisito | Justificativa | Prioridade | Dependências | Critério de aceite | Aprovação |
|---|---|---|---|---|---|---|
| GOV-001 | [controle] | [risco ou necessidade] | [critério negociado] | | [teste verificável] | |
| INF-001 | [classificação/acesso] | [motivo] | | | | |

Para cada mudança, definir piloto, comunicação, reversão, medição e revisão posterior. Não alterar permissões em massa sem simular impacto e obter aprovação.

## 8. Matriz de responsabilidade (RACI)
| Atividade | Patrocinador | Dono do dado | TI | RH | Privacidade |
|---|---|---|---|---|---|
| Aprovar política de informação | | | | | |
| Conceder acesso | | | | | |
| Revogar acesso após desligamento | | | | | |
| Aprovar janela de mudança | | | | | |
| Aceitar risco residual | | | | | |
| Aprovar retenção / descarte | | | | | |

Usar R=executa, A=responde/aprova, C=consultado, I=informado. Ajustar ao organograma e segregar funções quando necessário.

## 9. Evidências de homologação
- [ ] Stakeholders, escopo e riscos foram acordados.
- [ ] Acesso e tratamento de informações foram autorizados.
- [ ] Inventários, classificações e responsáveis foram revisados.
- [ ] Políticas e exceções possuem aprovação.
- [ ] Controles prioritários foram testados em piloto.
- [ ] A restauração e os principais cenários de falha foram ensaiados.
- [ ] A equipe conhece os procedimentos de operação e suporte.
- [ ] Existe calendário de revisão de acessos, contratos, riscos e documentação.

## 10. Plano de evolução e gestão de mudanças
Registrar versão anterior, mudança, responsável, aceite, riscos residuais, data de revisão, evidências e plano de reversão. Documento vivo.

*Este material não representa auditoria, diagnóstico profissional já executado, certificação ou aconselhamento jurídico.*