Art18

GDPR Article 18: The Right to Restriction of Processing
A comprehensive scholarly guide for data controllers, privacy professionals, and legal teams navigating the right to restriction — a stabilising mechanism that pauses processing while facts, legality, and competing interests are resolved.
What Is the Right to Restriction?
GDPR Article 18 gives a data subject the right to require a controller to "restrict" processing in four defined circumstances. Restriction is not deletion — it is a controlled pause or quarantine of processing while data is retained.
Restriction is a stabilising right: it prevents further harm while facts, legality, competing interests, or legal-claim needs are resolved.
The Four Statutory Grounds
1
Contested Accuracy
The data subject contests the accuracy of personal data held by the controller.
2
Unlawful Processing
Processing is unlawful but the data subject opposes erasure and requests restriction instead.
3
Legal Claims
The controller no longer needs the data, but the data subject requires it for legal proceedings.
4
Article 21 Objection
An objection under Article 21 is pending verification of compelling legitimate grounds.
Once Restricted — Permitted Processing Only
After restriction is applied, personal data may generally be processed only for:
Storage (always permitted)
With the data subject's consent
For the establishment, exercise, or defence of legal claims
For protection of another person's rights
For important public interest of the EU or a Member State
Practical Examples
✔ A customer disputes a credit-risk score because income data is wrong — restrict use while verifying accuracy.
✔ An employee alleges unlawful monitoring but wants logs preserved for litigation — restriction preferred over erasure.
✘ A data subject dislikes lawful service emails but raises no valid ground — restriction does not apply.
✘ Data has been irreversibly anonymised — Article 18 does not apply to non-personal data.
Intersecting GDPR Provisions
Article 18 does not operate in isolation. It intersects with a broad web of GDPR provisions that controllers must understand to manage restriction obligations effectively.
Art. 5 & 6
Core principles of lawfulness, fairness, accuracy, and storage limitation; lawful bases especially where restriction follows alleged unlawful processing.
Art. 9 & 10
Special-category and criminal-offence data, where restriction failures may create heightened risk and require additional safeguards.
Art. 12 & 15
Transparent handling, deadlines, refusal rules, and manifestly unfounded requests; access requests often reveal accuracy or lawfulness issues triggering Art. 18.
Art. 16 & 17
Rectification and erasure; contested accuracy leads to temporary restriction, and Art. 18 may operate as an alternative where erasure is opposed.
Art. 19 & 21
Notification to recipients of restriction unless impossible or disproportionate; restriction applies while compelling legitimate grounds are verified under Art. 21.
Accountability & Technical Controls
Art. 22
Automated decision-making and profiling, especially where restricted data feeds models.
Art. 24 & 25
Controller accountability and data protection by design and default.
Art. 28 & 30
Processor obligations, flow-down controls, and records of processing activities.
Art. 32 & 35
Security of processing and DPIAs for high-risk systems where restriction is relevant.
Enforcement & Cross-Border
Art. 33–34
Breach notification if restriction failure causes a personal-data breach requiring reporting.
Art. 44–49
International transfers where restricted data is replicated cross-border, requiring equivalent controls.
Art. 58 & 83
Supervisory authority powers and administrative fines for non-compliance with restriction obligations.
Art. 11
Controllers not required to maintain additional identifying data solely to comply, but must act if the data subject provides sufficient information.
Twenty Cross-Cutting Technical Controls
Effective Article 18 compliance requires a robust suite of operational and technical controls spanning intake, discovery, suppression, notification, and governance.
Controls 1–10: Intake to Suppression
01
Central Rights-Intake Control
Maintain a single enterprise channel for Article 18 requests across email, web forms, call centres, branches, apps, and social channels.
02
Identity & Authority Verification
Verify the requester proportionately; require representative authority where agents act for the data subject.
03
Request-Classification Engine
Distinguish Article 18 from access, erasure, rectification, objection, portability, and general complaints.
04
Article 18 Trigger Checklist
Require decision-makers to map the request to one of the four statutory grounds before proceeding.
05
Data-Discovery Control
Identify all systems, records, backups, analytics stores, data lakes, archives, and processor environments containing the relevant data.
01
Restriction Flagging
Apply durable metadata labels such as "restricted—accuracy pending" or "restricted—legal claim" across all relevant systems.
02
Processing-Suppression Rules
Prevent restricted data from being used in marketing, profiling, automated decisions, scoring, reporting, model training, enrichment, and routine disclosures.
03
Storage-Only Quarantine
Preserve the data without active use, except where Article 18(2) expressly permits processing.
04
Workflow Hold
Suspend downstream workflows that depend on the restricted data to prevent inadvertent use.
05
Processor Propagation
Notify processors and require confirmation that equivalent restriction controls are applied in their environments.
Controls 11–20: Notification to Governance
11. Recipient Notification
Notify prior recipients under Article 19 unless impossible or disproportionate.
12. Disproportionality Assessment
Document why notifying recipients would be impossible or involve disproportionate effort, with evidence.
13. Legal-Claim Preservation
Apply legal holds where data is needed to establish, exercise, or defend legal claims.
14. Accuracy-Verification Protocol
Define how disputed data will be checked, against what sources, by whom, and within what timeframe.
15. Objection-Balancing Protocol
Where Article 21 is involved, assess whether the controller's legitimate grounds override the data subject's interests.
16. Lifting-Restriction Notice
Notify the data subject before restriction is lifted, as Article 18(3) expressly requires.
17. Audit Logging
Log request receipt, identity checks, decisions, restrictions applied, recipients notified, exceptions, and closure.
18. SLA Monitoring
Track statutory deadlines, pauses, escalations, and overdue requests against Article 12 timelines.
19. Quality Assurance Sampling
Test closed cases for correct classification, timeliness, completeness, and evidence quality.
20. Management Reporting
Report volumes, breach links, recurring system defects, processor failures, and remediation actions to privacy governance bodies.
Operational Process: Receipt to Completion — Phase 1
A detailed large-company operational process for handling Article 18 requests from initial receipt through to risk triage and interim restriction. Each step must be documented and evidenced.
1
Step 1: Receive the Request
Capture requests from every channel. Do not require the words "Article 18" or "restriction." Treat phrases such as "stop using my data," "freeze my record," "don't delete it," "the data is wrong," or "I need it for court" as potential Article 18 triggers.
2
Step 2: Create a Case Record
Assign a unique case ID. Record date, time, channel, requester, business unit, products, systems, and alleged ground. Start the Article 12 response clock immediately.
3
Step 3: Verify Identity
Use proportionate verification. Avoid excessive identity demands. Escalate high-risk data, employee data, child data, financial data, health data, or fraud contexts to senior privacy staff.
4
Step 4: Confirm Scope
Identify whose data is involved and which processing operations are challenged. Avoid over-restricting unrelated data where the request is narrow and specific.
5
Step 5: Classify Legal Basis
Map to one of the four grounds: accuracy contested; processing unlawful and erasure opposed; controller no longer needs data but data subject needs it for legal claims; or Article 21 objection pending.
6
Step 6: Triage Risk
Prioritise cases involving automated decisions, credit, employment, safety, fraud, vulnerable people, special-category data, children, or imminent disclosure to third parties.
Where continued processing could cause harm, apply a temporary interim restriction immediately while full assessment proceeds — do not wait for the investigation to conclude before acting.
Operational Process: Phase 2 — Locating Data & Applying Technical Restriction
Step 7: Apply Interim Restriction
Where credible and feasible, apply a temporary restriction while assessment proceeds. This is especially important where continued processing could cause harm to the data subject.
Step 8: Locate Data
Search comprehensively across all systems:
CRM, ERP, HR, and finance systems
Marketing and customer-support platforms
Data warehouse and BI tools
Fraud platforms and identity systems
Archives and processor platforms
Derived, inferred, and linked data where relevant
Step 9: Map Downstream Use
Identify whether the data feeds campaigns, models, scoring, dashboards, third-party sharing, automated decisions, or operational workflows that must be suspended.
Step 10: Apply Technical Restriction
Add Restriction Flags
Apply durable metadata labels across all identified systems and records.
Suppress Workflows
Remove from active audiences and exclude from analytics pipelines immediately.
Block Disclosures
Block non-essential disclosures and prevent model training and data enrichment.
Step 11: Preserve Permitted Storage
Store the data securely. Prevent deletion if preservation is required for legal claims. Separate restriction from retention deletion rules where needed — restriction and deletion are distinct obligations that may conflict.
Operational Process: Phase 3 — Processor & Recipient Notification
Once technical restriction is applied internally, controllers must extend their obligations to processors and prior recipients under Articles 19 and 28.
1
Step 12: Notify Processors
Send structured processor instructions. Require written confirmation of implementation. Track processor SLA compliance against agreed timelines and escalate failures promptly.
2
Step 13: Notify Recipients
Identify all prior recipients of the restricted data. Notify them of the restriction unless notification is impossible or disproportionate. Record all notifications and exceptions with evidence.
3
Step 14: Assess Disproportionality
Consider number of recipients, age of disclosure, availability of contact details, technical feasibility, cost, risk to the data subject, and likely benefit of notification.
Disproportionality Assessment Factors
Number of Recipients
Large-scale disclosures may make individual notification impractical, but this must be evidenced.
Age of Disclosure
Very old disclosures where recipients may no longer hold the data may reduce the benefit of notification.
Technical Feasibility
Where contact details are unavailable or systems cannot be reached, document the barrier thoroughly.
Risk to Data Subject
Higher risk to the individual increases the obligation to notify, even where effort is significant.
Do not use inconvenience alone as a reason to avoid notifying recipients. Disproportionality must be evidenced, not assumed. Require DPO or privacy legal approval for high-risk non-notification decisions.
Operational Process: Phase 4 — Investigation, Decision & Communication
Step 15: Investigate Merits
Accuracy: Verify against authoritative records.
Unlawfulness: Assess Art. 5 and Art. 6 compliance.
Legal claims: Assess whether continued retention is plausibly necessary.
Objection: Complete legitimate-interest balancing test.
Step 16: Decide Outcome
Uphold restriction fully; uphold restriction partially; refuse restriction with documented reasons; or convert to another right such as rectification or erasure where more appropriate.
Step 17: Communicate Decision
Explain the outcome clearly. Identify what data is restricted. Explain permitted residual processing. Explain complaint rights and supervisory authority routes where refusing the request.
Investigation Standards by Ground
Decision Outcomes
1
Full Uphold
All processing suppressed; storage only permitted.
2
Partial Uphold
Restriction applied to specific data or operations only.
3
Refusal
No ground established; reasons documented; complaint rights explained.
4
Conversion
Redirected to rectification, erasure, or another right.
Operational Process: Phase 5 — Monitoring, Lifting & Closure
Step 18: Monitor Restriction
Run recurring checks to confirm restricted data is not reactivated by system updates, migrations, matching, deduplication, model refreshes, or campaign tools. Restriction must be technically durable, not a one-time flag.
Step 19: Lift Restriction Only When Justified
Lift only after the ground no longer applies. Notify the data subject before lifting, as Article 18(3) requires. Record the reason, approver, date, and systems released. Do not lift restriction without documented justification.
Step 20: Close and Retain Evidence
Retain the complete case file including legal analysis, technical logs, communications, processor confirmations, recipient notifications, and disproportionality assessments for the full retention period.
Evidence Retention Checklist
Case file with unique case ID and timeline
Legal analysis and ground classification
Technical restriction logs and system flags
All communications with the data subject
Processor instructions and confirmations
Recipient notification records
Disproportionality assessments with evidence
Lifting-restriction notice and approver record
Quality assurance review notes
Restriction monitoring must be ongoing — not a one-time technical action. System updates, data migrations, and model refreshes can silently reactivate restricted records.
The restriction lifecycle is not linear — monitoring must continue throughout the restriction period, and lifting requires the same rigour as initial application.
Monitoring Compliance & Grounds for Refusal
Monitoring Compliance
Volume Tracking
Track request volumes by ground, region, product, and system to identify patterns and systemic issues.
Timeline Monitoring
Monitor time to acknowledge, time to restrict, time to decide, and time to close against Article 12 deadlines.
Technical Testing
Test whether restricted records are excluded from marketing, profiling, analytics, AI training, and disclosures.
Processor Audits
Audit processors periodically and review complaints, DSAR escalations, regulator correspondence, and breach reports for Article 18 failures.
Use root-cause analysis where restriction requests reveal inaccurate data, unlawful processing, weak retention rules, or poor system lineage — these are systemic signals, not isolated incidents.
Grounds for Refusal, Exclusion, or Non-Action
A controller may refuse, exclude, narrow, or not action an Article 18 request in the following circumstances:
Identity Not Established
The requester cannot be identified after reasonable, proportionate verification efforts.
Not Personal Data
The request does not relate to personal data, or the data is anonymous and Article 18 does not apply.
Data Not Held
The controller does not process the relevant data, or none of the four Article 18 grounds applies to the request.
Manifestly Unfounded or Excessive
The request is manifestly unfounded or excessive under Article 12(5), or the same issue has already been resolved with no new facts provided.
Legal Obligation Conflict
The data must continue to be processed under a legal obligation, though unnecessary processing should still be suppressed where possible.
Third-Party Rights Conflict
The request conflicts with another person's rights and freedoms, requiring a balancing assessment.
Recipient notification being impossible or disproportionate must be evidenced, not assumed. The controller may still store the data and may process it where Article 18(2) permits — including for legal claims, consent, protection of rights, or important public interest.
Datari Home