SAP GRC and SAP S/4HANA: Better Together

ERP modernization is often measured by what changes inside the system: redesigned processes, a new data model, faster transactions, better analytics, and a more modern user experience. But there is another layer that can determine whether the transformation is actually ready for production: governance.

Organizations can modernize SAP S/4HANA while leaving access models, segregation-of-duties rules, approval structures, control ownership, and compliance processes largely unchanged. That creates a gap between the architecture the business is moving toward and the governance model designed for the environment it is leaving behind.

This is why SAP GRC S/4HANA planning should not be treated as a post-migration activity. As S/4HANA centralizes critical financial, operational, procurement, and enterprise processes, organizations need greater visibility into who can perform sensitive actions, how responsibilities are separated, how exceptions are managed, and how control evidence is produced.

This article focuses on that relationship rather than providing a basic introduction to SAP GRC. For foundational context, see the SAP GRC pillar. The focus here is the governance challenge created by S/4HANA transformation itself: migration risk, role and permission changes, segregation of duties, control redesign, audit continuity, governance architecture, testing, and post-go-live monitoring.

Governance is not an obstacle to modernization. When designed correctly, it is part of what makes modernization safe, scalable, and operationally sustainable.

Why ERP modernization changes the governance problem

An S/4HANA program is rarely a simple technical replacement. In most large organizations, it involves changes to business processes, organizational responsibilities, integrations, data structures, roles, and operating models.

That matters because governance is closely tied to how work gets done.

A procurement process may be redesigned so that fewer people are involved. Finance responsibilities may be consolidated. Approval workflows may become more automated. A previously separate application may become integrated with the ERP. A business unit may adopt a shared-services model.

Each of these changes can alter the risk profile.

A role that was appropriate in a legacy environment may provide excessive access in the target environment. A segregation-of-duties rule may no longer reflect the redesigned process. A control owner may have changed. An approval that previously required manual intervention may now happen through an automated workflow.

Organizations therefore need to evaluate governance as part of the target architecture, not as an additional layer applied after the architecture is complete.

For a broader view of how enterprise technology modernization connects platforms, processes, and operating models, see Enterprise Platforms. In that context, governance becomes part of the platform strategy rather than a separate compliance exercise.

Why legacy controls do not automatically fit the new environment

Legacy controls are usually designed around a specific combination of roles, transactions, responsibilities, applications, and workflows. When those elements change, the controls need to be reassessed.

Several changes are particularly important during S/4HANA transformation:

• Role redesign: New business roles may combine responsibilities that were previously separated across multiple legacy roles.
• Changed process ownership: a redesigned process can move accountability from one team to another, leaving old control ownership models outdated.
• Consolidated responsibilities: shared services and centralized operating models can create new combinations of access that did not exist previously.
• New approval flows: automated or redesigned approvals can change where authorization takes place.
• Obsolete legacy permissions: technical conversion or role migration can leave users with privileges that no longer have a business purpose.
• Control gaps: process simplification can remove manual checkpoints without introducing an equivalent control elsewhere.
• Inherited assumptions: teams may carry forward old governance assumptions simply because they were accepted in the previous environment.

The important distinction is between migrating an access model and validating an access model.

A migration can move roles successfully from one environment to another while still carrying forward unnecessary permissions, outdated responsibilities, or ineffective controls. Functional migration success does not, by itself, demonstrate governance readiness.

Where access risk emerges during migration

Access risk becomes particularly difficult during an S/4HANA program because the environment is changing while the organization still needs to operate.

Project teams need access to configure and test the system. Business users need new roles. Contractors may require temporary permissions. Integrations need technical identities. Privileged users may need elevated access for specific activities. At the same time, legacy environments may remain active during transition.

This creates a moving access landscape.

The core SAP S/4HANA access risk challenge is therefore not limited to the final production role design. It extends across the migration lifecycle, from project environments to cutover and stabilization.

Common sources of risk include:

• Redesigned business roles;
• Temporary project access;
• Duplicate or accumulated permissions;
• Conflicts created by consolidated responsibilities;
• Legacy roles copied into the target environment;
• Contractor and partner access;
• Emergency and privileged access;
• Incomplete access testing late in the program.

The earlier these issues are identified, the more options the organization has to resolve them without disrupting business operations.

