- Rising SAP GRC investment reflects a broader mandate to manage cybersecurity and transformation risk alongside compliance.
- Identity and access governance is gaining priority as organizations connect permissions to the business activities they enable.
- Access reviews must span SAP and connected applications to identify conflicting permissions held by the same identity.
- AI agents require oversight of both their access and their actions, with authorization based on delegated authority, intent, context, and risk.
- Continuous, application-aware governance helps teams address changing access risks and support SAP modernization and AI adoption.
A purchasing workflow moves to a new platform. An integration gains permission to update SAP records. An AI agent takes over a task that an employee used to perform. The business process may still produce the same result, even as the authority to change data or approve transactions shifts beneath it. Security and governance teams need to know whether the controls protecting that process still hold.
That challenge is becoming part of the Governance, Risk, and Compliance (GRC) mandate. Organizations modernizing SAP and adopting AI need to understand how technological changes affect business risk, including who or what can act within critical workflows. An access decision in one application can have consequences elsewhere in the process.
SAPinsider’s 2026 research reflects that broader responsibility. Seventy-two percent of respondents increased their GRC budgets, up from roughly 47% the previous year. The share citing cybersecurity, fraud, and risk exposure as a driver of GRC strategy rose from 56% to 68%. Meanwhile, technology and digital transformation risk became a higher priority: 33% expect to focus on it over the next 12–18 months, up from 13%.
Organizations are also committing to more integrated GRC environments. For access teams, that integration needs to reveal how permissions work together across a business process. As employees, service accounts, and AI agents share more of the work, understanding their combined authority becomes essential to deciding whether transformation is introducing risks that existing controls can manage.
Key takeaways:
Identity and access governance moves to the center of GRC
SAPinsider’s findings point to a growing emphasis on identity as organizations expand their GRC programs. Integrating identity, access, and entitlement governance rose from 38% to 54% as a strategic action, the largest increase among the actions measured. Integrated identity, access, and Segregation of Duties (SoD) governance also climbed from 14% to 40% as a requirement for executing GRC strategy, making it the second-most-cited requirement.
These priorities reflect an operational need. To assess risk in a critical business process, GRC teams need to know who or what can perform each action and what permissions they have. An account’s presence in a system tells them little about whether it can change financial records, approve transactions, or perform several steps that should require independent oversight.
SoD governance helps teams identify those conflicts. If one identity can both create a vendor and approve a payment to that vendor, it may be able to complete a transaction without the checks the organization intended. Understanding that risk requires connecting the identity’s entitlements to the business activities they permit.
For Saviynt, the implication is that application access governance needs to bring identity, permissions, and business context into the same view. Teams need sufficient detail to determine whether access aligns with an identity’s responsibilities and whether combinations of permissions undermine required controls. As business processes span more applications, the assessment must follow the process across the systems involved.
Expanding access changes SAP risk
Employees and contractors work alongside service accounts and bots in SAP business processes. An employee may enter orders while a service account transfers transaction data between applications. Governance teams need to understand the permissions behind that work and whether they fit each identity’s responsibilities.
Those permissions can accumulate as work changes. An employee may retain access from a previous role. A contractor’s account may remain active after an implementation ends. A service account created for a specific integration may acquire broader privileges as teams add functionality. Without clear ownership and a current understanding of purpose, teams can struggle to determine which access remains necessary.
SAP transformation makes that assessment more complex. As organizations connect workflows across applications, an identity’s permissions can affect several systems or stages of a business process. An integration account might retrieve supplier information from one application and update records in SAP. Assessing its access requires understanding the work it performs, the data it can modify, and the controls that apply throughout.
That assessment needs to cover the full business process. When a workflow extends into SaaS tools, cloud services, or other enterprise applications, reviewing SAP permissions alone leaves part of the identity’s authority out of view.
Access risk does not stop at the edge of SAP
A business process can begin in a SaaS application, pass through a cloud integration service, and end with a transaction in SAP. Each system may enforce its own access rules, while the process depends on permissions distributed across all of them. Reviewing those permissions separately can leave conflicts undetected.
Consider an employee who can change vendor banking details in a supplier management application and approve payments in SAP. Reviewed separately, both permissions may appear appropriate. Combined, they could let the employee redirect a payment and approve it, creating a cross-application SoD conflict. Independent verification of banking changes could reduce the opportunity for misuse, so the assessment also needs to account for that control.
Governance teams need to assess the cumulative access an identity holds across the applications involved. That means connecting accounts to the same person or non-human identity, mapping entitlements to business actions, and identifying combinations that could bypass required oversight. Application roles alone may not reveal the problem because different systems can use different labels for permissions that affect the same workflow.
SAPinsider’s findings on integration, unified access, and security governance support a more connected approach. For application access governance, this implies that risk assessments should follow business processes across application boundaries. A cross-application view helps teams identify where individually justified permissions combine to give an identity more authority than the process permits.
AI and non-human identities increase the scale and speed of access risk
AI agents add to an identity governance challenge that already includes service accounts, bots, and other automated systems. Their presence within enterprise applications is expected to grow substantially. In August 2025, Gartner forecast that 40% of enterprise applications would integrate task-specific AI agents by the end of 2026, up from less than 5% at the time.
That expansion increases both the volume of access to govern and the speed at which it can be used. Each agent may introduce accounts, entitlements, and connections to applications. Depending on its design and authority, it may also perform work continuously, moving through transactions faster than a periodic access review can identify a problem. Permissions that change shortly after certification could remain available through many automated actions before the next review.
Governance teams need to establish who owns each agent, which applications and data it can access, and whether that access still aligns with its purpose. Changes to an agent’s role, integrations, or permissions should trigger reassessment. These disciplines extend familiar identity governance practices to actors whose responsibilities and access may evolve quickly.
As agents begin taking action within business processes, governance needs to evaluate what they are attempting to do. An agent may have permission to update a supplier record, but a specific update may fall outside its delegated task. Deciding whether to permit that action requires considering the agent’s identity, delegated authority, intended task, current context, and risk. For example, an agent assigned to correct a supplier’s mailing address should not automatically have authority to change that supplier’s payment destination simply because its application permissions support both operations.
SAPinsider’s research places AI governance within the expanding GRC mandate. For application access governance, this raises a practical requirement: changes in an agent’s access must inform decisions about which actions it can take, with authorization evaluated when the action is attempted.
Modern application access governance has to keep pace with change
Keeping access aligned with business purpose requires an ongoing operating model. Teams need to continually discover identities and permissions, establish accountable owners, and understand the work each identity supports. With that context, they can assess entitlements and SoD risk across applications, then respond when access, responsibilities, or risk changes.
Periodic certifications remain useful, but access can change soon after a review. For example, a new integration may grant an account permissions that conflict with access it already holds elsewhere. Detecting that change promptly lets teams correct the conflict without waiting for the next certification cycle. SAPinsider’s finding that automated, intelligent risk detection remains a leading GRC requirement supports the need for ongoing assessment.
The model must cover human users, non-human identities, and AI agents, with controls appropriate to their work. An employee’s access may depend on job responsibilities and organizational changes. A service account needs a defined owner and permissions scoped to its integration. An AI agent also needs boundaries around delegated authority, with consequential actions evaluated against its task, context, and risk. All require governance that understands what application permissions enable within the business process.
Saviynt’s converged identity security approach supports this operating model by connecting identity governance with detailed application entitlements and risk information. That connection helps teams evaluate access against business responsibilities and coordinate remediation when they identify conflicts across applications. Organizations can explore its offering for SAP and connected enterprise applications through the Saviynt listing in the SAP Store.
Identity becomes the control plane for secure transformation
SAPinsider’s research shows identity and access governance gaining priority alongside cybersecurity and transformation risk. For organizations modernizing SAP or introducing AI, access decisions need to be part of implementation planning.
Identity provides a control plane for that work by connecting permissions to the business actions they enable. Before a workflow goes live, teams can resolve conflicting access and define the authority delegated to an agent. This can reduce late-stage access redesign and help projects proceed with the required controls in place.
Saviynt’s perspective is that continuous governance should carry those decisions into day-to-day operations, keeping access and agent actions within approved boundaries as business processes change.
