Could you rebuild the menu tomorrow? A restaurant recovery inventory that gets tested

A backup nobody has restored from is a guess about a file nobody has opened. NCSC states the principle in one sentence, under a heading called Restoring backups: once you have made your backup, it is important you know how to restore it, and to check that it contains all your important data. The job therefore has two halves, and most restaurants have done only the first. The first half is the inventory, which NCSC frames as making a copy of all the data the business needs to operate: the website, emails, invoicing, documents, presentations, contacts and customer information. The second half is proof, meaning a real restore, on a chosen day, by a named person, checked against that inventory and written down. Until that has happened once, the accurate description is that a copy exists somewhere.

Two boundaries before the detail. This article is not legal or security advice, and following the guidance in it is not a guarantee against data loss. Whether a particular arrangement satisfies the UK GDPR security principle depends on the restaurant's own risk assessment and circumstances, which no article can carry out on your behalf.

NCSC's list reads like generic office material because it is written for every small organisation, not for kitchens. Translating it into a restaurant is the step that decides whether a copy is worth holding. The useful test is not how much data a record contains. It is what stops when the record is gone, and how quickly a guest notices.

Menu content fails first and fails in public. Prices, dish names, descriptions and allergen notes are the working document of the business. A kitchen can cook without the file, but a restaurant cannot sell from a page that no longer exists, and rebuilding a full menu from a photograph of a printed card takes hours nobody has on a Friday.

Guest and booking records fail quietly, which is worse. The list of who is coming, who came before and who left a phone number is the only thing standing between a restaurant and starting its direct trade again from zero. It is also the record most likely to be personal data, which puts it under a separate legal duty covered further down. Most owners have never taken a copy of it, and the cheapest habit in this article is a dated export of that list, short enough to belong on a regular guest list export check rather than on a project plan.

Page content and images fail slowly. Opening hours, the about page, the directions, the photography somebody paid for. None of it stops service on the night, and all of it is expensive to reproduce, because the photographer's files and the original wording are usually on somebody's old laptop.

Invoices, supplier documents and contacts fail when you need to argue. A disputed delivery, a chargeback or an accountant's request depends on records the business assumes it can find.

Caption: the NCSC rows are general guidance for small organisations and the ICO rows describe a duty on the business that holds personal data. Neither source tests, endorses or certifies any product, and neither one has assessed your arrangements. NCSC pages reviewed 21 July 2026; ICO page read live on 24 August 2026.

The third column is the one restaurants leave blank. Owners can name the record and the harm within a minute. Saying where the second copy actually sits is where the exercise turns into work.

A copy that lives inside the thing you are protecting is not a copy. NCSC is direct about the storage device: it should not stay connected to your device when not in use, because some viruses will also affect devices that are connected to an infected computer. That rules out the most common restaurant arrangement, an external drive permanently plugged into the office computer and treated as a backup because a folder on it has the word backup in its name.

Cloud storage is the other route NCSC describes, and it describes it without ceremony. You can back up your data to the internet, also known as the cloud, if you have reliable internet access. Most providers offer limited free storage, and large amounts of additional storage can be purchased at low cost. For a restaurant that is the practical option, because it needs no rota beyond checking it is still running.

NCSC's next point is worth building the arrangement around. It recommends considering online storage and a storage device together, to create two backups, in case one of them is lost or stolen. A restaurant office is a room where drives get borrowed, laptops get spilled on and passwords are held by one person who is on holiday in August.

The ICO's own worked example uses a familiar shape. It describes an organisation following the well known 3-2-1 backup strategy: three copies, with two stored on different devices and one stored off-site. A ransomware attack disrupts the organisation, and the off-site copy allows it to restore its systems in a timely manner despite the disruption. That is a regulator describing an arrangement it treats as adequate on those facts, not a rule that 3-2-1 is required and not a finding about your restaurant.

One trap is specific to restaurants. If the website, the booking records and the menu all sit behind the same login, the copies have to be reachable when that login is not. If the email account attached to the site is locked tonight, can the manager still open the menu export and the guest list using access that does not depend on that email?

NCSC's instruction under the heading Restoring backups packs two separate obligations into one sentence: know how to restore the backup, which is a procedure, and check that it contains all your important data, which is an inspection of the contents.

Most failed restores fail on the second. The file exists, it opens, and it turns out to hold last October's menu, or the booking list without phone numbers, or the page text without any of the images. Nobody notices, because nobody has ever opened it next to the inventory and gone down the rows.

The ICO treats testing as a requirement rather than as good practice. Its guidance states that UK GDPR specifically requires you to have a process for regularly testing, assessing and evaluating the effectiveness of any measures you put in place. A backup with no test is a measure whose effectiveness has never been evaluated.

