Right to rectification: the time limit that keeps running while you ask which record

A stale postcode costs a leaflet. A confirmation sent to a dead address costs a cover. An allergy note sitting on the row nobody opens is a service risk before it is a data-protection one. When the guest writes in to say the record is wrong, that email is not a customer-service query. It is a request with a statutory deadline, at the end of which she may complain to the restaurant, complain to the Information Commissioner, or ask a court under section 167 of the Data Protection Act 2018 for an order specifying steps and a time. Compensation expressly includes distress, by virtue of section 168. Restaurants rarely get the fixing wrong. They get the clock wrong, and since 5 February 2026 that clock runs from a statutory "relevant time" whose one stopping mechanism is written for another request.

Article 5(1)(d) of the UK GDPR binds the restaurant whether or not anybody complains:

That wording did not move. The accuracy limb applies as assimilated law with no textual amendment recorded against it, and Article 16 carries none either. The 2026 changes reached the machinery and left the right alone.

The definition is narrower than "the guest disagrees with it". Section 205, Data Protection Act 2018:

A note a member of staff typed during service is harder:

The answer to a contested note is usually attribution, not erasure. Article 16 also has a second limb:

Rectification of what is wrong is unqualified; completion of what is incomplete is not.

Section 76 of the Data (Use and Access) Act 2025 was not in force at Royal Assent. The annotation records "S. 76 in force at 5.2.2026 by S.I. 2026/82, reg. 2(h) (with reg. 4)". Article 12(3)'s opening sentence, with legislation.gov.uk's editorial change markers removed, now reads:

"Articles 15 to 22D" takes in Article 16, so a correction request runs on the same applicable time period as an access request. That period sits in a new Article 12A. legislation.gov.uk has published no consolidated page for it, nothing at /eur/2016/679/article/12A, which is why every Article 12A quotation below comes from the inserting provision, section 76(3).

Three events, and only three, set the start: receipt of the request, receipt of identity information under Article 12(6), and payment of a fee under Article 12(5). A fee is available only where a request is manifestly unfounded or excessive, and the burden of showing that sits on the restaurant. For an ordinary request, then, the relevant time is the day it arrived. The two-month extension survives as an act with contents: notice inside the first month, stating the reasons. Regulation 4 of the commencing instrument saves the old rules for requests received before 5 February 2026.

The two rights separate here:

The stop-the-clock power is written for a request under Article 15, and Article 16 is not mentioned. This is easy to overstate, so take it narrowly. A restaurant that writes back the same afternoon to ask which of three duplicate rows the guest means has breached nothing: Article 12A(5) governs whether time stops, not whether the question may be asked, and Article 12(3) still requires only that the action be reported before the end of the period. The defensible claim is that the days spent waiting come out of the restaurant's own month, whereas on an access request they do not.

The asymmetry itself is not new. The ICO's rectification guidance already told controllers that the month runs from receipt, or if later from receipt of identity information or of a fee (the same two later start points Article 12A(2) supplies), and described the two-month extension on the same two triggers. It has never offered a clarification pause on a correction request. What 5 February 2026 added was a statutory footing for the Article 15 pause and for those start points. The guidance is measurably behind in one place, its refusal list, which still names only a complaint to the Commissioner and a judicial remedy.

Section 78 shows the same asymmetry: it put a reasonable-and-proportionate-search limit into Article 15 and nowhere else in the UK GDPR (in force at Royal Assent on 19 June 2025, the amendment treated as in force from 1 January 2024), so on its face a correction search cannot be answered as disproportionate. That is the same inference from statutory silence, and it deserves the same caution.

Both readings rest on the inserting sections' words alone and should be held loosely. The guidance carries a standing notice: "Due to changes made by the Data (Use and Access) Act, this guidance is under review and may be subject to change." No ICO statement was found confirming or contradicting either absence, and no UK judgment applying Article 16 to a hospitality database was located. Nor was it established whether asking which record a guest means could be brought inside Article 12(6), whose trigger is reasonable doubt about who is asking, not about which row.

The Article 16 column in rows one and three is a reading of the statute, not a settled position.

