Inventário e classificação de ativos com donos e critérios objetivos

Por que inventário e classificação de ativos são a base do controle (sem burocracia)

Inventário e classificação de ativos é a prática de identificar o que a organização tem (ativos), quem responde por cada item (dono do ativo) e qual o nível de proteção necessário (classificação), usando critérios objetivos e repetíveis. Na prática, isso evita dois problemas comuns: (1) proteger demais o que não precisa (custo e atrito) e (2) proteger de menos o que é crítico (incidentes e perdas).

Quando o inventário é incompleto, a segurança vira “caça ao tesouro”: controles são aplicados por suposição, auditorias viram discussões sobre escopo e incidentes demoram a ser contidos porque ninguém sabe onde o dado está, quem aprova mudanças ou quem decide prioridades. Quando a classificação é subjetiva (“acho que é importante”), ela vira debate interminável. O objetivo aqui é transformar isso em um processo simples: poucos campos, critérios claros, donos definidos e rotinas de atualização.

O que é um “ativo” (e o que deve entrar no inventário)

Ativo é qualquer coisa que tenha valor para o negócio e que, se comprometida (confidencialidade, integridade ou disponibilidade), gere impacto. Em ISO 27001/27002, isso inclui informação e tudo que a suporta. Para ser prático, vale separar em categorias, porque cada uma tem forma diferente de “contar” e de “classificar”.

Categorias de ativos mais úteis no dia a dia

• Ativos de informação: bases de dados, relatórios, contratos, código-fonte, planilhas críticas, registros de clientes, logs relevantes, modelos de precificação, documentos regulatórios.
• Ativos tecnológicos: servidores, endpoints, dispositivos móveis, redes, firewalls, serviços em nuvem, aplicações, APIs, contas privilegiadas, chaves e certificados.
• Ativos de serviço: serviços terceirizados (folha, CRM, suporte), provedores de nuvem, processadores de pagamento, bureaus, consultorias com acesso a dados.
• Ativos físicos: salas, datacenter, armários, mídias removíveis, impressoras, controles de acesso físico.
• Ativos humanos (como dependência): não se “classifica” pessoas como ativo, mas é útil registrar funções críticas e dependências (ex.: único administrador de um sistema legado) como risco operacional; isso pode ficar em outro registro, mas influencia o inventário de sistemas.

Para reduzir burocracia, não tente inventariar “tudo” no mesmo nível de detalhe. O inventário deve ser suficiente para responder perguntas operacionais: “onde está o dado?”, “quem decide?”, “qual é o nível de proteção?”, “qual sistema processa?”, “qual fornecedor participa?”.

Donos de ativos: definição prática e como evitar o “ninguém é dono”

O dono do ativo é a pessoa (ou função) responsável por garantir que o ativo seja usado de acordo com o negócio e com os requisitos de segurança. Não é necessariamente quem administra tecnicamente. Em geral:

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

• Dono do ativo de informação: alguém do negócio que entende o valor e o uso do dado (ex.: gerente de operações dono do “Cadastro de Clientes”).
• Dono do sistema/aplicação: responsável por priorização, orçamento e mudanças do sistema (ex.: product owner do CRM interno).
• Custodiante: TI/infra/DevOps que opera e mantém (ex.: time de plataforma que administra o banco).
• Usuários autorizados: áreas que consomem o ativo.

Um erro comum é nomear como dono alguém “genérico” (ex.: “TI”) ou um comitê. Isso enfraquece decisões. O dono precisa ter autoridade para aprovar acessos, aceitar exceções e priorizar correções. Se não houver essa autoridade, o inventário vira uma lista sem efeito.

Critérios para escolher o dono certo

• Consegue dizer para que o ativo existe e quais processos dependem dele.
• Consegue definir quem deve acessar e por quê.
• Consegue aprovar mudanças de classificação e retenção.
• Consegue responder por impacto em caso de incidente (mesmo que não execute a correção técnica).

Classificação: o que é e o que ela precisa decidir

Classificar é atribuir um nível de proteção ao ativo de informação (e, por extensão, aos sistemas que o processam) com base em impacto. A classificação deve orientar decisões concretas, como: criptografar ou não, exigir MFA, restringir compartilhamento, exigir revisão de acesso, definir retenção, exigir backup com RPO/RTO, controlar exportação, registrar auditoria, aprovar uso com terceiros.

Se a classificação não muda nenhum controle, ela vira etiqueta. Por isso, defina poucos níveis e conecte cada nível a um conjunto mínimo de regras operacionais.

Modelo simples de níveis (exemplo)

