A practical website recovery plan for small businesses in Europe

List the website functions that matter to daily trade, not every technical component. For a restaurant that may be opening hours, the menu and reservations. A veterinary clinic may prioritise phone details and emergency instructions. A marine repair company may need the enquiry form and service-area information. Give each function a recovery order and a workable temporary alternative.

Write two practical limits: how long the business can manage without the function, and how much recent content or enquiry data it could reasonably recreate. These are business decisions, not promises from a supplier. They help a web partner choose sensible backup frequency and restore order. Do not copy a large-company target that nobody has tested or funded.

Create a private register for the domain registrar, DNS, hosting, website platform, analytics, form delivery and business email. Record the business owner for each account, the supplier, renewal date, recovery method and where access instructions are stored. Do not put passwords in the public plan; use a managed password vault and require multi-factor authentication where the service supports it.

Domain control deserves its own line. ICANN explains that the registrant is the person or entity holding the rights to a registered domain and that registrations must be renewed to keep associated services working. Use a business-controlled registrant address, keep its contact details current, enable renewal reminders and name a second responsible person. Country-code domains may follow their local registry’s process.

A complete website recovery set may include the current site files or build source, database, uploaded images and documents, configuration, DNS records, redirects, form settings and a list of connected services. A platform snapshot alone may omit domain settings, third-party forms or content held elsewhere. Ask the supplier to state exactly what is included, how often it is copied and how long versions are kept.

ENISA describes a 3-2-1 approach in its detailed SME guidance: three copies, on two types of storage, with one copy off-site. The NCSC advises keeping backups separate from the systems they protect so an incident cannot easily affect both. Adapt the method to the business and platform. A synchronised folder is useful, but accidental deletion or malicious changes can also synchronise.

A successful backup notification proves that a copy was attempted; it does not prove that the website can be restored. Schedule a controlled test in a safe staging location. Confirm that pages, images, language versions, forms, redirects and administrative access work. Record the backup used, start and finish time, missing items and who confirmed the result.

Run a lightweight test after major platform changes and a fuller rehearsal at an interval the business can maintain. Never overwrite the live site merely to demonstrate a test. If a supplier performs the exercise, ask for a plain-language result and unresolved gaps. The outcome should update the plan, because a recovery document that ignores a failed form or forgotten DNS setting creates false confidence.

Keep the first page short enough to use under pressure. It should say who leads, who contacts the web provider, who communicates with customers and who records decisions. Start by preserving evidence and confirming the symptoms through a trusted device and network. Do not rush to delete logs, rebuild everything or announce a cause that has not been established.

The NCSC response-and-recovery guide recommends preparing, identifying what is happening, resolving the incident, reporting to relevant stakeholders and learning afterwards. Your card should include supplier emergency contacts, internal escalation, an approved temporary customer message and the appropriate national reporting route. Reporting duties vary by country and incident, so obtain qualified local advice when they may apply.

Once a quarter, the business owner and web partner can complete a 20-minute review: confirm account owners and recovery contacts, check domain and hosting renewal, inspect the latest separate backup, review significant website changes, and verify the temporary contact route. Each item needs a name and date rather than a vague “handled by IT”.

After any disruption, write down what customers experienced, what worked, what delayed recovery and which instruction was missing. Update the plan and remove obsolete access. The useful deliverable is one private page plus the supporting account and backup records. It cannot remove all risk, but it gives a small team an ordered, testable way to bring essential website services back.