A nova versão traz HANA, Fiori, identidade híbrida e IA. A decisão que importa é se ruleset, papéis e conflitos de SoD de hoje merecem ser migrados como estão.
“Ter uma ferramenta de GRC não é o mesmo que ter governança de acessos. O upgrade é a melhor chance dos próximos anos de corrigir o que o modelo atual esconde.”
O SoD que não aparece no dashboard
Em agosto de 2025, a Super Micro Computer declarou, em seu relatório anual (Form 10-K) à SEC, que seus controles de segregação de funções “não foram adequadamente desenhados e implementados”, uma das quatro fraquezas materiais nos controles internos sobre o reporte financeiro. No SAPinsider Las Vegas 2026, a empresa e a PwC mostraram como resolveram o problema: em vez de remendar o que existia, redesenharam o ruleset e os perfis do zero, em cerca de quatro meses.
O caso ensina algo desconfortável: ter uma ferramenta de GRC não é o mesmo que ter governança de acessos. Um ruleset desatualizado gera falsos positivos e falsos negativos, e o relatório de risco segue “verde” enquanto o risco real se acumula.
É nesse contexto que chega o SAP GRC for SAP HANA 1.0, apresentado ao mercado como “SAP GRC 2026”. A SAP insiste: não é fim de vida nem produto novo que exige nova compra. É a próxima versão do GRC que as empresas já usam, reconstruída sobre SAP HANA e S/4HANA Foundation. A manutenção padrão da versão 1.0 vai até 31/12/2032, e a SAP sinaliza um horizonte de suporte da linha até 2040.
A disponibilidade geral (GA) veio em 31 de julho de 2026, com o Support Package 01, e o primeiro Feature Pack está previsto para o fim de 2026. Para quem opera o SAP Access Control 12.0, o relógio já está correndo: a manutenção padrão termina no fim de 2027, e a estendida vai até 2030. O caminho de upgrade depende de decisões de banco de dados, arquitetura e licenciamento que não se resolvem em uma janela de fim de semana.
A pergunta estratégica, então, não é “quando vamos fazer o upgrade”. É outra: sua empresa vai usar o GRC 2026 para migrar o mesmo modelo de acessos de sempre, ou para finalmente corrigir o que o modelo atual esconde?
Figura 1 — A janela de transição: marcos do GRC 12.0 e do SAP GRC for SAP HANA 1.0. Fontes: SAP Notes 3326989, 3710821 e 3709892.
Por que o tema ficou urgente agora
Três gatilhos convergem em 2026 e 2027.
Tecnológico. O servidor do SAP GRC for SAP HANA 1.0 exige SAP S/4HANA Foundation 2025 (standalone) ou SAP S/4HANA 2025 (embarcado). Os sistemas gerenciados, porém, não precisam ir para 2025: a SAP publicou plugins da nova versão para releases anteriores, do EHP7 ao S/4HANA 2023, além do NetWeaver 7.4 e superiores. Os componentes GRCFND_A e SAPFRA dão lugar ao novo SAPGRC 100 (com UISAPGRC para o Fiori), e o upgrade é planejado como desinstalação/instalação no Maintenance Planner. GRC 12.0 e a nova versão não podem coexistir no mesmo sistema. Quem está em banco não-HANA precisa converter o banco de dados junto com o upgrade.
Contratual. Clientes do GRC 12.0 “for S/4HANA” recebem a nova versão pela manutenção padrão, sem nova SKU. Clientes da versão “clássica” em banco não-HANA precisam migrar e, segundo a SAP, converter o contrato para as entitlements S/4HANA como pré-requisito.
Regulatório. SOX, auditorias externas e a pressão por evidência contínua de controles de acesso não esperam o fim de um projeto de upgrade. Um upgrade mal planejado pode abrir uma janela em que o Firefighter, o workflow de solicitação ou a análise de risco simplesmente não estão disponíveis.
Nos projetos que conduzimos, vemos quatro falhas recorrentes:
- Tratar o upgrade como projeto de Basis. O SUM faz a parte técnica; ninguém revisa ruleset, workflows MSMP/BRF+ e mitigações.
- Ignorar a ordem da arquitetura. O GRC central deve ir primeiro. Os plugins 10.1/12.0 continuam compatíveis com o novo central (a SAP recomenda no mínimo o SP25), mas os novos plugins GRCPIBAS e GRCPIS4 100 só funcionam com a nova versão.
- Subestimar a mudança de interface. O NWBC deixa de ser suportado. A SAP entrega os catálogos técnicos do Fiori, mas não entrega catálogos de negócio para o GRC: cada empresa precisa desenhar os seus. Em outras palavras, o upgrade do GRC exige desenhar acessos ao próprio GRC.
- Carregar customizações sem inventário. A SAP orienta revisar, depois do upgrade, todos os workflows customizados (paths, stages, notificações, event linkage), que podem exigir ajuste manual. SPAU/SPDD, BAdIs e tabelas Z viram dívida técnica que só aparece no teste integrado.
O resultado é previsível: risco à segurança (acesso emergencial fora do ar), à governança (workflows quebrados), ao compliance (evidência de auditoria incompleta) e ao crescimento do negócio (projetos de S/4HANA atrasados por dependência do GRC).
O que muda de verdade no Access Control
O GRC 2026 não é só uma troca de versão. Para o Access Control, a SAP apresentou um conjunto claro de mudanças já entregues e outras planejadas.
Figura 2 — As mudanças mais relevantes para segurança, governança e auditoria. Fontes: SAP Note 3718627; SAP Help Portal.
Impacto estratégico. O GRC deixa de ser um “silo de SAP ECC” e passa a ser um ponto de governança para landscapes híbridas: S/4HANA, SuccessFactors (com ruleset para populações-alvo), apps de nuvem e Entra ID.
Impacto operacional. Atribuição em massa, inbox unificada e simulação de ruleset reduzem trabalho manual em manutenção de papéis e ruleset, onde as equipes de segurança costumam gastar mais tempo.
Impacto regulatório. O Read Access Log no EAM responde a uma pergunta frequente de auditoria e de proteção de dados: quem visualizou um dado sensível, como dados bancários de fornecedores, durante uma sessão privilegiada, e não só quem o alterou.
Figura 3 — Arquitetura de referência do Access Control for SAP HANA 1.0. Diagrama ilustrativo elaborado pela Trustsis a partir de documentação SAP.
Figura 4 — Buscador de apps do SAP GRC for SAP HANA 1.0 no Fiori Launchpad, com os apps organizados por papel: administrador, autorizador, empregado, gerente de segurança e responsável de conformidade. Ambiente de demonstração da Trustsis.
Figura 5 — Dashboard do GRC Access Control (Overview Page): violações de risco de acesso, conflitos de SoD por nível de risco e ações e funções críticas. Ambiente de demonstração da Trustsis, com volumes ilustrativos.
No roadmap apresentado pela SAP, e portanto sujeito a mudança, estão a solicitação de acesso assistida pelo Joule, com sugestão de papéis e justificativas em linguagem natural; a revisão periódica de acessos (UAR) com IA, que aponta acessos excessivos a partir de padrões de uso; e data products para o SAP Business Data Cloud. O calendário divulgado prevê Feature Packs e Support Packs anuais.
Três cenários práticos
Os cenários a seguir são ilustrativos, construídos a partir dos caminhos de upgrade documentados pela SAP.
Figura 6 — Três rotas para o SAP GRC Access Control for SAP HANA 1.0. Fontes: SAP Help Portal; SAP Notes 3677094 e 3736830; SAP KBA 3796471.
Cenário 1: indústria com GRC 12.0 for S/4HANA embarcado
- Contexto: GRC AC embarcado em S/4HANA 2020, já em HANA.
- Abordagem: upgrade conjunto para S/4HANA 2025 e GRC via Maintenance Planner e SUM (desinstalação/instalação, sem perda de dados), ativação dos BC Sets padrão, revisão dos workflows MSMP e desenho dos catálogos de negócio do Fiori.
- Ganho: sem nova licença; acesso às novidades de Fiori, analytics e Task Center.
- Risco mitigado: perda de suporte da 12.0 e dependência do NWBC. A janela de indisponibilidade é obrigatória: o Zero Downtime Option não é suportado nesse upgrade.
Cenário 2: instituição financeira com GRC 12.0 clássico em banco não-HANA
- Contexto: GRC standalone em outro banco, auditoria SOX anual, forte uso de Firefighter.
- Abordagem: conversão contratual primeiro. Depois, conversão de banco e upgrade em uma única execução (SUM DMO), ou migração para nuvem privada com parceiro certificado. Em RISE, o log de Firefighter no HANA depende de uma exceção na trilha de auditoria, que precisa ser solicitada.
- Ganho: plataforma com manutenção padrão até 2032 e Read Access Log para sessões privilegiadas.
- Risco mitigado: fim da manutenção padrão sem rota definida e janelas de indisponibilidade do acesso emergencial durante a auditoria.
Cenário 3: varejo com landscape híbrido (S/4HANA, SuccessFactors e Entra ID)
- Contexto: RH em SuccessFactors, identidades corporativas no Entra ID, apps de nuvem crescendo fora do SAP.
- Abordagem: Entra ID e Cloud Identity Services como fontes de usuários do GRC; análise de risco para SuccessFactors; apps de nuvem governados via SAP Cloud Identity Access Governance.
- Ganho: uma fonte de verdade para identidades e SoD consistente entre ERP e nuvem.
- Risco mitigado: conflitos de SoD entre sistemas que nenhuma ferramenta enxergava isoladamente.
Governança: o upgrade como oportunidade de reset
O caso apresentado no SAPinsider deixa uma lição: a empresa escolheu “refazer a fundação”, com ruleset, papéis e atribuições desenhados de novo, porque corrigir em cima do legado atrasaria a remediação. Seu princípio-guia vale para qualquer upgrade de GRC: começar pela boa prática e aceitar complexidade só por exceção.
Na prática, isso exige quatro papéis claros:
- Donos de processo de negócio: aprovam riscos do ruleset e mitigações.
- Donos de risco: decidem o apetite e aceitam riscos residuais.
- Segurança e TI: operam o GRC, os conectores e o provisionamento.
- Auditoria interna: valida a trilha de evidência antes e depois do upgrade.
A sustentabilidade vem de um ciclo simples: ruleset revisado ao menos uma vez por ano, UAR periódica, revisão de logs de Firefighter dentro de prazo definido e gestão de mudança do ruleset com aprovação formal. Esse ciclo se ancora em SOX ITGC (gestão de acessos lógicos), ISO/IEC 27001:2022, NIST CSF 2.0 e COSO ERM.
A agenda do líder
O upgrade para o GRC 2026 é uma decisão de negócio, não uma tarefa de Basis. Cinco decisões precisam de dono agora:
- Definir a rota: upgrade direto (HANA), conversão com DMO (não-HANA) ou migração para nuvem privada.
- Validar o licenciamento: confirmar com a SAP se as entitlements atuais cobrem a nova versão ou se há conversão contratual.
- Decidir entre migrar como está e fazer reset: avaliar a qualidade do ruleset e dos papéis antes de levá-los para a nova plataforma.
- Definir a janela à luz da auditoria: evitar indisponibilidade de EAM e ARM em períodos de fechamento e de testes de controle.
- Planejar a identidade híbrida: decidir o papel do Entra ID, do Cloud Identity Services e do IAG na arquitetura-alvo.
O papel da liderança é garantir que a pergunta “está funcionando?” seja substituída por “está correto?”.
Conclusão: a nova versão não corrige o modelo antigo
O SAP GRC for SAP HANA 1.0 moderniza o Access Control com plataforma HANA, Fiori, identidade híbrida, analytics e um roadmap de IA. A ferramenta, porém, não resolve sozinha o que um ruleset mal mantido esconde.
Líderes que tratarem o upgrade como mera atualização técnica vão levar os mesmos conflitos de SoD e acessos críticos para uma plataforma mais moderna. Quem o tratar como oportunidade de reset sai com uma fundação preparada para o próximo ciclo de suporte.
A decisão, e a responsabilidade pelo risco, é da liderança, não do cronograma de manutenção.
“Upgrade de GRC não é trocar a versão do software. É decidir se os conflitos de SoD e os acessos críticos de hoje vão junto.”