Article 23: Restrictions

To meet the article 23: restrictions requirement, you must only restrict GDPR data subject rights or controller/processor obligations when a specific Union or Member State legislative measure authorizes it, and you can show the restriction is necessary, proportionate, and preserves the essence of fundamental rights. Operationalize this with a documented “restriction decision” workflow tied to DSAR and breach-notification processes. (Regulation (EU) 2016/679, Article 23)

Key takeaways:

• You cannot “choose” to limit DSAR responses; you need a qualifying law and a defensible necessity/proportionality analysis. (Regulation (EU) 2016/679, Article 23)
• Build a repeatable restriction decision record for each event (DSAR, transparency notice, breach notice) where you claim Article 23. (Regulation (EU) 2016/679, Article 23)
• Maintain a role-and-scope register so you know which business units, systems, and third parties can trigger Article 23 scenarios. (Regulation (EU) 2016/679, Article 23)

Article 23 is the GDPR’s “legal override valve,” but it is narrower than many teams assume. It does not create an internal discretion to withhold information or deny rights because a request is inconvenient, expensive, or risky. It allows restrictions only where a Union or Member State law, through a legislative measure, restricts the scope of certain GDPR obligations and data subject rights, and only if the restriction respects fundamental rights and is necessary and proportionate in a democratic society. (Regulation (EU) 2016/679, Article 23)

For a CCO or GRC lead, the practical problem is repeatability: restrictions surface under pressure, usually during DSAR triage, investigations, litigation holds, insider-threat response, fraud monitoring, whistleblower programs, or law enforcement interactions. Your objective is to make “Are we allowed to restrict?” a structured decision, not an improvised judgment call. You want a small set of triggers, named owners (Legal, Privacy, Security), pre-approved legal bases mapped by jurisdiction, and an evidence packet that survives scrutiny months later.

This page gives requirement-level implementation guidance so your teams can apply Article 23 consistently across DSAR, transparency, and breach workflows, including when third parties are involved.

Regulatory text

GDPR Article 23 (excerpt): Union or Member State law to which the controller or processor is subject may restrict, by 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/obligations, when the restriction respects the essence of fundamental rights and freedoms and is a necessary and proportionate measure in a democratic society. (Regulation (EU) 2016/679, Article 23)

Operator meaning (what you must do):

1. Identify the legislative measure you rely on before restricting any right or obligation in scope (e.g., DSAR response content/timing, transparency disclosures, breach notification to individuals). Article 23 is conditional on law; policy alone is not enough. (Regulation (EU) 2016/679, Article 23)
2. Document necessity and proportionality for the specific restriction you apply. Expect to justify “why this restriction, why now, why this much.” (Regulation (EU) 2016/679, Article 23)
3. Preserve the essence of the right. Even with a restriction, you still need to handle the request or obligation to the extent permitted by the applicable law. (Regulation (EU) 2016/679, Article 23)

Plain-English interpretation of the requirement

Article 23 allows limited “carve-outs” from certain GDPR rights and duties, but only if a specific EU or Member State law says you can restrict them. You must treat restrictions as exceptions with tight controls: legal authority, documented rationale, and minimal scope. (Regulation (EU) 2016/679, Article 23)

Common real-world examples where teams look for Article 23 cover:

• DSARs that intersect with active investigations, fraud prevention, misconduct response, or security incidents.
• Transparency disclosures that could compromise an investigation or security controls.
• Breach notification to individuals where a law permits delay or limitation for public-interest reasons.

Whether you can restrict depends on the exact law applicable to your entity and jurisdiction, not on a general risk concern. (Regulation (EU) 2016/679, Article 23)

Who it applies to (entity and operational context)

Applies to:

• Controllers and processors subject to GDPR who are considering restricting obligations/rights within Articles 12–22, 34, and related parts of Article 5. (Regulation (EU) 2016/679, Article 23)

Where it shows up operationally:

• DSAR intake and fulfillment: access, deletion, rectification, objection, restriction of processing, portability, automated decision-making requests. (Regulation (EU) 2016/679, Article 23)
• Breach response: notification to data subjects (Article 34) decisions and messaging. (Regulation (EU) 2016/679, Article 23)
• Third-party processing: when a processor receives a request or incident information but the controller’s legal constraints drive the response, you still need a coordinated restriction decision and an auditable trail. (Regulation (EU) 2016/679, Article 23)

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

1) Build an Article 23 applicability map (jurisdiction + scenario)

Create a simple matrix that answers: “In which countries do we operate, and what legislative measures might constrain DSARs or notifications for specific scenarios?”

Minimum fields:

• Country/jurisdiction
• In-scope scenario (DSAR, breach notice, investigation)
• Qualifying legislative measure (name/reference maintained by Legal)
• What can be restricted (which rights/obligations)
• Conditions (who approves, what must be documented)