• Público: pode ser divulgado sem dano relevante (ex.: material institucional já publicado).
• Interno: uso interno; divulgação externa pode causar desconforto ou pequena perda (ex.: organogramas, procedimentos internos).
• Confidencial: divulgação indevida causa impacto significativo (ex.: dados de clientes, contratos, estratégia comercial).
• Restrito: impacto alto ou regulatório; requer controles reforçados (ex.: dados pessoais sensíveis, credenciais, chaves, segredos industriais, dados financeiros críticos).

Você pode adaptar nomes, mas evite mais de 4–5 níveis. Quanto mais níveis, mais divergência e mais custo de manutenção.

Critérios objetivos: como tirar a classificação do “achismo”

Critérios objetivos são perguntas com respostas verificáveis que levam a uma classificação consistente. O ideal é que duas pessoas diferentes, usando o mesmo critério, cheguem ao mesmo resultado na maioria dos casos.

Dimensões de impacto (CIA) com perguntas práticas

Confidencialidade (se vazar):

• Contém dados pessoais? Se sim, quais categorias (comuns, sensíveis, crianças/adolescentes)?
• Existe obrigação contratual de confidencialidade (NDA, cláusulas com clientes)?
• Vazamento gera vantagem competitiva para concorrentes (ex.: preços, roadmap, algoritmo)?
• Vazamento exige notificação regulatória ou a clientes?

Integridade (se for alterado indevidamente):

• Alteração pode causar erro financeiro (faturamento, impostos, folha)?
• Alteração pode causar decisão errada (relatórios gerenciais, indicadores)?
• Há trilha de auditoria exigida (regulatório/contratual)?

Disponibilidade (se ficar indisponível):

• Qual o tempo máximo tolerável de indisponibilidade (em horas)?
• Parada afeta operação crítica (vendas, produção, atendimento)?
• Existe janela de operação (24x7, horário comercial, sazonal)?

Critérios “gatilho” (regras de decisão rápidas)

Para acelerar, defina gatilhos que automaticamente elevam a classificação. Exemplos:

• Se contém dados pessoais sensíveis ou credenciais/chaves → no mínimo Restrito.
• Se é necessário para faturar ou entregar o serviço e RTO < 8h → disponibilidade alta (influencia controles do sistema).
• Se é compartilhado com terceiros e há obrigação contratual → no mínimo Confidencial e exige cláusulas e controles.

Gatilhos reduzem discussões e tornam o processo repetível.

Inventário mínimo viável (IMV): quais campos realmente importam

Um inventário útil não precisa ter 80 colunas. Comece com um conjunto mínimo que permita governar e operar. Abaixo um exemplo de campos essenciais para ativos de informação e sistemas.

Campos recomendados para ativo de informação

• Nome do ativo (ex.: “Base de Clientes Ativos”).
• Descrição e finalidade (para que serve).
• Dono do ativo (nome/função) e substituto.
• Classificação (Público/Interno/Confidencial/Restrito).
• Critério aplicado (marcar gatilhos: dados pessoais, contrato, segredo, etc.).
• Localização (onde está armazenado: sistema, bucket, repositório, pasta, SaaS).
• Sistemas que processam (origem, processamento, destino).
• Compartilhamento (interno/externo; com quais terceiros).
• Retenção (prazo e base: legal/contratual/negócio).
• Requisitos de disponibilidade (RTO/RPO ou categoria: alta/média/baixa).

Campos recomendados para sistema/aplicação

• Nome do sistema e tipo (SaaS, interno, legado).
• Dono do sistema e time custodiante.
• Dados processados (link para ativos de informação).
• Ambiente (prod/homolog/dev) e criticidade de produção.
• Integrações (APIs, filas, ETL) e dependências.
• Fornecedor (se aplicável) e contato de suporte.
• Controles mínimos exigidos (ex.: MFA, criptografia, backup, logging).

Com isso, você já consegue direcionar controles, auditorias e resposta a incidentes sem criar um “monstro” administrativo.

Passo a passo prático para implementar (em ondas)

Passo 1: Defina o escopo inicial por valor e exposição

Escolha um recorte que gere resultado rápido. Exemplos de escopo inicial:

• Top 10 processos críticos (faturamento, atendimento, onboarding, logística).
• Top 20 sistemas em produção.
• Todos os repositórios que armazenam dados de clientes/colaboradores.
• Todos os fornecedores com acesso a dados.

Evite começar por “toda a empresa”. O objetivo é criar um padrão e depois expandir.

Passo 2: Crie o modelo de classificação com critérios e gatilhos

