Papéis, responsabilidades e modelo de decisão em segurança da informação

Por que papéis e responsabilidades são o “antídoto” para a segurança informal

Em segurança da informação, muitos problemas não acontecem por falta de tecnologia, e sim por falta de clareza sobre quem decide, quem executa, quem aprova e quem responde quando algo dá errado. Quando papéis e responsabilidades não estão definidos, surgem sintomas recorrentes: controles implementados “pela metade”, exceções concedidas sem critério, incidentes sem dono, auditorias com evidências incompletas e conflitos entre áreas (TI, jurídico, negócio, fornecedores).

Um modelo de papéis e decisão bem desenhado reduz atrito e acelera entregas porque transforma segurança em um fluxo operacional previsível: demandas chegam, são avaliadas, alguém decide com base em critérios, alguém executa, alguém valida e tudo fica rastreável. Isso também evita que a segurança seja vista como “o time que diz não”, porque a decisão passa a ser do nível correto (negócio e liderança), com suporte técnico e critérios objetivos.

Conceitos essenciais: papel, responsabilidade, autoridade e accountability

Papel (role)

Papel é uma função organizacional com um conjunto de expectativas. Um papel pode ser exercido por uma pessoa, por um time ou até por um comitê. Exemplo: “Dono do Sistema de Folha”, “Gestor de Identidade”, “DPO/Encarregado”, “Gestor de Riscos”.

Responsabilidade (responsibility)

Responsabilidade é o que o papel faz no dia a dia: tarefas, entregas e obrigações. Exemplo: “revisar acessos trimestralmente”, “aprovar exceções de controle”, “garantir que logs sejam retidos por X dias”.

Autoridade (authority)

Autoridade é o poder formal para decidir e direcionar recursos. Exemplo: “aprovar orçamento para correção de vulnerabilidade”, “priorizar backlog”, “aceitar risco residual”.

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

Accountability (prestação de contas)

Accountability é a obrigação de responder pelo resultado. Uma pessoa pode delegar tarefas, mas não delega accountability. Exemplo: o dono do processo de vendas pode delegar a execução de controles para TI, mas continua respondendo pelo risco de indisponibilidade do CRM.

Separação de funções (SoD) e conflitos de interesse

Separação de funções evita que uma mesma pessoa consiga iniciar e concluir uma ação crítica sem revisão independente. Exemplo: quem desenvolve não deve aprovar a própria mudança em produção; quem administra acessos privilegiados não deve ser o único a auditar esses acessos. O objetivo não é burocracia, e sim reduzir risco de erro e fraude.

Quais papéis normalmente existem (e como descrevê-los sem inflar organograma)

Os nomes variam, mas os papéis abaixo aparecem com frequência em organizações que querem governança prática. O ponto-chave é descrever responsabilidades e decisões, não criar cargos novos.

Alta direção / patrocinador executivo

• Define prioridades e apetite a risco (o quanto a organização aceita de risco em troca de velocidade/custo).
• Resolve impasses entre áreas quando há conflito de prioridade.
• Patrocina investimentos e cobra resultados.

Comitê de Segurança (ou fórum de decisão)

• Não precisa ser um “comitê formal” mensal; pode ser um fórum quinzenal com pauta objetiva.
• Decide sobre exceções relevantes, riscos altos, prioridades de roadmap e temas transversais (ex.: MFA corporativo, classificação de dados).
• Garante que decisões tenham dono, prazo e critério de sucesso.

Responsável por Segurança da Informação (CISO ou equivalente)

• Traduz risco em linguagem de negócio e propõe controles.
• Define requisitos mínimos e orienta a implementação.
• Monitora indicadores e reporta riscos relevantes.
• Coordena resposta a incidentes (com apoio das áreas).

Gestor de Riscos (corporativo ou de TI)

• Facilita a identificação, análise e tratamento de riscos.
• Padroniza critérios (probabilidade, impacto, níveis de risco).
• Garante consistência entre áreas e registra decisões.

Dono do Processo (Process Owner)

• Responde pelo risco do processo (ex.: faturamento, logística, atendimento).
• Define requisitos de negócio (disponibilidade, prazos, tolerância a falhas).
• Decide sobre aceitar risco residual quando controles impactam o negócio.

