A backup is useful only if the business can recover the right records, open them in a working system and resume controlled trading. A green “backup complete” message does not prove that receipts, stock, customer balances and permissions can be restored after a lost laptop or compromised account.
For a retailer evaluating Bizman, make recovery part of the buying conversation. Ask BriskRetail to demonstrate the proposed backup, export and restore process for your deployment, with responsibilities and support terms written down. This is our primary recommendation because recovery needs to fit the system the shop will actually operate; no specific Bizman recovery time, hosting arrangement or security certification is assumed here.
Commercial disclosure: BriskRetail offers Bizman. This affiliated guide uses authoritative security guidance and original fictional exercises, not a security audit or a hands-on recovery test of the product. Research was checked on 23 October 2026. Legal incident-response requirements need qualified review for the particular business.
COVER BRIEF — Original illustration, 1600 × 900. A retailer checks restored receipts on a clean spare workstation beside a sealed recovery checklist. Alt text: “A shop verifies restored sales and stock records before reopening its system.” No certification symbol or claim of an actual incident; artwork pending.
1. Identify what would stop the shop trading
Start with business tasks rather than a list of devices. Can the shop retrieve current prices, record a sale, confirm payment, issue a receipt, check stock and process a return? Which tasks depend on internet service, the local network, a particular computer, a cloud account or an external payment provider?
Write down the dependency chain. The application may be available while the only person with administrator access is unreachable. A database may be recoverable while the licence, printer setup or encryption key is missing. A customer list may survive while its opt-out history does not.
Separate ordinary outage planning from a suspected compromise. A power failure may permit a tested offline procedure. An infected till should not simply be placed into offline mode and trusted. Staff need to know when to use the continuity process and when to stop using the affected device.
The FBI’s cyber-resiliency guidance recommends understanding critical assets and testing recovery. It is general security guidance, not Nigerian law or a promise that a particular backup design prevents every loss. Use it to frame a realistic business-impact discussion with your supplier.
2. Set recovery objectives in plain language
The recovery point objective, or RPO, describes how much recent data the business can tolerate losing, expressed as time. A 15-minute RPO means the recovery design must aim to recover to a point no more than 15 minutes before the incident. It does not mean all work within that interval is automatically reconstructable.
The recovery time objective, or RTO, is the target time to restore an agreed usable service after disruption. Define the service: one working till may be a different target from every branch and report. Include detection, access to a clean device, restoration and business verification in the plan.
| Business function | Fictional objective | Dependency to test |
|---|---|---|
| Record ordinary sales | RPO 15 minutes; RTO 2 hours | Recent records, clean till and approved payment process |
| Retrieve customer balances | RPO 15 minutes; RTO 2 hours | Invoice and allocation history, not just a total |
| Review management reports | RPO 24 hours; RTO 1 working day | Complete exports and usable reporting definitions |
| Retrieve older supporting documents | RPO 24 hours; RTO 2 working days | Archive permissions and readable file formats |
These are illustrative targets, not recommended defaults or Bizman commitments. A shop completing many credit transactions may need a tighter target than a business that can safely record a small number on controlled paper forms. Choose objectives after considering impact, cost and staff capacity.
Suppose the last recoverable point is 13:45 and disruption occurs at 14:00. Fifteen minutes of records are at risk. If the shop processes 12 transactions per hour, three transactions would fall in that interval only under an even-rate assumption; actual activity could be much higher. Use real peak periods when sizing the process.
3. Distinguish exports, synchronisation and recoverable backups
A product CSV can help rebuild a catalogue, but it may omit transaction history, permissions, tax settings, attachments and customer allocations. Synchronisation can copy accidental deletions to another location. Neither should be described as a complete recovery solution without a tested scope.
Shopify’s backup and duplication documentation gives a useful concrete example: CSV exports cover several record types, but store duplication has important limits and some settings require manual reconfiguration. Do not infer that exporting products recreates an entire business system.
For the proposed Bizman deployment, request a recovery inventory: database, attachments, configuration, application version, licence dependencies, encryption keys, integrations and device settings. Confirm what the retailer can export independently and what requires supplier assistance. Record the format, frequency and retrieval process.
Protect recovery copies from the same credentials and failure modes as the live system. The CISA StopRansomware Guide recommends offline encrypted backups and regular recovery testing. Its guidance also addresses cloud risks; cloud hosting does not transfer every responsibility away from the retailer.
Keep authorised access to encryption keys and recovery codes available through a controlled emergency process. Storing the only key on the computer being backed up defeats the purpose. Equally, leaving a plaintext key with an openly accessible customer-data export defeats the protection. Assign an owner and an alternate, and test access without sharing secrets in ordinary chat groups.
DIAGRAM BRIEF — Original dependency diagram, 1440 × 960. Live records, separately protected backup, controlled key access and isolated restore environment. Alt text: “Recovery needs data, configuration and authorised access outside the failed system.” Conceptual design, not a verified hosting architecture; image pending.
4. Reduce everyday opportunities for compromise
Use named accounts and grant each role only the access its job requires. A cashier may need to complete sales but not export all customers, edit cost prices or create administrators. A manager’s approval should be attributable to that manager rather than to a shared password.
Loyverse’s access-rights documentation demonstrates that permissions are configurable and tied to product features. Use a role-by-role demonstration in any software evaluation. A supplier’s statement that “permissions are supported” does not establish that your specific restriction can be enforced.
Protect email and administrator accounts with appropriate multi-factor authentication where supported, preferably phishing-resistant methods for high-risk access. Keep operating systems and supported applications updated through a controlled maintenance routine. Record who manages the router and any remote-support software; forgotten access paths can outlive the employee or contractor who installed them.
Train staff on plausible retail messages: a fake settlement problem, a delivery attachment or someone claiming that support needs a password or one-time code. Verify unusual requests through an independently known channel. Do not teach staff to judge authenticity solely by a familiar logo or sender display name.
Keep guest access separated from business systems where the network supports it, and lock unattended devices. These are practical risk-reduction steps, not a guarantee. Ask a competent technician to implement network changes and confirm that printers and required services still function afterward.
5. Run an isolated restore drill and inspect the result
Schedule a drill when it will not disrupt trading. Use an approved test environment isolated from live payment, messaging and fiscal integrations. A restored production database can otherwise resend notifications or duplicate external actions. Use synthetic or appropriately protected records and limit access to the drill team.
Select a backup, record its timestamp and restore it according to the supplier’s procedure. Open the application using the required version. Confirm that the restored business is the expected one, not a similarly named old copy. Test permissions before allowing wider access.
| Drill check | Example evidence | Pass condition |
|---|---|---|
| Recovery point | Latest restored transaction reference and time | Meets the agreed RPO |
| Financial records | Sample sale, return and credit allocation | Relationships and totals reconcile |
| Stock | Sample SKU movements and location balances | Movement history explains the balance |
| Access and integrations | Role test; disabled outbound actions | No unintended privileged access or live sends |
| Recovery time | Start, ready and verified timestamps | Meets the defined service RTO |
In a fictional drill, preparation takes 20 minutes, restoration 50 minutes and business verification 25 minutes. Total recovery time is 95 minutes against a 120-minute target, leaving 25 minutes of headroom. If the latest usable data is 45 minutes old against a 15-minute RPO, the drill still fails its recovery-point requirement. A fast restoration of old data is not a complete pass.
Keep the result, failures, corrective actions and retest owner. Do not record a pass simply because the software opens. Include at least one partial payment, a returned item and a changed permission, because these relationships are easy to overlook in a superficial check.
6. Reconcile trading that happened during the gap
If an approved manual process is used, give each temporary transaction a unique reference. Record time, items, quantities, amounts, payment method and the staff member responsible. Store the forms securely and avoid unnecessary customer details. Agree which operations are too risky to continue without the system.
Payment confirmation must remain independent of customer screenshots. A card terminal may have taken money even though the till record is missing. Use provider and bank evidence to determine the payment result before asking the customer to pay again or issuing a refund.
When service returns, compare the temporary record with restored transactions before entering it. Mark every reconstructed item with its source reference. This prevents a transaction that survived in another system from being added twice. Reconcile stock effects and customer balances as well as cash.
Nominate one person to control the catch-up queue and another to review it. Where the record is uncertain, keep an exception rather than inventing a sale or forcing a balance. The payment reconciliation guide provides a useful companion workflow for explaining settlement differences.
7. Keep an incident runbook available without the affected account
The first response should be easy to follow under pressure. Do not keep the only runbook in an email account that may be locked or compromised. Maintain a controlled offline copy and review the contacts regularly.
| Runbook field | What to fill in before an incident |
|---|---|
| Incident lead and alternate | Names, independent contact routes and decision authority |
| Technical responders | Supplier support, hosting contact and qualified security assistance |
| Immediate containment | Who can isolate a suspected device or account and record actions |
| Business continuity | Permitted manual tasks, temporary references and spending limits |
| Legal and external communication | Privacy adviser, bank/provider contacts and reporting assessment owner |
| Recovery approval | Evidence required before reconnecting systems and resuming normal use |
For suspected compromise, isolate affected systems from the network and contact the designated responder. Preserve evidence; avoid an improvised wipe or reconnecting the device to “see if it works.” CISA’s response checklist distinguishes containment, investigation and recovery. Your responder should adapt the technical steps to the actual incident.
The Nigeria Data Protection Act, section 40 requires a controller to notify NDPC within 72 hours of awareness of a breach likely to risk individuals’ rights and freedoms; high-risk breaches also trigger communication to affected people. Obtain prompt professional assessment, including any other applicable reporting duties. Recovery of a backup does not establish that copied customer data is safe or that notification is unnecessary.
8. Compare supplier recovery promises with business needs
Ask the Bizman team who performs backups, who monitors failures, how long usable recovery points remain available and who can request a restore. Obtain a named escalation route and a clear explanation of support hours. An uptime percentage is not an RPO or an RTO.
Check the scope of any service-level commitment: does it cover only infrastructure, the application, or a usable retail workflow? Does the stated recovery time start when the incident occurs or when a paid support ticket is accepted? What happens if the retailer has lost administrator access or stopped paying the supplier?
Ask for an exit rehearsal too. Retrieve products, stock movements, transactions and relevant customer balances in a documented usable format. A downloadable file is only helpful if another authorised person can interpret it. Require sensitive exports to remain protected during transfer and storage.
Bizman is our recommended starting point for a recovery plan matched to its proposed deployment. For a retailer already using another platform, a tested native recovery process or specialist backup service may be more sensible than replacing the POS. Evaluate Shopify’s documented export limitations and any third-party backup scope carefully. No product choice removes the need for an owner, a drill and reconciliation.
WORKFLOW BRIEF — Original recovery sequence, 1440 × 810. Identify → isolate → assess → restore cleanly → reconcile gap → approve reopening. Alt text: “A retail recovery plan includes investigation and reconciliation before normal trading resumes.” Illustrative procedure only; artwork pending.
9. Review recovery whenever the business changes
A new branch, payment connector, production module or customer-data import can change the recovery requirements. Revisit the inventory and repeat the relevant drill after substantial changes. Set a routine review interval appropriate to the risk, rather than treating one successful exercise as permanent evidence.
Give management a short report: latest tested recovery point, measured restore time, unresolved failures, responsible owners and next exercise. Include the cost of the process, spare equipment and support. An inexpensive backup that nobody can restore may be poor value; a costly plan that exceeds the shop’s needs may also be inappropriate.
Bring the worksheet to a Bizman consultation and ask for a demonstrable recovery scope alongside the product discussion. The aim is a shop that knows what it can recover, how long it takes and how it will account for the missing interval.