Recovery
A backup plan for a small business in South Africa
A backup is useful only when the business knows what it can restore, how quickly it needs it, and who owns the recovery decision. Build the plan around the work that stops when data or systems disappear.
List the systems that stop the business
Start with email, customer and accounting records, shared files, website content, passwords, devices, and line-of-business software. Record where each system lives, who owns it, what data it contains, and which person can approve a restore.
Include cloud SaaS and Microsoft 365 data. A provider’s default recycle bin or synchronisation may not meet the business’s recovery requirement.
Choose recovery targets
For each workload, record the maximum acceptable data loss and maximum acceptable downtime. Those answers determine backup frequency, retention, storage, and the support response actually needed.
A finance system may need a different recovery priority from an old marketing archive. Put the business impact beside the technical requirement so the plan can be priced and tested.
Keep a separated recovery copy
Keep at least one recovery copy separated from the main administrator account or environment. Ask how the provider protects backups from deletion, encryption, accidental overwrite, compromised credentials, and an outage in the main location.
Record the storage location, encryption ownership, retention, deletion process, and person who can approve or perform recovery. Do not make one administrator the only recovery path.
Test a real restore
A green backup dashboard does not prove that a usable file can be restored. Schedule a small restore, open the result, record the time taken, and confirm who would handle a full recovery.
Test a mailbox, document, accounting export, website file, or device recovery as appropriate. Record what failed, fix it, and test again rather than treating the first successful job as evidence for every system.
Protect the backup account
Use individual administrator accounts, multi-factor authentication, least privilege, sign-in alerts, and a documented offboarding process. Review who can delete, change, export, or restore the copies.
Keep the backup account, recovery contacts, documentation, and credentials under business control. A provider may manage the service but should be able to hand over the recovery path.
Plan the incident response
Record what staff should do after ransomware, a lost laptop, a compromised mailbox, accidental deletion, a failed update, or a provider outage. Preserve evidence and avoid restoring into an environment that may still be compromised.
Name the internal decision-maker, IT provider, insurer or legal contact where relevant, and the route for assessing personal-information exposure. This guide is operational, not legal advice.
Ask the IT provider the hard questions
Ask what is included, what is excluded, how long versions are kept, where copies are stored, whether Microsoft 365 or cloud SaaS data is covered, what an emergency response costs, and how a full rebuild is coordinated.
Get ownership of the backup account, encryption keys, documentation, restore credentials, and export process in writing. Confirm response time and whether the quoted service includes actual recovery work.
Review after every material change
Review the plan after a system change, staff change, new legal or contractual requirement, new device, provider migration, or incident. Update the inventory, recovery target, owner, and test schedule.
Small Business IT SA can help structure the decision and compare support options. A provider link does not replace a tested recovery plan.
Sources and further reading
Back to all guides Compare support options Compare software Compare hosting