Article 72: Procedure

GDPR Article 72 is a governance requirement about how the European Data Protection Board (EDPB) makes decisions: by simple majority unless the GDPR specifies a different voting rule. To operationalize it, you don’t “implement” voting mechanics inside your company; you ensure your GDPR program can recognize, track, and act on EDPB decisions and guidelines that are adopted under this procedure. 1

Key takeaways:

  • Article 72 applies to the EDPB’s internal decision-making, not to a company’s internal approvals. 1
  • Your operational obligation is indirect: monitor EDPB outputs and translate them into policy, controls, and evidence. 2
  • Build a documented intake-to-implementation workflow for EDPB decisions, with owners, impact assessment, and closure evidence.

“Article 72: procedure requirement” sounds like a corporate process control. It isn’t. Article 72 is addressed to “the Board,” meaning the European Data Protection Board (EDPB), and it sets the default voting threshold for EDPB decisions: simple majority, unless another GDPR provision sets a different rule. 1

Why should a CCO or GRC lead care? Because EDPB decisions and guidance can materially affect how regulators interpret GDPR requirements in practice. Your risk is not “failing a vote.” Your risk is missing an EDPB position that changes enforcement expectations, then continuing to operate an outdated control, DPIA approach, or cross-border process.

This requirement page is written for operators who need a fast path: define scope, stand up a monitoring and triage workflow, assign accountable owners, and produce an audit-ready evidence pack that shows you consistently track and implement EDPB-driven changes. The goal is practical defensibility during supervisory authority inquiries, customer diligence, and internal audit.

Regulatory text

Text (excerpt): “The Board shall take decisions by a simple majority of its members, unless otherwise provided for in this Regulation.” 1

What the operator must do with this text

  • Treat Article 72 as external governance context: it tells you how EDPB decisions are validly adopted. 1
  • Operationalize the impact by building a repeatable mechanism to identify EDPB outputs (decisions, guidelines, opinions, recommendations) and translate them into your GDPR control environment. 2
  • Document your “EDPB change intake” so you can show an examiner you have a system to keep your GDPR program current, not a one-time policy publication.

Plain-English interpretation (what Article 72 means for a company)

  • Literal meaning: EDPB decisions pass by simple majority unless GDPR requires another threshold. 1
  • Practical meaning for you: When the EDPB issues a decision or guidance, you should assume it has gone through a defined, legitimate process. Your job is to decide whether it changes your obligations, controls, or risk posture, then implement changes with evidence. 2

Who it applies to (entity and operational context)

Direct addressee

  • The requirement directly applies to the European Data Protection Board and its members’ decision-making procedure. 1

Indirect applicability (your reality)

  • Any organization subject to GDPR (controllers and processors) should maintain an operating capability to track and implement authoritative regulatory interpretations and decisions that influence supervisory expectations. 2

Operational contexts where this matters most

  • Cross-border processing and multi-authority exposure: you need a consistent interpretation baseline across EU operations.
  • High-risk processing portfolios: where guidance shifts can affect DPIA thresholds, transparency expectations, or security expectations.
  • Third-party-heavy ecosystems: where a change in interpretation requires updates to DPAs, vendor due diligence, and onward transfer controls.

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

1) Establish scope and ownership (make it auditable)

Create a short, requirement-specific record that states:

  • This requirement is EDPB governance (external).
  • Your internal control objective: EDPB monitoring, assessment, implementation, and evidence retention.
  • Primary owner (e.g., Privacy/GRC) and approvers (Legal, Security, Product).
    This is where Daydream fits naturally: store a single “requirement card” with named owners, systems in scope, and linked artifacts so the work doesn’t live in scattered inbox threads.

2) Build an “EDPB intake” workflow (one page, not a binder)

Define trigger events and routing:

  • Trigger: new EDPB guideline/opinion/decision relevant to your processing profile. 2
  • Triage within the privacy function: classify as No impact / Needs review / Requires change.
  • Route “Needs review” to a small standing group (Privacy + Legal + Security/Engineering rep).
  • Capture a decision record: what you reviewed, what you concluded, and why.

