GDPR Article 18: right to restriction of processing

Restriction is the least implemented of the GDPR rights, mostly because systems tend to have a delete button and a keep button and nothing in between. Article 18 requires exactly the thing in between: hold the data, stop using it.

Article 18(1): the four grounds

The data subject shall have the right to obtain from the controller restriction of processing where one of the following applies:

(a) the accuracy of the personal data is contested by the data subject, for a period enabling the controller to verify the accuracy of the personal data;

(b) the processing is unlawful and the data subject opposes the erasure of the personal data and requests the restriction of their use instead;

(c) the controller no longer needs the personal data for the purposes of the processing, but they are required by the data subject for the establishment, exercise or defence of legal claims;

(d) the data subject has objected to processing pursuant to Article 21(1) pending the verification whether the legitimate grounds of the controller override those of the data subject.

Two of these are automatic consequences of other rights rather than standalone requests. Ground (a) attaches to any accuracy dispute, so a rectification complaint carries a restriction obligation with it for the verification period. Ground (d) attaches to any Article 21(1) objection while you work out whether your legitimate grounds win.

That means a controller can owe a restriction duty without anyone having used the word restriction.

Article 18(2): what you may still do

Where processing has been restricted under paragraph 1, such personal data shall, with the exception of storage, only be processed with the data subject's consent or for the establishment, exercise or defence of legal claims or for the protection of the rights of another natural or legal person or for reasons of important public interest of the Union or of a Member State.

Storage is carved out at the start of the sentence, which is the whole design. You keep the record. Beyond keeping it, you need one of four justifications, and ordinary business use is not among them.

Article 18(3): before you switch it back on

A data subject who has obtained restriction of processing pursuant to paragraph 1 shall be informed by the controller before the restriction of processing is lifted.

This is short and easy to miss in an implementation. Lifting a restriction is an event that requires advance notice to the person, not a silent internal state change once your investigation closes.

Why ground (b) exists

Article 18(1)(b) looks strange at first. The processing is unlawful, and the person does not want the data erased. Why would anyone choose that?

Because erasure destroys evidence. Someone who intends to complain to a supervisory authority or bring a claim may need the unlawfully processed data to still exist. Ground (c) covers the mirror image, where the controller is finished with the data but the person still needs it for legal claims and does not want it routinely deleted.

Both grounds exist to stop deletion being used, deliberately or accidentally, to end a dispute.

Restriction against erasure

The comparison people usually want is with the right to erasure. Erasure removes the data. Restriction preserves it in a frozen state. A person can often choose between them, and under Article 18(1)(b) that choice is explicitly theirs, not the controller's.

Practically, restriction is also what you fall back on when erasure is unavailable because a retention obligation applies. The data has to stay, so the answer to a person who wants it left alone is to restrict rather than to refuse.

Article 19: restriction has to travel to your recipients

The duty most often missed sits in the next article, not this one. Restricting processing in your own systems is only half of what the Regulation asks.

Article 19 reads in full: "The controller shall communicate any rectification or erasure of personal data or restriction of processing carried out in accordance with Article 16, Article 17(1) and Article 18 to each recipient to whom the personal data have been disclosed, unless this proves impossible or involves disproportionate effort. The controller shall inform the data subject about those recipients if the data subject requests it."

Two obligations follow, and they run in opposite directions.

Outward: every recipient to whom you disclosed the personal data has to be told about the restriction. Article 19 names Article 18 explicitly alongside rectification and erasure, so a restriction is not a purely internal state. Your processors, your sub-processors, and any controller you shared the data with are all recipients.

Inward: if the data subject asks who those recipients are, you must tell them. That is a standing entitlement attached to the restriction, not a separate subject access request, and answering it requires you to know where the data went in the first place.

The "impossible or disproportionate effort" qualifier is real but narrow, and it is a defence about the communication rather than about the restriction. Not having kept a record of recipients is not, on its own, disproportionate effort, because Article 30 records of processing activities are meant to answer that question.

Article 19 is also why restriction and erasure produce similar downstream work. The internal action differs, since you suppress rather than delete, but the notification obligation to recipients is identical, and it is the part most implementations forget to build.

Article 18(1) and the one-month clock

Article 18 sets no deadline of its own. The clock is the general one in Article 12(3): the controller shall provide information on action taken on a request under Articles 15 to 22 without undue delay and in any event within one month of receipt, extendable by two further months where necessary taking into account the complexity and number of the requests, provided the data subject is informed of the extension and its reasons within the first month.

For restriction that deadline is unusually demanding in practice, because the action requested is a change in system behaviour rather than a document. Ground (a), where accuracy is contested, is the clearest case: the restriction is meant to hold "for a period enabling the controller to verify the accuracy," so the restriction has to be in force while the verification is still running, not after it concludes.

Implementing it

The common failure is architectural rather than legal. A restriction flag that only your CRM respects is not a restriction if the nightly export, the analytics warehouse and the email platform never see it. Deciding where the flag lives, and what reads it, is the actual work.

The related objection right that feeds ground (d) is covered in Article 21, and the timescales and format rules that apply to responding to any of these requests sit in Article 12.