Your cloud or AI supplier has processor BCR: what a municipality checks

Imagine you are the privacy officer of a municipality. The customer service team wants an AI service that transcribes and summarises calls with residents. The supplier is an international group with an establishment in Ireland. Administration and support are partly provided from India and the United States. When you ask how the transfer of personal data works, the supplier answers: "We have approved processor BCR." Is that enough?

On 10 November 2026 the European Data Protection Board (EDPB) adopted the final version of its recommendations on binding corporate rules for processors, the BCR-P. They are written for groups that apply for or already hold BCR-P, but they also say a lot about what you can ask for as a customer.

What BCR-P are

If you transfer personal data to a country outside the EEA for which the European Commission has not adopted an adequacy decision, appropriate safeguards are required (Article 46 GDPR). Binding corporate rules are one of them (Article 46(2)(b)). They are rules that apply within a group and that the competent supervisory authority approves (Article 47(1) GDPR), after an opinion of the EDPB. The version for processors is called BCR-P; the version for controllers is called BCR-C.

Recommendations 1/2026 contain the standard application form and the required content. The EDPB adopted a draft on 15 January 2026 and invited comments between 19 January and 2 March 2026. It received 11. In substance the recommendations build on the former documents of the Article 29 Working Party.

Point 1: BCR-P only cover transfers within the group

BCR-P apply to data that a group entity in the EEA processes as a processor for a customer and then transfers to group entities outside the EEA acting as sub-processors. A transfer from an external controller, such as your municipality, directly to a group entity outside the EEA is not covered. According to the EDPB, that requires another Article 46 tool, for example standard contractual clauses. Binding corporate rules by definition concern transfers within the group (Article 4(20) GDPR). An external sub-processor outside the EEA is therefore not itself bound by the BCR-P. The BCR-P do require the group to conclude a written contract with such a party providing in substance the same obligations, and the liable entity in the EEA also answers for that party (see point 7). You can ask for a copy of that contract.

For your municipality: conclude the contract with the entity in the EEA and ask which data go where. If your municipality itself will send data directly to an entity outside the EEA, the BCR-P do not cover that. If the group engages external parties outside the EEA, ask which ones and request the contract with each of them.

Point 2: the processing agreement is still required

Alongside the BCR-P you must conclude a processing agreement with one or more group entities in the EEA that meets all the requirements of Article 28(3) GDPR. It should refer to the BCR-P, and the BCR-P must be enforceable by you against the group entities. The agreement may not lower the protection of the BCR-P.

Within the group, a separate sub-processing agreement with each entity is not needed: that is exactly what BCR-P are for. Your authorisation for sub-processors is still required, also for group entities on the BCR-P list (Article 28(2) GDPR). And your instructions must reach every sub-processor.

For your municipality: the list of group entities is part of the published BCR-P. Compare it with the list of sub-processors in your processing agreement.

Point 3: approved does not mean it works in practice

The EDPB is explicit about this. An approval confirms that the commitments in the BCR-P provide adequate safeguards. It does not confirm that the processing in practice complies with the BCR-P and the GDPR. That remains the responsibility of the group and of the customer. As controller you remain ultimately responsible, even if the transfer is made by your processor rather than by you (Article 24(1) GDPR).

Processor and customer must assess for each transfer whether supplementary measures are needed because the law or practice of the destination country may undermine the protection. That assessment stems from the Schrems II judgment of the Court of Justice (C-311/18); for the details the EDPB refers to its Recommendations 01/2020. The group as processor implements the measures, the customer verifies them. Supervisory authorities do not assess those measures as part of the approval.

Point 4: ask for the transfer impact assessment

According to the recommendations, the BCR-P must oblige the group to document its assessment of the law and practice in the destination country, with the supplementary measures chosen, and to make that documentation available to you on request. Check that this is actually in your supplier's BCR-P: existing BCR-P only have to be brought in line at the 2028 update. In practice this assessment is called a transfer impact assessment (TIA). The draft said the group had to carry out the TIA "in agreement with the controller". That was removed. The reason the EDPB gives in its consultation report: you can obtain the group's TIA at any time and use it as the basis for your own assessment. So you no longer have a say in drawing it up, but you can still request it. The EDPB is also working on a TIA template.

For your municipality: ask for the TIA before the contract award and include in the contract that you receive an updated version when the situation in a country changes. The group must keep monitoring developments in the destination countries and inform you when it identifies such developments. How you assess a transfer yourself is set out in EDPB Recommendations 01/2020.

Point 5: you receive audit results on request, and you may audit yourself

The group must regularly check its compliance with the BCR-P through internal or external audits, and also where there are indications of non-compliance. How often depends on the risk to the data subjects. In the draft the results always had to go to the customer. In the final version the customer receives them on request, as under the standard contractual clauses. In addition, every group entity processing your data must, at your request, accept an audit of the processing for your municipality, at reasonable intervals or where there are indications of non-compliance. That may also be an independent auditor you mandate.

For your municipality: unlike under the draft, you only receive the audit results if you ask for them. So actively request the latest results during procurement.

Point 6: you are told when a government outside Europe asks for your data

