What Regulatory Frameworks Should an ERP Actually Support?
A 200-employee medical device distributor learned the hard way that ERP compliance isn't one feature to check off. During a customer audit, they discovered their system tracked FDA UDI (Unique Device Identification) numbers correctly but had no built-in workflow for the 21 CFR Part 11 electronic signature requirements their quality process actually needed, two different compliance obligations, both relevant to the same company, and their ERP only covered one of them. The lesson generalizes: before evaluating whether an ERP is "compliant," you need to know which specific frameworks apply to your business, because they impose genuinely different requirements on the system.
Compliance isn't one thing, it's a stack of separate obligations
Most mid-sized businesses are actually subject to several overlapping regulatory frameworks at once, each with a different origin and a different set of demands on the ERP:
- Financial reporting rules (SOX, for U.S. public companies or their vendors): requires demonstrable internal controls over financial reporting, segregation of duties between who can create and who can approve a transaction, and change management controls over the financial system itself.
- Data privacy regulations (GDPR, CCPA): requires the ERP to support data subject access requests, the right to erasure, and clear records of what personal data is stored where and why, which for an ERP usually means customer and employee records scattered across sales, HR, and support modules.
- Industry-specific frameworks: FDA 21 CFR Part 11 for pharmaceutical and medical device companies, ITAR for defense contractors, HIPAA for healthcare-adjacent businesses, PCI DSS for anyone processing card payments directly. Each imposes requirements that have nothing to do with the others.
- Tax and trade compliance: multi-state sales tax nexus rules, or import and export documentation requirements for companies trading across borders.
A company can be fully compliant with one of these and have a meaningful gap in another, which is exactly what happened to the medical device distributor above.
The cost of getting this wrong isn't hypothetical. GDPR fines can reach up to 4% of global annual revenue for the most serious violations; a failed SOX audit finding can trigger a formal remediation plan that slows or blocks a planned acquisition or public offering; a lost 21 CFR Part 11 certification can halt a regulated product's ability to ship at all until the gap is closed. None of these penalties come from a company having bad intentions. They typically come from a compliance requirement nobody mapped to a specific system control before the audit happened.
What each framework actually requires the ERP to do
SOX and financial controls
For a public company, or a private company preparing for acquisition or IPO, the ERP needs role-based permissions that enforce separation of duties. The person who enters a vendor invoice can't be the same person who approves payment to that vendor, and the system needs to enforce this structurally, not just through a policy document. It also needs formal change management: any modification to financial workflows, chart of accounts structure, or approval thresholds needs to be logged, reviewed, and approved before deployment, not pushed live by whoever has admin access that week.
GDPR and data privacy
The practical requirement here is less about security (though that matters too) and more about the ERP being able to answer, on request, what personal data it holds on a given individual, and whether it can delete it. That's harder than it sounds in a system where a customer's name and contact information might appear in the CRM, the order history, the support ticket module, and an old marketing export, all as separate records. An ERP evaluated for GDPR fitness needs either a unified customer data model or a documented, tested process for finding and purging records across every module where personal data could live.
Industry-specific frameworks
These tend to be the most concrete and the easiest to verify, because they're usually written down as specific technical requirements. Part 11 requires electronic signatures with specific authentication properties for regulated document approvals; PCI DSS requires that card data either never touches the ERP's database directly or is tokenized through a certified payment processor. The risk with industry frameworks isn't ambiguity, it's assuming a general-purpose ERP module labeled "compliance" automatically covers the specific one your industry needs, when in practice most general ERPs support these as add-on modules or third-party integrations rather than native functionality.
Tax and trade compliance
This category deserves a closer look than a one-line summary suggests, particularly for companies selling across U.S. state lines since the 2018 Wayfair Supreme Court decision redefined how sales tax nexus works. An ERP handling multi-state sales needs either a built-in tax engine or a certified integration with a dedicated tax compliance service (Avalara, Vertex), because nexus rules, which vary by state and change periodically, are not something most finance teams can track accurately by hand once a business sells into more than a handful of states. Companies moving goods across borders face a parallel problem with export documentation and denied-party screening, where the ERP needs to flag a shipment against restricted-party lists before it goes out, not after. Getting this wrong doesn't just create paperwork; a shipment released to a restricted party can trigger real regulatory penalties against the exporting company regardless of whether the violation was intentional.
A practical framework-mapping exercise
Before evaluating ERP vendors on compliance, it's worth building a simple table mapping which frameworks actually apply to the business, with legal or a compliance consultant signing off on the list rather than guessing:
| Framework | Triggers when... | Core ERP requirement |
|---|---|---|
| SOX | Public company, or vendor/subsidiary of one | Segregation of duties, change controls |
| GDPR / CCPA | Handling EU or California resident data | Data subject access and erasure workflows |
| 21 CFR Part 11 | FDA-regulated manufacturing or distribution | Validated electronic signatures |
| PCI DSS | Processing card payments directly | Tokenized or segregated card data handling |
| ITAR | Defense or controlled-technology exports | Access controls restricting data to authorized persons |
Vetting a vendor's compliance claims
"Our ERP is compliant" is not a specific enough claim to evaluate. The useful question in a vendor call is narrower: which specific framework, which specific requirement within it, and can they show a reference customer in your industry who has actually passed an audit using the system configured the way you'd configure it. A vendor that answers with a SOC 2 Type II report is telling you something different than one that answers with a generic security whitepaper. The first is independently audited evidence; the second is marketing. For frameworks like SOX or Part 11 in particular, ask whether the compliance controls are native to the platform or delivered through a third-party add-on, since add-ons introduce their own integration and support risk on top of the core system.
Building the framework list before you shop, not during
The most common sequencing mistake is starting ERP vendor demos before the compliance framework list is finalized internally. Legal, finance, and whoever owns industry-specific regulatory relationships (a quality director in a regulated manufacturer, a data protection officer if one exists) should sign off on the list of applicable frameworks first. Walking into a vendor conversation already knowing you need Part 11 electronic signatures and SOX-grade segregation of duties, specifically, gets a far more useful answer than asking a vendor to tell you what compliance features they have and hoping the list happens to match what your business actually needs.