For deeper context on access governance and segregation of duties, the SAP GRC pillar provides the broader foundation. Within an S/4HANA program, however, the key question is more specific: does the target access model reflect how the organization will actually operate after go-live?

How segregation-of-duties conflicts can change during migration

Segregation of duties (SoD) is especially sensitive to process redesign because SoD rules are based on combinations of responsibilities.

Consider a financial process where one person can create a vendor and another must approve a payment. If the target operating model consolidates procurement and accounts payable responsibilities, the access combination may change significantly.

The same applies to other financial activities. A user who can create and post journal entries may create a different risk profile from one who only prepares journals. A user who can modify sensitive master data and approve transactions may introduce a conflict that did not exist under the previous role structure.

During migration, organizations should therefore reassess:

• Transaction responsibilities;
• Role combinations;
• Approval authority;
• Sensitive master-data access;
• New integrations;
• Redesigned business processes;
• Organizational changes.

An SoD rule set based on the previous environment should be treated as an input to the redesign, not as the final answer.

This does not mean every theoretical conflict must be eliminated. The objective is to identify material business risk, determine whether the access is genuinely required, and establish appropriate remediation or mitigating controls where necessary.

Why access remediation should happen before go-live

Discovering an access conflict after production launch creates a different operational problem from discovering it during design or testing.

Once users depend on the new environment, removing access can affect business continuity. Teams may need emergency changes. Project accounts may remain active longer than planned. Business leaders may face pressure to weaken controls because a user cannot complete a critical task.

That is why remediation should happen before go-live whenever practical.

The goal is not to produce a perfectly conflict-free environment at any cost. It is to make informed decisions about risk before production access is deployed.

A practical remediation approach prioritizes high-risk issues, confirms ownership, documents accepted exceptions, and ensures that critical business processes can operate without relying on uncontrolled emergency access.

This approach also supports broader Enterprise Platforms modernization efforts, where security, governance, architecture, and operational readiness need to work together rather than being managed as isolated activities.

How governance should be built into the migration program

Governance becomes more effective when it follows the same lifecycle as the migration itself.

Instead of creating a separate compliance workstream that becomes active near the end of the project, organizations can connect governance requirements to discovery, process design, architecture, build, testing, cutover, and production operations.

A governance-oriented migration lifecycle should address:

• Governance requirements during discovery;
• Control mapping during process redesign;
• Access and role design;
• SoD analysis;
• Control ownership;
• Testing and validation;
• Remediation;
• Go-live criteria;
• Post-go-live monitoring.

This structure helps turn governance into a delivery requirement. The question is no longer whether the project has completed its GRC activities, but whether the target environment is capable of operating with appropriate controls.

For organizations planning broader platform modernization, Enterprise Platforms provides additional context on connecting enterprise architecture and transformation strategy.

Governance during discovery and design

Governance decisions become more difficult when they are postponed because the assumptions behind the target architecture have already been established.

During discovery, teams should identify the processes and access patterns that carry the greatest business or regulatory risk. That includes financial close, procurement, payments, sensitive master data, privileged administration, and other activities where unauthorized actions could have material consequences.

The discovery phase should also surface:

• Critical business processes;
• Regulatory obligations;
• Sensitive permissions;
• Existing control weaknesses;
• Previous audit findings;
• Access exceptions;
• Control owners;
• Manual workarounds.

For regulated organizations, these questions should be considered alongside the broader transformation strategy. The Digital Transformation in Banking and Financial Services perspective is particularly relevant because modernization in financial services must balance technology change with operational resilience, auditability, and regulatory expectations.

The output should be more than a list of requirements. It should establish the governance assumptions that the target operating model and system design need to support.

Governance during build and testing

Governance requirements should be validated alongside functional requirements.

A role can successfully execute a business process and still create an unacceptable access combination. An approval workflow can function correctly while granting authorization to the wrong population. A technical integration can transfer transactions successfully while bypassing an expected control boundary.

Testing therefore needs to examine both what users can do and what they should be able to do.

Relevant scenarios include:

• Role and authorization testing;
• SoD analysis;
• Access-request workflows;
• Control execution;
• Evidence generation;
• Negative testing;
• Privileged-access scenarios;
• Regression testing after role or process changes.