Documente em uma página: níveis, definição de cada nível, gatilhos e exemplos típicos. Inclua uma tabela simples de decisão. Exemplo de regra: “Se contém dados pessoais sensíveis → Restrito; se contém dados pessoais comuns → Confidencial; se não contém dados pessoais e é interno → Interno”. Ajuste conforme sua realidade.

Passo 3: Defina o “pacote de controles” por nível

Para cada classificação, defina o mínimo que muda na prática. Exemplo (ilustrativo):

• Interno: acesso por grupos; compartilhamento externo proibido sem aprovação do dono; backup padrão.
• Confidencial: MFA obrigatório; criptografia em trânsito; revisão de acesso semestral; logging de acesso; compartilhamento externo apenas com contrato e necessidade.
• Restrito: criptografia em repouso; acesso mínimo com aprovação explícita; segregação de ambientes; monitoramento reforçado; exportação controlada; retenção e descarte formal.

Isso conecta a etiqueta a decisões operacionais.

Passo 4: Monte o inventário mínimo viável (planilha ou ferramenta simples)

Use um formato que as áreas consigam manter. Uma planilha bem estruturada pode funcionar no início, desde que tenha: controle de versão, dono do inventário, e rotina de revisão. Se já houver CMDB ou catálogo de serviços, integre, mas não dependa disso para começar.

Passo 5: Faça workshops curtos com donos (coleta guiada)

Em vez de enviar um formulário e esperar retorno, faça sessões de 45–60 minutos por área/processo. Leve uma lista prévia de sistemas e dados (mesmo incompleta) e valide ao vivo. Perguntas que aceleram:

• Quais dados vocês criam/recebem que seriam problemáticos se vazassem?
• Quais relatórios/planilhas são “fonte da verdade”?
• Quais sistemas vocês não podem ficar sem por mais de X horas?
• Quais terceiros recebem ou acessam esses dados?

Ao final do workshop, já saia com dono definido e classificação preliminar aplicada por critérios.

Passo 6: Valide com evidências rápidas

Para evitar inventário “declaratório” incorreto, valide pontos críticos com evidências simples:

• Se disseram “não tem dado pessoal”, verifique amostras de tabelas/campos, formulários e integrações.
• Se disseram “não compartilhamos com terceiros”, verifique integrações, exportações e acessos de suporte.
• Se disseram “é pouco crítico”, confirme com métricas de indisponibilidade aceitável e impacto em receita/operação.

Não é auditoria pesada; é checagem para manter a classificação confiável.

Passo 7: Atribua ações imediatas para os itens mais críticos

Inventário sem ação perde credibilidade. Para cada ativo/sistema classificado como Confidencial/Restrito, gere 2–5 ações objetivas e pequenas, por exemplo:

• Habilitar MFA para todos os usuários do sistema.
• Restringir exportação de dados a um grupo específico.
• Configurar criptografia em repouso no storage.
• Ativar logging de acesso e retenção de logs por X dias.
• Revisar acessos existentes e remover contas órfãs.

Essas ações criam tração e mostram valor do processo.

Passo 8: Estabeleça rotina de manutenção (gatilhos de atualização)

Inventário desatualiza rápido. Em vez de “revisão anual de tudo”, use gatilhos:

• Novo sistema em produção → registro obrigatório antes do go-live.
• Nova integração/API → atualizar “sistemas que processam” e “compartilhamento”.
• Novo fornecedor com acesso a dados → criar/atualizar ativo de serviço e vincular aos dados.
• Mudança relevante de processo (ex.: novo canal de vendas) → revisar classificação.
• Incidente ou quase-incidente → validar se a classificação e controles estavam adequados.

Defina também uma revisão periódica leve (ex.: trimestral para itens Restritos, semestral para Confidenciais).

Exemplos práticos de classificação com critérios objetivos

Exemplo 1: Planilha de comissões de vendas

Descrição: planilha usada pelo gerente comercial para calcular comissões mensais, com nomes, valores e metas.

• Dados pessoais: sim (colaboradores) → pelo menos Confidencial.
• Impacto de integridade: alteração indevida gera pagamento incorreto → integridade alta.
• Compartilhamento: enviada por e-mail para alguns líderes → risco de vazamento.

Classificação sugerida: Confidencial. Ações: mover para repositório corporativo com controle de acesso; restringir compartilhamento; registrar dono; definir retenção (ex.: 5 anos se necessário por auditoria interna/contábil).

Exemplo 2: Repositório de chaves de API e segredos

Descrição: local onde ficam tokens, senhas de serviço e chaves privadas.

• Gatilho: credenciais/chaves → Restrito automaticamente.
• Impacto: vazamento permite acesso a múltiplos sistemas → impacto alto.

