GDPR Article 18: Right to Restriction of Processing

In one sentence. GDPR Article 18 grants the data subject the right to restrict (pause) processing of their personal data in four specific cases: (a) accuracy contested, (b) processing unlawful but data subject doesn’t want erasure, © controller no longer needs the data but the data subject needs it for legal claims, (d) data subject has objected and the controller’s overriding interests are pending verification. During restriction, the data may only be stored — any other processing requires the data subject’s consent or specific exceptions.

Article 18 is the least-used data subject right but the most technically demanding. While erasure removes data, restriction keeps it but locks it. Implementing restriction requires either a database flag respected by every system that touches the data, or physical isolation of the records. Most controllers don’t have a working implementation.

For related rights: right of access (Article 15), right to erasure (Article 17), right to object (Article 21). For modalities, GDPR Article 12 transparency.

Key takeaways

• Article 18 = pause processing, keep data. Different from erasure (Article 17).
• Four trigger cases: accuracy contested, unlawful processing without erasure request, data needed for legal claims, pending objection verification.
• During restriction: storage is allowed; any other processing requires consent or specific exception.
• Controller must inform recipients of the restriction (Article 19).
• Controller must inform data subject before restriction is lifted (Article 18(3)).

1. Article 18 — the four trigger cases

18(1)(a) — Accuracy contested

Data subject contests the accuracy. Restriction lasts as long as the controller needs to verify accuracy. Useful in cases of data correction disputes.

18(1)(b) — Unlawful processing, erasure not wanted

Processing is unlawful but the data subject prefers restriction over erasure. Common when the data subject needs the data for a legal claim or proof.

18(1)© — Controller no longer needs, but subject needs for legal claims

Controller would normally erase but the data subject needs the data preserved for legal proceedings.

18(1)(d) — Pending objection verification

Data subject has objected under Article 21. Restriction lasts until the controller verifies whether their legitimate grounds override the data subject’s interests.

2. What “restriction” means technically (Article 18(2))

During restriction, the data may only be:

• Stored
• Processed with the data subject’s consent
• Processed for legal claims
• Processed for the protection of another natural person
• Processed for important public interest reasons

No other processing. This means: no marketing emails, no analytics aggregation including this person, no automated decisions, no profile updates.

3. Technical implementation patterns

Pattern 1 — Restriction flag on the record

• Database column: restriction_status (none / restricted / lifted)
• Every read query joins this column and filters
• Application code checks the flag before any operation
• Risk: easy to forget in new code paths

Pattern 2 — Move to restricted partition

• Restricted records moved to a separate database / schema
• Production code unaware of restricted records
• Restricted records accessible only via dedicated tooling
• Pro: stronger isolation, harder to accidentally process

Pattern 3 — Encrypt with key withheld

• Restricted records encrypted with a key under data subject control
• Storage continues, processing impossible without key
• Pro: cryptographic enforcement
• Con: complex implementation

For most SaaS, pattern 1 (restriction flag) is the practical choice. The CNIL has accepted this if rigorously applied.

4. Notification obligations (Article 19)

The controller must:

• Communicate the restriction to each recipient to whom the data was disclosed, unless this proves impossible or involves disproportionate effort
• Inform the data subject about those recipients if requested

This means processors and onward recipients must implement the restriction too. The DPA with each processor should mandate this.

5. Lifting the restriction (Article 18(3))

Before lifting the restriction, the controller must inform the data subject. This gives the data subject the opportunity to challenge or escalate.

6. Article 18 vs other rights

Right	What happens to the data
Access (Art. 15)	Data stays, copy provided
Rectification (Art. 16)	Data corrected
Restriction (Art. 18)	Data stays, processing paused
Erasure (Art. 17)	Data deleted
Portability (Art. 20)	Data exported in machine-readable form
Object (Art. 21)	Processing stops if no overriding interest

7. Common implementation failures

Failure	Risk
No database flag for restriction	Cannot honor request technically
Marketing system not linked to flag	Restricted user keeps receiving emails
Analytics aggregation includes restricted records	Aggregate processing continues unlawfully
Lifting without notice to data subject	Article 18(3) violation
No notice to recipients (Article 19)	Onward processing continues

8. Sanctions

Article 18 violations are typically rolled into broader Article 12 / 17 / 19 sanctions. Notable cases:

• Brico Privé (CNIL, 2023): €50K — failed restriction implementation
• Spartoo (CNIL, 2020): €250K — multiple data subject right failures including restriction

Article 83(5)(b) places Article 18 violations at the top tier — up to €20M or 4% of global turnover.

9. Practical workflow

1. Receive request — log timestamp, classify as Article 18
2. Verify identity — proportionate
3. Verify trigger case (a/b/c/d) — document
4. Apply restriction flag (DB + downstream systems)
5. Notify recipients (Article 19) — DPA-mandated processors must implement
6. Confirm to data subject within 30 days
7. Maintain restriction until trigger condition resolves
8. Before lifting: notify data subject (Article 18(3))
9. Log all events

10. Tooling

Legiscope handles the data subject request workflow including Article 18 restriction logic, sub-processor notification, and audit trail.

For related deep-dives: right of access GDPR, right to erasure GDPR, right to object GDPR, data portability right.

Conclusion

Article 18 is the right that exposes architecture problems. Restriction requires every system to respect a flag, every batch job to filter, every onward recipient to be notified. Most controllers can technically delete data but can’t technically restrict it. Build the restriction capability before the first request — retrofit during a CNIL audit is significantly more expensive.

FAQ

What is the right to restriction of processing under GDPR Article 18?

The right to require the controller to pause processing while keeping the data stored. Unlike erasure, the data is not deleted. Triggered in four cases: accuracy contested, unlawful processing without erasure request, controller no longer needs but data subject does for legal claims, pending objection verification.

How is restriction different from erasure?

Erasure (Article 17) deletes the data. Restriction (Article 18) keeps the data but pauses any processing other than storage. The data subject may want restriction over erasure when they need the data preserved for legal proceedings or evidence.

What can I do with restricted data?

Only store it. Any other processing requires the data subject’s consent or specific exception (legal claims, protection of another person, important public interest).

Do I need to inform sub-processors of a restriction?

Yes. Article 19 requires the controller to communicate restriction (and rectification and erasure) to each recipient to whom the data was disclosed, unless impossible or involving disproportionate effort. The DPA with each processor should mandate this.

Can I lift a restriction without telling the data subject?

No. Article 18(3) requires the controller to inform the data subject before the restriction is lifted. This gives the data subject the opportunity to challenge.