Dono do Ativo / Dono da Informação (Information Owner)

• Define classificação e regras de uso/compartilhamento dos dados sob sua responsabilidade.
• Aprova acessos a dados sensíveis e revisa periodicamente.
• Define retenção e descarte (em conjunto com jurídico/compliance quando aplicável).

Dono do Sistema (System Owner)

• Responde pela saúde do sistema (disponibilidade, integridade, mudanças).
• Garante que controles técnicos sejam implementados (logs, backups, hardening).
• Coordena correções com fornecedores e times internos.

TI Operações / Infra / Cloud

• Implementa controles técnicos (rede, endpoint, IAM, backup, monitoramento).
• Opera serviços com SLAs e evidências (tickets, relatórios, configurações).
• Executa correções e mudanças com rastreabilidade.

Desenvolvimento / Engenharia / DevOps

• Constrói e mantém aplicações com práticas seguras (revisão, testes, pipeline).
• Corrige vulnerabilidades no código e dependências.
• Garante que segredos, chaves e configurações sejam tratados corretamente.

Jurídico / Compliance / Privacidade (DPO/Encarregado)

• Interpreta requisitos legais e contratuais (LGPD, cláusulas de clientes).
• Apoia decisões sobre retenção, base legal, compartilhamento e incidentes com dados pessoais.
• Participa de avaliações de risco quando há impacto regulatório.

RH

• Integra controles de ciclo de vida do colaborador (admissão, movimentação, desligamento).
• Define regras disciplinares e apoia conscientização.
• Garante que desligamentos acionem revogação de acessos e devolução de ativos.

Compras / Gestão de Fornecedores

• Inclui requisitos de segurança em contratos e renovações.
• Garante que avaliações de risco de terceiros aconteçam antes da contratação.
• Monitora SLAs e obrigações de segurança acordadas.

Auditoria interna (quando existir)

• Avalia aderência e efetividade de controles de forma independente.
• Testa evidências e recomenda melhorias.
• Não deve ser dona do controle nem executora do dia a dia.

Modelo de decisão: o que precisa ser decidido e em qual nível

Um modelo de decisão em segurança define “quem decide o quê” e “com base em quais critérios”. Isso evita que decisões estratégicas fiquem no nível operacional e que decisões operacionais virem escalonamentos intermináveis.

Tipos comuns de decisão em segurança

• Aceite de risco: quando um risco permanece acima do aceitável e a organização decide conviver com ele por um período.
• Exceção de controle: quando um requisito mínimo não será cumprido (temporariamente ou permanentemente) e precisa de justificativa e compensações.
• Priorização: o que entra primeiro no roadmap (ex.: MFA, segmentação de rede, EDR, correção de vulnerabilidades críticas).
• Classificação e compartilhamento de dados: quem pode acessar, com quem pode compartilhar, como deve proteger.
• Resposta a incidentes: quando acionar jurídico, comunicação, clientes, autoridade regulatória; quem aprova comunicações externas.
• Arquitetura e padrões: decisões sobre tecnologias e padrões mínimos (ex.: criptografia, logging, autenticação).

Princípio prático: decisão no nível do impacto

Uma regra simples: quanto maior o impacto potencial (financeiro, reputacional, regulatório, operacional), mais alto deve ser o nível de decisão. Exemplo: aceitar risco que pode parar faturamento por 48h não deve ser decisão apenas de TI; deve envolver dono do processo e liderança.

Ferramenta prática: matriz RACI (e como não errar ao usar)

RACI é uma forma objetiva de mapear responsabilidades:

• R (Responsible): executa a tarefa.
• A (Accountable): responde pelo resultado e aprova.
• C (Consulted): é consultado e contribui.
• I (Informed): é informado do andamento/resultado.

Regras que evitam confusão:

• Para cada atividade, tenha um único A (senão ninguém decide).
• Evite muitos C; consulte quem realmente agrega.
• R pode ser mais de um, mas com divisão clara (ex.: “Infra implementa”, “SOC monitora”).
• RACI não substitui processo; ele esclarece papéis dentro do processo.

Exemplo de RACI (recorte) para gestão de vulnerabilidades