Negative testing is particularly useful. Instead of testing only whether an authorized user can complete a transaction, teams should also test whether unauthorized users are prevented from performing sensitive actions.

This creates a stronger connection between security requirements, business controls, and production readiness.

Governance before go-live

Governance readiness should be treated as part of the go-live decision, not as documentation that can be completed afterward.

Leadership should have visibility into unresolved access conflicts, exceptions, control ownership, and temporary privileges before production launch.

A practical readiness review should validate:

• Unresolved critical access conflicts;
• Approved mitigating controls;
• Privileged access;
• Temporary migration accounts;
• Control ownership;
• Audit evidence;
• Access-certification readiness;
• Support procedures;
• Escalation paths.

This gives executives a more useful picture than a simple statement that "security testing is complete."

The objective is to understand whether known risks have been addressed, accepted, or appropriately controlled before the organization becomes dependent on the new environment.

Why process modernization increases the need for control visibility

S/4HANA modernization can make processes faster and more integrated. That is one of its core benefits. But greater integration can also increase the impact of a wrong or unauthorized action.

When fewer manual handoffs exist, a transaction can move through several stages more quickly. When more data is centralized, a single access decision can affect more business processes. When automation increases, there may be fewer people reviewing each individual transaction.

The result is not that modernization creates inherently higher risk. It means that the organization needs a governance model capable of operating at the same speed and scale as the new environment.

As process integration increases, leaders need visibility into:

• Connected business processes;
• Centralized data;
• Automated transactions;
• Authorization boundaries;
• Exceptions;
• Downstream effects;
• Audit trails.

Governance must evolve with the process architecture.

Automation does not eliminate control requirements

Automation changes where controls operate. It does not eliminate the need for them.

An automated approval workflow may reduce manual effort, but the organization still needs to know who can approve, under which conditions, and how exceptions are handled.

Similarly, automated processes require clear ownership. When a process executes without direct human intervention, accountability cannot become ambiguous.

Effective governance for automated workflows should consider:

• Automated approvals;
• Exception handling;
• Control ownership;
• Authorization boundaries;
• Audit trails;
• Human intervention for high-risk scenarios;
• Accountability for automated decisions.

This becomes even more important when S/4HANA is extended through custom applications and integrations. Additional software can introduce new authorization paths that are not visible from the standard SAP user experience. Organizations evaluating these extensions can also review Custom Software Development Services to understand the broader implications of custom enterprise software.

How custom applications and integrations affect governance

An S/4HANA environment rarely exists in isolation.

Enterprise architectures often include APIs, middleware, custom applications, data platforms, identity services, third-party systems, and external partners. A business process may begin outside SAP, pass through several integration layers, and ultimately create or modify data in S/4HANA.

Governance therefore needs to follow the business process across system boundaries.

This includes consideration of:

• Custom extensions;
• External applications;
• Middleware;
• Service accounts;
• APIs;
• Technical users;
• Third-party integrations;
• Identity propagation;
• Control ownership across platforms.

The relevant question is not simply, "Who has access to SAP?"

It is, "Who or what can initiate, authorize, modify, or complete this business action across the entire transaction path?"

That distinction is critical for modern enterprise environments.

Organizations building or extending this architecture should consider Custom Software Development Services alongside governance requirements so that application design and access control are addressed together.

Why custom development can create new access paths

Custom applications can expose functionality or data through channels that do not map neatly to standard SAP role structures.

For example, an external application may use a service account to initiate transactions through an API. Middleware may pass an identity between systems. A custom approval application may determine whether a transaction can proceed before it reaches the ERP.

These mechanisms can create access paths that are difficult to identify through traditional user-role analysis alone.

Governance should therefore consider:

• Service accounts and their ownership;
• API credentials;
• Technical permissions;
• Custom approval workflows;
• Externally initiated transactions;
• Identity models across applications.

The complete transaction path matters because a control can be technically present in one system while being bypassed through another integration.

Compliance risks financial organizations should prioritize

For banks, insurers, and other regulated organizations, the governance implications of an S/4HANA transformation can extend beyond access administration.

The priority should not be to create a catalog of every possible regulatory requirement. Instead, organizations should identify the governance failures most likely to create operational, financial, or audit exposure during modernization.