Keep the matrix owned by Legal/Privacy, but published to DSAR and incident response owners as “what to check.” (Regulation (EU) 2016/679, Article 23)

2) Define a restriction decision workflow with named owners

Put Article 23 into your operating procedures, not just your privacy policy.

Workflow triggers (examples):

• DSAR includes data tied to active investigation or fraud monitoring.
• Request involves information that would reveal security controls.
• Breach response includes law enforcement engagement.

Decision owners:

• Privacy lead (process owner)
• Legal counsel (legislative measure validation)
• Security/Incident Commander (facts and risk context)

Decision output:

• Approve restriction (scope defined)
• Partially restrict (redactions, staged response)
• Deny restriction (proceed with normal GDPR flow)

This should be a formal approval step in your DSAR case management and incident management tooling. (Regulation (EU) 2016/679, Article 23)

3) Standardize the “restriction decision record” (one-page, auditable)

Make it easy for teams to do the right thing quickly. A restriction decision record should include:

• Request/incident identifier and date
• Controller/processor role for the activity and which entity is “subject to” the legislative measure (important for groups)
• Which GDPR right/obligation is being restricted (Articles 12–22 or 34)
• Legislative measure relied upon (link/reference maintained by Legal)
• Necessity analysis (why a restriction is needed for this case)
• Proportionality analysis (why the restriction is limited to what’s needed)
• Scope: what is withheld/delayed/limited; what will still be provided
• Review date/trigger for lifting the restriction
• Approver names and timestamps

This is the core artifact regulators, customers, and internal audit ask for when they suspect “blanket DSAR denials.” (Regulation (EU) 2016/679, Article 23)

4) Align DSAR playbooks and templates to “restricted response” modes

Update DSAR runbooks so teams can execute restrictions without inventing language on the fly.

Operational changes:

• Add DSAR outcome codes: “fulfilled,” “partially fulfilled,” “restricted under applicable law (Article 23).”
• Create response templates for partial disclosure and delayed disclosure that avoid over-explaining the restriction.
• Add redaction standards, including review by Legal for investigative or security-sensitive content.

Your goal is consistent execution and consistent tone across business units. (Regulation (EU) 2016/679, Article 23)

5) Connect third parties to the restriction process

If third parties process personal data for you, update procedures so they:

• Route DSARs to you promptly.
• Do not respond directly unless contractually authorized.
• Preserve relevant logs and extracts, because you may need evidence of what was withheld and why.

If you are the processor, build an intake-to-controller escalation path and retain the controller’s instruction and restriction rationale where appropriate. (Regulation (EU) 2016/679, Article 23)

6) Run a defensibility check: “No blanket restrictions”

Audit for patterns:

• Same restriction rationale pasted into many cases.
• Restrictions applied without a specific legislative measure.
• Restrictions applied to the entire request when only a small subset needed protection.

Article 23 is exception handling. Treat repetition as a signal your matrix, training, or tooling is weak. (Regulation (EU) 2016/679, Article 23)

Required evidence and artifacts to retain

Keep an “Article 23 evidence packet” per restricted event, plus program-level artifacts.

Program-level artifacts

• Role-and-scope register (controller vs processor per system/process)
• Article 23 applicability matrix (jurisdiction/scenario mapping)
• DSAR procedure with Article 23 decision point
• Incident response procedure with Article 23/Article 34 decision point
• Training records for DSAR and incident response teams

Case-level artifacts

• Restriction decision record (approved and time-stamped)
• Copies of communications sent (restricted response templates)
• Redaction logs or withheld-data index (what categories were restricted)
• Evidence of review/lifting decision when the restriction no longer applies

These artifacts are what you need to answer “show me” questions without reconstructing decisions from email threads. (Regulation (EU) 2016/679, Article 23)

Common exam/audit questions and hangups

Expect auditors or regulators to test consistency and legal authority:

• “Show the legislative measure that allowed this restriction.” (Regulation (EU) 2016/679, Article 23)
• “Who approved the restriction, and what facts did they rely on?” (Regulation (EU) 2016/679, Article 23)
• “Why was the restriction necessary and proportionate, and why did you restrict this portion rather than the whole request?” (Regulation (EU) 2016/679, Article 23)
• “How do you ensure restrictions are lifted when no longer needed?” (Regulation (EU) 2016/679, Article 23)
• “How do processors follow controller instructions and avoid unauthorized responses?” (Regulation (EU) 2016/679, Article 23)

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	What to do instead
Treating Article 23 as a general “risk exception”	Article 23 requires a legislative measure, not internal preference. (Regulation (EU) 2016/679, Article 23)	Maintain a jurisdictional map of qualifying laws and require Legal validation per case.
Blanket DSAR restriction when only one data source is sensitive	Proportionality requires narrow scope. (Regulation (EU) 2016/679, Article 23)	Redact or segment specific systems/records; fulfill the rest.
No written decision record	You cannot prove necessity/proportionality after the fact. (Regulation (EU) 2016/679, Article 23)	Use a one-page restriction decision template in the case tool.
Processors responding ad hoc	Creates inconsistent legal posture and messaging. (Regulation (EU) 2016/679, Article 23)	Contract and procedure: route to controller; document controller instructions.
No “lift restriction” trigger	Restrictions become de facto permanent. (Regulation (EU) 2016/679, Article 23)	Add a review trigger tied to investigation closure or elapsed time set by Legal.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific matters.