Atividade: Identificar vulnerabilidades (scan contínuo)     R: SecOps/SOC   A: CISO   C: Infra/Dev   I: Donos de sistema/Processo
Atividade: Priorizar correções (critério risco/impacto)     R: CISO/Riscos  A: Dono do sistema  C: Dono do processo  I: TI
Atividade: Corrigir (patch/config/código)                   R: Infra/Dev    A: Dono do sistema  C: Segurança         I: Riscos
Atividade: Validar correção e evidência                      R: Segurança    A: CISO             C: Dono do sistema   I: Auditoria

Note que o “A” muda conforme a natureza da decisão: correção técnica pode ser do dono do sistema; critérios e governança podem ser do CISO; priorização pode exigir dono do processo quando há impacto operacional.

Passo a passo prático para definir papéis, responsabilidades e decisões

1) Liste os processos de segurança que realmente acontecem

Evite começar por organograma. Comece por fluxos reais. Exemplos de processos típicos:

• Gestão de acessos (solicitar, aprovar, provisionar, revisar, revogar).
• Gestão de mudanças (especialmente mudanças com impacto em segurança).
• Gestão de vulnerabilidades (identificar, priorizar, corrigir, validar).
• Resposta a incidentes (triagem, contenção, comunicação, lições aprendidas).
• Gestão de terceiros (avaliação, contratação, monitoramento).
• Classificação e compartilhamento de dados (incluindo uso de SaaS).

Escolha 3 a 5 processos para começar, os que mais geram risco ou atrito.

2) Para cada processo, escreva as decisões críticas

Exemplo em “gestão de acessos”:

• Quem aprova acesso a dados sensíveis?
• Quem autoriza acesso privilegiado (admin)?
• Quem decide exceção quando alguém pede acesso fora do padrão?
• Quem define periodicidade de revisão e o que acontece se não revisarem?

Escreva as decisões como frases objetivas, começando com “Decidir se…”, “Aprovar…”, “Aceitar…”.

3) Defina critérios de decisão (para reduzir subjetividade)

Sem critérios, a decisão vira opinião. Crie critérios simples e repetíveis. Exemplos:

• Acesso: mínimo privilégio, segregação de funções, necessidade de negócio, validade (prazo), trilha de auditoria.
• Exceção: justificativa, prazo de expiração, controle compensatório, risco residual, aprovação do nível correto.
• Vulnerabilidade: criticidade técnica + exposição (internet?) + valor do ativo + existência de exploit + impacto no processo.

Documente critérios em linguagem prática, com exemplos do que “passa” e do que “não passa”.

4) Atribua R, A, C, I para cada atividade e decisão

Monte uma matriz por processo (pode ser uma tabela simples). Garanta:

• Um A por decisão.
• R claro para execução e evidência.
• C apenas para especialistas necessários (jurídico, privacidade, arquitetura).
• I para quem precisa acompanhar (gestores, auditoria, donos de processo).

5) Valide com as áreas em uma reunião curta e orientada a casos

Em vez de discutir teoria, traga 3 casos reais recentes (ou prováveis) e simule:

• “Um fornecedor precisa acessar produção por 2 horas: quem aprova?”
• “Uma vulnerabilidade crítica em servidor de faturamento exige reinício: quem decide janela?”
• “Um time quer usar um novo SaaS para dados de clientes: quem autoriza?”

Se a simulação travar, é sinal de lacuna de decisão ou de excesso de “C”. Ajuste na hora.

6) Publique em formato utilizável e conecte ao dia a dia

Evite documentos longos. Publique:

• Uma página por processo com RACI + critérios + fluxo resumido.
• Modelos prontos: formulário de exceção, registro de aceite de risco, checklist de onboarding de fornecedor.
• Onde abrir solicitação (fila/ticket) e quais evidências anexar.

O objetivo é que qualquer pessoa saiba “para onde vai” e “quem decide” em menos de 2 minutos.

7) Crie gatilhos de escalonamento (quando sair do padrão)

Defina limites claros para subir decisão de nível. Exemplos:

• Exceção acima de 90 dias exige aprovação do dono do processo + CISO.
• Aceite de risco “alto” exige patrocinador executivo.
• Incidente com dados pessoais exige envolvimento do DPO/Encarregado e jurídico.
• Acesso privilegiado fora do horário comercial exige dupla aprovação (dono do sistema + segurança) e sessão monitorada.