If a group entity outside the EEA receives a legally binding request from a public authority to disclose data, it promptly notifies the entity that transferred the data and you, and where possible the data subject. The same applies if the entity becomes aware of direct access by a public authority to the data. If it is prohibited from notifying, it must use its best efforts to obtain a waiver. In addition, you receive at regular intervals, where feasible annually, as much relevant information as possible on such requests.

If the group can no longer comply with the BCR-P for a transfer, even with supplementary measures, or if you or the supervisory authority instruct it to, the transfer is suspended, as are similar transfers. If compliance is not restored within one month, the transfer ends. Data already transferred are then, at your choice, returned or destroyed in their entirety. If local law prohibits that, the entity continues to comply with the BCR-P and keeps the data only for as long as that law requires.

For your municipality: set out in the processing agreement who in your organisation receives such a notification, and what you then do with the service.

Point 7: liability lies with an entity in the EEA

At least one group entity in the EEA accepts responsibility for breaches by entities outside the EEA and by external sub-processors outside the EEA, and pays compensation. If you or a resident can demonstrate damage and establish facts showing that it has likely occurred because of a breach of the BCR-P, that entity must prove that the entity outside the EEA was not responsible or that there was no breach. Data subjects can enforce the main parts of the BCR-P themselves as third-party beneficiaries, such as their rights, security and the rules on government access requests; internal rules such as training and the audit programme are excluded. The BCR-P must be easy for data subjects to access.

And the United States?

For transfers to a US organisation certified under the EU-US Data Privacy Framework, the Commission's adequacy decision applies (Decision (EU) 2023/1795). Where a transfer falls under it, no Article 46 safeguards are needed, and the transfer falls outside the approval of the BCR-P. If a US group entity is not certified, the BCR-P simply apply to transfers to it. The General Court dismissed an action against that decision on 3 September 2025 (Latombe, T-553/23, see our article on Latombe). An appeal against that judgment is pending before the Court of Justice (C-703/25 P).

The recommendations offer a fallback here. A group may provide that the BCR-P will apply to transfers to entities in a country with an adequacy decision if that decision is invalidated. The group must then flag those entities in the list.

For your municipality: ask for each US entity whether it is certified. If so, ask whether the BCR-P serve as a fallback for it and whether the entity is flagged that way in the list.

When the group updates its BCR-P

The recommendations become effective on publication of the final version. The EDPB expects new and ongoing applications to meet them now. An exception applies to applications that already had a consolidated draft and receive an EDPB opinion by 30 June 2027: they bring their BCR-P in line at the 2028 annual update. Groups that already hold approved BCR-P also do so at the 2028 update. That generally does not require a new approval.

This means your supplier's BCR-P may still be based on the old documents until their 2028 annual update. So ask which version applies.

What the AI Act adds, and what it does not

The AI Act contains no rules on transfers of personal data to countries outside the EEA; Chapter V of the GDPR continues to govern those. The AI Act is without prejudice to the GDPR, with Article 4a and Article 59 as the only reservation (Article 2(7) AI Act). That an AI service falls under the AI Act, or even meets the AI Act duties well, therefore says nothing about the transfer.

There is a link between the two, though. If you are the deployer of a high-risk AI system, you use, where applicable, the information the provider must give in the instructions for use (Article 13) for the DPIA the GDPR already requires of you (Article 26(9)). For Annex III systems that applies from 2 December 2027. A service that transcribes and summarises calls is usually not a high-risk system. But if an AI system is intended to evaluate whether residents are eligible for essential public assistance benefits or services, or to grant, reduce, revoke or reclaim them, it is in principle high-risk (Annex III, point 5(a)), unless the exception in Article 6(3) applies. Whether you must carry out a DPIA follows from the GDPR itself (Article 35); see when a DPIA is required.

For a bank and a school

A bank that buys an AI service for customer contact or fraud analysis from a group with BCR-P has the same questions: which entities, which TIA, which audit results and who reports a request from a foreign government. If an AI system evaluates the creditworthiness of individual customers, it is a high-risk system (Annex III, point 5(b)). A system used only to detect financial fraud is expressly excluded. In both cases the transfer remains a separate GDPR question.

A school or university that buys a learning environment with AI feedback processes data of pupils or students at a supplier that may provide support from other continents. Here too: processing agreement, list of entities and TIA.

What you do now

1. For every cloud or AI supplier that relies on BCR-P, ask for the published BCR-P and the list of group entities.
2. Check that your processing agreement refers to the BCR-P and makes them enforceable by you.
3. Ask for the TIA, with the supplementary measures, and verify it.
4. Ask for the latest audit results and lay down your own audit right.
5. Agree who in your organisation is notified of a request from a government outside Europe, and what you then do.
6. Ask which external sub-processors outside the EEA there are, and request a copy of the contract with each of them.
7. Ask whether the BCR-P already meet the 2026 recommendations, or only will after the 2028 update.

To check which GDPR and AI Act duties apply to a system of your own, use the free case check. New EDPB guidelines are listed under GDPR guidelines.

What remains open

• The TIA template. The EDPB is working on a template for the transfer impact assessment. There is no date yet.
• Latombe on appeal. If the Court annuls the adequacy decision for the United States, the fallback arrangements in BCR-P become important.
• Transition until 2028. Until the 2028 update, approved BCR-P may still be based on the old documents. What the recommendations mean in the meantime for a customer of such a group, they do not say.