ERP systems hold the most sensitive data in your business. Financial records, employee salaries and identification numbers, customer contact and payment information, supplier pricing and contracts. If that data is exposed, modified without authorization, or lost, the consequences are immediate and serious.
Security is not a feature you add to an ERP system after it's built. It's a design requirement from the beginning, and there are specific practices that distinguish a well-secured system from a vulnerable one.
Role-Based Access Control
The most fundamental ERP security principle: not every user should be able to see or do everything in the system.
A warehouse staff member needs to record goods receipts, process stock transfers, and view inventory levels. They have no legitimate need to view employee salaries, customer credit limits, or the company's financial statements. A sales representative needs customer information and order history. They shouldn't be able to adjust pricing in the master price list or view the supplier purchase costs that determine margins.
Role-based access control (RBAC) defines what each role can see and do in the system, then assigns users to roles. Changes to access are made at the role level, not individually — when a new sales rep joins, you assign them the sales representative role, which already has the correct permissions configured.
Good RBAC design starts from the principle of least privilege: every user has access to exactly what they need to do their job, and nothing more. In practice, this requires mapping each role's actual daily tasks and designing permissions from those tasks — not from a default template that grants broad access.
Common access control mistakes:
- Giving admin-level access to early users for convenience and never restricting it when the team grows
- Creating a single "operations" role that combines permissions from multiple functions because it was easier to configure
- Not removing or adjusting access when someone changes roles or leaves the company
The last point matters specifically for offboarding. When an employee leaves, their ERP access should be deactivated on their last day — not when someone gets around to it. A former employee with active credentials is an unnecessary risk.
Audit Trails
An audit trail records who changed what and when. Every transaction in the ERP should be attributable to a specific user at a specific time. Every modification to master data — a change in a customer's credit limit, an adjustment to inventory quantity, a change in payroll records — should be logged with the before-value, the after-value, the user who made the change, and the timestamp.
The value of audit trails is twofold.
For operations: when something goes wrong — an inventory discrepancy, a financial record that doesn't match expectations, an invoice that appears to have been modified — the audit trail tells you what happened. Who created this transaction? Was it modified after creation? By whom and when?
For compliance: Indonesian businesses increasingly face scrutiny from DJP on financial records. The ability to show that a financial record was entered correctly and was not subsequently modified without authorization is valuable in an audit context. An audit trail that is complete and cannot be edited after the fact (write-once logging) provides this assurance.
Audit trails should not be optional. They should be on by default for all financial transactions and all modifications to sensitive master data.
Data Backup and Recovery
Every ERP system should have an automated backup schedule. The frequency depends on how much data you can afford to lose in a worst-case scenario.
For a business with hundreds of transactions per day, losing a full day's data is a serious operational problem. Hourly or continuous backups are appropriate. For a business with lower transaction volumes, daily backups may be acceptable.
Backups are only useful if they work. A backup that's never been tested is an assumption, not a safety net. Backup testing — periodically restoring from backup to a test environment and verifying the data integrity — should be a scheduled activity, not something done only after a failure.
The recovery time objective matters: if your ERP is unavailable, how long can the business operate before it becomes critical? The answer determines how fast your recovery infrastructure needs to be. A business that can operate for 48 hours manually while the system is restored has different infrastructure requirements from one that can't function for more than four hours.
Backups should be stored separately from the primary system. A backup stored on the same server as the production database provides no protection against server failure.
HTTPS and Encryption
All ERP access, whether on a browser or a mobile app, should be encrypted in transit using HTTPS. Security considerations extend beyond the ERP itself to the APIs it connects with — ERP third-party integration and API security is relevant here, since external system connections introduce additional attack surface that needs to be accounted for in the overall security design. This prevents network eavesdropping — someone intercepting the data passing between your browser and the server.
This is standard for any modern web application and should be verified, not assumed. A browser warning about "not secure" when accessing the ERP is a serious flag.
For sensitive data stored in the database — employee identification numbers (NIK/KTP), bank account details, NPWP tax identification numbers — database-level encryption should be considered, particularly for businesses with significant personal data holdings.
Password and Authentication Policies
Basic password requirements — minimum length, complexity, periodic change — are the minimum baseline. A password policy that's never enforced is not a policy.
For businesses with sensitive data, multi-factor authentication (MFA) for ERP access is worth considering. This requires users to confirm their identity through a second factor — typically a code sent to their registered phone — in addition to their password. This significantly reduces the impact of a compromised password.
Single sign-on (SSO) integration with corporate identity systems is worth considering for larger organizations — it centralizes identity management and ensures that when someone's corporate account is deactivated, their ERP access is automatically revoked.
Indonesian Personal Data Protection (UU PDP)
Indonesia's Personal Data Protection Law (UU No. 27 Tahun 2022) establishes requirements for how personal data must be handled. ERP systems that store customer information, employee data, and other personal data are subject to these requirements.
Relevant obligations under UU PDP for ERP purposes:
- Personal data must be protected with appropriate security measures against unauthorized access, disclosure, modification, and loss
- Data subjects have the right to access information about how their data is used and to request correction of inaccurate data
- Data breaches must be reported to the supervisory authority and affected individuals within a defined timeframe
These aren't just compliance checkboxes. They represent good security hygiene — the kind of practices that also protect your business from operational damage when something goes wrong.
Questions to Ask Your ERP Vendor or Developer
When evaluating an ERP implementation partner's approach to security:
- How is RBAC designed and maintained? Who controls access changes?
- What data is covered by the audit trail, and is the trail write-protected?
- What is the backup frequency, storage approach, and recovery testing schedule?
- Is MFA available for user authentication?
- How are security patches and updates managed for the hosting environment?
- What happens to data security if we stop the maintenance relationship?
Good implementation partners answer these questions with specifics, not generalities. "We take security seriously" is not an answer. A described backup architecture, a defined role management process, and a clear update policy are answers.
CERIS builds ERP systems with security requirements addressed from the design phase, not added as an afterthought. See what we build or contact us to discuss what appropriate data security looks like for your business.