Operator tip: your workflow must produce artifacts even when the outcome is “no change.” “No change” with a rationale is defensible; silence is not.

3) Maintain a GDPR role-and-scope register (anchor every interpretation)

Even though Article 72 is not about controller/processor roles, your ability to apply EDPB outputs depends on knowing:

  • Are you acting as controller, processor, or both for each product line?
  • What data categories and systems are implicated?
  • Which third parties touch the flow?
    Maintain a living register that maps processing activities to roles, data types, and systems. This is a practical prerequisite to implementing any regulatory change consistently.

4) Perform a structured impact assessment (fast, repeatable, consistent)

Use a standard template:

  • What changed? (summary of the EDPB output)
  • Where could it apply? (systems/processes/regions)
  • What control areas are impacted? privacy notices, legal bases, DPIAs, DSAR handling, retention, security measures, transfer assessments, third-party contracting
  • Decision: adopt change, track as watch item, or no change
  • Actions and owners: tickets, policy updates, contract changes, training updates

Map impacted actions to recognized control families so audit and security stakeholders can follow:

  • ISO/IEC 27001 control program (change management, policy control, supplier relationships, evidence retention)
  • NIST-style governance and lifecycle controls (govern, identify, protect, respond)
    You don’t need to “implement ISO” here; you need an internal taxonomy that makes changes traceable and testable.

5) Translate decisions into operational controls (where teams fail)

Convert conclusions into concrete work items:

  • Update policy language and SOPs (privacy by design, DPIA triggers, DSAR playbooks)
  • Update engineering requirements (logging, deletion workflows, consent management)
  • Update third-party controls (DPA templates, SCC addenda process, subprocessor reviews, security addenda)
  • Update training and internal guidance for customer-facing teams

Daydream can reduce the operational drag by linking “the requirement → the decision record → the control updates → the evidence packet,” so you can answer diligence requests without rebuilding the story.

6) Close the loop with evidence and testing

For each EDPB item you triage:

  • Confirm completion of changes (e.g., PR merged, procedure published, contract template versioned).
  • Run a lightweight validation (spot-check a DSAR, check a retention job, sample vendor agreements).
  • Record exceptions and remediation plans.

Required evidence and artifacts to retain

Keep an “evidence packet” per tracked EDPB item:

  • EDPB intake log entry (date received, source, internal reference)
  • Triage decision record (impact category, rationale, approvers)
  • Role-and-scope mapping (which processing activities/systems were evaluated)
  • Action tracker (tickets, owners, completion evidence)
  • Updated documents (policy/SOP version history, control narratives)
  • Exception register (accepted risks, compensating controls, remediation owner)

If your auditors ask “show me how you stay current,” this packet is the answer.

Common exam/audit questions and hangups

  • “Show how you monitor EDPB guidance and determine applicability.” Expect to produce your intake log and decision records. 2
  • “Where is this embedded in change management?” Auditors dislike privacy changes that bypass formal change control.
  • “How do you ensure consistency across business units and regions?” A central log with scoped applicability is the cleanest response.
  • “Prove this is operating, not shelfware.” They will sample multiple items and trace to implemented changes.

Frequent implementation mistakes (and how to avoid them)

  1. Treating Article 72 as an internal corporate voting requirement
    Fix: document it explicitly as EDPB procedure, then focus on monitoring and adoption of outputs. 1

  2. No defined owner for regulatory change intake
    Fix: assign Privacy/GRC as accountable, with Legal as required approver for interpretive calls.

  3. Policy updates without control updates
    Fix: require each “adopt” decision to generate operational tasks (engineering, third-party contracting, training) plus closure evidence.

  4. No evidence for “no impact” decisions
    Fix: require a short rationale and scope statement (what you checked) for every triage item.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for Article 72, so you should not expect fines to cite “Article 72 violations” against companies. Your risk is indirect: if you fail to track and implement EDPB positions that affect supervisory interpretation, you increase the chance of adverse findings under other GDPR obligations during an investigation or audit. 2

Practical 30/60/90-day execution plan