A restaurant restore test is small. Take the copy on a quiet morning, put it somewhere that is not the live site, open it, and work down the recovery inventory row by row. Does the menu have current prices, or prices from a season ago? Does the guest export have the columns you would need to contact somebody, and does the row count match the number of guests you think you have? Do the page images exist as files, or only as links to a place you can no longer reach? Then write down four things: the date, who did it, what came back correctly, and what did not.

The last of those is the valuable one. Every restore test finds something, and finding it in advance costs a morning rather than a service.

The legal frame applies to guest data specifically rather than to the menu. Article 5(1)(f) UK GDPR is the integrity and confidentiality principle, also known as the security principle. It requires personal data to be processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures. The ICO's summary of the principles puts it plainly: you must ensure that you have appropriate security measures in place to protect the personal data you hold.

Accidental loss and destruction are in that list next to unlawful access. A restaurant that thinks of data protection as a subject about hackers is reading half of it.

Article 32(1) then asks for measures appropriate to the risk: the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. The ICO explains that these measures must ensure the confidentiality, integrity and availability of your systems and services and the personal data you process within them. Availability is the word doing the work here. Data you hold but cannot reach is a security problem, not an inconvenience.

On restoring, the ICO is explicit. The measures must also enable you to restore access and availability to personal data in a timely manner in the event of a physical or technical incident. Its own checklist restates the same duty in the language a small business would use: we make sure that we can restore access to personal data in the event of any incidents, such as by establishing an appropriate backup process.

Timely manner has no fixed figure, and it is worth resisting the temptation to invent one. The ICO says UK GDPR does not define what a timely manner should be, and that it depends on who you are, what systems you have, and the risk that may be posed to individuals if the personal data you process is unavailable for a period of time. The risk to individuals from a neighbourhood restaurant's booking list being unavailable for a day is not the risk from a hospital record being unavailable for a day, and the ICO's framing allows for that difference.

Two qualifiers belong with this section. The duty falls on the restaurant as the business collecting guest data, not on any software supplier, and no supplier discharges it for you. And the ICO pages quoted here were read as a browser renders them, live on 24 August 2026, because the site turns away automated fetching, so check the live page before relying on exact wording. If an incident does happen to personal data, the reporting clock is a separate subject with its own timings, covered in the walkthrough of a restaurant's first 72 hours after a guest data breach.

Do this in one sitting, with a spreadsheet open, and keep it to a single page. An inventory that runs to nine tabs is a document nobody maintains past the month it was written.

Step 10 gets skipped, because a successful test feels like it needs no paperwork. A test that nobody recorded is a test the next manager will assume never happened.

The inventory earns its keep twice. The list of pages, images and structured content you build here is close to the list you need when a site changes hands, which is why it overlaps so heavily with a restaurant website migration checklist. Build it once for recovery and it is written for the move.

A recovery inventory is easiest to keep when the underlying material is already structured rather than scattered. On TableSpark, menu and page content sits in owner-editable structured fields, and guest records collected through the restaurant's site, including bookings, enquiries and orders, are stored under that restaurant's own TableSpark account, visible in its Inbox and guest list, with CSV export. Together those two things mean the restaurant holds portable copies of the material a recovery inventory has to cover: a menu it can read outside the site, page content in named fields rather than in a designer's file, and a guest list it can export on any morning it chooses.

Where the responsibility sits is worth stating plainly. The restaurant takes the copies, stores them somewhere separate from the working account, and tests that a restore returns what the inventory says it should. Holding that work yourself is what makes the copies dependable, because you have opened them.

Three jobs came out of this article: naming the records that stop service when they go, keeping a copy of each one somewhere separate from the account that holds the original, and proving by restoring it that the copy holds what you think. The first and the third stay with the restaurant on any platform, and doing them yourself is what makes the copies worth having. The second gets easier when the underlying material is already exportable, and that is the practical case for running the site on TableSpark: menu and page content sit in owner-editable structured fields, and guest records sit under the restaurant's own account with CSV export, so a dated copy is a few minutes of work rather than a project. Starter is £19 per month, Growth at £39 a month and Full at £69 a month, all three excluding VAT, with Stripe's standard card-processing fees on online payments and cancellation at any time. Yearly billing is 10 months paid for 12 used, and a site is free until it is published. None of that plan price is topped up by a share of your covers, because TableSpark commission is 0% on bookings and orders, which is why it is the best-value and best overall choice for an independent UK restaurant that wants to own its records and its direct trade.