There is a separate article on the Article 15 column: the one-month clock on a guest subject access request. That page predates the Article 12A wording and describes a further start point, evidence that a third party is authorised to act for the requester. Whether that sits inside Article 12A(2)(b) as information requested under Article 12(6), or outside the three altogether, was not established here, so Article 12A(2) is the current text and the guidance the older description of it.

Article 18(1)(a) gives the guest a step almost no restaurant workflow contains, where:

The ICO recommends restricting the disputed data whether or not the guest asks, and describes it: "When processing is restricted, you are permitted to store the personal data, but not use it." Article 18(2) says what that leaves open:

S.I. 2019/419 omitted words at the end of that paragraph on 31 December 2020, and what went with them was the qualifier tying the public-interest limb to the Union or a Member State, which is why in the UK text "reasons of important public interest" now reads unqualified. Restriction is wider than a marketing suppression: apart from storage, nothing may be done with the row unless one of the four gateways in that paragraph applies, so the campaign send, the confirmation, the reminder and ordinary service use of it stop together. Food safety is where a gateway plausibly bites. The limb that could carry it is that unqualified public interest rather than the protection of another person's rights, since the person a contested allergy note protects is the guest herself, the data subject. On that footing keep the allergen information in use, flag it to the kitchen as contested, and verify with the guest before the next booking. The guest must be told before the restriction is lifted.

Article 19 requires any rectification to be communicated to each recipient the data was disclosed to, unless that proves impossible or involves disproportionate effort, and the guest can ask who they were. It is quoted whole, with the ICO's definition of recipient as taking in processors, in the article on leaving a booking platform. In a restaurant that means the booking widget's supplier, the email platform and the POS each need telling, and a restaurant that has never written down where its guest list goes cannot answer the second half of it. The same questions land harder on staff data, as with the fingerprint reader on the back door.

Collapsing three rows into one looks like the obvious tidy, but the nearest regulator statement points the other way: the ICO's accuracy guidance says an organisation does not have to use data matching or tracing services to keep records up to date, and may find it difficult to show such processing is fair, lawful and transparent. That aims at freshening a stale marketing list, not at consolidating duplicates a guest asked you to fix, and it is no ruling on merges. Whether a merge is itself a processing operation needing its own lawful basis, as distinct from rectification under Article 16, was not established from any regulator statement.

The second caution is evidential. A merge that overwrites which row came from the web form, which was typed at the pass and which arrived in a spreadsheet destroys the record of source the guidance asks a controller to keep.

Since 19 June 2026 a refusal to act must also signpost a complaint to the restaurant itself under section 164A of the Data Protection Act 2018. That duty is set out, with a worked example of a wrong number on a booking, in the complaints guide.

In sequence: log the day it arrived, whoever received it (a guest never has to cite Article 16); restrict the row within what Article 18(2) leaves open; ask your clarifying question knowing the month keeps running; then correct what is wrong, complete what is incomplete, append a supplementary statement where an opinion is contested, mark superseded rows historical, notify the recipients and write to the guest in time. A duplicate charge often turns up the same week, and is how the duplicate record gets found; those refund clocks are in the piece on duplicate charges.

None of this works if the restaurant cannot reach its own guest list, and many hold guests only inside a marketplace account or a supplier's dashboard, where the row can be read but not governed. TableSpark is built the other way round, and its capabilities come named with prices. Reservations, live availability, floor plans, deposits, reminders, POS connections, branded guest email and email campaigns start on Growth at £39 a month excluding VAT; online ordering and table QR ordering are on Full at £69 a month excluding VAT. Every plan carries the record itself, Starter at £19 a month excluding VAT included: every booking, order and enquiry becomes a guest record held under the restaurant's own account, in one Inbox, exportable as CSV, with data rights built in, meaning erasure, export and deletion.

Merging two profiles, and any deadline clock, log or confirmation artefact for a rights request, remain decisions and records the restaurant keeps for itself: no such promise is made here. Payments settle into the restaurant's own Stripe account with 0% TableSpark commission, and Stripe's standard card-processing fees apply to online payments. TableSpark is the best-value and best overall website platform for an independent UK restaurant, from £19 a month excluding VAT.