The cloud has transformed how we deploy, scale, and maintain enterprise software. For many organizations, migrating ERP systems like Infor LN, SAP S/4HANA, or Oracle Cloud to the cloud promises lower infrastructure costs, faster deployment, and improved flexibility. But when it comes to Segregation of Duties (SoD)—one of the foundational pillars of internal controls—does the cloud make life easier or harder?
The answer isn’t straightforward. Cloud migration introduces a new dimension to compliance: the shared responsibility model. Understanding where your accountability begins and where your cloud provider’s ends is critical to maintaining robust SoD controls and passing your next audit.
In this post, we’ll explore how cloud ERP changes the SoD landscape, what the shared responsibility model means for your compliance program, and what you need to do differently to protect your organization.
What is the Shared Responsibility Model?
In traditional on-premises ERP environments, your organization owns everything: the physical servers, the network, the operating system, the database, and the application layer. You’re responsible for patching, monitoring, access controls, and disaster recovery at every level.
When you move to the cloud, that changes. Cloud providers (like AWS, Microsoft Azure, Google Cloud, or SaaS vendors like Infor or SAP) take on responsibility for certain layers of the technology stack, while you remain responsible for others.
Here’s a simplified breakdown:
| Layer | On-Premises | IaaS (e.g., AWS) | SaaS (e.g., Infor CloudSuite) |
|---|---|---|---|
| Physical Infrastructure | You | Cloud Provider | Cloud Provider |
| Network & Virtualization | You | Cloud Provider | Cloud Provider |
| Operating System | You | You or Cloud Provider | Cloud Provider |
| Database & Middleware | You | You | Cloud Provider |
| ERP Application | You | You | Cloud Provider (with your config) |
| User Access & Permissions | You | You | You |
| Data & Compliance | You | You | You |
Key Takeaway: Even in a fully managed SaaS ERP environment, you remain responsible for user access controls, role design, and Segregation of Duties.
The cloud provider secures the infrastructure. You secure who can do what inside your ERP.
How Cloud ERP Can Simplify SoD
Let’s start with the good news. Cloud migration can make some aspects of SoD easier—if you approach it strategically.
1. A Chance to Start Fresh
Migrating to the cloud is an opportunity to redesign your security roles from scratch. Many organizations carry forward years of “role bloat” from legacy systems—users accumulating access over time, outdated roles that no one dares to touch, and undocumented exceptions.
Cloud migration projects force you to define:
- What roles do we actually need?
- Who should have access to what?
- Which combinations of permissions create SoD conflicts?
This is your chance to implement a clean, role-based access control (RBAC) model aligned with your business processes and control objectives.
2. Built-In Audit Trails and Monitoring
Cloud ERP platforms often come with enhanced logging and monitoring capabilities that are more robust than older on-premises systems. Many SaaS vendors provide dashboards, anomaly detection, and automated alerts for unusual activity.
For example:
- Real-time alerts when a user performs a high-risk transaction
- Automated logs of configuration changes
- Pre-built reports for auditors showing who accessed what and when
These features can make continuous monitoring of SoD conflicts easier than relying on periodic manual reviews.
3. Centralized Identity Management
Cloud environments encourage the use of Single Sign-On (SSO) and centralized identity providers (like Azure Active Directory, Okta, or Ping Identity). This can simplify user provisioning and de-provisioning, reducing the risk of orphaned accounts or “ghost users” with excessive access.
When identity management is centralized, it’s easier to enforce policies like:
- Multi-factor authentication (MFA)
- Conditional access based on role or location
- Automated access reviews and recertification
How Cloud ERP Can Complicate SoD
Now for the challenges. The cloud introduces new layers of complexity that can catch unprepared organizations off guard.
1. The Blurred Line Between Admin and Business User
In on-premises ERP, your IT team manages the infrastructure, and your functional users operate within the application. Roles are relatively distinct.
In the cloud—especially in SaaS models—some configuration and administrative tasks are delegated to business users through the ERP interface itself. For example:
- A finance manager might have the ability to configure approval workflows
- An HR lead might manage employee data structures
- A procurement user might adjust vendor master data settings
This blurs the line between “system administration” and “business operations,” creating new SoD risks that weren’t present before. A user who can both configure a control and execute transactions within that control is a classic SoD violation.
What to do: Clearly define and segregate “configuration” roles from “operational” roles. Treat cloud admin permissions with the same rigor you would apply to database admin access in an on-premises environment.
2. Multi-Tenant Architecture and Shared Controls
In a SaaS environment, your ERP instance runs on shared infrastructure alongside other customers. While the cloud provider isolates your data, they manage the underlying controls (e.g., patching, encryption, physical security).
This means you’re relying on the provider’s SOC 2 Type II or ISO 27001 audit reports to verify that their controls are working. If your auditor asks, “How do you know the cloud provider is segregating administrative duties in their own operations?” you need to have an answer.
What to do:
- Review your cloud provider’s compliance certifications annually
- Request and analyze their SOC 2 reports
- Include cloud provider controls in your risk assessments
3. Access to Cloud Management Consoles
If you’re using IaaS or PaaS (like hosting Infor LN on AWS), your IT team will have access to cloud management consoles (AWS Management Console, Azure Portal, etc.). These consoles give administrators powerful capabilities: spinning up servers, modifying databases, changing network rules, and more.
This is a critical control point. If a single admin has both cloud console access and ERP application admin access, they could potentially bypass SoD controls entirely—modifying logs, creating backdoor accounts, or altering transactions.
What to do:
- Implement SoD at the cloud infrastructure level, not just the ERP application level
- Use separate accounts for cloud admins vs. ERP admins
- Enable detailed logging in the cloud console (e.g., AWS CloudTrail, Azure Monitor)
- Regularly review who has privileged access to cloud environments
4. Integration Complexity
Cloud ERP often integrates with dozens of other cloud applications: payment processors, CRM systems, HR platforms, data warehouses, and more. Each integration point is a potential SoD risk if not properly managed.
For example:
- A user with access to both the ERP and the payment gateway might be able to initiate and approve payments end-to-end
- A developer with access to the integration middleware might be able to alter transaction data in transit
What to do:
- Map all integrations and data flows
- Apply SoD principles across the entire ecosystem, not just within the ERP
- Use API gateways and monitoring tools to track integration activity
Key Actions to Maintain SoD in Cloud ERP
So, does the cloud simplify or complicate SoD? The truth is: it does both. But with the right approach, you can leverage the benefits while mitigating the risks.
Here’s your action plan:
Before Migration:
- Conduct an SoD audit of your current system. Identify existing conflicts and resolve them before migration—don’t carry forward bad practices.
- Design a clean role model. Use the migration as an opportunity to implement a least-privilege access model.
- Understand the shared responsibility model. Document which controls are managed by the provider and which are your responsibility.
During Migration:
- Segregate cloud admin roles from ERP roles. Ensure that infrastructure admins don’t have business user access, and vice versa.
- Test SoD controls in the cloud environment. Run SoD conflict reports in your new system before go-live.
- Train your team on cloud-specific risks. Make sure everyone understands how the shared responsibility model impacts their role.
After Migration:
- Implement continuous monitoring. Use automated tools (like Dynaflow) to detect SoD conflicts in real time.
- Review cloud provider compliance reports annually. Stay informed about changes to their control environment.
- Conduct regular access reviews. Recertify user permissions quarterly, especially for high-risk roles.
- Document, document, document. Your auditors will ask how you’re managing SoD in the cloud. Have clear policies, procedures, and evidence ready.
Conclusion: The Cloud Demands a New Compliance Mindset
Migrating your ERP to the cloud doesn’t eliminate the need for Segregation of Duties—it changes the how and where you apply it. The shared responsibility model means you’re no longer responsible for patching servers, but you’re still responsible for ensuring that no single user can commit fraud undetected.
The cloud offers powerful tools for monitoring, automation, and centralized identity management. But it also introduces new risks: blurred admin boundaries, multi-layered access points, and reliance on third-party controls.
The organizations that thrive in the cloud are those that treat migration as a compliance opportunity, not just a technology upgrade.
If you’re planning a cloud migration—or if you’ve already moved and want to verify your SoD controls are still intact—it’s time to take a fresh look at your access model.
Need help assessing SoD risks in your cloud ERP? Dynaflow Compliance Solutions specializes in automated SoD monitoring and risk analysis for Infor LN, SAP, and other ERP systems—whether on-premises or in the cloud. Contact us to learn more.