Binding Corporate Rules (BCRs) Guide: Approval, Content and Intra-Group Transfers

Multinational groups move personal data between their own entities all day, and signing Standard Contractual Clauses between every pair of affiliates quickly becomes unmanageable. Binding Corporate Rules (BCRs) are the GDPR's answer: a single, regulator-approved set of data protection rules that binds every group member and lets personal data flow between them, inside and outside the EEA, under Article 46(2)(b) and Article 47 GDPR. Approval is slow and demanding, and an approved BCR is a living programme with annual reporting, audits and local-law assessments rather than a one-off document. This guide covers who BCRs suit, what Article 47 and the EDPB require, how the approval and UK routes work, where controller and processor BCRs stand in 2026, and what BCRs mean for the service accounts, integrations and AI agents that actually move group data. It is written for DPOs, privacy counsel, security architects and group compliance teams.

Key takeaways

• BCRs are a group-wide transfer tool. They cover transfers within a group of undertakings or enterprises engaged in a joint economic activity, and must be legally binding on, and enforced by, every member concerned (Art. 47(1) GDPR).
• The EDPB sets the bar. Recommendations 1/2022 on controller BCRs (final version of 20 June 2023) replaced WP256 rev.01 and WP264, and draft Recommendations 1/2026 on processor BCRs were published for consultation in January 2026.
• Approval runs through a lead authority and the EDPB. One application goes to a BCR Lead supervisory authority, and its draft approval decision is subject to an EDPB opinion before it is adopted.
• Schrems II applies to BCRs too. Members must assess third-country law before transferring, add supplementary measures where needed, handle government access requests under set rules and suspend transfers they cannot protect.
• The UK needs its own BCRs. The ICO has approved UK BCRs under UK GDPR since 1 January 2021, and its guidance is under review following the Data (Use and Access) Act 2025.

Scope: who and what is covered

Article 47 GDPR lets a competent supervisory authority approve BCRs through the consistency mechanism in Article 63, provided they are legally binding on every member concerned, expressly confer enforceable rights on data subjects and contain the elements listed in Article 47(2). Once approved, BCRs are an "appropriate safeguard" under Article 46(2)(b), so group members can transfer personal data covered by the rules to members in third countries without separate contracts for each flow.

Controller and processor BCRs

• Group membership: only entities listed as BCR members are covered. The list must be kept current and available to data subjects. A new acquisition is outside the BCR until it signs the intra-group agreement and is added.
• Material scope: the BCR must describe the transfers it covers: data categories, processing types and purposes, data subjects and the third countries involved (Art. 47(2)(b)). Data outside that description needs another tool.
• Not covered: transfers to entities outside the group, such as external vendors, still need SCCs, an adequacy decision or a derogation. The draft BCR-P recommendations also state that a BCR-P is not suited to a direct transfer from an external controller to a group processor abroad, where SCCs are likely to be needed.

The EDPB keeps a register of approved BCRs; when checked in October 2026 it listed 253, with the EDPB opinion and the authority's decision linked for approvals after 25 May 2018.

Key obligations

Article 47(2) lists fourteen elements every BCR must specify. The EDPB recommendations turn these into a referential with numbered sections, which is what reviewers check line by line.

Obligations that matter most in practice

• Third-party beneficiary rights: data subjects can enforce the BCR, complain to a supervisory authority and go to court for redress and compensation (section 1.3). This is what makes the rules more than an internal policy.
• Liability and assets: an EEA-based member accepts liability for breaches by members outside the EEA, must have sufficient assets to pay, and carries the burden of proving that the non-EEA member was not responsible.
• Local laws and practices (5.4.1): before relying on the BCR for a transfer, members assess whether the destination's law and practice prevent them meeting their commitments, document it, add supplementary measures following EDPB Recommendations 01/2020, and suspend the transfer if protection cannot be ensured.
• Government access requests (5.4.2): the importer notifies the exporter and the data subject where possible, seeks a waiver if prohibited from notifying, reviews and challenges unlawful requests, documents its assessment and discloses the minimum data required.
• Breach notification: security incidents are reported within the group and to supervisory authorities within 72 hours where feasible, in line with Article 33.
• Accountability: records of processing, DPIAs and prior consultation apply across members (5.3). See the DPIA Guide.