These commonly include:

• Excessive access;
• SoD conflicts;
• Privileged access;
• Incomplete audit trails;
• Inconsistent approval workflows;
• Temporary project access that remains active;
• Unclear control ownership;
• Undocumented exceptions;
• Inconsistent controls between legacy and target environments.

The right priority depends on the organization, its regulatory obligations, its operating model, and the processes being migrated.

For financial institutions, these considerations should form part of the wider Digital Transformation in Banking and Financial Services strategy rather than being handled as an isolated compliance exercise.

Why audit continuity matters during migration

Migration creates a period in which governance can operate differently across multiple environments.

Controls may work one way in the legacy system and another way in S/4HANA. Some processes may temporarily run in parallel. Responsibility may move between teams. Compensating controls may be introduced for a limited period.

These changes need to be documented.

Audit continuity depends on being able to explain not only what control exists after migration, but how the organization moved from the old control environment to the new one.

That can require evidence showing:

• How access changes were approved;
• Why a control changed;
• Who accepted a risk;
• How temporary controls operated;
• When responsibilities changed;
• How evidence was retained across environments.

The objective is traceability. A successful migration should leave the organization able to demonstrate how governance evolved, not simply that a new system went live.

Greenfield, brownfield, and selective transformation governance

Governance priorities also depend on the migration approach.

A greenfield implementation creates more freedom to redesign roles and controls. A brownfield approach can preserve valuable business configuration, but it may also carry forward historical access complexity. Selective transformation introduces another challenge: governance may need to remain consistent across migrated and retained processes.

The governance strategy should therefore reflect the transformation model rather than applying the same remediation approach to every program.

Brownfield risk and inherited access complexity

A technical conversion does not automatically modernize governance.

Brownfield programs may inherit roles, permissions, exceptions, and control assumptions that accumulated over years of organizational change. Some may still be necessary. Others may reflect responsibilities, transactions, or organizational structures that no longer exist.

Before production, teams should look for:

• Inherited roles;
• Obsolete permissions;
• Historical exceptions;
• Accumulated access;
• Outdated SoD assumptions;
• Remediation opportunities.

The objective is not to treat every legacy permission as a problem. It is to distinguish necessary business access from access that exists because no one revisited it.

That distinction becomes increasingly valuable as organizations move toward more standardized and scalable operating models.

Greenfield opportunities to redesign governance

Greenfield implementations provide a different opportunity: governance can be designed around the target operating model from the beginning.

Rather than asking how existing roles should be copied, teams can ask what access the redesigned processes actually require.

This can support:

• Role design aligned with target processes;
• Clearer ownership;
• Cleaner access models;
• Modern approval workflows;
• Control automation;
• Consistent evidence requirements.

The benefit is not simply a cleaner security model. It can also reduce the amount of remediation required later and make the environment easier to operate as the organization grows.

How to measure governance readiness before go-live

Senior leaders need more than assurances that governance activities are "on track." They need measurable indicators that show whether the target environment is ready.

Governance readiness can be assessed through metrics that connect access, controls, remediation, and operational risk.

Useful measures include:

• Number of unresolved critical SoD conflicts;
• Percentage of roles reviewed;
• Percentage of sensitive-access scenarios tested;
• Number of outstanding mitigating controls;
• Number of temporary privileged accounts;
• Percentage of control owners confirmed;
• Number of unresolved audit findings affecting migration;
• Percentage of high-risk processes with validated controls;
• Number of outstanding access-remediation items;
• Time required to produce audit evidence.

These measures become more useful when tracked over time rather than reported as a single go-live snapshot.

A declining number of critical conflicts, increasing role-review coverage, and faster remediation can provide stronger evidence of readiness than a simple completion percentage.

Which governance metrics should continue after go-live

Go-live is the beginning of the operating model, not the end of governance.

Once the new environment is in production, roles will continue to change. Employees will join and leave. Business processes will evolve. New applications will be integrated. Exceptions will emerge.

Post-go-live governance should therefore continue to monitor:

• New SoD conflicts;
• Privileged-access activity;
• Access-review completion;
• Unresolved exceptions;
• Access-request cycle time;
• Control failures;
• Remediation time;
• Repeat audit findings;
• Role changes;
• Orphaned or unnecessary access.