8) Estabeleça cadência de revisão (sem burocracia)

Papéis mudam com reorganizações e terceirizações. Defina uma revisão leve:

• Trimestral: lista de donos de sistemas e donos de informação (atualização rápida).
• Semestral: RACI dos processos críticos e critérios de decisão.
• Após incidentes relevantes: ajustar responsabilidades que falharam na prática.

Exemplos práticos de decisões e responsabilidades (situações comuns)

Exemplo 1: exceção para MFA em um sistema legado

Cenário: um sistema legado não suporta MFA e o time pede exceção por 6 meses.

• R: TI/Infra documenta limitação técnica e plano de correção.
• C: Segurança avalia risco e propõe controles compensatórios (VPN restrita, IP allowlist, monitoramento reforçado, contas nominativas).
• A: Dono do sistema aprova a exceção operacional; se o risco afetar processo crítico, o dono do processo também aprova.
• I: Riscos e auditoria são informados; registra-se data de expiração e responsável por renovar ou encerrar.

Critérios: prazo máximo, controles compensatórios mínimos, evidência de plano com marcos (ex.: atualização, substituição, desativação).

Exemplo 2: acesso de fornecedor a ambiente de produção

Cenário: fornecedor precisa acessar produção para suporte.

• R: Dono do sistema abre solicitação com janela, escopo e justificativa.
• R: TI provisiona acesso temporário, com conta nominativa, MFA e expiração automática.
• A: Dono do sistema aprova o acesso; Segurança aprova requisitos mínimos (ou é C, dependendo do risco).
• C: Compras/terceiros valida se contrato cobre obrigações de segurança e confidencialidade.
• I: SOC recebe informação para monitorar sessão e alertas.

Separação de funções: quem aprova não deve ser o mesmo que cria a conta e libera permissões sem revisão.

Exemplo 3: decisão de priorização de correção que impacta operação

Cenário: patch crítico exige reinício de servidor que pode parar atendimento por 30 minutos.

• R: Infra propõe janela e plano de rollback.
• C: Segurança informa criticidade e risco de exploração.
• A: Dono do processo decide a janela (porque o impacto é no negócio), com base em risco e tolerância operacional.
• I: Atendimento/Operações é informado para preparar comunicação interna.

Critério: se houver exploração ativa, a janela pode ser emergencial; se não houver, pode ir para janela de manutenção acordada, com prazo máximo.

Artefatos mínimos para sustentar o modelo (sem virar papelada)

Mapa de donos (sistemas e informações)

Uma lista simples: sistema → dono do sistema → dono do processo → dono da informação (quando aplicável). Isso resolve rapidamente “quem aprova” e “quem responde”.

Registro de decisões (log de governança)

Uma planilha ou ferramenta com: decisão, data, responsável (A), participantes, critérios usados, prazo/expiração, evidências. Útil para auditoria e para evitar rediscutir o mesmo tema.

Modelos padronizados

• Formulário de exceção de controle (com prazo e compensações).
• Termo de aceite de risco (com risco residual e responsável).
• Checklist de acesso privilegiado (conta nominativa, MFA, expiração, logging).
• Checklist de onboarding de fornecedor (escopo de dados, acesso, requisitos contratuais).

Erros comuns e como corrigir rapidamente

“Segurança aprova tudo”

Quando segurança vira aprovadora universal, cria gargalo e assume accountability indevida. Correção: segurança define critérios e valida requisitos mínimos; o dono do processo/sistema aceita impactos e riscos residuais.

“Comitê para qualquer coisa”

Se tudo vai para comitê, nada anda. Correção: estabeleça limites (thresholds) para escalonamento e delegue decisões operacionais com critérios claros.

RACI com muitos A ou sem A

Dois A geram disputa; nenhum A gera paralisia. Correção: force um A por atividade/decisão e registre o racional.

Donos “de fachada”

Nomear dono que não tem autoridade ou tempo não resolve. Correção: alinhar autoridade mínima (priorização, aprovação, cobrança) e ajustar para quem realmente controla recursos e decisões.

Separação de funções ignorada em acessos privilegiados

Admin sem monitoramento e sem revisão é risco alto. Correção: dupla aprovação, expiração automática, logging centralizado e revisão periódica por alguém independente.