POS Security, User Permissions and Backup Recovery
Your POS holds customer records, payment references and the history of the business. Decide who can change those records and how the business will recover them before trading starts.
Give each role a written list of actions
Separate ordinary selling from changes that affect money, stock and ownership. Write down who can issue a refund, reduce a price, change a stock count, export customer details and create another account. Check these permissions in the application using a test account for each role.
An accountant may need statements and exports without needing permission to edit the catalogue. A cashier may need to view a customer balance without seeing private notes or every location. Avoid sharing one owner password across the counter.
| Action | Control to test |
|---|---|
| Refund or credit | Named approver and original transaction reference |
| Price or stock change | Reason, user and original value retained |
| Customer export | Explicit permission and activity record |
| New user or device | Owner approval and prompt revocation |
| Closed period | Controlled reopening and recorded reason |
Rehearse a lost device and a departing employee
Sign in on a second test device, revoke its access from the owner account and attempt another request. Check whether private screens and cached files remain available. Repeat after changing a password and after disabling a user.
Use an authenticator where supported and store recovery codes separately. Keep the recovery process with a responsible person who can restore access during trading hours. Never send passwords, full card numbers or secret payment keys in a public support form.
Ask to see a restored backup
Agree how much recent activity the business could reconstruct if the server failed. Then agree how long it could operate without the system. These decisions set the backup frequency and recovery procedure.
A restore test should open a separate copy and compare product counts, stock quantities, invoices, customer balances and payment references. Record the backup date, recovery steps and any missing files or configuration. Keep a copy in a separate location under the agreed encryption and access policy.
Ask who controls the encryption keys. A database file alone may be insufficient when attachments and protected integration settings are stored separately. Document how every required part is recovered without exposing credentials to ordinary staff.
Include access and exit terms in the contract
Request usable exports and a sample file before signing. Specify how long records remain accessible after cancellation, who owns custom source code and who responds during a security incident. Keep the support responsibilities for the POS and payment processor separate.
The current DSDillon POS uses an owner sign in and scheduled database backups. Additional staff roles, two factor access and offsite recovery belong in the agreed deployment and acceptance scope. Staff access stays disabled until the owner explicitly authorizes it.
Questions before you decide
Does a cloud backup guarantee recovery?
Recovery needs a usable copy, any required keys and files, and a tested procedure. Ask for a restore demonstration and the documented recovery time.
Should a cashier use the owner account?
Use individual accounts with the permissions required for the role. Keep owner access for authorized administrative actions.
Tell us how your business sells.
Share your business type, locations, currencies, invoice requirements and payment providers. We will scope the workflow, connections and acceptance tests.
