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 risco de acesso que não aparece no dashboard

Em 2025, uma fabricante de tecnologia com ações negociadas nos Estados Unidos admitiu, em seu relatório anual ao mercado, que seus controles de segregação de funções não haviam sido adequadamente desenhados nem implementados. Foi uma das fraquezas materiais apontadas em seus controles internos sobre o reporte financeiro. A saída não foi remendar o que existia: a matriz de riscos de acesso e os perfis foram redesenhados 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. Uma matriz de riscos 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 matriz de riscos, 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 matriz de riscos de acessos para populações-alvo), apps de nuvem e Entra ID.A

Impacto operacional. Atribuição em massa, inbox unificada e simulação de análise de riscos de acessos reduzem trabalho manual em manutenção de roles e riscos de acessos, 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 role: 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 roles 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: 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: 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: 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 matriz de riscos SOD/SAT, roles 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 da matriz de riscos 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: matriz de riscos revisada 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 da matriz de riscos 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:

1. Definir a rota: upgrade direto (HANA), conversão com DMO (não-HANA) ou migração para nuvem privada.
2. Validar o licenciamento: confirmar com a SAP se as entitlements atuais cobrem a nova versão ou se há conversão contratual.
3. Decidir entre migrar como está e fazer reset: avaliar a qualidade da matriz de riscos e dos roles antes de levá-los para a nova plataforma.
4. Definir a janela à luz da auditoria: evitar indisponibilidade de EAM e ARM em períodos de fechamento e de testes de controle.
5. Planejar a identidade híbrida: decidir o role 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 uma matriz de riscos 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.”