ERP security due diligence: ask for evidence and owners
Review ERP access, data flows, recovery, logging, supplier responsibilities, and incident procedures with evidence that applies to the service you will buy.
ERP security due diligence should identify the data and critical processes involved, ask for evidence that applies to the proposed service, and assign customer responsibilities. A security badge or a general claim of compliance is not enough. Have qualified security and privacy owners evaluate the actual deployment, configuration, connected systems, and contract.
Start with data and business consequences
Inventory the data the ERP and its integrations will process. This may include customer, supplier, employee, pricing, payment, inventory, and financial records. Describe where data enters, where it is copied, who accesses it, and which other services receive it. Include migration files, test environments, logs, exports, and support access rather than treating the production database as the entire system.
Identify critical business activities and the consequences of unavailable, incorrect, or exposed data. A purchasing system may be important for cash control while warehouse availability affects shipping. Those consequences inform access design, recovery requirements, and supplier questions. Do not assign a universal security rating to an ERP product without understanding how your organization will use it.
Ask specific, scoped questions
| Area | Evidence question |
|---|---|
| Identity | How are users authenticated and removed? |
| Permissions | Can required duties be separated and tested? |
| Logging | Which events are recorded, retained, and accessible? |
| Recovery | What is restored, by whom, and how is it tested? |
| Support access | Who can access customer data and under what controls? |
| Incident process | Who notifies whom, through which channel, and when? |
Request current documents and note their scope, period, limitations, and relevance. An assurance report about a different service or region may not answer your question. Review what the report expects the customer to do. Where evidence is confidential, use the supplier's authorized review process; do not ask employees to circulate restricted reports casually through the project team.
Distinguish provider duties from customer duties
A provider may operate infrastructure while the customer administers identities, permissions, integrations, records, and business procedures. Write those boundaries into a responsibility matrix. If a partner manages configuration, specify how changes are requested, approved, tested, and logged. Shared responsibility should identify actual handoffs instead of leaving both parties expecting the other to act.
Test the roles used in critical workflows. An approval control is not demonstrated by showing that an administrator can complete the transaction. Check that an ordinary user cannot bypass the intended limit and that an authorized user can perform their job without borrowing credentials. Include joiners, role changes, leavers, emergency access, and service identities in the operating procedure.
Price the controls that require work
Security-related effort may include identity integration, role design, logging review, recovery tests, access recertification, and secure integration operations. Ask which capabilities are included in the proposed tier and which require additional products or services. Do not assume a feature is included merely because it exists somewhere in the vendor's catalog.
Keep the effort traceable. A project might need a role-design workshop, configuration, negative testing, and documentation. Price those tasks from the actual scope rather than inventing a security surcharge. If a control is unavailable, have the appropriate owner evaluate the consequence and any alternative. A project budget cannot resolve a security gap simply by assigning it a nominal dollar allowance.
Use official resources within their limits
NIST's Small Business Cybersecurity Corner links to cybersecurity basics, cloud security, access-related topics, and practical planning resources. Use it to structure conversations with your team. It does not certify an ERP vendor, validate a particular implementation, or replace obligations arising from your industry, customer contracts, or applicable law.
Have counsel and privacy specialists review material data-processing and notification provisions. Record outstanding questions as conditions of approval where appropriate. Before launch, verify the customer's own responsibilities are funded and assigned. A well-researched supplier assessment is incomplete if the organization has no owner for removing departed employees, investigating alerts, or validating recovery results.
Approval worksheet
At the approval meeting, separate documents received from conclusions reached. A report can be present while its scope has not been assessed. Record which reviewer evaluated it, what service and period it covers, which customer responsibilities apply, and which questions remain. Do not circulate a binary “security passed” label without the conditions and limitations that make it meaningful.
Before production access is released, test the organization's own procedures using representative identities. Remove a departed test user, change a role, review a privileged action, and trace a critical integration credential to its owner. Exercise the incident contact route and confirm that recovery responsibilities are understood. Retain the evidence under appropriate access controls. These practical checks make the supplier assessment relevant to the actual implementation and identify work that must continue after the buying decision, when the project team is no longer available to answer every question.
FAQ
Does a security report prove our implementation is secure?
No. Review its scope and limitations and assess the customer configuration and responsibilities. Supplier assurance is one input, not a guarantee of the organization's end-to-end system.
Should security review wait until the final vendor is selected?
Bring material requirements into the shortlist and scope stages. Otherwise the team may discover that a required feature changes the license tier, deployment design, or feasibility after negotiating the commercial offer.
Can a general checklist establish legal compliance?
No. Requirements depend on data, activities, contracts, jurisdiction, and industry. Use qualified advisers for those determinations and retain their requirements in the scope and acceptance plan.
Sources
- NIST Small Business Cybersecurity Corner — official security planning resources; not an ERP certification or legal compliance checklist.
Continue the workbook
- ERP project risk register: turn concerns into actions
- ERP exit planning: test the export before you need it
- ERP go-live support: budget for stabilization and ownership
Use the ERP total cost calculator for your own scenario, the quote readiness checklist to track evidence, and the cost structure comparison to review purchasing models.
