Article 23: Restrictions

GDPR Article 23 lets you restrict certain GDPR transparency, data subject rights, and breach-notification duties only if an applicable EU or Member State law authorizes the restriction through a legislative measure. To operationalize it, you need a documented “restriction decision” workflow that confirms the legal basis, necessity and proportionality, scope, safeguards, and a controlled way to respond to data subject requests and incident notices under that restriction. ¹

Key takeaways:

• You cannot invent Article 23 restrictions; they must be grounded in an applicable legislative measure. ¹
• Treat restrictions as exceptions with tight scope, time bounds, and documented safeguards tied to specific purposes. ¹
• Your auditors will want evidence of the legal mapping, approvals, and consistent handling of data subject requests and Article 34 decisions. ¹

Article 23 is the GDPR’s “escape hatch” for certain obligations, but it is not a discretionary one. It applies when another law that binds your organization (EU-level or a Member State law) restricts the scope of specific GDPR rights and duties through a legislative measure, and only where the restriction preserves the essence of fundamental rights and is necessary and proportionate in a democratic society. ¹

For a CCO or GRC lead, the operational problem is predictable: business teams (or law enforcement-facing functions, security teams, HR/investigations, fraud, AML, or legal hold programs) want to delay or limit disclosures to a data subject, or avoid notifying individuals about a breach, because notification could undermine an investigation or another protected objective. Article 23 is the framework that tells you when that is legally possible, and what boundaries must be respected. ¹

This page gives requirement-level implementation guidance you can drop into your GDPR program: who owns decisions, what “good” evidence looks like, how to keep restrictions narrow, and how to prevent ad hoc “we can’t tell them” behavior that fails in an audit.

Regulatory text

Working excerpt (operator-relevant): Union or Member State law applicable to the controller or processor may restrict, by a legislative measure, the scope of obligations and rights in Articles 12–22 and Article 34, and Article 5 to the extent it corresponds to those rights and obligations, if the restriction respects the essence of fundamental rights and freedoms and is necessary and proportionate in a democratic society. ¹

What the operator must do with this text

1. Identify whether a restriction is legally available at all for the specific situation, based on an applicable legislative measure, not internal preference. ¹
2. Limit the restriction to the scope authorized (which rights/obligations, which processing, which people, which timeframe), and confirm it meets necessity/proportionality. ¹
3. Implement safeguards and consistent execution: your DSR process, transparency notices, and Article 34 breach notification workflow must have a controlled “restriction path” with approvals and records. ¹

Plain-English interpretation (what Article 23 means in practice)

Article 23 says: if another binding law tells you to withhold, delay, limit, or modify certain GDPR disclosures or rights (like access, erasure, objection, or breach notification), you may do so only within what that law allows. You still need to protect people’s fundamental rights. You still need governance, written rationale, and safeguards. ¹

For operators, this usually shows up as:

• DSR constraints (you cannot provide full access information because it would compromise a protected purpose under another law).
• Transparency constraints (you cannot fully disclose details at the moment of collection or later).
• Article 34 “no-notification” decisions (you delay or limit communications to affected individuals if another law permits restriction). ¹

Who it applies to

Entity scope

• Any organization acting as a controller or processor that is subject to Union or Member State law that creates a valid restriction by legislative measure. ¹

Operational contexts where you need an Article 23 procedure

• Security and incident response teams making Article 34 decisions. ¹
• Legal, compliance, investigations, fraud, and HR teams handling DSRs where responding could conflict with another legal obligation or protected objective. ¹
• Customer support / privacy operations teams that need a repeatable way to route “restricted response” cases to Legal/DPO for a decision. ¹

What you actually need to do (step-by-step)

1) Build a “Restriction Inventory” tied to real laws

Create a living register of the specific Union or Member State laws your organization relies on to restrict GDPR rights/obligations, with:

• Jurisdiction and entity applicability (which legal entity, which business line).
• The GDPR articles impacted (Articles 12–22 and/or 34; and Article 5 only as it corresponds). ¹
• The permitted restriction type (withhold vs delay vs partial disclosure).
• Preconditions and required safeguards.

This register is where teams fail most often: they treat “legal hold” or “investigation” as the authority, but Article 23 requires a legislative measure. ¹

Practical control: Maintain a GDPR role-and-scope register for this requirement, including controller/processor role, data categories, and affected systems.

2) Define a restriction decision workflow with named owners

Write an operating procedure that triggers when:

• A DSR response may need limitation, or
• A transparency notice may need modification, or
• Article 34 notification might be delayed/limited.

Minimum workflow design:

• Intake owner (privacy ops) triages and flags a potential restriction.
• Decision owner (DPO or Legal) validates the legislative measure and records necessity/proportionality rationale. ¹
• Approver (Legal/CCO) signs off for higher-risk cases (for example, where multiple rights are curtailed or a large population is impacted).
• Execution owner (privacy ops / incident manager) delivers the restricted response and tracks any future re-evaluation date or condition.

Practical control: Define a requirement-specific operating procedure with named owners, trigger events, and required approvals.

3) Standardize the “Restriction Decision Record” (your defensibility packet)

Use a template. Do not leave this to email threads.

Include:

• Request/incident identifier.
• Data subject and processing context.
• Which rights/obligations would normally apply (Articles 12–22 and/or 34). ¹
• Cited legislative measure (name, jurisdiction, applicability statement).
• Necessity and proportionality narrative tied to the situation. ¹
• Scope boundaries: what is restricted, what is still provided, and why.
• Safeguards: access controls, need-to-know, retention limits, internal review, and when the restriction will be reassessed.
• Final decision, approvers, timestamps.
• Outbound response text or incident communication decision outcome.

4) Implement restricted-response playbooks for DSRs

For privacy ops, create pre-approved response patterns:

• “We cannot provide full information at this time due to legal restrictions” (only where supported by your restriction inventory).
• Partial disclosure rules (what fields you can still return).
• Escalation triggers (law enforcement involvement, ongoing investigations, suspected fraud, employee investigations).

Operational requirement: your DSR tooling should support a case subtype for “Article 23 restriction” with mandatory fields for the decision record and approval capture.

5) Add an Article 23 checkpoint to your Article 34 workflow

If your incident response team decides not to notify individuals, or to limit/delay notification content, the workflow must require:

• Documented legal basis (legislative measure).
• Documented necessity/proportionality. ¹
• Documentation of which parts of Article 34 are restricted and what you still do (for example, notifying the authority versus individuals, depending on your legal analysis).

6) Audit the control in practice (not on paper)

Run periodic sampling:

• A sample of DSRs closed as “restricted” and verify the decision record exists and matches the register.
• A sample of incidents where notification decisions were complex and confirm Article 23 was considered and documented, if used. ¹

Practical control: Retain auditable evidence packets (decision record, control outputs, exceptions, and remediation) on a recurring cadence.

Required evidence and artifacts to retain (what auditors ask for)

Maintain an “Article 23 evidence packet” per restriction event, plus program-level artifacts:

Program-level

• Restriction Inventory (law mapping to impacted GDPR rights/obligations). ¹
• Operating procedure for restrictions (owners, triggers, approvals).
• Training record for privacy ops and incident response on restricted pathways.

Case-level

• Restriction Decision Record (completed template).
• Copy of the restricted DSR response (or logged response content).
• Incident comms decision record where Article 34 is affected. ¹
• Any remediation actions (process fixes, staff coaching, tool configuration changes).

Common exam/audit questions and hangups

Expect these questions:

• “Show the law that authorizes the restriction, and show it applies to this entity and this situation.” ¹
• “Which GDPR rights/obligations did you restrict, and why were narrower alternatives insufficient?” ¹
• “How do you ensure consistency so the restriction isn’t applied ad hoc?”
• “Who approves restrictions, and what separation of duties exists between the request handler and decision maker?”
• “How do you reassess restrictions over time so they don’t become permanent by default?” ¹

