Checklist de segurança e compliance na avaliação de sistemas de RH

Por que segurança em sistemas de RH é crítica (e não é burocracia)

Muitas organizações, especialmente pequenas, veem compliance como obstáculo administrativo. A realidade é diferente. Um sistema de RH contém informações entre as mais sensíveis da empresa: dados pessoais, números de identidade, informações de saúde (para seguros), histórico de desempenho, salários e benefícios, histórico de conflitos. Uma violação de segurança não é apenas um incômodo técnico — é risco legal, reputacional e financeiro.

Sob LGPD (Lei Geral de Proteção de Dados), organizações podem ser multadas em até 2% de faturamento (máximo 50 milhões de reais) por violação. Para uma empresa pequena, uma multa assim é existencial. Além disso, a lei responsabiliza tanto o controlador (a empresa) quanto o operador (o fornecedor). Se seu sistema de RH sofre violação e você não verificou se havia controles de segurança básicos, responsabilidade é compartilhada. Segundo relatório de breach tracking do CERT.br, dados de RH estão entre os mais frequentemente alvo de ataques no Brasil — junto com dados financeiros e pessoais^[2].

A avalição de segurança não é sobre paranoia ou paralisia por análise. É sobre fazer perguntas certas, entender o que você está contratando, e garantir que fornecedor tem controles básicos — não avançados, mas básicos.

O panorama regulatório: LGPD, GDPR, CCPA e regulações setoriais

LGPD (Lei Geral de Proteção de Dados): Lei brasileira de 2018, em vigor desde agosto 2020, que regula processamento de dados pessoais. Aplicável a qualquer organização que coleta, processa ou armazena dados de indivíduos no Brasil — independentemente de tamanho. Exige: consentimento (com exceções para dados de funcionários); direito de acesso, correção, exclusão de dados (DSAR — Data Subject Access Requests); notificação obrigatória de breaches à Autoridade Nacional de Proteção de Dados (ANPD) em até 72 horas; programas de segurança documentados; responsabilização clara entre controlador e operador.

GDPR (General Data Protection Regulation): Regulação europeia, em vigor desde 2018, aplicável a organizações que processam dados de residentes da UE. Multas chegam a 20 milhões de euros ou 4% de faturamento (o que for maior). Requisitos similares a LGPD, mas com enforcement mais rigoroso. Se sua empresa tem subsidiária na Europa ou clientes europeus, GDPR é obrigatório.

CCPA (California Consumer Privacy Act): Lei de privacidade da Califórnia, aplicável a empresas que coletam dados de residentes da Califórnia com faturamento acima de USD 25 milhões. Menos rigorosa que GDPR, mas obrigatória para empresas grandes com presença na Califórnia.

Regulações setoriais: Organizações em setores específicos têm requisitos adicionais. Instituições financeiras devem cumprir resoluções do Banco Central; fundos de pensão (LGPS) têm requisitos de segurança específicos; saúde tem HIPAA (se atuação nos EUA) ou Lei Geral de Proteção de Dados de Saúde no Brasil. Se sua organização está em setor regulado, essas regulações devem estar presentes na RFP de sistema de RH.

Certificações de segurança: o que cada uma atesta e o que não atesta

Quando avaliar um fornecedor, a pergunta "você tem ISO 27001?" virou tão comum quanto "você tem HTTPS?". Mas nem todas as certificações são iguais, e ter uma certificação não significa que fornecedor está realmente seguro — significa apenas que foi auditado em determinado momento contra critério específico.

ISO/IEC 27001 (Information Security Management System): Padrão internacional de gestão de segurança da informação. Fornecedor auditado deve demonstrar que tem programa documentado de segurança — política, controles, monitoramento. A certificação é válida por 3 anos, com auditorias intermediárias anuais. É baseline: praticamente qualquer fornecedor de HCM sério tem. O que ela NÃO garante: que todos os controles funcionam perfeitamente; que fornecedor nunca sofreu (ou sofrerá) violação; que sistema específico de RH foi auditado (é auditoria de programa geral, não de produto). Útil: valida que fornecedor leva segurança a sério.

