Data Security in Business Software: What to Verify Before You Commit

An ERP concentrates everything valuable about a business in one place: customer records, pricing, margins, supplier terms and financial position. That concentration is the point of the system — and also its main risk. This article covers the controls worth verifying, in the order they matter.

Access Control

The most common weakness is not a sophisticated attack; it is that everyone can see everything. Practical requirements:

• Role-based permissions. Permissions attached to roles, not individuals. When someone changes job, you change their role rather than auditing dozens of individual settings.
  
• Field-level restriction. A sales representative may need the customer record but not the cost price. If permissions only work at screen level, this is impossible.
  
• Record-level scope. A regional manager sees their own region. Without this, "read access" means read access to everything.
  
• Export limits. The ability to export the full customer list to a spreadsheet is the single most common route for data to leave a company. It should be restricted and logged.
  
• Prompt deactivation. Accounts of departed employees closed the same day. Reviewing dormant accounts quarterly catches what leavers processes miss.
  

Audit Logging

Knowing who did what and when matters both for security and for resolving internal disputes. A useful audit log records the old and new value on changes, not just that a change occurred. It should cover price changes, discount overrides, stock adjustments, payment records and permission changes — and it must not be editable by the people it records.

Backup and Restore

Every vendor says backups are taken. The questions that matter are about restoring:

• How often are backups taken, and how much data would a failure lose? Nightly backups mean a day's work at risk.
  
• How long does a restore take? This is the number that determines your downtime, and it is rarely quoted unless asked.
  
• Are backups held somewhere separate? A backup on the same infrastructure does not survive an event affecting that infrastructure.
  
• When was a restore last tested? An untested backup is an assumption, not a safeguard. Ask for the date of the last successful restore test.
  
• Can you take your own copy? Independent of the vendor's process.
  

Encryption and Transport

Data in transit should be encrypted end to end — including any integrations with marketplaces, banks or logistics providers, which are often overlooked. For data at rest, ask specifically whether database-level encryption is applied and where the keys are held.

Data Residency and Compliance

• Where the servers physically sit, and whether that satisfies your regulatory obligations.
  
• Which subprocessors the vendor uses, and where they operate.
  
• Retention periods for personal data, and whether deletion is actually enforced when they expire.
  
• How a data subject's access or deletion request is fulfilled in practice — through a screen, or by opening a support ticket.
  

Practical Habits

• Enable multi-factor authentication. Especially for administrator accounts and any external access.
  
• Restrict administrator count. Two or three people is usually sufficient. Everyone being an administrator is convenient until it is not.
  
• Review permissions periodically. Permissions accumulate; nobody removes them. A twice-yearly review keeps this in check.
  
[*]Use separate test data. Copying live customer data into a test environment quietly widens your exposure.

In Short

Security in business software is mostly about access discipline and verified recovery, not exotic threats. Attach permissions to roles, restrict exports, keep an audit log the administrators cannot edit, and insist on evidence that restores have been tested.

We are happy to answer all of these in writing for Mekjoy. Get in touch to discuss your requirements.