A practical guide for SMEs to recover POS, inventory, payroll, and customer data when devices fail, accounts are hijacked, or ransomware hits.
Backup is an operating decision
A broken cashier laptop can stop sales faster than a slow marketing week. A hijacked admin account can lock staff out of inventory, payroll, and customer history before anyone knows who should respond.
Many SMEs say they already have backup because files are copied to a shared drive. That is a start, but it is not yet disaster recovery. Recovery means knowing which systems must return first, who restores them, and what data loss the business can tolerate.
For Sundie clients, the useful question is operational. If the device, account, or server fails today, can the team sell, count stock, pay people, and serve customers without improvising from chat history?
Map the systems that keep money moving
Start with the systems that touch transactions and obligations. For many Indonesian SMEs, that list includes POS, inventory, customer database, payment records, attendance, payroll, simple finance, website orders, and shared documents.
Do not treat every file as equally urgent. Product photos may wait. Today’s sales records, unpaid invoices, employee attendance, supplier balances, and customer contact data usually cannot wait long.
Write a short dependency map. The POS may need product data from inventory. Payroll may need attendance logs. A sales dashboard may depend on the same database used by the cashier app. This map prevents the team from restoring the wrong thing first.
Set recovery targets before the incident
Two simple targets make recovery practical. Recovery time objective is how long the business can operate with a system down. Recovery point objective is how much recent data the business can afford to re-enter or lose.
A retail POS may need a short recovery time because every hour affects sales. Payroll may allow a longer recovery time, but poor backup can still create salary disputes if attendance records disappear.
These targets do not need enterprise language. A useful version can fit in one table. System, backup frequency, maximum downtime, maximum data gap, owner, and restore method.
Use layered backups, not one folder
A single synced folder is fragile. If ransomware encrypts local files and the sync tool mirrors the damage, the backup may become useless. If one admin account is hijacked, shared storage can be deleted or altered.
Use layers. Keep automated database backups, document backups, and configuration exports. Store at least one copy away from the everyday account. Use version history where available, and protect the backup account with multi factor authentication.
For custom apps, include the database, uploaded files, environment settings, integration keys, and deployment notes. A clean database backup is not enough if no one can rebuild the app or reconnect payment, email, and reporting services.
Control access so backup does not become the next risk
Shared admin passwords are convenient until a staff member leaves, a phone is stolen, or a phishing message works. Recovery planning should reduce account risk, not create a larger master key.
Separate daily user access from admin access. Cashiers should not be able to delete backup sets. Supervisors may approve stock adjustments without seeing payroll exports. Developers or vendors should use named accounts rather than borrowed owner logins.
Keep a small access register. Note who can restore, who can delete, who can invite users, and who receives security alerts. Review it whenever staff roles change.
Test restore with a small drill
A backup that has never been restored is only a hope with a timestamp. Testing does not need to be dramatic. Pick one system and restore it into a safe test environment.
Check whether the restored app opens, the latest records are present, uploaded files still appear, reports match expected totals, and user access behaves correctly. Record how long the test took and where the team got stuck.
Run this drill before peak season, before payroll week, or after major app changes. The goal is not to blame anyone. The goal is to turn panic steps into a repeatable runbook.
Prepare a simple recovery runbook
A runbook is a calm checklist for a bad day. It should name the incident owner, affected systems, first contacts, decision rules, backup location, restore steps, and customer or staff communication notes.
Keep the runbook outside the systems it protects. If the company email or shared drive is inaccessible, the team still needs emergency phone numbers, vendor contacts, and the order of recovery.
For a typical SME, the first version can be short. Stop the spread, secure accounts, preserve evidence, restore the most critical system, validate data, then communicate the safe operating mode to staff.
Where Sundie can help
Sundie helps SMEs and organizations design websites, business dashboards, POS, inventory, attendance and payroll, finance workflows, mobile apps, PWAs, and maintenance routines with recovery in mind.
That can include database backup schedules, role based access, audit logs, restore documentation, staging environments, monitoring, and practical drills for owners and ops teams.
The best time to discuss recovery is before the incident. If your operations depend on an app or database, Sundie can help review what must be backed up, how it should be restored, and what the team should do first.
Sources used
NIST SP 800-34 Rev. 1 informed the contingency planning and recovery runbook structure.
ISO 22301 informed the business continuity framing around critical processes, roles, and service continuity.
NIST Cybersecurity Framework 2.0 and the UK National Cyber Security Centre small organisations guide informed the practical account, backup, and recovery controls.