These metrics help organizations detect governance deterioration before it becomes a significant operational or compliance issue.

They also create a feedback loop between governance and ongoing transformation. As processes and applications change, the organization can assess whether its controls remain aligned with the operating model.

Common modernization mistakes to avoid

Many governance problems during S/4HANA programs are not caused by a lack of technology. They result from timing, ownership, or assumptions.

Senior transformation leaders should watch for several recurring patterns:

• Treating GRC as a post-go-live activity: waiting until production turns governance into a remediation exercise.
• Copying legacy roles without reassessment: technical continuity can preserve unnecessary access and outdated control assumptions.
• Involving compliance teams too late: governance requirements may become expensive to address once architecture and processes are already fixed.
• Designing controls separately from process redesign: controls can fail to reflect how the business actually operates.
• Overlooking custom integrations: APIs, service accounts, middleware, and external applications can create access paths outside the core SAP role model.
• Failing to clean up temporary project access: temporary permissions can become permanent if ownership and expiration are unclear.
• Focusing only on technical migration success: a system can migrate successfully while governance remains incomplete.
• Failing to define governance metrics: without measurable indicators, leaders have limited visibility into actual readiness.
• Assuming functional testing validates access risk: a process can work correctly while still allowing the wrong users to perform sensitive actions.

The common thread is treating governance as something that happens around the transformation rather than something designed into it.

How to build governance into a scalable operating model

The long-term objective is not simply to pass an audit after migration. It is to create a governance model that continues to work as the organization adds users, processes, applications, integrations, and regulatory obligations.

That requires clear ownership and repeatable processes.

A scalable operating model should establish:

• Sustainable role ownership;
• Recurring access reviews;
• Control ownership;
• Exception management;
• Continuous risk monitoring;
• Integration with change management;
• Governance for new applications and extensions;
• Operating metrics;
• Clear responsibility across business, IT, security, and compliance teams.

This approach prevents governance from becoming dependent on individual project teams or one-time migration activities.

For organizations managing complex technology environments, Enterprise Platforms provides a broader view of how architecture, integration, and operating models need to evolve together. In regulated environments, that perspective also connects naturally with Digital Transformation in Banking and Financial Services.

Governance as part of transformation ROI

Governance does not need to be positioned as a cost center to demonstrate its value.

Stronger governance can support modernization by reducing avoidable remediation work, improving accountability, and making operational processes more predictable.

Potential business benefits include:

• Lower remediation effort;
• Fewer audit disruptions;
• Reduced manual access-review effort;
• Faster onboarding and role approval;
• Clearer accountability;
• Lower probability of control failures;
• Easier expansion into new teams or business units.

Organizations should establish baseline metrics before transformation so that improvements can be measured after go-live.

For example, if access reviews currently require significant manual effort, the organization can measure the time involved before and after modernization. If remediation cycles are slow, baseline remediation time can provide a comparison point for the new operating model.

The objective is not to assign an artificial financial value to every control. It is to connect governance improvements with operational outcomes that leadership can actually track.

Frequently asked questions

Modernize SAP Governance Alongside S/4HANA

Modernizing an ERP platform without modernizing the governance around it leaves a critical part of the transformation unfinished.

SAP S/4HANA can centralize and accelerate critical financial, operational, procurement, and enterprise processes. That makes effective governance more important, not less. Organizations need clear visibility into access, segregation of duties, control ownership, exceptions, privileged activity, and audit evidence as the new environment becomes the foundation for business operations.

This is why SAP GRC migration should be connected to the transformation roadmap from discovery through post-go-live operations. Governance requirements should influence role design, process architecture, testing, remediation, go-live decisions, and the operating model that follows.

The strongest approach is not to treat GRC as a final compliance checkpoint. It is to build governance into the architecture and operating model from the beginning, while recognizing that different migration strategies, custom integrations, and regulated processes create different risk profiles.

Before go-live, decision-makers should ask a straightforward question: does the governance model reflect the environment the organization is actually moving into?

If the answer is not yet clear, it is worth addressing that gap before production rather than after it.

Talk to NTConsult about SAP governance modernization to discuss S/4HANA modernization, SAP GRC architecture, access-risk remediation, governance design, or integration requirements.