Deployment model, cloud-native, cloud-hosted, or on-premises, does not determine whether an Identity Governance and Administration (IGA) platform can deliver real access controls for ERP and other business-critical or financial applications.
Most IGA platforms, regardless of how they’re deployed, lack visibility into the ERP application’s own security model: the fine-grained entitlements, authorizations, and usage activity that SOX, NIS2, and other compliance frameworks require evidence of.
Key Takeaways
- Cloud-native, cloud-hosted, and on-premises IGA platforms share the same blind spot: none of them natively see fine-grained entitlements, authorizations, or usage inside the ERP itself.
- The determining factor isn’t the deployment model. It’s whether the platform has visibility into the ERP application’s own security model.
- SOX is a US-only requirement for public companies. NIS2 and other frameworks extend similar access-control expectations to a much broader set of organizations.
- Transaction-level SoD, dollar-based risk quantification, and continuous monitoring are the three checkable capabilities that actually indicate ERP-level visibility, regardless of deployment model.
This piece breaks that visibility gap into the specific, checkable questions a compliance program should be asking, rather than treating deployment model as a proxy for capability.
Does the Platform Support Transaction-Level SoD?
Role-level segregation of duties (SoD) checks whether two roles conflict. Transaction-level SoD checks whether two specific transactions, at the authorization-object or field level, conflict for a given user, which is a materially finer-grained analysis. In SAP, Oracle, and similar business-critical applications, where a single role can bundle dozens of transaction codes, role-level analysis alone tends to under-detect real conflicts.
Checkable question: Can the platform show a conflict at the transaction code and authorization-object level, or only at the role level?
Does It Quantify Access Risk in Dollars?
Audit committees and boards generally want to know what an access risk would cost if it went uncaught, not just that a conflict exists on a list. Financial exposure quantification translates a segregation-of-duties violation or a control failure into a dollar figure tied to the transactions it touches.
Checkable question: Does the platform output a financial exposure estimate per risk, or only a severity label like “high” or “medium”?
Does It Monitor Configuration Changes Continuously?
Periodic certification reviews access on a quarterly or semi-annual cycle. Continuous controls monitoring (CCM) checks configuration and transaction changes as they happen, which closes the gap between when a risky change occurs and when a periodic review would have caught it. Pathlock’s Continuous Controls Monitoring module is built around this distinction specifically, replacing sampling-based testing with analysis of a much larger share of actual transactions.
Checkable question: Does the platform flag a risky configuration change within hours, or does it surface at the next scheduled review?
Why Your Identity Governance Deployment Model Doesn’t Change the Visibility Problem
Cloud-native, cloud-hosted, and on-premises IGA platforms are typically evaluated on how they’re hosted and how their interface works. None of that changes what the platform can actually see inside an ERP system. SAP, Oracle, and similar business-critical applications maintain their own security model, authorization objects, transaction codes, and field-level permissions, that sits at the Fine-Grained/Usage Governance layer most IGA platforms are built to manage, regardless of deployment. A cloud-native platform with a modern interface and a long-standing on-premises platform can share exactly the same blind spot: neither one natively analyzes what a role actually permits at the transaction and field level inside the ERP, and neither tracks what that access was actually used to do.
Deployment model answers a question about where the software runs. ERP visibility answers a question about what the software can see. The two are unrelated, and treating one as a proxy for the other is how access-control gaps get missed during procurement.
Beyond SOX: NIS2 and Other Compliance Frameworks Need the Same Depth
SOX is a US requirement that applies specifically to public companies’ financial reporting controls, and it’s the framework most commonly cited in access-control discussions. That can create the impression that fine-grained ERP visibility is a US, public-company problem. It isn’t. The EU’s NIS2 Directive extends similar access-control and risk-management expectations to a much broader set of organizations, including many that were never in scope for SOX, and requires evidence that access to essential and important systems is managed, monitored, and auditable. Pathlock’s NIS2 Compliance for Business-Critical Applications eBook covers how that plays out specifically for SAP and other business-critical applications.
The underlying requirement is the same one SOX asks for: proof that access inside critical systems is governed at a meaningful level of granularity, not just logged at the account level. A platform that can’t see transaction-level SoD or usage inside an ERP for SOX purposes has the identical gap under NIS2, or under any other framework that expects evidence at that depth.
Glossary: Terms That Show Up in Every Compliance Access-Controls RFP
SoD (Segregation of Duties): A control principle requiring that no single person or account can both execute and approve a transaction, or otherwise complete a full risk-bearing process alone. Role-level SoD checks roles; fine-grained SoD checks transactions, fields, and authorization objects.
CCM (Continuous Controls Monitoring): Automated, ongoing testing of configuration and transaction controls, as opposed to periodic, sample-based manual testing.
Firefighter / Emergency Access: Time-bound, logged elevated access granted for emergency situations, typically with automatic revocation and full session logging for audit purposes. Pathlock’s Elevated Access Management module handles this specifically for SAP and other ERP systems.
ERP Application Security Model: The authorization objects, transaction codes, and field-level permissions an ERP system like SAP or Oracle uses internally to control access. Most IGA platforms, regardless of deployment model, operate above this layer and don’t have native visibility into it.
Why This Distinction Matters in Practice
Independent evaluation frameworks used in enterprise access-governance procurement generally score platforms against a fixed set of hard requirements for ERP-centric compliance programs: cross-application SoD, fine-grained SoD, out-of-the-box ruleset content, preventive risk simulation at request, mitigating-controls management, time-bound elevated access, configuration controls monitoring, and a compliance framework library. Platforms built primarily for workforce identity lifecycle, regardless of whether they’re cloud-native, cloud-hosted, or on-premises, tend to clear only a minority of those specific requirements, simply because none of them were built to operate at the transaction layer inside the ERP.
That’s not a knock on any particular deployment model. It’s a statement about what deployment does and doesn’t determine. A platform can be modern and easy to deploy, on any hosting model, and still need a second layer for ERP-specific access controls. Pathlock’s SOX Compliance Software use case covers how that second layer automates ITGCs and evidence collection, Pathlock’s Access Risk Analysis module is where the transaction-level SoD question above gets answered in practice, and the SEC’s own Section 404 guide is a useful baseline for what the US-specific requirement asks for.
FAQ
Does deployment model (cloud-native, cloud-hosted, on-premises) affect ERP access control capability?
Generally, no. Deployment model determines how a platform is hosted and how its interface works. ERP access control capability depends on whether the platform has visibility into the ERP’s own security model, fine-grained entitlements, authorizations, and usage, which is a separate question from deployment.
What’s the difference between SoD and CCM?
SoD analysis checks whether a person’s combined access creates a conflict of interest or control risk. CCM monitors whether controls, including the resolution of SoD conflicts, remain effective over time by checking configuration and transaction changes continuously.
Is SOX the only compliance framework that requires this level of ERP visibility?
No. SOX applies specifically to US public companies’ financial reporting controls. Other frameworks, including the EU’s NIS2 Directive, extend similar access-control and risk-management expectations to a much broader set of organizations.
How do I know if my current platform has real ERP-level visibility?
Ask for its scoring against specific checkable questions, such as transaction-level SoD, dollar-based risk quantification, and continuous monitoring, rather than general claims about deployment model or risk capability.
Go Deeper
For a step-by-step look at replacing periodic, sample-based testing with continuous, transaction-level monitoring, see Pathlock’s eBook, Automate SAP SOX Compliance with CCM. For the EU-specific version of this same gap, see NIS2 Compliance for Business-Critical Applications.
