Article 47: Binding corporate rules

Article 47 requires you to implement Binding Corporate Rules (BCRs) as an approved, legally binding internal code for cross-border transfers of personal data within your corporate group, and to run them like an audited control system. Operationalize it by scoping eligible intra-group transfers, drafting controller/processor BCRs with required commitments, and preparing an approval package for the competent supervisory authority under the GDPR consistency mechanism. (Regulation (EU) 2016/679, Article 47)

Key takeaways:

• BCRs are an intra-group transfer tool; they are not a general-purpose substitute for third-party transfer agreements. (Regulation (EU) 2016/679, Article 47)
• Your biggest execution risk is treating BCRs as a policy project rather than a program with owners, training, auditability, and change control. (Regulation (EU) 2016/679)
• Start with role-and-scope decisions (controller vs. processor BCRs, systems, data types, transfer routes) before writing. (Regulation (EU) 2016/679, Article 47)

A CCO or GRC lead usually meets Article 47 when the business wants a scalable way to support recurring personal data transfers inside a multinational group, including transfers from the EEA to affiliates in other jurisdictions. Binding Corporate Rules are designed for that use case: they are internal rules that become legally binding across group members and are approved by a supervisory authority using the GDPR’s consistency mechanism. (Regulation (EU) 2016/679, Article 47)

Operationally, Article 47 is less about a single document and more about building a defensible “transfer governance system” for intra-group processing. Regulators and customers will expect you to show: (1) you know which transfers are in scope, (2) your rules cover the required commitments, (3) the rules are actually binding and enforced across entities, and (4) you can prove training, audit, complaint handling, remediation, and change management work in practice. (Regulation (EU) 2016/679)

This page focuses on turning that into an execution plan: how to scope, draft, govern, evidence, and maintain BCRs so you can pass a regulator review or customer diligence without scrambling.

Regulatory text

Excerpt (provided): “The competent supervisory authority shall approve binding corporate rules in accordance with the consistency mechanism set out in Article 63, provided that they:” (Regulation (EU) 2016/679, Article 47)

What that means for an operator

• You do not “self-declare” BCR compliance. Approval comes from the competent supervisory authority, and the approval process follows the GDPR consistency mechanism referenced in Article 63. (Regulation (EU) 2016/679, Article 47)
• Your job is to build (a) BCR content that meets the GDPR’s conditions, and (b) evidence that the rules are binding and operationally effective across the group. (Regulation (EU) 2016/679)

Practical reading: Article 47 is the requirement to run an approval-grade program for intra-group transfers, not a template exercise. Treat it like a control framework with a legal wrapper. (Regulation (EU) 2016/679, Article 47)

Plain-English interpretation (requirement-level)

If your company group wants to transfer personal data within the group across borders (including outside the EEA) on a repeatable basis, you must adopt Binding Corporate Rules that are legally binding on all relevant group members, grant enforceable rights to data subjects, and are approved by a supervisory authority. Then you must keep them current and provably followed. (Regulation (EU) 2016/679, Article 47)

Who it applies to (entity and operational context)

Applies to:

• Corporate groups (multiple affiliated legal entities) that move EU personal data between group members across borders and want to rely on BCRs as the transfer safeguard. (Regulation (EU) 2016/679, Article 47)
• Controllers and processors. In practice, you may need controller BCRs, processor BCRs, or both, depending on how group entities act in the transfer chain. (Regulation (EU) 2016/679)

Common operational triggers

• Shared service centers (HR, finance, IT support) processing EU employee/customer data for multiple affiliates.
• Centralized hosting or analytics outside the EEA for group companies.
• Group-wide platforms (CRM, IAM, logging, customer support tooling) administered by a non-EEA affiliate.

When BCRs are a poor fit

• Transfers to third parties outside your corporate group. BCRs are designed for intra-group transfers, so your third-party transfer path usually needs different safeguards and contracting. (Regulation (EU) 2016/679, Article 47)

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

1) Establish role and scope (your “BCR eligibility map”)

Create a register that answers, for each in-scope processing stream:

• Which entity is exporting data from the EEA?
• Which group entities import and process the data?
• Controller vs. processor role for each entity per processing purpose.
• Data categories and systems involved.
• Transfer routes (including onward flows inside the group).