Classificação sugerida: Restrito. Ações: acesso mínimo; MFA; rotação periódica; logging; proibir cópia para locais pessoais; segregação por ambiente.

Exemplo 3: Base de tickets de suporte ao cliente

Descrição: sistema de atendimento com histórico de conversas, anexos e dados de contato.

• Dados pessoais: sim (clientes) → Confidencial (ou Restrito se houver dados sensíveis em anexos).
• Disponibilidade: se parar, atendimento degrada, mas operação pode continuar por algumas horas → definir RTO (ex.: 4–8h).
• Terceiros: SaaS com suboperadores → exige registro de fornecedor e compartilhamento.

Classificação sugerida: Confidencial (com regra: anexos com documentos sensíveis elevam para Restrito). Ações: política de anexos; DLP ou bloqueio de tipos de arquivo; revisão de acessos; retenção de tickets.

Como ligar inventário e classificação a decisões do dia a dia

Controle de acesso baseado em dono e classificação

Defina que qualquer concessão de acesso a ativos Confidenciais/Restritos exige aprovação do dono do ativo (não apenas do time técnico). Para reduzir atrito, use grupos padrão por função e exceções registradas. A classificação define o rigor: para Restrito, acesso por tempo limitado e revisão mais frequente.

Gestão de mudanças e projetos

Inclua um checkpoint simples em mudanças: “Este sistema processa dados classificados como Confidencial/Restrito?” Se sim, exigir evidências mínimas (MFA, criptografia, logging, backup). Isso evita que novos projetos criem “ilhas” fora do padrão.

Resposta a incidentes

Quando ocorre um incidente, o inventário acelera: você sabe o dono, onde está o dado, quais integrações existem e quais terceiros podem estar envolvidos. A classificação ajuda a priorizar: incidente em ativo Restrito tem prioridade máxima e pode exigir notificações e ações mais rápidas.

Erros comuns (e como corrigir sem recomeçar do zero)

Erro 1: Inventário vira lista infinita e ninguém mantém

Sintoma: dezenas de campos, baixa adesão, dados desatualizados. Correção: volte ao inventário mínimo viável; arquive campos “nice to have”; automatize o que der (ex.: puxar lista de sistemas da TI) e mantenha manual apenas o que exige decisão (dono, classificação, compartilhamento).

Erro 2: Dono é “TI” ou “Segurança” para tudo

Sintoma: aprovações travam, decisões não refletem o negócio. Correção: diferencie dono do dado (negócio) e custodiante (TI). Se o negócio não quer assumir, comece com “dono provisório” por 60 dias e formalize na primeira revisão.

Erro 3: Classificação sem critérios vira disputa

Sintoma: reuniões longas, cada área classifica diferente. Correção: adote gatilhos e perguntas fechadas; registre o critério aplicado no inventário; revise casos ambíguos e transforme em regra.

Erro 4: Tudo vira Restrito

Sintoma: controles pesados para tudo, queda de produtividade, “shadow IT”. Correção: refine critérios para diferenciar Confidencial vs Restrito (ex.: Restrito apenas para sensíveis, credenciais, segredos industriais, alto impacto regulatório). Faça amostragem e reclassifique itens superestimados.

Erro 5: Classifica o dado, mas esquece os fluxos

Sintoma: base principal protegida, mas exportações e integrações vazam. Correção: inclua no inventário “sistemas que processam” e “compartilhamento”; mapeie pelo menos origem → processamento → destino para ativos Confidenciais/Restritos.

Modelos prontos (para copiar e adaptar)

Tabela de decisão de classificação (exemplo simples)

Nível: Público | Critério: aprovado para divulgação externa | Ex.: site, releases, posts oficiais
Nível: Interno | Critério: uso interno, sem dados pessoais, sem segredo comercial | Ex.: procedimentos, comunicados internos
Nível: Confidencial | Critério: contém dados pessoais comuns OU contrato confidencial OU impacto financeiro relevante | Ex.: cadastro de clientes, contratos, relatórios de vendas
Nível: Restrito | Critério: dados pessoais sensíveis OU credenciais/chaves OU segredo industrial OU obrigação regulatória crítica | Ex.: tokens, chaves privadas, prontuários, dados bancários completos

Template de registro de ativo de informação

Nome do ativo:
Descrição/finalidade:
Dono do ativo (e substituto):
Classificação:
Critérios/gatilhos aplicados:
Localização (sistemas/repositórios):
Sistemas que processam (origem/processamento/destino):
Compartilhamento (interno/externo/terceiros):
Retenção e descarte:
Disponibilidade (RTO/RPO ou categoria):
Observações e ações pendentes: