Diagnóstico de Documentação Organizacional e Administrativa (DOA): Identifique as Falhas Antes que o Regulador Encontre
Entenda como diagnosticar a saúde da sua Documentação Organizacional e Administrativa (DOA) em cibersegurança. Descubra os anti-padrões mais comuns e utilize um checklist prático para garantir que seus documentos estejam alinhados com as melhores práticas e exigências regulatórias, evitando multas e garantindo a segurança da informação.
MundiX News·15 de abril de 2026·15 min de leitura·👁 2 views
A abordagem dos reguladores em relação aos processos de segurança da informação está mudando. Eles não perguntam mais apenas "você tem os documentos?". A questão agora é: "Como você comprova que esses documentos funcionam?". A análise das atividades de fiscalização do FSTEC (Serviço Federal de Supervisão Técnica e Controle de Exportação da Rússia), do Banco Central da Rússia e do Roskomnadzor (Serviço Federal de Supervisão de Comunicações, Tecnologia da Informação e Mídia de Massa) nos últimos anos mostra que mais de 80% das violações na área de proteção da informação (sejam instalações de Infraestruturas Críticas de Informação (ICIs), organizações financeiras ou operadores de dados pessoais) não estão relacionadas à falta de meios técnicos de proteção, mas à desconexão entre o que está estabelecido na Documentação Organizacional e Administrativa (DOA) e a prática real.
Para realizar a maioria das minhas tarefas de trabalho, preciso analisar a documentação organizacional e administrativa existente e desenvolver a documentação que falta para organizações de diferentes setores (incluindo energia, metalurgia e organizações financeiras). Na prática, percebo que empresas com baixo nível de maturidade em segurança da informação cometem os mesmos erros, e quais abordagens as empresas com níveis médios e altos de maturidade em segurança da informação usam para construir processos de segurança da informação que funcionam. Neste artigo, mostrarei onde a documentação geralmente "manca" e darei um checklist conciso com o qual a maioria dos documentos pode ser verificada em cerca de 15 minutos.
Quando realizar um diagnóstico de DOA
O diagnóstico da documentação organizacional e administrativa de segurança da informação é necessário se:
Você está se preparando para uma auditoria do FSTEC, Roskomnadzor ou Banco Central da Rússia;
É necessário um auditoria de segurança da informação ou avaliação da maturidade dos processos;
Há dúvidas sobre a relevância dos documentos;
É necessário identificar erros típicos em documentos de segurança da informação.
Parte 1. Anti-padrões em DOA
Comecemos com erros típicos em documentos de segurança da informação. Neste artigo, analisaremos 5 anti-padrões típicos em DOA – aquelas formulações e abordagens que podem causar comentários do regulador. Abaixo estão exemplos e opções de como reescrevê-los para que os documentos não apenas existam, mas funcionem na prática.
1. Responsabilidade Difusa
Quando os deveres são prescritos, mas é impossível encontrar quem exatamente é responsável por quê.
Qual é o risco?
O regulador não consegue estabelecer quem deve ser responsável por medidas específicas e qualifica isso como uma ausência de um sistema de gestão. Em caso de um incidente de computador, começa o caos: o chefe espera a ação do engenheiro, o engenheiro – a decisão do chefe. Minutos preciosos são gastos em coordenação e a proteção técnica não funciona devido à falta de gerenciamento. Vamos analisar como corrigir isso com exemplos concretos.
2. Requisitos Não Verificáveis
Formulações que não podem ser medidas ou confirmadas.
Qual é o risco?
Durante uma auditoria, o regulador perguntará: "Como você confirma que o nível de proteção é alto?" Sem critérios documentados, haverá uma ordem para eliminar a violação e, por não cumpri-la, uma multa administrativa. Sem critérios mensuráveis – sem provas.
Nesse caso, os documentos geralmente têm as seguintes formulações:
3. Documentos Isolados
Documentos que existem por si só e se contradizem.
Qual é o risco?
Ao verificar os documentos, o regulador encontrará contradições, o que será considerado uma violação da integridade do Sistema de Gestão de Segurança da Informação (SGSI). Um funcionário não pode fisicamente cumprir requisitos mutuamente exclusivos – a violação é inevitável.
Exemplos típicos – abaixo:
4. Linguagem Burocrática
O documento é escrito em uma linguagem compreensível para um advogado, mas não para um funcionário.
Qual é o risco?
Violações em massa por ignorância, vazamentos por meio de canais não controlados. A empresa não consegue provar que transmitiu os requisitos aos funcionários de forma compreensível.
Na prática, isso se parece com isto:
5. Cenário Ideal
O documento descreve apenas o modo normal, mas não contém algoritmos de ação em uma crise.
Qual é o risco?
Um funcionário, ao se deparar com um desvio do procedimento, fica sem instruções. Ele é forçado a improvisar ou interromper o processo, o que leva a erros, atrasos e riscos não controlados. O regulador, por sua vez, durante uma auditoria, verá que o sistema de gestão não leva em consideração as condições reais de operação e registrará uma violação.
Nesse caso, as seguintes formulações são usadas nos documentos:
Se você olhar para esses exemplos, fica claro: os problemas raramente estão relacionados à falta de requisitos. Muito mais frequentemente – com a forma como eles são formulados e interconectados.
Tudo isso pode ser verificado rapidamente o suficiente com a ajuda de um checklist de autodiagnóstico: sem uma auditoria dispendiosa e o envolvimento de consultores externos.
Parte 2. Checklist de Autodiagnóstico
Pegue qualquer documento de segurança da informação e faça cinco perguntas a ele. Se pelo menos uma pergunta não puder ser respondida inequivocamente – o documento está em risco.
Quase todos os problemas descritos acima são unidos por uma razão: os documentos são escritos para auditoria, não para uso.
É aqui que surge um aspecto importante, mas frequentemente ignorado – a facilidade de percepção do documento. Essencialmente, qualquer DOA é uma interface entre um requisito e uma ação.
UX e Documentação Organizacional e Administrativa
À primeira vista, o layout de um jornal e o desenvolvimento de documentação organizacional e administrativa são tarefas completamente diferentes. Mas, na prática, eles têm muito mais em comum do que parece. Durante meus estudos na universidade, eu era apaixonado por design UX/UI e trabalhei como designer em um jornal universitário. Então, li muitos livros sobre design de interface, tipografia e pesquisa de usuários. Um pensamento-chave do livro ficou comigo para a vida toda: "O usuário não deve pensar. Sua tarefa é obter informações, não quebrar a cabeça sobre como lê-las".
Se um funcionário abriu uma política e não entendeu nada após 30 segundos – o documento não existe. Ele não vai vasculhar, ele simplesmente continuará fazendo do seu jeito. Isso significa que mesmo os melhores requisitos não funcionarão.
Don Norman em "O Design do Dia a Dia" escreve que, quando algo dá errado, o usuário tende a culpar a si mesmo. Mas, na verdade, o design da interface é o culpado. O mesmo vale para os documentos: se o usuário não entendeu como agir – não é problema dele, é problema do documento. Ele deve ser projetado para não deixar espaço para interpretações ambíguas.
É por isso que acredito que o desenvolvimento de DOA não é burocracia, mas engenharia. Um documento é uma interface entre um requisito e uma ação real. E deve ser projetado como uma interface: levando em consideração o usuário, o contexto, os cenários.
Engenharia, não Burocracia
Um bom documento não é um conjunto de belas frases. É uma descrição de processos reais que serão realizados por pessoas. Seu desenvolvimento requer:
Compreensão dos processos de negócios. Você não pode escrever um regulamento de gerenciamento de acesso sem saber como diferentes categorias de pessoas obtêm acesso na empresa, quem aprova o direito de acesso, como isso é tecnicamente implementado.
Habilidade de negociar. Um documento é um compromisso entre os requisitos do regulador, as capacidades da infraestrutura de TI e os desejos do negócio. Se você não conseguiu negociar, o documento permanecerá um "pedaço de papel na gaveta".
Pensamento sistêmico. O documento deve fazer parte de um sistema, não uma ilha. Ele deve referenciar outros documentos, não contradizê-los, ser facilmente atualizado.
Empatia. Você está escrevendo para pessoas. Elas o lerão em diferentes humores, em diferentes circunstâncias. Seu texto deve ser compreensível mesmo às 3 da manhã, quando ocorreu um incidente de computador.
Avalie seus processos de acordo com esses quatro critérios. Se você não pode responder afirmativamente a cada item – você tem um motivo para reconsiderar sua abordagem.
Em Conclusão
Os reguladores estão mudando. Os negócios estão mudando. As ameaças estão se tornando mais complexas. Mas uma coisa permanece inalterada: enquanto houver pessoas, haverá documentos. A documentação é a única maneira de registrar acordos, transmitir conhecimento, garantir a repetibilidade das ações. A questão não é se livrar deles, mas torná-los uma ferramenta de trabalho.
A documentação não é um "pedaço de papel", mas um ativo que:
Economiza tempo ao apresentar novos funcionários ao trabalho;
Reduz o risco de erros e multas;
Ajuda a passar por auditorias sem surpresas;
Dá aos funcionários uma compreensão clara do que e por que fazer.
Dica: pare de ver os documentos como um mal inevitável. Comece a projetá-los como parte dos processos. Use o checklist acima para se verificar ao desenvolver DOA. E lembre-se: um bom documento é quando um funcionário, depois de lê-lo, diz honestamente: "Eu entendo o que precisa ser feito".
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
A abordagem dos reguladores em relação aos processos de segurança da informação está mudando. Eles não perguntam mais apenas "você tem os documentos?". A questão agora é: "Como você comprova que esses documentos funcionam?". A análise das atividades de fiscalização do FSTEC (Serviço Federal de Supervisão Técnica e Controle de Exportação da Rússia), do Banco Central da Rússia e do Roskomnadzor (Serviço Federal de Supervisão de Comunicações, Tecnologia da Informação e Mídia de Massa) nos últimos anos mostra que mais de 80% das violações na área de proteção da informação (sejam instalações de Infraestruturas Críticas de Informação (ICIs), organizações financeiras ou operadores de dados pessoais) não estão relacionadas à falta de meios técnicos de proteção, mas à desconexão entre o que está estabelecido na Documentação Organizacional e Administrativa (DOA) e a prática real.
Para realizar a maioria das minhas tarefas de trabalho, preciso analisar a documentação organizacional e administrativa existente e desenvolver a documentação que falta para organizações de diferentes setores (incluindo energia, metalurgia e organizações financeiras). Na prática, percebo que empresas com baixo nível de maturidade em segurança da informação cometem os mesmos erros, e quais abordagens as empresas com níveis médios e altos de maturidade em segurança da informação usam para construir processos de segurança da informação que funcionam. Neste artigo, mostrarei onde a documentação geralmente "manca" e darei um checklist conciso com o qual a maioria dos documentos pode ser verificada em cerca de 15 minutos.
Quando realizar um diagnóstico de DOA
O diagnóstico da documentação organizacional e administrativa de segurança da informação é necessário se:
Você está se preparando para uma auditoria do FSTEC, Roskomnadzor ou Banco Central da Rússia;
É necessário um auditoria de segurança da informação ou avaliação da maturidade dos processos;
Há dúvidas sobre a relevância dos documentos;
É necessário identificar erros típicos em documentos de segurança da informação.
Parte 1. Anti-padrões em DOA
Comecemos com erros típicos em documentos de segurança da informação. Neste artigo, analisaremos 5 anti-padrões típicos em DOA – aquelas formulações e abordagens que podem causar comentários do regulador. Abaixo estão exemplos e opções de como reescrevê-los para que os documentos não apenas existam, mas funcionem na prática.
1. Responsabilidade Difusa
Quando os deveres são prescritos, mas é impossível encontrar quem exatamente é responsável por quê.
Qual é o risco?
O regulador não consegue estabelecer quem deve ser responsável por medidas específicas e qualifica isso como uma ausência de um sistema de gestão. Em caso de um incidente de computador, começa o caos: o chefe espera a ação do engenheiro, o engenheiro – a decisão do chefe. Minutos preciosos são gastos em coordenação e a proteção técnica não funciona devido à falta de gerenciamento. Vamos analisar como corrigir isso com exemplos concretos.
2. Requisitos Não Verificáveis
Formulações que não podem ser medidas ou confirmadas.
Qual é o risco?
Durante uma auditoria, o regulador perguntará: "Como você confirma que o nível de proteção é alto?" Sem critérios documentados, haverá uma ordem para eliminar a violação e, por não cumpri-la, uma multa administrativa. Sem critérios mensuráveis – sem provas.
Nesse caso, os documentos geralmente têm as seguintes formulações:
3. Documentos Isolados
Documentos que existem por si só e se contradizem.
Qual é o risco?
Ao verificar os documentos, o regulador encontrará contradições, o que será considerado uma violação da integridade do Sistema de Gestão de Segurança da Informação (SGSI). Um funcionário não pode fisicamente cumprir requisitos mutuamente exclusivos – a violação é inevitável.
Exemplos típicos – abaixo:
4. Linguagem Burocrática
O documento é escrito em uma linguagem compreensível para um advogado, mas não para um funcionário.
Qual é o risco?
Violações em massa por ignorância, vazamentos por meio de canais não controlados. A empresa não consegue provar que transmitiu os requisitos aos funcionários de forma compreensível.
Na prática, isso se parece com isto:
5. Cenário Ideal
O documento descreve apenas o modo normal, mas não contém algoritmos de ação em uma crise.
Qual é o risco?
Um funcionário, ao se deparar com um desvio do procedimento, fica sem instruções. Ele é forçado a improvisar ou interromper o processo, o que leva a erros, atrasos e riscos não controlados. O regulador, por sua vez, durante uma auditoria, verá que o sistema de gestão não leva em consideração as condições reais de operação e registrará uma violação.
Nesse caso, as seguintes formulações são usadas nos documentos:
Se você olhar para esses exemplos, fica claro: os problemas raramente estão relacionados à falta de requisitos. Muito mais frequentemente – com a forma como eles são formulados e interconectados.
Tudo isso pode ser verificado rapidamente o suficiente com a ajuda de um checklist de autodiagnóstico: sem uma auditoria dispendiosa e o envolvimento de consultores externos.
Parte 2. Checklist de Autodiagnóstico
Pegue qualquer documento de segurança da informação e faça cinco perguntas a ele. Se pelo menos uma pergunta não puder ser respondida inequivocamente – o documento está em risco.
Quase todos os problemas descritos acima são unidos por uma razão: os documentos são escritos para auditoria, não para uso.
É aqui que surge um aspecto importante, mas frequentemente ignorado – a facilidade de percepção do documento. Essencialmente, qualquer DOA é uma interface entre um requisito e uma ação.
UX e Documentação Organizacional e Administrativa
À primeira vista, o layout de um jornal e o desenvolvimento de documentação organizacional e administrativa são tarefas completamente diferentes. Mas, na prática, eles têm muito mais em comum do que parece. Durante meus estudos na universidade, eu era apaixonado por design UX/UI e trabalhei como designer em um jornal universitário. Então, li muitos livros sobre design de interface, tipografia e pesquisa de usuários. Um pensamento-chave do livro ficou comigo para a vida toda: "O usuário não deve pensar. Sua tarefa é obter informações, não quebrar a cabeça sobre como lê-las".
Se um funcionário abriu uma política e não entendeu nada após 30 segundos – o documento não existe. Ele não vai vasculhar, ele simplesmente continuará fazendo do seu jeito. Isso significa que mesmo os melhores requisitos não funcionarão.
Don Norman em "O Design do Dia a Dia" escreve que, quando algo dá errado, o usuário tende a culpar a si mesmo. Mas, na verdade, o design da interface é o culpado. O mesmo vale para os documentos: se o usuário não entendeu como agir – não é problema dele, é problema do documento. Ele deve ser projetado para não deixar espaço para interpretações ambíguas.
É por isso que acredito que o desenvolvimento de DOA não é burocracia, mas engenharia. Um documento é uma interface entre um requisito e uma ação real. E deve ser projetado como uma interface: levando em consideração o usuário, o contexto, os cenários.
Engenharia, não Burocracia
Um bom documento não é um conjunto de belas frases. É uma descrição de processos reais que serão realizados por pessoas. Seu desenvolvimento requer:
Compreensão dos processos de negócios. Você não pode escrever um regulamento de gerenciamento de acesso sem saber como diferentes categorias de pessoas obtêm acesso na empresa, quem aprova o direito de acesso, como isso é tecnicamente implementado.
Habilidade de negociar. Um documento é um compromisso entre os requisitos do regulador, as capacidades da infraestrutura de TI e os desejos do negócio. Se você não conseguiu negociar, o documento permanecerá um "pedaço de papel na gaveta".
Pensamento sistêmico. O documento deve fazer parte de um sistema, não uma ilha. Ele deve referenciar outros documentos, não contradizê-los, ser facilmente atualizado.
Empatia. Você está escrevendo para pessoas. Elas o lerão em diferentes humores, em diferentes circunstâncias. Seu texto deve ser compreensível mesmo às 3 da manhã, quando ocorreu um incidente de computador.
Avalie seus processos de acordo com esses quatro critérios. Se você não pode responder afirmativamente a cada item – você tem um motivo para reconsiderar sua abordagem.
Em Conclusão
Os reguladores estão mudando. Os negócios estão mudando. As ameaças estão se tornando mais complexas. Mas uma coisa permanece inalterada: enquanto houver pessoas, haverá documentos. A documentação é a única maneira de registrar acordos, transmitir conhecimento, garantir a repetibilidade das ações. A questão não é se livrar deles, mas torná-los uma ferramenta de trabalho.
A documentação não é um "pedaço de papel", mas um ativo que:
Economiza tempo ao apresentar novos funcionários ao trabalho;
Reduz o risco de erros e multas;
Ajuda a passar por auditorias sem surpresas;
Dá aos funcionários uma compreensão clara do que e por que fazer.
Dica: pare de ver os documentos como um mal inevitável. Comece a projetá-los como parte dos processos. Use o checklist acima para se verificar ao desenvolver DOA. E lembre-se: um bom documento é quando um funcionário, depois de lê-lo, diz honestamente: "Eu entendo o que precisa ser feito".
📤 Compartilhar & Baixar
📩 Newsletter MundiX
Receba novidades de cibersegurança + um checklist de pentest grátis. Sem spam.
Ao assinar você concorda em receber e-mails. Cancele quando quiser.