Frequent implementation mistakes (and how to avoid them)

1. Treating Article 23 as internal discretion. Fix: require a legislative-measure citation in every restricted case; no citation, no restriction. ¹
2. Over-broad restrictions. Fix: force scoping fields in the decision template (which data, which systems, which time window, which rights).
3. No record of necessity/proportionality. Fix: a mandatory “alternatives considered” section and an approver checklist. ¹
4. Privacy ops stuck in the middle. Fix: pre-approved routing and response patterns, with Legal/DPO as decision owner.
5. Incident response and privacy are disconnected. Fix: add an Article 23 checkpoint in the Article 34 decision tree and require privacy sign-off when notification is limited/delayed. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so this guidance stays requirement-level. Practically, Article 23 failures tend to surface during supervisory authority inquiries, customer diligence, or litigation, because restrictions impact data subject rights and breach communications. Your risk is less about having a restriction and more about failing to prove it was legally grounded, necessary, proportionate, and tightly executed. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up governance and repeatability)

• Assign owners: DPO/Legal (decision), privacy ops (intake/execution), security (Article 34 workflow integration).
• Draft the operating procedure and decision template.
• Start the Restriction Inventory with the top jurisdictions you operate in, and your most common restriction scenarios. ¹
• Configure DSR case management to require approval and documentation for restricted cases.

Days 31–60 (embed into workflows and train)

• Train privacy ops, incident response, investigations, and customer support on triggers and escalation paths.
• Integrate an Article 23 checkpoint into:
  • DSR workflow (Articles 12–22 scope) ¹
  • Incident workflow (Article 34 decisions) ¹
• Pilot sampling: review a small set of recent DSRs/incidents to validate evidence quality.

Days 61–90 (prove operating effectiveness)

• Perform a structured control test: pull restricted cases and confirm the register, decision record, approvals, and outbound comms align.
• Close gaps: fix templates, add required fields, adjust routing rules, update training content.
• Package evidence for external scrutiny: a clean folder structure per case and a quarterly summary report for the CCO/DPO.

How Daydream helps (practical, non-disruptive)

If you manage third-party risk and privacy operations across multiple tools, Daydream can act as the system of record for Article 23 restriction decisions: intake routing, required fields, approval capture, and evidence packet assembly. The key is consistency: Daydream makes the “restriction path” a controlled workflow rather than an email-based exception.

Frequently Asked Questions

Can we restrict a data subject access request because it’s inconvenient or resource-intensive?

Not under Article 23. A restriction must be based on an applicable Union or Member State legislative measure and meet necessity and proportionality conditions. ¹

Does Article 23 let us ignore GDPR principles in Article 5?

Only to the extent Article 5 provisions correspond to the restricted rights and obligations in Articles 12–22. Treat it as a narrow linkage, not a broad waiver. ¹

Who should approve an Article 23 restriction decision?

Put the decision with Legal and/or the DPO, with documented approval and a recorded rationale. Privacy ops should execute the response, not decide the legal basis. ¹

How do we handle third parties (processors) when a restriction applies?

Ensure contracts and operating procedures require the processor to route restricted DSRs and incident communications decisions to you (controller) or to the responsible decision owner, and to preserve the decision record evidence.

Can we delay Article 34 breach notifications using Article 23?

Only if an applicable legislative measure permits restricting the Article 34 obligation and the restriction is necessary and proportionate. Document the legal basis and the scope of what is delayed or limited. ¹

What’s the minimum documentation an auditor will expect for restricted DSRs?

A documented link to the legislative measure, a necessity/proportionality rationale, scope boundaries, approvals, and the actual outbound response text or record of what was withheld. ¹

Footnotes

1. Regulation (EU) 2016/679, Article 23