Artifact: “Article 47 role-and-scope register” (owner: Privacy/GRC; contributors: Legal, Security, IT, HR, product ops).
This aligns with the operational control expectation to maintain a role-and-scope register. (Regulation (EU) 2016/679, Article 47)

2) Choose your BCR type(s) and governance model

Decide whether you need:

• Controller BCRs (group companies determine purposes/means).
• Processor BCRs (a group entity processes on behalf of customers or another group controller).

Set program governance:

• Executive sponsor (often CCO, GC, or DPO depending on structure).
• Named control owners for training, audit, complaint handling, security coordination, and change control.
• Decision forum for new affiliates, new systems, and new transfer routes.

Artifact: RACI + operating procedure with triggers and approvals (new affiliate onboarding, M&A, new platform, material purpose change). This matches the recommended control to define a requirement-specific operating procedure. (Regulation (EU) 2016/679, Article 47)

3) Draft the BCR package as “policy + enforceability + procedures”

Do not stop at policy text. Your package needs three layers:

1. BCR legal text (the binding commitments and rights).
2. Intra-group enforceability instruments (how each entity becomes bound; how conflicts are handled; consequences for non-compliance).
3. Operational procedures (training, audits, incident handling interface, complaint intake, remediation, cooperation with regulators).

A useful internal drafting test: for every commitment in the BCR, identify the operational control and the evidence it produces.

Artifact: BCR control mapping (BCR clause → process/control → system of record → evidence owner).

4) Build the “approval-ready evidence pack”

Even before you approach the supervisory authority, assemble evidence that you can run the rules:

• Group entity list and structure (which entities are covered).
• Training plan and proof of completion workflow (by population).
• Audit plan and reporting line for findings/remediation.
• Complaint handling workflow and SLAs (your own internal targets are fine; document them as commitments you can meet).
• Change management process for BCR updates and affiliate onboarding.
• Security and privacy incident coordination process across affiliates.

Artifact: Auditable evidence packet, stored on a recurring cadence (decision record, control outputs, exceptions, remediation). This matches the recommended evidence-retention control. (Regulation (EU) 2016/679, Article 47)

5) Prepare and submit to the competent supervisory authority

Your submission should be organized so a reviewer can quickly validate:

• Scope clarity (transfers, entities, roles).
• Binding nature across the group.
• Data subject rights and redress mechanisms.
• Governance, audits, and enforceability.

Track the submission like a regulated deliverable:

• Owner, status, Q&A log, revisions, and approvals.
• Version control and sign-off trail.

Artifact: “BCR approval dossier” + submission tracker.

6) Operationalize: make BCRs the default control path for intra-group transfers

Once approved, your operational requirement becomes ongoing:

• Gate new intra-group transfers through an intake workflow that checks “BCR scope match.”
• Ensure procurement/IT onboarding processes for new systems flag cross-border intra-group data access.
• Maintain an affiliate onboarding checklist that binds new entities and trains staff before data access is granted.

Where Daydream fits naturally Daydream can act as the system of record for your Article 47 role-and-scope register, the operating procedure (with owners and triggers), and the evidence packets that auditors and regulators ask for. That reduces “spreadsheet drift” when affiliates and transfer routes change. (Regulation (EU) 2016/679, Article 47)

Required evidence and artifacts to retain (exam-ready list)

Keep these in one place, with versioning and approvals:

• Article 47 role-and-scope register (entities, roles, systems, data categories, transfer routes). (Regulation (EU) 2016/679, Article 47)
• Approved BCR text (final, approved version) and version history. (Regulation (EU) 2016/679, Article 47)
• Proof of binding effect across entities (signatures/adhesion records or equivalent internal legal mechanism).
• Operating procedures: training, audits, complaints, cooperation/escalation, change control. (Regulation (EU) 2016/679, Article 47)
• Audit reports, findings, remediation tickets, and closure evidence.
• Training records and role-based training content.
• Exceptions register (approved deviations, compensating controls, sunset dates).
• Management review minutes showing oversight of BCR performance (issues, trends, remediation).

Common exam/audit questions and hangups (what reviewers probe)

• “Show me all intra-group transfers that rely on BCRs. How do you know the list is complete?”
  Hangup: no authoritative inventory; ownership split across IT, HR, and business units. (Regulation (EU) 2016/679, Article 47)

• “Which entities are bound today? Show evidence for the newest affiliate.”
  Hangup: M&A or re-org adds entities faster than governance updates. (Regulation (EU) 2016/679)

