ERP security is a business-control issue as much as an IT issue. An ERP platform can contain supplier bank details, payroll, customer records, pricing, inventory, financial transactions and production information. A compromised account or excessive permission can therefore affect cash, operations, regulatory obligations and customer trust.
Strong ERP security is not achieved by enabling a firewall or assigning every user a standard role. It requires a layered control model covering identities, business permissions, data, integrations, infrastructure, monitoring and recovery. The controls must also reflect the organisation’s actual processes and regulatory obligations.
1. Start with an ERP data and risk inventory
Identify the data and processes held in the ERP, where the data is stored, which systems exchange it and which users or service accounts can access it. Classify information by sensitivity and business impact. For example, supplier bank details and payroll records need tighter controls than a public product description.
| ERP asset | Example risk | Control priority |
|---|---|---|
| Finance and payments | Fraudulent vendor changes, unauthorised journals or payments | Segregation of duties, approvals, change logs and alerts |
| Customer and supplier master data | Data theft, fraudulent changes or unauthorised disclosure | Role restrictions, validation, approval and audit trails |
| Payroll and employee data | Exposure of personal and compensation information | Restricted roles, data minimisation and access reviews |
| Inventory and production | Manipulated stock, recipes, bills of material or work orders | Transaction controls, approvals and exception monitoring |
| Integration accounts | Stolen credentials or excessive machine permissions | Managed identities, secret rotation and scoped access |
| Backups and exports | Unauthorised access to copied ERP data | Encryption, retention, access control and recovery testing |
2. Enforce least privilege and role-based access
Grant each user only the access needed to perform their job. Design roles around business duties and processes rather than creating a unique role for every employee. Use separate roles for tasks that should not be combined, and review permissions when people change jobs or leave the organisation.
- Use single sign-on and multi-factor authentication where supported.
- Restrict privileged and administrator accounts; use separate accounts for routine work.
- Review inactive users, guest accounts, service principals and emergency access.
- Use time-bound or just-in-time elevation for sensitive administration.
- Test access with realistic user roles before go-live and after major changes.
- Apply access controls to reports, data warehouses, exports and connected applications—not only the ERP user interface.
Microsoft’s Dynamics 365 implementation guidance recommends designing security roles around business processes and segregation of duties. This is important because role design can affect compliance, maintainability and application performance. The specific role model differs across ERP products, so use the controls documented for your platform.
3. Apply segregation of duties to financial and operational processes
Segregation of duties (SoD) prevents one person from controlling incompatible steps in a sensitive process. For example, the same user should not be able to create a supplier, change its bank account, approve an invoice and release payment without an independent control.
| Process | Potential conflict | Example control |
|---|---|---|
| Procure to pay | Supplier maintenance and payment release by the same user | Separate vendor master changes, invoice approval and payment execution |
| Order to cash | Credit-limit changes and order release without independent approval | Separate credit authority and order processing |
| Record to report | Journal creation and approval by one person | Independent journal review and posting permissions |
| Inventory | Stock adjustment and adjustment approval by one user | Threshold-based approvals and variance review |
| Payroll | Employee bank detail changes and payroll release by one user | Independent validation and payroll sign-off |
Where staffing levels make strict separation difficult, document compensating controls such as independent review, exception reports and periodic audit. Do not treat a conflict report as proof that the risk has been resolved.
4. Protect data at rest, in transit and in use
Use platform-supported encryption for stored data, backups and network traffic. Require secure protocols for integrations and administrative access. Manage encryption keys and secrets under controlled ownership, with documented rotation and revocation procedures.
Data protection also includes exports and secondary copies. A report downloaded to a laptop, a spreadsheet sent by email or a replicated dataset in a data warehouse may no longer inherit the ERP’s original access rules. Apply classification, access restrictions, retention and deletion controls to these copies.
- Classify sensitive information and minimise collection and replication.
- Encrypt data in transit and at rest using supported, current standards.
- Restrict bulk exports and monitor unusual download activity.
- Mask or tokenise sensitive fields in non-production environments where appropriate.
- Keep development, test and production environments separate.
- Review data residency, retention and cross-border transfer obligations.
5. Secure APIs, integrations and service accounts
ERP environments connect to CRM, ecommerce, banking, payroll, warehouse, analytics and supplier systems. Every integration introduces another identity, endpoint and data path. Avoid shared administrator credentials and broad API permissions.
Use dedicated service identities, scoped permissions, secure secret storage, certificate or token rotation and allowlisted endpoints where appropriate. Validate inbound data, protect webhooks, monitor API usage and establish ownership for failed jobs. Where a third-party integration provider is involved, assess its security controls and incident notification process.
6. Monitor activity and maintain audit evidence
Security monitoring should identify unusual sign-ins, privilege changes, failed authentication, sensitive master-data edits, bulk exports, suspicious API activity and unexpected transaction patterns. Send relevant logs to a central monitoring environment where the security team can correlate activity across ERP, identity, endpoint and network systems.
Define what must be logged, who reviews alerts, how quickly incidents are escalated and how long evidence is retained. Test that critical events are actually captured; a log configuration that nobody reviews does not provide an effective control.
7. Protect backups and test recovery
Confirm what the ERP provider backs up, how long backups are retained, what recovery objectives apply and which responsibilities remain with your organisation. SaaS backup arrangements vary: automatic platform backups may not provide the granular restore, long-term retention or independent recovery capability your business needs.
- Define recovery time objective (RTO) and recovery point objective (RPO) for critical processes.
- Understand provider backup retention, restore process and service limitations.
- Assess independent backup needs for configuration, documents, attachments and connected data.
- Protect backups from deletion or modification by compromised administrator accounts.
- Run restoration exercises and document the actual recovery time and data loss window.
- Include integrations and downstream systems in business continuity tests.
8. Build an incident response plan for ERP scenarios
Prepare playbooks for compromised administrator accounts, fraudulent supplier changes, data exfiltration, ransomware affecting connected infrastructure, malicious integrations and accidental bulk updates. Identify who can disable accounts, suspend integrations, block transactions, preserve evidence and communicate with business leaders.
Test the plan with finance, operations, IT, security, legal and the ERP partner. Include a decision path for manual workarounds if the ERP is unavailable, and define how transactions entered during an outage will be reconciled later.
9. Include implementation and change management in security
Security should be designed during discovery and solution architecture, not added after configuration is complete. Review customisations, extensions, workflows and reports for access-control implications. Reassess permissions after each release, new integration or organisational change.
During implementation, use representative security roles in system testing, validate permissions after data migration and ensure users can complete their duties without being granted unnecessary access. The ERP partner should document security decisions, privileged access, integration identities and operational responsibilities.
ERP data security checklist
- Inventory ERP data, integrations, identities and critical processes.
- Classify sensitive data and define retention requirements.
- Use MFA, least privilege and periodic access reviews.
- Design role-based permissions around business duties.
- Identify and mitigate segregation-of-duties conflicts.
- Encrypt data and protect keys, credentials and secrets.
- Secure APIs, service accounts and third-party integrations.
- Monitor privileged actions, sensitive changes and unusual exports.
- Confirm backup retention, RTO and RPO; test restoration.
- Exercise incident response and business continuity plans.
- Revalidate controls after upgrades, migrations and role changes.
Conclusion
ERP security is an ongoing operating discipline. The strongest programmes combine role design, segregation of duties, encryption, secure integrations, monitoring and tested recovery. Start with the processes and data that would cause the greatest business harm if compromised, assign control owners and verify that safeguards work in practice.
For implementation risks that can affect security and control design, read our guide to ERP implementation challenges. Organisations using Dynamics 365 can also review Microsoft’s guidance on Dynamics 365 security configuration.