Timeline and current status

• Controller BCRs: stable. Recommendations 1/2022 are final, and EDPB Article 64 opinions on draft BCR decisions continue, including opinions dated 13 October 2026.
• Processor BCRs: in transition. The draft 1/2026 merges the referential and application form, adds transfer impact assessment and public authority access duties, adopts exporter and importer wording aligned with SCC Module 3, and requires the liable member to confirm sufficient assets each year. Commentators expect existing BCR-P to need amendment. At the time of writing we had not confirmed a final version; check the EDPB documents page before starting a BCR-P project.
• UK BCRs: active, with guidance under review after the Data (Use and Access) Act 2025. Existing EU BCRs did not need a new UK application form, but holders must give the ICO a UK version of their BCRs.

Enforcement and penalties

A transfer made outside the approved scope of a BCR, or after the group stopped meeting its commitments, lacks a valid Chapter V basis. Under Article 83(5)(c) GDPR, infringements of the transfer rules carry fines up to EUR 20 million or 4% of total worldwide annual turnover, whichever is higher. Supervisory authorities can also order a transfer to be suspended under Article 58(2)(j). The Irish Data Protection Commission's EUR 1.2 billion decision against Meta, adopted on 12 May 2023, concerned SCCs rather than BCRs, but it shows the order of magnitude and the suspension orders (five months to stop transfers, six to stop unlawful storage) that follow when local-law risk is not addressed.

• Data subjects: can enforce third-party beneficiary rights in court against the liable EEA member.
• Supervisory authorities: audit members, require corrective action and can reassess the BCR if annual updates show changes that reduce protection.
• Internal sanctions: the BCR must make non-compliance a disciplinary matter for employees, which auditors will test.

What it means for AI agents and non-human identities

In a modern group, most intra-group transfers are made by machines: replication between regional data centres, shared HR and CRM platforms, global support tooling, data pipelines and AI agents that query group data stores. A BCR describes those transfers on paper; identity and access controls are how the group proves they happen only as described.

• Member scope is enforced through identity: a service account in a non-member entity, or a shared credential used by a joint venture outside the member list, can move data out of BCR scope without anyone noticing. Tie each workload identity to a legal entity and check it against the member list. See the NHI Ownership Guide.
• Purpose limitation becomes scope limitation: the BCR's transfer descriptions should map to the permissions of the integrations and agents that carry them. An analytics agent with read access to global HR data exceeds a BCR that describes HR transfers for payroll only. See the AI Agent Authorisation Guide.
• Suspension must be technically possible: section 5.4.1 requires suspending transfers that cannot be protected. In practice that means being able to disable or re-scope the credentials and pipelines that send data to a given country within days.
• Government access requests hit platforms first: requests may arrive at a cloud or SaaS provider rather than the group member. Know which provider holds which keys. See the Encryption Guide.
• External AI services are outside the BCR: sending group data to an external model provider is a transfer to a third party, which needs SCCs or another tool, even when the agent is run by a BCR member. See the Third-Party AI Risk Guide.

Compliance steps