• “How do employees learn the rules, and what happens when they don’t follow them?”
  Hangup: training exists, but enforcement and remediation are ad hoc. (Regulation (EU) 2016/679)

• “How do you handle data subject complaints that involve an importer outside the EEA?”
  Hangup: complaint workflow is local-market only; no cross-affiliate handoff. (Regulation (EU) 2016/679)

Frequent implementation mistakes (and how to avoid them)

1. Writing BCRs before scoping transfers.
   Fix: build the role-and-scope register first, then draft to match real flows. (Regulation (EU) 2016/679, Article 47)

2. Treating BCRs as a one-time legal deliverable.
   Fix: assign control owners, set change triggers, and retain recurring evidence packets. (Regulation (EU) 2016/679, Article 47)

3. No operational gate for new transfer routes.
   Fix: integrate a privacy intake check into system access provisioning and platform onboarding.

4. Unclear controller/processor roles across affiliates.
   Fix: document role determinations per processing activity; update when purpose or means changes. (Regulation (EU) 2016/679)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so this section is limited to practical risk. The risk is structural: if you rely on BCRs without a clear scope, binding mechanism, and operating evidence, you can lose the defensibility of your transfer safeguard during regulator review or customer diligence. Treat BCRs as a live compliance program with auditable outputs. (Regulation (EU) 2016/679, Article 47)

Practical 30/60/90-day execution plan

First 30 days (foundation)

• Stand up program governance: sponsor, DPO/Privacy lead, Legal, Security, IT, key regional stakeholders. (Regulation (EU) 2016/679)
• Build the Article 47 role-and-scope register for known intra-group transfers. (Regulation (EU) 2016/679, Article 47)
• Decide BCR type(s) needed (controller, processor, or both) and define the minimum viable evidence pack structure. (Regulation (EU) 2016/679, Article 47)

Days 31–60 (draft + control design)

• Draft BCR text and parallel operational procedures (training, audit, complaints, change control). (Regulation (EU) 2016/679, Article 47)
• Create the BCR control mapping (clause → control → evidence).
• Pilot the intake workflow for new intra-group transfers and affiliate onboarding.

Days 61–90 (approval readiness)

• Finalize the approval dossier structure and internal sign-offs; ensure enforceability mechanics are documented and executed. (Regulation (EU) 2016/679, Article 47)
• Run a tabletop audit: pick sample transfers and prove end-to-end evidence (inventory entry, training, incident/complaint path, audit trail).
• Prepare submission tracking and a regulator Q&A log template to manage the approval process. (Regulation (EU) 2016/679, Article 47)

Frequently Asked Questions

Do we need BCRs if we already use standard contractual clauses for transfers?

BCRs are designed for intra-group transfers and require supervisory authority approval, while contractual approaches are typically used for third-party transfers. Use BCRs when you need a scalable, group-wide transfer mechanism for repeated internal flows. (Regulation (EU) 2016/679, Article 47)

Can BCRs cover both controller and processor activities in the same group?

Many groups perform both roles across different processing activities, so you should scope where you act as controller versus processor and plan the appropriate BCR coverage. Start with a role-and-scope register so the drafting matches reality. (Regulation (EU) 2016/679, Article 47)

What evidence do auditors usually ask for first?

Expect requests for an inventory of in-scope transfers and entities, proof the rules are binding, and proof the program operates (training records, audit results, remediation). If you cannot produce these quickly, the review tends to expand. (Regulation (EU) 2016/679, Article 47)

How do we keep BCRs current when the org changes through M&A?

Treat new affiliates as a trigger event: bind the entity, train relevant staff, update the transfer inventory, and run an onboarding control check before granting system access to EU personal data. Track all of this in an evidence packet. (Regulation (EU) 2016/679)

Can we rely on BCRs for transfers to external processors or sub-processors?

BCRs are an internal group mechanism. External third parties typically require their own transfer and contracting approach; keep that path separate so you do not over-scope BCR reliance. (Regulation (EU) 2016/679, Article 47)

What’s the simplest way to make this program auditable?

Centralize three records: your role-and-scope register, your operating procedure with named owners and triggers, and your recurring evidence packets (outputs, exceptions, remediation). A system like Daydream helps keep those artifacts consistent as transfers and affiliates change. (Regulation (EU) 2016/679, Article 47)