Your ERP concentrates financial data, procurement workflows, HR processes, and customer transactions. It is also, by nature, the first system auditors scrutinise when assessing your operational risk exposure. Yet in most mid-market organisations, risk management remains structured outside the ERP — in a spreadsheet, a ticketing tool, or, worse, in the heads of two or three key people.
In 2026, this approach has become both a regulatory weakness and an operational vulnerability. DORA Regulation (EU) 2022/2554 has been in force since 17 January 2025 with no grace period for financial entities. NIS2 Directive (EU) 2022/2555 will bring approximately 160,000 entities across the EU under risk mapping obligations for IT systems — including mid-market organisations in sectors classified as “important”: healthcare, energy, transport, water, and digital infrastructure.
This guide is aimed at CIOs, CISOs, and CEOs who understand what “risk management” means but have not yet structured their approach within their ERP. The goal: a precise regulatory overview, a comparative analysis of software options, and a three-tier maturity roadmap to move from intention to action.
Operational Risk and ERP in 2026: The Regulatory Context That Changes Everything
The 5 Categories of Operational Risk That the ERP Centralises (or Should)
The Basel definition of operational risk — the risk of loss resulting from inadequate or failed internal processes, people, systems, or external events — maps precisely to the functional scope of an ERP.
In practice, five categories of operational risk naturally sit within the management information system:
- Process risks: data entry errors, duplicate payments, missing or bypassed approvals, incorrect validation sequencing.
- Access risks: incompatible entitlements (creating a supplier and approving a payment to that supplier), active dormant accounts, unmonitored administrator access.
- Continuity risks: data loss, system unavailability during a month-end close, absence of a documented recovery plan.
- Regulatory risks: breach of a traceability obligation (statutory accounts, SOX, GDPR), absence of an audit trail on a modified transaction, failure to meet data retention deadlines.
- Third-party risks: failure of a critical SaaS provider, vulnerability in an EDI connector, incident at a managed services provider.
An ERP configured for risk management does not eliminate these risks. It makes them visible, measurable, and auditable.
DORA (Digital Operational Resilience Act): What It Has Required of Management Systems Since January 2025
Regulation (EU) 2022/2554, known as DORA, entered into application on 17 January 2025. Unlike NIS2, it is a regulation: directly applicable across all 27 Member States, without national transposition, without local variations.
Approximately 22,000 European financial entities are in scope: banks, insurers, asset managers, payment service providers, regulated fintechs, central counterparties, and depositories. Smaller entities benefit from a simplified regime (Article 16), but the baseline obligations remain: ICT risk mapping, third-party register, mandatory contractual clauses.
What DORA requires concretely for ERP systems:
ICT Third-Party Register (Register of Information): every provider delivering an ICT service to a financial entity must be listed. This includes the ERP vendor, the hosting provider, the implementation partner handling ongoing maintenance, and every critical connector. This register is submitted annually to the competent supervisory authority by 31 March.
Major Incident Management: an incident affecting the management system must be notified to the competent authority (for example FCA in the UK, BaFin in Germany, ACPR in France) within strict deadlines: initial alert within 4 hours, intermediate report within 72 hours.
Resilience Testing: significant entities must conduct advanced penetration testing (TLPT, Threat-Led Penetration Testing) on critical systems. An ERP classified as a critical system falls within scope.
In 2026, supervisory authorities have moved from the documentation phase to the in-depth control phase. If your organisation has not finalised its ICT register or updated its vendor contracts, the non-compliance situation has now persisted for more than a year.
NIS2: Mid-Market “Important Entities” Now in Scope
Directive (EU) 2022/2555, known as NIS2, considerably broadens the scope of NIS1: approximately 160,000 entities across the EU will be subject to its obligations, compared with roughly 4,000 under NIS1, according to EU Commission estimates.
Transposition deadlines passed on 17 October 2024. Several Member States are facing infringement proceedings, but the substantive obligations are known and preparation must already be underway regardless of the local transposition status.
For a mid-market organisation classified as an “important entity” (minimum 50 employees, turnover above €10 million, operating in healthcare, energy, transport, water, digital infrastructure, postal services, or critical manufacturing), NIS2 requires:
- A documented IT risk mapping, regularly reviewed.
- Proportionate security measures covering access management, supply chain security, and staff training.
- Incident notification within 24 hours (initial alert) then 72 hours (detailed report).
- Personal liability for senior management: governing bodies are required to approve and supervise cybersecurity measures.
Penalties for non-compliance reach up to €7 million or 1.4% of global annual turnover for important entities, and €10 million or 2% of turnover for essential entities (source: fidens.fr, NIS2 Sanctions).
The Risk Register in the ERP: Native Functionality vs Dedicated GRC Modules
SAP GRC (Governance, Risk and Compliance): Actual Scope and Relevance Threshold
SAP GRC is the reference solution for large organisations running SAP S/4HANA or ECC. It covers four main domains: access control, risk management, internal audit, and SOX compliance. Its primary advantage is native integration with the SAP core: transactional flows automatically feed the controls.
However, SAP GRC is calibrated for large enterprises. Licensing costs range from approximately $150,000 to $550,000 annually for an enterprise deployment, with implementation costs often representing 50–200% of the licence fee (source: vendorbenchmark.com, GRC Pricing 2026). For a mid-market organisation below 500 employees, the ROI is difficult to justify without strong regulatory pressure (listed group, subsidiary subject to SOX, entity under prudential supervision).
If your organisation is an SAP customer but cannot commit the full GRC budget, the SAP Access Control module alone (for SoD management) is more accessible and addresses the most frequently audited risk.
Oracle Risk Management Cloud: Positioning and Target
Oracle Risk Management Cloud (formerly Oracle GRC) is integrated into Oracle Fusion Applications. Its architecture is oriented towards continuous control: risk rules execute in real time against transactions, not only during periodic audits.
Its natural target is the organisation running Oracle ERP Cloud or Oracle Fusion Financials. For Oracle customers, the value lies in native integration: an SoD conflict detected triggers an alert directly within the Oracle approval workflow. For non-Oracle organisations, the integration cost makes it less competitive against more ERP-agnostic third-party GRC tools.
Dynamics 365 + Power Platform: Building a Risk Register Without a Dedicated Module
Microsoft Dynamics 365 does not have a native GRC module equivalent to SAP GRC. However, combining D365 with the Power Platform (Power Apps + Dataverse + Power Automate) makes it possible to build a functional risk register at significantly lower cost.
The typical approach for a mid-market Dynamics customer:
- Power Apps to create a risk entry form and a monitoring dashboard.
- Dataverse to store the register (risk category, likelihood, impact, owner, treatment plan, status).
- Power Automate to automate alerts (quarterly reviews, threshold breaches, incidents).
This approach covers Maturity Level 1 (see below) and can be deployed in two to four weeks with an intermediate-level Power Platform developer. It does not replace an integrated GRC solution for organisations facing strong regulatory pressure, but it is sufficient to address initial NCSC or ISO 27001 limited-scope audits.
Third-Party GRC Solutions Connected to the ERP: When to Connect Rather Than Integrate
When regulatory pressure justifies a GRC tool but the ERP lacks a suitable native module, three third-party platforms position themselves as a “hub” connected to the ERP:
- ServiceNow GRC: well known for its ITSM workflows, ServiceNow has developed a solid GRC module with connectors for SAP, Oracle, and Dynamics. Key strength: unified management of IT and non-IT risks in a single register. Key weakness: the ServiceNow platform cost is significant for a mid-market organisation.
- MetricStream: a long-standing GRC specialist, positioned in heavily regulated sectors (finance, healthcare, energy). Rich in regulatory reporting features (SOX, DORA, ISO 27001).
- Pathlock (formerly Greenlight Technologies): a multi-ERP SoD analysis specialist, with connectors for SAP, Oracle, Dynamics, and Workday. Relevant if you manage multiple ERP instances or have recently acquired a subsidiary with a heterogeneous IT landscape.
The decision rule: connect a third-party tool when your ERP spans multiple heterogeneous instances, when you must produce structured regulatory reporting (DORA register, NIS2 report), or when the level of continuous control required exceeds what the native module can deliver.
Segregation of Duties (SoD) and Internal Controls in the ERP
SoD in Practice: Which Access Conflicts to Block
Segregation of Duties (SoD) is the first internal control that any SAP, Oracle, or Dynamics auditor will check. The principle: no single individual should be able to initiate and approve the same sensitive transaction.
Examples of prohibited access conflicts in practice:
- Creating a supplier and approving a payment to that supplier.
- Creating a purchase order and confirming goods receipt.
- Configuring a supplier bank account and initiating a payment.
- Modifying an item price and approving a purchase invoice.
- Creating a user and assigning administrator rights to that user.
These conflicts are detectable natively in most modern ERP systems through their entitlement management tool. However, native detection identifies theoretical conflicts within the entitlement repository: it does not detect conflicts actually exercised in practice — cases where a user has genuinely used two incompatible entitlements within the same transaction.
This is precisely where SoD analysis tools such as SAP Access Control, Pathlock Assure, or Fastpath Assure come in: they cross-reference the entitlement repository with transaction logs to produce a list of active conflicts, no longer just theoretical ones.
Moving from Periodic to Continuous Control: Native Tools vs Add-Ons
Periodic control is the classic approach: a quarterly or annual audit reviews the entitlement matrix and identifies SoD conflicts. It is the minimum practice required in a SOX or ISO 27001 audit.
Continuous control goes further: every transaction is checked in real time against internal control rules. If a user attempts to execute a conflicting transaction, they receive an alert (or the transaction is automatically blocked).
Most ERP products on the market offer native continuous control for the most critical scenarios (payment flows, supplier master data changes). For more sophisticated scenarios (cross-module analysis, behavioural analytics), an add-on is required.
For a mid-market organisation, the practical recommendation: start by activating the ERP’s native controls, document results for the audit, then evaluate whether recurring incidents justify investment in a dedicated SoD analysis tool.
Link with Statutory Audit Trails, SOX ITGC, and ISAE 3402
Three regulatory frameworks intersect with SoD in the ERP:
Statutory accounting audit trails: most jurisdictions require that every accounting entry be traceable with its author, timestamp, and source journal. A correctly configured ERP produces this automatically. A poorly configured ERP (manual changes without an audit trail, deletion of entries) generates non-compliant records. In France this is formalised as the FEC (Fichier des Écritures Comptables), with equivalent requirements under GoBD in Germany and Making Tax Digital in the UK.
SOX ITGC (IT General Controls): for EU subsidiaries of US-listed groups, Section 404 of the Sarbanes-Oxley Act requires controls over access to financial systems. ITGCs cover exactly SoD: who can access what, who can change what, who approves changes.
ISAE 3402 / SOC 1: for providers that host or operate an ERP on behalf of a client, this assurance report certifies that the provider’s internal controls are adequate. A serious SaaS ERP vendor should be able to provide its SOC 1 Type II report annually.
To explore audit trail requirements and data retention obligations in depth, the article ERP Audit Trail: SOX, GDPR, GoBD, and FEC Compliance details requirements by jurisdiction.
ERP and Business Continuity Planning (BCP/DRP): The 4 Functionalities to Configure
RTO and RPO in ERP Cloud SLA Contracts: What to Negotiate
Two indicators structure every continuity plan:
- RTO (Recovery Time Objective): the maximum tolerable interruption before business is severely impacted. For accounting during month-end close, a 4-hour RTO may be acceptable. For a production line driven by the ERP, 4 hours can represent hundreds of thousands of euros in losses.
- RPO (Recovery Point Objective): the maximum amount of data loss tolerable. An RPO of 1 hour means backups are performed every hour. An RPO of 24 hours means an entire day of transactions could be lost in the event of an incident.
Most SLA contracts from cloud ERP vendors advertise RTOs of 4 to 8 hours and RPOs of 1 to 4 hours. But these values are typically guaranteed for the standard infrastructure. For full disaster recovery scenarios (primary datacenter inaccessible), actual contractual RTOs may exceed 24 to 72 hours if you have not subscribed to a geographic high-availability option.
Points to negotiate with your cloud ERP vendor: separate RTO and RPO by criticality tier (production, close, reporting), measurable contractual penalties for breaches, right to audit recovery procedures.
DORA requires precisely this level of contractual precision for financial entities: contracts with critical ICT third-party providers must include documented service level objectives, tested recovery procedures, and audit rights.
Backups, Encryption, and Sensitive Data Segmentation in the ERP
Minimum best practices for an ERP in 2026:
- Backups: hourly frequency for critical transactions (finance, payroll), daily for master data. Retention: at least 7–10 years for accounting data, depending on local legal requirements (e.g. 10 years in France and Germany, 6 years under UK HMRC rules).
- Encryption: encryption of data at rest (AES-256 minimum) and in transit (TLS 1.2 minimum). For SaaS vendors, verify that your encryption key is separate from the vendor’s key (BYOK, Bring Your Own Key) if you process sensitive data.
- Segmentation: HR and payroll data must be segmented from production data within the ERP. Access to consolidated financial data must be restricted to roles that genuinely require it.
Annual Failover Exercise: Recommended Protocol
An untested recovery plan is not a recovery plan — it is a document. DORA has formalised this for financial entities, but the practice applies to any mid-market organisation for which the ERP is critical.
Recommended protocol for an annual exercise:
- Define the scenario: primary datacenter failure, ransomware on the production environment, critical connector failure.
- Test the technical failover: verify that the recovery environment actually starts within the contractual RTO.
- Test business processes: can a chief accountant close a trading day on the recovery environment? Do payment approvals work?
- Document gaps: record what did not go as expected and track corrective actions.
- Report to senior management: DORA requires that management be informed of resilience test results.
ERP Risk Management Roadmap: 3 Maturity Levels
Level 1 — Basic: The Non-Negotiable Foundations
This level covers the minimum obligations for a mid-market organisation beginning to structure its ERP risk management.
- Manual risk register: documented table (Excel or Power Apps) covering at minimum categories, likelihood, impact, owner, and status for each identified risk. Quarterly review minimum.
- Documented SoD matrix: list of incompatible entitlement combinations in the ERP, with active exceptions and their justifications. Semi-annual review.
- Entitlement review: annual audit of active accounts vs current employees, with immediate deactivation of leavers’ accounts. This simple step eliminates one of the most frequently exploited vulnerabilities.
- Tested backups: quarterly verification that backups can actually be restored.
- BCP documentation: written description of the recovery scenario, even at a summary level.
This level requires no additional software budget. It demands organisation and tracking discipline.
Level 2 — Advanced: Automated Controls and KRIs in the Management Dashboard
This level suits a mid-market organisation for which the ERP is critical to continuity and that must produce structured documentation for an external audit.
- Automated SoD controls in the ERP: activation of native conflict detection rules, with alerts to the process owner.
- KRIs (Key Risk Indicators) in the management dashboard: number of active SoD exceptions, proportion of dormant accounts with ERP access, number of transactions rejected by automated controls, average incident resolution time.
- Complete audit trail: every sensitive transaction (master data changes, payments, close) is tracked with author, timestamp, and before/after value.
- Annual recovery test, documented with results communicated to management.
- Risk register in the ERP or connected to it: moving out of the spreadsheet to an integrated tool (native module or Power Platform under Dynamics).
Level 3 — Expert: Integrated GRC, SIEM Correlation, and Automated Regulatory Reporting
This level applies to entities subject to DORA, subsidiaries of SOX-compliant groups, or ISO 27001-certified organisations with the ERP included in scope.
- Dedicated GRC module (SAP GRC, Oracle Risk Management Cloud, ServiceNow GRC, MetricStream) with native transactional integration.
- ERP + SIEM correlation: ERP security events (unusual logins, entitlement changes, denied access attempts) feed the SIEM (Security Information and Event Management) for real-time threat detection.
- Automated regulatory reporting: generation of the DORA register, NIS2 report, and SOX ITGC attestations directly from the ERP, without manual reprocessing.
- TLPT (Threat-Led Penetration Testing) for DORA entities.
- Formal risk review at board level: quarterly report to the Board or Executive Committee, with KRI tracking and major incident follow-up.
Checklist: 15 Points to Audit the Risk Management Maturity of Your ERP
- Do you have a documented list of operational risks linked to your ERP, with identified owners?
- Is the SoD matrix formalised and reviewed at least annually?
- Are accounts of departed employees deactivated in the ERP on the day of their departure?
- Are active SoD exceptions documented, justified, and signed off by a responsible manager?
- Does your ERP generate a complete audit trail on financial transactions (compliant with local statutory requirements)?
- Do you know the RTO and RPO in your ERP cloud SLA contract?
- Have these values been tested in a recovery exercise in the last 12 months?
- Is your ERP data encrypted at rest and in transit?
- Do you have a register of critical ICT third-party providers (vendor, hosting provider, implementation partner) with their contractual obligations?
- If you are a financial entity: is your DORA register up to date and has it been submitted to your supervisory authority?
- If you are in the NIS2 scope: have you initiated your pre-registration with your national competent authority?
- Are your KRIs (Key Risk Indicators) visible in the management dashboard?
- Are ERP resilience test results documented and communicated to management?
- Have you conducted an SoD analysis on actual transactions (not just the theoretical entitlement repository) in the last 12 months?
- Has your ERP security policy been formally approved by senior management or the Board?
Structuring risk management within your ERP is no longer an advanced governance initiative reserved for large enterprises. It is a growing regulatory requirement for mid-market organisations in regulated sectors, and a signal of operational maturity for all others.
To explore the two most directly related topics in depth, see our dedicated guides: ERP and Zero Trust: Securing Access with IAM, PAM, and MFA and DORA and ERP: What Financial Sector CIOs Must Require from Their Vendors in 2026.