1. Decide whether BCRs fit: compare against intra-group SCCs (see the table below). Start only with board-level sponsorship and a realistic timeline: approval involves a lead authority, co-review and an EDPB opinion.
2. Map intra-group flows: list every data category, purpose and destination country moved between members, and the systems and identities that carry them. See the Data Mapping and ROPA Guide.
3. Choose the BCR Lead: propose the supervisory authority of the group's EEA headquarters or main establishment, with reasons in Part 1 of the application form. Authorities are not obliged to accept the proposal.
4. Draft against the referential: complete the application form (Part 1, then Part 2 when the lead is confirmed), the BCR policy and the intra-group agreement, mapping each Recommendations 1/2022 section to a clause and a supporting procedure.
5. Build the operating model before approval: privacy network, training, complaint handling, audit programme, local law assessments and the government access procedure must work on day one.
6. Pilot and test: run the local law assessment and a mock government access request for one high-risk country, and audit one member against the BCR before submission.
7. Submit, respond, adopt: answer reviewer comments, then sign the intra-group agreement across members once the authority adopts its decision following the EDPB opinion.
8. Run the annual cycle: report changes and the member list to the BCR Lead each year, notify in advance changes that could reduce protection, renew the asset confirmation and publish the current BCR. Roll back a problematic change by keeping the previously approved text in force until the authority confirms the change.
9. Add the UK: where UK data is in scope, prepare a UK BCR package for the ICO: application form, intra-group agreement, BCR policy, supporting policies and the UK BCR Referential Table v2.0. See the UK GDPR and Data Protection Act 2018 Guide.

BCRs or intra-group SCCs

Many groups run SCCs while their BCR application is pending, then switch. Smaller groups rarely recover the cost of BCRs. For external transfers see the Standard Contractual Clauses (SCCs) Guide, and for US recipients the EU-US Data Privacy Framework Guide.

Detection and measurement

• Member coverage: share of legal entities that process EEA personal data and have signed the intra-group agreement.
• Identity-to-entity linkage: share of service accounts and integrations moving personal data between countries that are mapped to a BCR member and a described transfer.
• Local law assessments: share of destination countries with a current, documented assessment.
• Complaint handling: share of data subject complaints answered within one month.
• Audit closure: median days to close BCR audit findings.
• Annual update on time: whether the update reached the BCR Lead by the agreed date.

Framework mapping

Common failure patterns

• Stale member list: acquisitions and new subsidiaries start receiving data before they sign the intra-group agreement.
• Scope creep: new purposes, such as AI training on group HR data, start without checking that the BCR describes them.
• Paper local law assessments: assessments written once for the application and never refreshed, so suspension decisions cannot be supported.
• BCR used for external flows: data sent to vendors or external AI services on the assumption the BCR covers it.
• Missed annual update: changes not reported to the BCR Lead, or reductions in protection made without advance notice.
• UK gap: groups relying on EU BCRs for UK transfers without giving the ICO a UK version.

Practitioner checklist

• Keep the BCR member list and the intra-group agreement signatures in step with corporate changes.
• Map each described transfer to the systems, service accounts and agents that carry it.
• Maintain a dated local law assessment for every destination country and a tested suspension procedure.
• Run the government access request procedure as a tabletop at least yearly.
• Answer data subject complaints within one month and log extensions.
• Deliver the annual update to the BCR Lead, including the asset confirmation and member list.
• Check whether processor BCRs need amending once the EDPB finalises Recommendations 1/2026.
• Hold a UK version of the BCR with the ICO where UK data is in scope.

Standards and references

• EUR-Lex: Regulation (EU) 2016/679 (GDPR), Articles 46, 47 and 83
• EDPB: Recommendations 1/2022 on the application for approval and on the elements and principles to be found in Controller Binding Corporate Rules
• EDPB: Approved Binding Corporate Rules
• ICO: Application for approval of UK binding corporate rules for data controllers
• ICO: Binding corporate rules, previous updates
• Information and Data Protection Commissioner (Malta): EDPB adopts recommendations on the application for Processor BCR
• Bird and Bird: Latest updates to EU Processor Binding Corporate Rules
• Data Protection Commission: Conclusion of inquiry into Meta Ireland

Related NHI Mgmt Group resources: International Data Transfers Map · GDPR Compliance Guide for Security Teams · Standard Contractual Clauses (SCCs) Guide · Privacy Programme Guide for Security Teams. This guide summarises GDPR Article 47 binding corporate rules, the EDPB recommendations and UK BCRs as of October 2026 and is not legal advice.