Practically, Article 23 failures tend to show up as:

• DSAR escalation risk: individuals challenge incomplete responses, and you cannot show a valid legal basis for restricting. (Regulation (EU) 2016/679, Article 23)
• Incident communications risk: delayed or altered notices to individuals without a clear legislative measure and documented rationale. (Regulation (EU) 2016/679, Article 23)
• Program credibility risk: internal audit and supervisory authority confidence drops when restrictions look routine rather than exceptional. (Regulation (EU) 2016/679, Article 23)

A practical 30/60/90-day execution plan

First 30 days (stabilize decisions)

• Assign an Article 23 owner (Privacy or Legal) and create the restriction decision template. (Regulation (EU) 2016/679, Article 23)
• Update DSAR triage to include an Article 23 flag and mandatory Legal review when flagged. (Regulation (EU) 2016/679, Article 23)
• Start the role-and-scope register for DSAR and breach workflows, including key systems and third parties. (Regulation (EU) 2016/679, Article 23)

Days 31–60 (operationalize across teams)

• Publish the jurisdiction/scenario applicability matrix maintained by Legal, and train DSAR and incident responders on how to use it. (Regulation (EU) 2016/679, Article 23)
• Add restricted-response templates and redaction standards to the DSAR playbook. (Regulation (EU) 2016/679, Article 23)
• Update third-party procedures: routing, instructions, and evidence preservation expectations. (Regulation (EU) 2016/679, Article 23)

Days 61–90 (prove repeatability)

• Run a tabletop exercise: one DSAR with investigation overlap and one breach scenario that tests Article 34 interactions with Article 23 restrictions. (Regulation (EU) 2016/679, Article 23)
• Sample closed cases and check for complete evidence packets; remediate gaps with targeted coaching. (Regulation (EU) 2016/679, Article 23)
• Put ongoing monitoring in place: periodic review of restriction frequency, rationale quality, and “lift restriction” outcomes. (Regulation (EU) 2016/679, Article 23)

Where Daydream fits naturally Daydream helps by turning Article 23 into an executable control: a role-and-scope register, a restriction decision workflow with approvals, and recurring evidence packets you can hand to audit or regulators without rebuilding the story from scratch. (Regulation (EU) 2016/679, Article 23)

Frequently Asked Questions

Does Article 23 let us deny a DSAR because it would reveal internal investigations?

Only if a Union or Member State legislative measure applicable to your entity allows restricting the relevant GDPR rights, and you document necessity and proportionality for the specific case. Article 23 itself is not the legal measure; it points you to one. (Regulation (EU) 2016/679, Article 23)

Can we apply a standard “restricted under Article 23” message to all sensitive requests?

You can standardize templates, but the decision cannot be boilerplate. Each restriction needs a case-specific record tied to an applicable legislative measure and scoped to what is necessary. (Regulation (EU) 2016/679, Article 23)

Which GDPR obligations can be restricted under Article 23?

Article 23 references restricting the scope of obligations and rights in Articles 12 to 22 and Article 34, plus Article 5 to the extent it corresponds to those rights and obligations. Your workflow should explicitly label which right/obligation is impacted in each case. (Regulation (EU) 2016/679, Article 23)

We’re a processor. Do we make the Article 23 restriction decision?

Usually the controller determines the legal posture, but processors still need an internal process to escalate, document controller instructions, and avoid unauthorized responses. Keep the controller’s instruction with the case record. (Regulation (EU) 2016/679, Article 23)

How do we show “necessary and proportionate” in a way that stands up in audit?

Require a short written rationale that ties the restriction to the specific risk the legislative measure addresses, and document why you restricted only certain data elements or timing rather than the entire response. Add a trigger to revisit and lift the restriction. (Regulation (EU) 2016/679, Article 23)

Do we need to update our incident response plan because of Article 23?

Yes if your breach workflow includes decisions about notifying individuals under Article 34 and you operate in jurisdictions where a legislative measure can restrict or delay that obligation. Embed Legal approval and a decision record in the incident timeline. (Regulation (EU) 2016/679, Article 23)