First 30 days (stand up the mechanism)

  • Assign owner and approvers for EDPB intake and interpretation.
  • Create the intake log and a decision record template.
  • Stand up the role-and-scope register for GDPR processing that your team can keep current.
  • Choose a system of record (a GRC tool or Daydream) for storing decision records and evidence packets.

Days 31–60 (operate it on real items)

  • Run the workflow on recent EDPB outputs relevant to your footprint.
  • Produce evidence packets, including “no impact” decisions.
  • Convert at least one “adopt change” decision into tracked implementation tasks across policy, engineering, and third-party contracting (as applicable).

Days 61–90 (make it exam-ready)

  • Add lightweight testing steps (spot checks) to prove the control operates.
  • Create an internal audit-ready narrative: “how we monitor, decide, implement, and evidence EDPB-driven changes.”
  • Train stakeholders (Legal, Security, Procurement, Product) on how requests will be routed and what “done” looks like.

Frequently Asked Questions

Does Article 72 require my company’s privacy committee to vote by simple majority?

No. Article 72 describes how the European Data Protection Board takes decisions. 1 Your company obligation is to monitor and act on EDPB outputs as part of a mature GDPR governance process. 2

What should I show an auditor to demonstrate alignment with the article 72: procedure requirement?

Show your EDPB intake log, decision records, and evidence packets tying regulatory outputs to implemented control changes. Keep proof even when you decide “no impact,” with a brief rationale and scope statement.

We don’t operate in the EU. Do we still need this?

If GDPR applies to your processing, you should track EDPB outputs that can influence supervisory interpretation. 2 If GDPR does not apply, you can document that determination and close the item as out of scope.

How do I keep this lightweight without missing meaningful updates?

Use a triage model: log everything you monitor, then escalate only items that plausibly affect your processing activities or third-party arrangements. Require a short decision record for each item so you can prove governance without creating paperwork for its own sake.

Who should approve “no impact” vs “requires change” decisions?

Privacy/GRC can typically approve “no impact” with Legal review available for edge cases. For “requires change,” require Legal sign-off and an accountable delivery owner (Security, Engineering, or Procurement) for implementation closure.

How does Daydream help here without turning this into busywork?

Daydream works well as the system of record for the intake log, scoped applicability, decision records, and linked evidence artifacts. The practical benefit is faster responses to audits and diligence because the story is already assembled and traceable.

Footnotes

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

  2. Regulation (EU) 2016/679

Frequently Asked Questions

Does Article 72 require my company’s privacy committee to vote by simple majority?

No. Article 72 describes how the European Data Protection Board takes decisions. (Source: Regulation (EU) 2016/679, Article 72) Your company obligation is to monitor and act on EDPB outputs as part of a mature GDPR governance process. (Source: Regulation (EU) 2016/679)

What should I show an auditor to demonstrate alignment with the article 72: procedure requirement?

Show your EDPB intake log, decision records, and evidence packets tying regulatory outputs to implemented control changes. Keep proof even when you decide “no impact,” with a brief rationale and scope statement.

We don’t operate in the EU. Do we still need this?

If GDPR applies to your processing, you should track EDPB outputs that can influence supervisory interpretation. (Source: Regulation (EU) 2016/679) If GDPR does not apply, you can document that determination and close the item as out of scope.

How do I keep this lightweight without missing meaningful updates?

Use a triage model: log everything you monitor, then escalate only items that plausibly affect your processing activities or third-party arrangements. Require a short decision record for each item so you can prove governance without creating paperwork for its own sake.

Who should approve “no impact” vs “requires change” decisions?

Privacy/GRC can typically approve “no impact” with Legal review available for edge cases. For “requires change,” require Legal sign-off and an accountable delivery owner (Security, Engineering, or Procurement) for implementation closure.

How does Daydream help here without turning this into busywork?

Daydream works well as the system of record for the intake log, scoped applicability, decision records, and linked evidence artifacts. The practical benefit is faster responses to audits and diligence because the story is already assembled and traceable.

Operationalize this requirement

Map requirement text to controls, owners, evidence, and review workflows inside Daydream.

See Daydream