Results at a glance

• Increased onboarding of high‑impact applications from 8 to 22 in 9 months
• Reduced manual effort for quarterly identity access reviews by 55%
• Cut median access fulfillment time in selected non‑ERP apps from 3 business days to <1 day
• Achieved the next annual audit with zero critical access findings related to non‑ERP applications
  
  

Background: Strong ERP controls, growing blind spots

This global animal health leader operates in a regulated environment with complex supply chains and a diverse application landscape. They had already invested in mature tools:

• SAP GRC to enforce segregation of duties within ERP
• SailPoint to handle provisioning and access reviews
  
  

Both were focused primarily on the ERP environment.

As the business expanded:

• Dozens of SaaS and on‑prem applications—including CRM, financial close, procurement, HR, and specialized platforms—became business‑critical.
• Many of these systems sat outside any consistent identity and access governance framework.

Risk and audit leaders began to see a clear mismatch:

• Significant spend on identity tools
• Many high‑value applications still loosely controlled
  
  

Challenges: Strong ERP controls, truncated IGA everywhere else

When the team mapped their full application landscape, a clear pattern emerged: identity governance was deep around ERP and thin everywhere else.

• SAP GRC and SailPoint worked well in the ERP environment for SoD, provisioning, and reviews.
• Many other high‑impact systems—CRM, financial close, procurement, HR—were only partially integrated into SailPoint or not connected at all.
• Each new integration required significant budget, scarce specialists, and complex project work.
  
  

In non‑ERP applications:

• Access flowed through tickets, emails, or local administrators.
• Segregation of Duties checks were inconsistent.
• Central visibility for risk and audit teams was limited.

At baseline:

• Only about one‑third of critical applications—8 of roughly 25—were under consistent, centralized governance.
• The rest relied on local controls, spreadsheets, and fragile point‑to‑point integrations.

The result was a truncated IGA implementation: strong ERP controls surrounded by growing blind spots in the wider application ecosystem.

Extending the existing centralized model to every critical app was not realistic:

• Several key systems lacked modern APIs or would have required expensive custom integration.
• Each onboarding effort meant reinventing roles and entitlements to fit the central IGA catalog.
• SAP GRC was effectively tied to its home ERP environment and could not stretch across dozens of heterogeneous cloud and on‑prem systems.

For fraud and cyber risk, there is no partial ROI: as long as most identities and entitlements sat outside a common governance layer, residual risk stayed unacceptably high.

Solution: SafePaaS federated governance, not another rip‑and‑replace

The turning point came when the company reframed the problem from “force everything into one identity platform” to “govern everything that matters using the controls we already trust.” They adopted the SafePaaS federated access governance platform, designed to coexist with SAP GRC and SailPoint rather than replace them.

The goal was simple:

• Keep what already worked for ERP.
• Extend governance to the many critical non‑ERP applications stuck outside the current model.

In the new design:

• SailPoint continues to handle provisioning and access reviews, where it is already effective.
• SAP GRC continues to enforce SoD inside ERP.
• SafePaaS adds a federated governance layer over CRM, financial close, procurement, HR, and other business‑critical systems—without forcing every access change through a single hub.

This respected real‑world constraints on budget, people, and application capabilities while still driving toward complete coverage.

A key differentiator:

• SafePaaS uses standard APIs and its DataPaaS tool to handle integration and data mapping inside the product.
• This avoided an estimated 800–1,000 hours of custom integration work for internal teams and partners.
• For smaller or legacy applications without modern connectors, teams could load user and role data from reports and snapshots to enable access reviews, SoD analysis, and audit‑ready evidence—without full automation.

The SafePaaS also took a governance‑first stance on provisioning:

• High‑risk non‑ERP applications moved from email‑based requests to policy‑checked workflows, cutting median fulfillment time from 3 business days to under 1 day and creating an auditable trail for every request.
  
  
• Other systems could keep local provisioning, as long as access and entitlement data flowed into SafePaaS for monitoring, analytics, and certifications.

This adaptive, coexistence‑based model gave senior stakeholders a credible path to materially lower risk—without committing to yet another multi‑year identity replacement program.

What made this approach different

SafePaaS did the integration work, not the customer

Earlier models assumed the customer would fund large-scale integration projects—hiring third‑party specialists and building custom agents whenever a new system came into scope. SafePaaS flipped that assumption:

• Leverages standard APIs where they exist
• Uses DataPaaS to handle data mapping inside the product
• Avoids hundreds of hours of custom integration work and dependence on niche skills

Support for smaller and legacy apps

Smaller or older applications were often treated as “too hard” or “out of scope” for central governance. With SafePaaS, teams can:

• Export user and role data from those systems
• Load it via snapshots and flat files, without custom connectors
• Run access reviews, SoD analysis, and produce audit‑ready evidence

This extended governance to a long tail of critical but previously overlooked applications.

Governance‑first stance on provisioning

Rather than insisting that every application be fully orchestrated through a single provisioning engine from day one, SafePaaS:

• Starts with governance as the non‑negotiable layer
• Moves high‑risk non‑ERP apps from email/tickets to policy‑checked workflows with clear approvals and audit trails
• Allows local or manual provisioning elsewhere, as long as data flows back into SafePaaS for monitoring and certifications

This lets the organization prioritize automation where it delivers immediate risk and efficiency gains, instead of turning provisioning into a bottleneck.

Business‑aligned framing

SafePaaS is positioned as an extension of tools the customer already trusted, not as another multi‑year platform replacement:

• Emphasizes adaptive governance and coexistence with SAP GRC and SailPoint
• Provides realistic paths to coverage across dozens of non‑ERP systems
• Makes it easier for risk and finance stakeholders to support the program

Results: From ERP‑only to enterprise‑wide coverage

Broader coverage where it mattered most

By adding SafePaaS alongside SAP GRC and SailPoint, the customer expanded governance far beyond ERP into CRM, financial close, procurement, and HR systems.

• High‑impact applications under consistent governance increased from 8 to 22.
• More than doubled the share of critical systems in scope and closed blind spots around non‑ERP access.
  
  

Faster, more controlled access changes

Non‑ERP access changes moved from emails and tickets to policy‑checked workflows where it mattered most.

• Median fulfillment time in selected non‑ERP apps dropped from ~3 business days to <1 day.
• Every request now includes an auditable trail and embedded SoD / sensitive‑access checks.
  

Fewer hidden conflicts across applications

With cross‑application rules, the team could finally see and address toxic access combinations across systems.

• Identified and remediated dozens of high‑risk cross‑application access combinations in the first consolidated review cycle.
  
  

A cleaner, more defensible audit story

A single governance layer for ERP and non‑ERP access simplified certifications and audit prep.

• 55% reduction in preparation effort for user access certifications.
• The next annual audit recorded zero critical access findings related to non‑ERP applications.