SOC 2 Type II (Service Organization Control): Auditoria de controles de segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade. Type II é mais rigoroso que Type I porque avalia controles ao longo de período (6-12 meses), não em snapshot. Para fornecedores de software SaaS, SOC 2 Type II é padrão ouro — atesta que controles de segurança funcionam na prática, não apenas em papel. Relatório de SOC 2 (Auditor's Report) é documento que pode ser compartilhado com clientes sob NDA. O que NÃO garante: conformidade legal (ex: LGPD — SOC 2 é sobre segurança técnica, não conformidade regulatória); que não há vulnerabilidades; que fornecedor faz penetration testing regularmente.

ISO/IEC 27018 (Personal Data Protection in Cloud): Extensão de ISO 27001 focada em proteção de dados pessoais em ambiente cloud. Relevante se sistema de RH está em infraestrutura cloud (público ou privado). Atesta que fornecedor tem controles específicos para dados pessoais em cloud (segregação, criptografia, conformidade GDPR). Menos comum que ISO 27001 ou SOC 2, mas cada vez mais exigido por empresas que priorizem privacidade.

BSI C5 (Cloud Computing Compliance Criteria Catalog): Certificação alemã de segurança em cloud, reconhecida na Europa. Se sistema de RH está hospedado em infraestrutura na Alemanha ou Europa, C5 pode ser exigido por conformidade regulatória. Menos relevante para contexto brasileiro, a menos que empresa tenha presença significativa na Europa.

PCI DSS (Payment Card Industry Data Security Standard): Se sistema de RH processa dados de cartão de crédito (ex: cartão corporativo para despesas), PCI DSS é obrigatório. Nem sempre relevante para HCM, a menos que integração com sistema de despesas seja incluída.

Arquitetura de segurança: as camadas que importam

Certificações garantem avaliação externa, mas entender arquitetura de segurança do sistema é fundamental. Três camadas definem segurança prática em sistema de RH: acesso, dados e auditoria.

Autenticação e Autorização (Gestão de Acesso): Quem pode acessar dados de RH e o quê? Sistema deve implementar: (1) Autenticação forte — login com senha + segundo fator (autenticação multifator). Senhas em plaintext ou sem MFA é risco inaceitável. (2) Segregação de funções — RH vê dados de RH; financeiro vê folha; gestores veem apenas dados de equipes diretas. É princípio "least privilege": cada usuário tem acesso apenas ao mínimo necessário para sua função. (3) Controle de acesso por data — antiga prática de "RH tem acesso a tudo" é insegura. Mesmo em RH, nem todos precisam ver salários de todos. (4) Revogação de acesso imediata — quando funcionário sai, acesso é removido em minutos, não dias. Uma pessoa que saiu não deveria conseguir acessar sistema por "esquecimento" de revogar credenciais.

Criptografia de Dados: Dados pessoais e sensíveis devem estar protegidos em duas situações: em repouso (dados armazenados no servidor) e em trânsito (dados viajando pela rede). Para dados em repouso: criptografia de banco de dados com chave gerenciada de forma segura (não chave "padrão"). Para dados em trânsito: HTTPS/TLS com versão moderna (TLS 1.2 no mínimo, 1.3 preferível). Muitos sistemas dizem "temos criptografia" mas implementam de forma fraca — é importante validar padrão de criptografia específico e quem gerencia chaves (fornecedor vs. cliente pode usar sua própria chave — BYOK).

Logging e Auditoria: Sistema deve manter log detalhado de quem acessou quê e quando. Logs permitem: (1) Detectar acesso não autorizado ou anômalo ("por que RH financeiro acessou dados de salário de todos ontem à noite?"). (2) Investigar incidentes ("quem alterou data de saída daquele funcionário?"). (3) Cumprir obrigações de compliance (regulador pode solicitar logs de auditoria). Logs devem ser imutáveis (não podem ser deletados facilmente) e protegidos de acesso não autorizado. Mínimo aceitável: logs de 90 dias; ideal: 1-2 anos dependendo regulação.

Gestão de dados: ciclo de vida e responsabilidade

Além de proteger dados enquanto estão sendo usados, é crítico entender como fornecedor lida com todo ciclo de vida: coleta, armazenamento, backup, exclusão.

Coleta de dados: Que dados são coletados? É possível o cliente controlar o escopo (ex: não coletar dados de saúde se não for necessário)? Dados devem ser coletados com base em finalidade clara e consentimento apropriado (incluindo consentimento de funcionários onde obrigatório).

Armazenamento: Onde dados são armazenados (geograficamente e em infraestrutura de quem)? Se LGPD é regra, dados devem estar armazenados no Brasil (com exceção de cópia de backup). Se GDPR se aplica, dados de europeus devem estar em data centers na Europa. Alguns fornecedores armazenam tudo em AWS US ou outro data center global sem considerar regulações de residência de dados.

Backup e recuperação de desastre (RTO/RPO): Qual é a política de backup? Com que frequência? Onde são mantidos backups? Se data center falha, qual o tempo para recuperação (RTO — Recovery Time Objective) e quanto de dados se perde (RPO — Recovery Point Objective)? Um RTO de 24 horas pode ser aceitável para muitas funções de RH, mas perda de 24 horas de dados (RPO 24h) é arriscada. Ideal: RPO de horas, RTO de até 4 horas para dados críticos.

Retenção de dados: Por quanto tempo dados são armazenados? LGPD exige que dados sejam mantidos apenas enquanto necessário. Histórico de funcionário ativo deve ser mantido enquanto ativo + período legal (ex: 5 anos após saída para fins fiscais e trabalhistas). Dados sensíveis (ex: saúde, motivo de saída relacionado a saúde) podem ter retenção mais curta. Política clara evita manutenção desnecessária de dados e reduz risco de vazamento de dados antigos.

Exclusão e anonimização: É possível solicitar exclusão de dados (direito de esquecimento conforme LGPD/GDPR)? Como fornecedor processa solicitação — é exclusão completa ou apenas anonimização? Se cliente sai, como dados são deletados — imediatamente ou apenas após período de retenção? Fornecedor atesta que exclusão foi realizada?

Gestão de terceiros e subcontratados

Não é incomum que sistema de RH do fornecedor dependa de múltiplos terceiros: cloud provider (AWS, Azure, Google Cloud), provedores de segurança, fornecedores de suporte técnico terceirizado. A pergunta é: quem mais tem acesso aos seus dados?

Cloud providers: Se sistema está em AWS, Azure ou Google Cloud, esses providers têm acesso em nível de infraestrutura. Dados devem estar criptografados para que cloud provider não leia conteúdo — mas technicamente, servidor do cloud provider hospeda dados. Contrato deve estar claro sobre responsabilidade: cloud provider é responsável por segurança de infraestrutura; fornecedor de HCM é responsável por aplicação e criptografia. Importante: validar se fornecedor está usando shared infrastructure ou dedicated — para dados sensíveis, dedicado é preferível.

Provedores de suporte técnico terceirizado: Fornecedor faz suporte interno ou terceiriza? Se terceiriza, quem tem acesso a quais dados? Suporte pode ver dados do sistema para troubleshooting? Há contratos com fornecedor de suporte garantindo confidencialidade? É possível restringir acesso de suporte (ex: suporte não vê dados pessoais, apenas logs técnicos)?

Integradores de dados e parceiros de implementação: Frequentemente, implementação de sistema de RH envolver parceiros integradores. Esses parceiros precisam acessar dados para implementar? Por quanto tempo têm acesso? Após implementação, acesso é revogado?

A resposta correta é: fornecedor conhece seus terceiros, tem contrato explícito com cada um, há segregação de responsabilidades (quem é responsável pelo quê), e cliente é informado sobre quem tem acesso.

Plano de resposta a incidentes de segurança

Nenhum sistema é 100% seguro. A pergunta não é "vocês já sofreram ataque?" (todos já sofreram). É "se acontecer, o que vocês fazem?"

Detecção: Como fornecedor detecta incidente? Há monitoramento 24/7 de segurança? Quem detecta — sistema automático ou pessoa? Tempo típico de detecção (idealmente minutos, não dias).

Resposta imediata: Ao detectar, o que fornecedor faz? Isola sistema? Mantém evidência forense? Ativa plano de resposta? Tempo típico de resposta (idealmente <1 hora).

Investigação: Quem investiga incidente? É equipe interna ou terceirizada? Qual é o escopo — determinar origem, amplitude (quantas pessoas/dados foram afetados), impacto?

Notificação ao cliente: Se violação afeta dados do cliente, como fornecedor notifica? Por qual canal (email, portal, telefone)? Em que tempo (LGPD exige notificação imediata, idealmente em horas, no máximo dias)? Que informação é compartilhada (o quê foi afetado, quantas pessoas, que ações tomar)?

Notificação a regulador: Em LGPD, se violação é de alto risco, ANPD deve ser notificada em até 72 horas. Fornecedor é responsável? Cliente é responsável? Ambos? Responsabilidade deve estar clara no contrato.

Comunicação pública: Se incidente é significante, pode haver necessidade de comunicação pública. Quem determina se comunicação é necessária? Fornecedor tem media training? Cliente pode revisar comunicação antes de ser divulgada?

Um plano robusto de resposta a incidente não previne incidente, mas reduz tempo de resposta e dano. Fornecedor deve ter plano documentado, testado regularmente (exercício simulado pelo menos anualmente), e compartilhar com clientes grandes.

Checklist prático de perguntas para RFP de sistemas de RH

Abaixo, template de perguntas para avaliar segurança e compliance de fornecedor de HCM. Adapte conforme seu porte e setor.

Certificações e conformidade:

• Seu sistema tem certificação ISO/IEC 27001? Se sim, qual é a data de validade? Quem auditou?
• Seu sistema tem certificação SOC 2 Type II? Se sim, qual é a data do relatório? É possível compartilhar cópia sob NDA?
• Seu sistema está em conformidade com LGPD? Com que metodologia foi avaliada conformidade?
• Se clientes estão na Europa, está em conformidade com GDPR? Tem Data Processing Agreement padrão?
• Se clientes estão em setores regulados, tem conformidade setorial (ex: LGPS para fundo de pensão, resoluções BC para banco)?
• Seu sistema sofreu penetration testing ou vulnerability assessment nos últimos 12 meses? Qual foi o escopo e resultado?

Arquitetura de acesso e autenticação:

• Autenticação multifator (MFA) é obrigatória? É opcional? É possível exigir MFA para todos os usuários?
• Como seu sistema implementa segregação de funções (ex: RH não vê salários, gestor vê apenas sua equipe)?
• Qual é seu SLA para revogação de acesso quando funcionário sai da empresa?
• É possível integrar com SSO corporativo (SAML, LDAP)? Qual é o tempo de implementação?
• Como auditaria a revogação de acesso após desligamento?

Criptografia e proteção de dados:

• Qual é o padrão de criptografia usado para dados em repouso? (esperado: AES-256 ou equivalente)
• Qual é o padrão de criptografia para dados em trânsito? (esperado: TLS 1.2+)
• Quem gerencia as chaves de criptografia — vocês ou cliente? É possível usar chave do cliente (BYOK)?
• Com que frequência vocês fazem rotação de chaves de criptografia?
• Dados sensíveis (ex: dados de saúde, dados de salário) têm criptografia adicional?

Gestão de dados:

• Onde estão armazenados os dados geograficamente? (importante para LGPD/GDPR — dados do Brasil devem estar no Brasil)
• Qual é a política de backup? Com que frequência? Onde backups são mantidos?
• Qual é o RTO (Recovery Time Objective) e RPO (Recovery Point Objective) de seu sistema?
• Por quanto tempo vocês mantêm dados do cliente após cancelamento do contrato?
• Como cliente solicita exclusão de dados (direito de esquecimento)? Qual é o SLA?
• Vocês fornecem comprovação de exclusão de dados (certificado de destruição)?

Logging e auditoria:

• Por quanto tempo vocês mantêm logs de auditoria? (mínimo: 90 dias; ideal: 1-2 anos)
• Qual é o detalhe dos logs? (devem incluir: quem acessou, o quê, quando, de onde)
• Logs são imutáveis (não podem ser apagados)?
• É possível cliente exportar logs para auditoria própria?
• Há alertas para atividades anômalas (ex: acesso fora de horário, acesso de múltiplas localizações)?

Terceiros e subcontratados:

• Qual é a sua cloud provider (AWS, Azure, Google Cloud)? Qual região?
• Dados estão em infrastructure compartilhada ou dedicada?
• Que fornecedores terceiros têm acesso a dados? (ex: provedores de suporte, ferramentas de segurança)
• Há contrato de confidencialidade com cada terceiro?
• É possível cliente opor-se a uso de terceiro específico?

Incidentes e resposta:

• Vocês têm plano documentado de resposta a incidentes de segurança?
• Qual é o tempo médio de detecção de incidente? (idealmente minutos)
• Qual é seu SLA de notificação ao cliente após detecção? (idealmente horas)
• Como vocês mantêm sigilo durante investigação de incidente?
• Vocês contratam terceiro independente para investigação forense de incidentes?
• Quem é responsável por notificação a órgãos reguladores (ANPD para LGPD)?
• Vocês testam seu plano de resposta a incidente regularmente? (exercício simulado)

Contrato e responsabilidade:

• Há cláusula clara de responsabilidade compartilhada (o que é responsabilidade do cliente vs. fornecedor)?
• Qual é o prazo de notificação de mudanças de segurança (ex: novo terceiro, mudança de região de dados)?
• Há cláusula de auditoria de segurança — cliente pode auditar fornecedor? Com que frequência?
• Qual é a política de retenção de dados após término do contrato?
• Há cláusula de indenização em caso de violação de segurança?