Your ERP knows that James approved a $45,000 purchase order last night at 11:47 pm. It recorded the transaction, updated inventory, and triggered the accounting entry. What it does not know: James has been approving his own orders for six months, because his manager left the company and no one reconfigured the authorisation matrix. This is a classic Segregation of Duties (SoD) conflict. And it is exactly where ERP reaches its limits in terms of GRC.
Governance, Risk and Compliance (GRC) is one of the most costly blind spots in ERP projects. Mid-market companies invest hundreds of thousands in their ERP, yet consistently underestimate what it does not do natively: map risks, maintain a multi-regulatory compliance register, or alert the Risk Manager when a transaction pattern looks like fraud.
This guide is for Risk Managers, Compliance Officers, CIOs and CFOs at companies with 500 to 5,000 employees who must respond to NIS2, CSRD, DORA or statutory audits, and who want to structure their GRC approach without duplicating data across their ERP.
The essentials in 30 seconds
- GRC = Governance + Risk + Compliance: three distinct disciplines that ERP covers partially, not comprehensively.
- ERP is an essential GRC layer (SoD, audit logs, access rights) but insufficient on its own beyond 500 employees or 3 legal entities.
- NIS2 (EU Directive 2022/2555) and DORA (EU Regulation 2022/2554) require formalised risk mapping that ERP cannot produce alone.
- Dedicated GRC platforms (SAP GRC, ServiceNow, MetricStream) cost between €50,000 and €300,000 per year depending on company size.
- Undetected internal fraud costs a median of $117,000 per incident (ACFE, Occupational Fraud 2022: A Report to the Nations) — a cost that ERP alone cannot prevent without active GRC controls.
1. GRC: Definition and Why ERP Alone Is Not Enough
The GRC acronym covers three disciplines that are often conflated in practice.
Governance (G): Internal Controls, Policies and Delegation of Authority in ERP
Governance covers the rules and structures that define how decisions are made, who can do what, and how accountability is traced. In an ERP, this translates into the role matrix, signature delegations, and approval workflows.
Most modern ERPs (SAP S/4HANA, Sage X3, Odoo, Microsoft Dynamics 365) allow approval rules by amount, multi-level workflows and access profiles to be configured. This layer exists. The problem is that it degrades over time: exceptions granted “temporarily” are never revoked, accumulated roles pile up after reorganisations, and the ERP does not produce a consolidated governance report readable by a Risk Manager or an external auditor.
Risk (R): Risk Mapping — the ERP’s Major Blind Spot
Risk management means identifying, assessing and prioritising operational, financial, regulatory and strategic risks. ERP generates a considerable amount of data relevant to risk analysis: abnormal transactions, out-of-hours access, orders outside approved thresholds.
But ERP does not map risks. It has no risk heat map module, no risk register with probability-impact scoring, and no mechanism to link an identified risk to a transaction or business process. It is a risk data generator, not a risk manager.
Compliance (C): Regulatory Complexity Exceeds Native ERP Capabilities
Compliance means demonstrating that the organisation meets its legal and regulatory obligations. In 2026, a mid-market European company must simultaneously address several frameworks that involve the ERP: GDPR for personal data, NIS2 for information system cybersecurity, CSRD for sustainability reporting, DORA if operating in the financial sector, and anti-corruption requirements such as the UK Bribery Act, FCPA or equivalent national frameworks.
ERP handles statutory accounting compliance well (SAF-T, GoBD, audit trail exports across jurisdictions). It is less equipped to maintain a multi-regulatory compliance register, track remediation plan progress, and produce the evidence expected during an audit.
2. ERP as the First GRC Layer: What It Already Does Well
Before investing in a dedicated GRC platform, you must have fully exploited what the ERP offers natively.
Segregation of Duties (SoD): the Most Basic Control Layer
Segregation of Duties (SoD) is the first principle of internal control. It ensures that no single person can initiate a transaction, approve it, and record it in the accounts. ERP implements this principle through its role matrix.
All market-leading ERPs have this capability. SAP S/4HANA offers a role conflict simulation tool directly within authorisation management transactions. Odoo and Sage X3 allow access groups to be defined with separate scopes. Microsoft Dynamics 365 provides approval workflows with separation between initiators and validators.
The operational problem is not the absence of initial configuration — it is drift over time. A dedicated article on this site covers the 12 ERP SoD controls to implement before your annual audit.
Audit Trails and Event Logs: ERP’s Native Traceability
ERP natively produces transaction logs. Every accounting entry, every order modification, every price change is timestamped and linked to a user. These logs form the documentary basis for an audit.
In SAP S/4HANA, Change Documents and the FI Audit Trail allow the full history of a document to be traced. In Odoo, the chatter records all modifications. In Sage X3, the event journal covers sensitive user actions.
These traces are valuable but unstructured for GRC analysis. They answer the question “what happened?” but not “does what happened represent a risk?”
Access and Role Management: ERP as an Identity Reference System
ERP is often the system of reference for business access rights: who has access to accounts payable, who can approve an invoice, who can modify customer pricing. This reference system is valuable for GRC.
A critical point: in many organisations, ERP is the declarative authority for access rights, but those rights leak through other channels. Direct database access granted to an integrator during the initial project, mass exports via BI connectors configured with an over-privileged technical account, SSH access on the application server. GRC must cover these vectors that ERP does not see.
The Limits: What ERP Cannot Do Alone
ERP does not consolidate risks across multiple entities into a single view. It does not produce a risk heat map. It cannot simultaneously maintain a compliance register for NIS2 and CSRD. It does not detect fraud patterns in transactions. It does not produce the structured reports expected by a statutory auditor in a GRC audit.
Beyond a certain level of complexity — typically more than 500 employees, more than 3 legal entities, or multi-framework regulatory exposure — a dedicated GRC platform becomes necessary.
3. When to Invest in a Dedicated GRC Platform?
Four trigger criteria guide the decision:
Organisational size and complexity. Beyond 500 employees or 3 entities, managing risks manually in Excel becomes uncontrollable. Consolidating a risk register across entities and tracking remediation plans requires a dedicated tool.
Multiple regulatory exposure. If the organisation is simultaneously subject to NIS2, CSRD, DORA and annual statutory audits, the cost of manually producing compliance evidence quickly exceeds the cost of a GRC platform.
Sector risk profile. A financial institution subject to DORA (EU Regulation 2022/2554) must maintain an ICT third-party register, conduct TLPT tests and notify incidents within strict deadlines. This level of requirement demands a structured tool.
Audit findings. If an internal or external audit has identified gaps in risk management or compliance traceability, that is a clear signal that a dedicated tool is needed.
Expected ROI. Reducing audit costs is the most direct return on investment. Companies that industrialise compliance evidence collection typically reduce time spent preparing for audits by 30 to 50%. Add to this proactive risk detection: according to the ACFE, Occupational Fraud 2022: A Report to the Nations, the median loss per undetected internal fraud incident reaches $117,000. A GRC tool that detects a single major incident can pay for several years of licensing.
4. Overview of GRC Platforms and Their ERP Integration
The GRC market is segmented between solutions integrated with a specific ERP and independent platforms.
| Solution | Vendor | Primary Strength | ERP Integration |
|---|---|---|---|
| SAP GRC Access Control | SAP | SoD, access controls, remediation | Native SAP (S/4HANA, ECC) |
| ServiceNow GRC | ServiceNow | Risk mapping, workflows | API to all ERPs |
| MetricStream | MetricStream | Regulatory compliance, audit | Standard connectors |
| OneTrust | OneTrust | GDPR, privacy, ESG | API |
| Diligent (formerly Galvanize) | Diligent | Internal audit, governance | Connectors |
SAP GRC Access Control deserves a special mention. It is natively integrated with SAP S/4HANA and SAP ECC, with direct read access to roles and authorisations. It enables SoD conflict simulation before assigning a role, generating SOX or ISAE 3402 compliance reports, and triggering automated remediation workflows. Many SAP customers have it included in their licence agreement but have never activated it — it is one of the most under-utilised GRC tools on the market.
ServiceNow GRC (now integrated into ServiceNow IRM, Integrated Risk Management) is the reference solution for organisations that want a GRC platform independent of their ERP. It stands out for its risk mapping capabilities with automated workflows and its API integrations with SAP, Oracle, Microsoft Dynamics and mid-market ERPs.
MetricStream is positioned for large enterprises and heavily regulated sectors (banking, insurance, pharma). Its regulatory compliance module automatically tracks updates to normative frameworks (ISO 27001, SOX, GDPR) and maps them to internal controls.
5. ERP-GRC Architecture: Making Data Flow in Both Directions
ERP-GRC integration is not simply a periodic data export. It must enable bidirectional flows.
Inbound GRC Flow from ERP
The GRC platform feeds on ERP data to drive its risk analyses:
- Financial transactions: amounts, frequencies and unusual counterparties are risk signals that GRC analyses.
- Access and event logs: off-hours logins, modifications to sensitive configuration, access to unusual modules.
- Access rights data: the list of active users with their access profiles, synchronised regularly to detect dormant or accumulated rights.
- Reference data: legal entities, profit centres and business processes mapped in the ERP serve as the reference framework for risk mapping.
Outbound Flow from ERP Triggered by GRC
GRC must also be able to act on ERP:
- Access blocking: when GRC detects a confirmed SoD conflict or an unauthorised access attempt, it must be able to trigger an access rights modification in the ERP.
- Control alerts: GRC controls that fail trigger remediation tasks directly in ERP workflows.
- Reference data sync: entities and processes created in the ERP must automatically be reflected in the GRC risk map.
Master Data Governance for Shared Data
A structural point that is often overlooked: ERP and the GRC platform share common master data. The legal entity register, the user directory, the list of business processes. Without clear governance of this data, the two systems diverge within months and GRC analyses lose their reliability.
6. Integrated Risk Mapping: From Excel Register to Intelligent Platform
The GRC maturity of an organisation can often be read from its risk mapping tool.
Level 1 — Excel register or basic ERP module. Risk mapping is maintained in a spreadsheet updated once a year. Some ERPs offer a minimal “Risks” module, often limited to a list of risks with manual scoring. This level is insufficient for NIS2 or DORA.
Level 2 — GRC platform with automatic feeds from ERP. Abnormal transactions detected in the ERP automatically feed into identified risks in the GRC platform. Remediation workflows are triggered automatically. The risk heat map is updated continuously rather than annually. This is the target level for a mid-market company subject to NIS2.
Level 3 — GRC with AI and pattern detection. The most advanced platforms integrate anomaly detection algorithms on ERP flows. They identify potential fraud patterns (split orders to stay below approval thresholds, suppliers sharing a bank account with an employee, bank details changes followed immediately by a payment). This level is relevant for larger organisations and companies in sectors with high fraud risk.
7. GRC-ERP Deployment Plan in 90 Days
A GRC deployment is not a single project. It happens in phases. Here is a three-month plan for mid-market companies starting from an existing ERP with no dedicated GRC platform.
Month 1 — Audit of existing ERP controls
- Map active roles and access rights in the ERP: how many users, how many profiles, how many SoD conflicts identified.
- Analyse access logs from the past 12 months: off-hours logins, access to sensitive modules, configuration modifications.
- Assess dormant access rights: active accounts with no login in more than 90 days.
- Inventory applicable regulations and required compliance evidence.
This diagnostic takes 15 to 20 working days for a company of 1,000 employees. It must involve the CIO, Risk Manager, Compliance Officer and Internal Auditor.
Month 2 — GRC platform selection and configuration
- Solution selection based on regulatory scope and the ERP in place (SAP GRC if the company runs SAP, ServiceNow or MetricStream otherwise).
- Risk register configuration with taxonomy adapted to the sector.
- Configuration of data feeds from ERP: API connections or ETL connectors.
- Training of Risk Managers and process owners.
Month 3 — Flow integration and ramp-up
- Activation of real-time flows between ERP and GRC.
- First risk mapping run with real ERP data.
- Deployment of remediation workflows for detected SoD conflicts.
- Training of internal auditors on using GRC reports for statutory audit preparation.
What NIS2 and DORA Change in Practice for Your GRC
Two European directives make GRC formalisation urgent for many mid-market companies.
NIS2 Directive (2022/2555) requires essential and important entities to implement formalised cybersecurity risk management: documented security policies, risk mapping for information systems, incident response procedures. The ERP, as a critical information system, is at the heart of this obligation. NIS2 demands a risk mapping that ERP alone cannot produce.
DORA Regulation (2022/2554), applicable since 17 January 2025, goes further for the financial sector. It requires an ICT third-party register, resilience testing, and third-party risk governance covering ERP vendors themselves. A dedicated article details the DORA obligations for your financial ERP.
The Cultural Dimension: a GRC Tool Does Not Replace a Risk Culture
An essential point that GRC platform buyers often forget: a tool does not create a risk culture. It can reveal, structure and accelerate it, but it cannot replace it.
Organisations that fail in their GRC deployments have generally installed a tool without having first clarified who is responsible for what in risk management. Is the Risk Manager informed of detected incidents? Do process owners actually populate the risks in the tool, or do they let the register degrade? Does the executive team spend 30 minutes a month reviewing the risk dashboard?
The GRC tool is an amplifier. If risk culture is weak, the tool amplifies its gaps. If the culture is strong, the tool makes it visible, measurable and auditable.
To go further, see our related articles on this topic:
- 12 ERP SoD Controls to Implement Before Your Annual Audit — the first level of GRC in ERP, practical and actionable
- DORA and ERP: Digital Operational Resilience Requirements for the Financial Sector — the DORA regulatory framework in detail
- NIS2 and ERP: Cybersecurity Compliance for Mid-Market Companies — NIS2 obligations and their impact on your IT systems
