What Article 47 binding corporate rules require from a group
A multinational group that moves employee or customer data between its entities needs a transfer basis for each flow that leaves the EEA. Binding corporate rules are approved by the competent supervisory authority through the consistency mechanism, must be legally binding on every group member, must expressly confer enforceable rights on data subjects, and must meet the 14 elements listed in Article 47(2). The rules are a group-wide policy set, not a contract with each entity, so the group has to show that every affiliate, including those that never see the data directly, is bound and accountable. The risk being addressed is that personal data leaves the EEA inside a corporate group with no enforceable protection that follows it to the receiving entity.
Writing the rules is the easier part. Approval is the hard part, and it cannot be self-declared. The lead supervisory authority reviews the draft through the consistency mechanism, and other concerned authorities can comment before approval. Expect the review to test whether the group structure, the transfers covered, the data security measures, the complaint procedure and the liability of an EU-based member are described concretely enough to be enforced. Article 47(2)(m) also requires a mechanism to report to the authority any third-country legal requirement likely to have a substantial adverse effect on the guarantees, so the group needs a working process for that reporting, not only a clause.
Before committing budget, ask the group's privacy team to confirm three things: which entities will be bound and how each one accepts the rules in local law, whether the rules cover controller or processor transfers (the EDPB published separate recommendations for each, and the processor version was open for consultation from 19 January to 2 March 2026), and which supervisory authority would act as lead. The EDPB's controller recommendations, version 2.0 finalized on 20 June 2023, set out the expected structure and are the natural next read. Approval timelines depend on the authority and the quality of the first submission, so confirm them with the authority rather than assuming them.
Which entities, transfers and teams fall inside binding corporate rules
Binding corporate rules only cover what the group decides to put inside them, and the approving authority will test that boundary. Each scoping choice below changes which members must be bound, which content the rules must carry and which evidence an assessor will ask to see.
Which group members are bound
Article 47(1) requires the rules to be legally binding on every group member, so each entity covered must be bound by an instrument it can actually enforce. Map the legal entities that import or export personal data, not only the parent company. For each one, confirm how the binding effect is created under local law and who signs for it. A subsidiary left out of the intra-group commitment becomes a gap in the transfer chain that the approving authority will find.
Which transfers the rules cover
The rules must name the transfers they cover, including the categories of data, purposes and countries receiving the data. A broad statement that all group data is covered can be harder to defend than a precise transfer inventory. Confirm which flows are controller-to-controller, which are controller-to-processor, and which pass through a non-EEA hub before reaching the destination member. Each flow you leave out needs another Article 46 or Article 49 basis.
Controller versus processor BCRs
Controller BCRs cover data the group decides how to use, while processor BCRs cover data a group member handles on behalf of external customers. The EDPB issued separate recommendations for each, and the processor version is still in consultation as of October 2026. A group that acts as both needs to decide which instrument fits each flow, because the duties to customers, sub-processor controls and audit commitments differ.
HR and employee data flows
Employee records often move between group members for payroll, performance and global directories, so HR data is usually the first flow scoped in. Name the HR systems, the categories of employee data and the local works-council or employee-representation steps that apply in each country. Confirm whether health or other special category data is included, since that raises the protection the rules and evidence must show.
Customer data and group service flows
When a group member hosts a platform or support desk used by customers of other members, its data flows are transfers the rules must describe. Confirm which member is controller for each customer dataset and whether processor commitments to customers are needed. Shared ticketing, logging and analytics platforms are common places where customer data reaches group members that were not in the original scope.
Outsourced IT and third parties
Third parties such as outsourced IT, managed hosting and support vendors sit outside the group, so BCRs cannot bind them. Where a group member sends data to such a vendor, the flow needs its own contract and transfer basis, and the rules must reflect the sub-processor controls in place. Map each vendor that touches covered data, its location and its access, and confirm which of those relationships the group's rules will rely on.
Controller BCRs and processor BCRs compared
Controller BCRs cover personal data that a group member collects and uses for its own purposes, such as employee records, customer accounts or marketing data, and then moves to other group members outside the EEA. The group decides why and how the data is processed, so the rules must show how each entity meets the principles, lawful basis and data subject rights. The EDPB's Recommendations 1/2022 on controller BCRs reached their final version 2.0 on 20 June 2023 (published 30 June 2023) and set out how the application and approval file should be built around the Article 47(2) elements.
- Application file: The group prepares a set of documents that sets out its structure, the transfers covered and the binding rules, and submits them to a lead supervisory authority.
- Legally binding commitments: Every group member must be bound, and the rules must give data subjects enforceable third-party rights.
- Audit and training content: The rules describe the data protection audits and the training given to staff with permanent or regular access to personal data.
- Third-country law reporting: The rules include a mechanism to report legal requirements in a third country that could substantially undermine the guarantees.
- Liability: An EU-based member accepts liability for breaches by group members outside the EU.
Confirm the version of the EDPB recommendations and the approval status of your lead authority before drafting, since the application process depends on both.
Processor BCRs cover personal data that a group member handles on behalf of external controllers, typically when the group provides hosting, support or managed services to clients. The group does not decide the purposes, so the rules must bind the group to the client's instructions, flow down obligations to sub-processors and let clients enforce them. The EDPB published draft Recommendations 1/2026 on processor binding corporate rules for public consultation from 19 January to 2 March 2026, and the final text was not available when this page was written.
- Client instructions: The rules commit each member to process data only on documented instructions from the controller.
- Sub-processor flow-down: Group members and external sub-processors must be bound by terms no less protective than the group's rules.
- Client audit rights: The rules explain how controllers can audit compliance, including through the group's own audits.
- Dual structure: A processor BCR often sits alongside a separate controller arrangement for the group's own employee and commercial data.
- Enforcement rights: Controllers need an enforceable route against the group, not only against the processor entity.
Check the processor version against the final EDPB text when it is issued, and confirm with your lead supervisory authority which version it will apply in the approval process.
The choice between the two types follows from the group's role for each data flow, not from the group's size or preference. A single group often needs both, because it acts as controller for its own HR and sales data and as processor for customer data it hosts. Mapping each flow to a role is the first step, and it determines which EDPB recommendations and approval file apply.
- Map each flow: Record whether each group member decides purposes or only processes on instructions.
- Separate the scopes: Keep controller and processor flows in separate BCR documents or clearly separated sections.
- Plan for dual approval: Confirm with the lead authority whether one or two applications are expected.
- Watch sub-processors: Processor flows that involve external sub-processors need contractual flow-down in addition to the rules.
- Budget for review: Ask advisers and the authority how long each approval track is expected to take, since no fixed timeline is set in the supplied facts.
Ask your lawyers and data protection officer to confirm the role of each flow in writing before choosing the type of rules.
How a supervisory authority and assessor test binding corporate rules
This table compares what the approving supervisory authority tests, what evidence it expects, and where applications commonly stall for each part of the Article 47 BCR requirements. Read it as a checklist for preparing evidence, remembering that an independent assessor can pre-check readiness but the competent authority alone decides approval.
| Requirement | What the reviewer tests | Evidence expected | Where applications usually stall |
|---|---|---|---|
| Legal binding nature across group members | Whether every group entity, including those with no direct data flows, is legally bound by the rules | Intra-group agreements or unilateral undertakings, board resolutions, signed accession records for each entity | Entities added after approval with no accession mechanism, or subsidiaries whose local law does not recognize the binding effect |
| Enforceable rights for data subjects | Whether the rules expressly confer third-party beneficiary rights that individuals can enforce | Clauses naming data subject rights, complaint routes and courts or authorities available to individuals | Rights described only as internal policy, or enforcement limited to the group rather than the individual |
| Group structure and transfers covered (Article 47(2)(a) and (b)) | Whether the group, its contact details and the categories of transfers and processing are described precisely | Entity list with roles, data flow maps, purposes, data categories and data subject categories | Vague descriptions of transfers, or flow maps that omit processors or onward transfers |
| Application of principles and data security (Article 47(2)(d)) | Whether the general principles and security measures are applied across the group and tied to the Article 32 standard | Security standards, data protection policies, minimum control baselines for each member | Principles restated without showing how each member applies them in practice |
| Liability and EU-based member (Article 47(2)(f)) | Whether an EU-based entity accepts liability for breaches by non-EU members and can show it can pay | Liability clause, assets or insurance arrangements, and the designated EU entity's role | Liability acceptance that is conditional or lacks evidence the EU entity can meet it |
| Complaint procedures (Article 47(2)(i)) | Whether individuals can complain easily and whether handling is independent and timely | Complaint procedure, contact points, escalation paths and sample handling records | Complaints routed only to the business unit concerned, with no independent review |
| Audits and training (Article 47(2)(j) and (l)) | Whether audits cover all BCR commitments and whether staff with permanent or regular access receive training | Audit plan and scope, prior audit reports, training curriculum, completion records by role | Audits that do not cover every member, or training that is not tracked against staff with access |
| Third-country legal requirements (Article 47(2)(m)) | Whether a process reports legal demands likely to undermine the guarantees to the supervisory authority | Documented reporting mechanism, assessment criteria, named owner and examples of how requests would be escalated | A reporting duty stated without a trigger, owner or process to assess foreign laws |
| Approval route and decision | Whether the lead authority completes the consistency mechanism and the EDPB opinion is addressed | Application file, lead authority correspondence, EDPB opinion and the applicant's responses | Applications submitted before the content is stable, forcing repeated rounds of changes |
Steps to prepare binding corporate rules for approval
The sequence moves from knowing which transfers exist to a set of group-wide rules that are binding on every member, tested in practice, and approved by the lead supervisory authority. Each step produces a document or record that the next step depends on.
Map the group structure and intra-group transfers
Start by listing every legal entity in the group, its role as controller or processor, and each flow of personal data between members, including flows that run through shared platforms and support teams. The privacy team and business owners do this together, because the transfers covered must be described precisely in the rules. The step closes when you hold a transfer map that names the exporting and importing members, the categories of data, the purposes and the third countries involved, and each business owner has confirmed it.
Establish intra-group binding instruments
Article 47(1) requires the rules to be legally binding on every group member, so the group needs an instrument that each entity can be bound by, such as intra-group agreements, a resolution or a unilateral undertaking where local law allows it. Legal counsel in each relevant jurisdiction confirms which mechanism works and whether employees are bound as well. The output is a signed set of instruments, plus a register showing which entity signed what and when, that the supervisory authority can review.
Draft the rules against the 14 elements
Write the binding corporate rules so that each element required by Article 47(2) has a clear home in the text, from the group structure and the transfers covered to data security measures and the reporting mechanism for third-country legal requirements under point (m). A cross-reference table mapping each element to its section is useful for the reviewer. The step closes when legal and privacy leads have checked the draft against the element list and the recitals of the EDPB recommendations, and no element is left to be inferred.
Build data subject rights and complaint procedures
The rules must expressly confer enforceable rights on data subjects, so this step defines how an individual can exercise rights, lodge a complaint with the group, and bring a claim before a competent authority or court. It also fixes which EU-based member accepts liability and how the group handles requests that reach a non-EU member. The output is a written procedure, with named owners and an intake route, that is consistent with the rights described in the rules and that can be tested with a sample request.
Design audit and training programmes
Article 47(2) requires data protection audits and training for staff with permanent or regular access to personal data, so this step sets the audit plan, its scope across group members, who performs it, and how results reach the group board. The training programme defines the audience, content, frequency and records of completion. Internal audit or an external reviewer may perform the audits. The step closes with an approved audit calendar, a training curriculum, and a sample of completion records that shows the programme works in practice.
Submit the application and complete the consistency review
The group identifies its lead supervisory authority, submits the application with the draft rules, the instruments, and the supporting evidence, and answers questions from the authority during the review. Where the consistency mechanism applies, other concerned authorities comment and the EDPB may be involved in resolving disagreements. Confirm the current procedural steps with the lead authority and the EDPB guidance, since the timeline is set by the authority and not by the group. The step closes with a written approval decision that defines the rules as approved.
Operate the approved rules after authorization
Approval starts the operating phase, not the end of the project. The group runs its audits and training on schedule, keeps the transfer map current as entities and flows change, handles data subject complaints, and monitors third-country legal requirements that could affect the guarantees in the rules. Changes to the rules or the list of members are reported to the authority under the conditions in the approval. The output is a recurring evidence set (audit reports, training records, complaint logs and change notices) that the authority can request at any time.
Evidence that shows the rules are binding and working
Article 47 asks for more than an approved document. Supervisors and auditors look for proof that every group member is bound, that data subjects can enforce their rights, and that the rules run day to day. The cards below list the artifacts that show this and how to keep each one current between formal reviews.
Intra-group binding instruments
Each group member needs a legally effective instrument that makes the rules binding on it, such as an intra-group agreement or unilateral undertaking where local law allows. Keep a signed copy per entity, with signatory authority and the date it took effect. Check that the list matches the current group structure, because a new subsidiary that joins without signing creates a gap the approved rules do not cover. Confirm with local counsel how each jurisdiction recognizes the instrument.
Approved rules and version history
Keep the approved rules text, the supervisory authority's approval decision, and a dated history of every amendment. Changes to group structure or the transfers covered may require the authority to be informed, so record which version each entity relies on at any date. A current controlled copy that staff and the public-facing notices point to avoids conflicting versions in circulation.
Transfer register
A register lists each intra-group transfer: sender, recipient, data categories, purposes, countries and the BCR section that covers it. It is the basis for checking that the rules cover every flow and for answering a supervisor's questions. Assign an owner and tie new system integrations to a register update before go-live, so flows discovered later are not left uncovered.
Data protection audit plans and reports
Article 47(2) requires audits covering the rules. Keep an annual audit plan, the scope of each audit, findings, corrective actions with owners and closure dates, and the reports sent to the group's board. Audits should test real transfers, not only policy text. Independent auditors or internal audit may perform them, and the organization owns the conclusions and remediation.
Training records and completion logs
Staff with permanent or regular access to personal data covered by the rules must be trained. Keep the curriculum version, the audience list derived from access rights, completion dates and follow-up for those who miss deadlines. An LMS such as Moodle can record completion when learners view or pass an activity, so confirm which completion condition matches your evidence standard before relying on it.
Complaint logs and third-country request reports
Keep a log of complaints raised under the BCR complaint procedure, with dates, handling steps and outcomes. Separately, record every third-country legal requirement that may have a substantial adverse effect on the guarantees, and each report made to the supervisory authority under Article 47(2)(m). Review both logs at each scheduled review so that patterns, late responses and unreported requirements are visible.
What binding corporate rules cost in money and effort
This table breaks down the main cost and effort components of putting binding corporate rules in place, who is paid for each, and whether it is one-time or recurring. No fee or duration figures were supplied, so use the drivers and quote questions to compare written proposals. The main takeaway is that most of the cost sits in the controls and evidence the rules describe, not in the drafting alone.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it and what to ask for in a quote |
|---|---|---|---|
| Legal drafting of the BCR text and intra-group instrument | External counsel or in-house legal, sometimes with a privacy consultant | One-time, with later updates | Number of group members, countries, and processing activities covered. Ask for the drafting scope and how many revision rounds are included. |
| Intra-group instrument execution | Group legal team and each group entity's management | One-time, repeated when entities join | Count of legal entities and local corporate formalities. Ask who prepares the signature pack and who maintains the list of bound members. |
| Engineering time for logging and access evidence | Internal platform or security engineers, or an implementation partner | Build is one-time, operation is recurring | Number of systems holding covered data, and whether access logs are already centralized. Ask what evidence each system will produce and how it is retained. |
| Training delivery for staff with regular access | Internal privacy team, learning platform costs, or an outside trainer | Initial course is one-time, refresher training is recurring | Headcount with permanent or regular access to covered data and the number of languages needed. Ask how completion is recorded for audit. |
| Internal audit of group members | Internal audit or privacy function | Recurring | Number of group members and the audit cycle set in the rules. Ask how audit scope, sampling and findings tracking are defined. |
| External audit or independent assessment | External auditor or assessor, where the organization engages one | Recurring, usually tied to the audit cycle | Scope of systems and entities tested and the depth of testing. Ask for the assessment scope in writing and the evidence list before fieldwork starts. |
| Supervisory authority review time | Internal team time to answer questions and provide documents to the lead authority | One-time approval, with recurring updates to the rules | Number of rounds of questions and the quality of the initial file. Ask the reviewing authority or counsel to confirm expected review steps before committing to a timeline. |
| Updates for legal changes and new transfers | Internal legal and privacy team, sometimes counsel | Recurring | Frequency of new group entities, new processing, and third-country legal changes that must be reported. Ask how change control and reporting duties are handled. |
How the authority review and internal audit cycle runs
A lead supervisory authority reviews draft binding corporate rules and, once it is satisfied, submits them through the consistency mechanism so that the other competent authorities can comment before approval. The group should expect the lead authority to be the one in the EU country where its main establishment decides how personal data is processed, and it should confirm that choice early, because the identity of the lead authority determines who reviews the rules and how the file moves. The rules must meet the content requirements of Article 47(2) before the review can conclude, so the review often turns on documents rather than on the group's intent: the group structure, the transfers covered, the audit and training programme, the complaint process, and the mechanism for reporting third-country legal demands. Ask the lead authority for its current procedural expectations in writing, since the review file is usually where gaps in the rules are found.
The European Data Protection Board plays two roles. Its Recommendations 1/2022 on controller binding corporate rules, in version 2.0 of 20 June 2023 (published 30 June 2023), set out the application and approval checklist that most authorities use as a working standard, so the group's rules should be mapped against that checklist before submission. For processor rules, the EDPB's Recommendations 1/2026 were open for public consultation from 19 January to 2 March 2026, so teams should confirm whether a final version has been adopted before relying on any draft text. If authorities disagree during the consistency mechanism, the Board can resolve the dispute through a binding decision, which is why the group should track public consultations and adopted documents on the EDPB site throughout the review.
Approval does not end the work. The approved rules must be kept true in operation, which means an internal audit cycle that tests whether group members apply the principles, security measures, data subject rights handling and complaint procedures in the rules, and that the results reach the group's governance body. Audit scope should cover each group member that transfers personal data under the rules, and the audit plan should name owners for evidence such as access reviews, training completion records and records of changes to the group structure, since a new affiliate or a changed processing activity may require the rules to be updated. Teams should confirm with their lead authority how and when changes to the rules are reported, because an unreported change can undermine the approval itself. Evidence should be stored in a form that an auditor or supervisory authority can test without a long walkthrough.
Where binding corporate rules usually fall short
Most BCR applications stall on the same handful of weaknesses, and supervisory authorities test them against the binding and enforceable character of the rules in Article 47(1) and the content list in Article 47(2). The cards below cover the gaps that come up most often, each with the check to run before the application is filed.
Rules not binding on every member
Article 47(1) requires the rules to be legally binding on every group member, not only on the parent that signs the policy. Subsidiaries in some countries may need intra-group agreements, board resolutions or local adoption steps before they are bound. Check each group entity, including recent acquisitions and entities that process data only for other group members, and record how each one is bound.
No enforceable third-party rights
The rules must expressly give data subjects enforceable rights, so individuals can rely on them as third-party beneficiaries. A policy that only binds employees or states good intentions does not meet this. Confirm that the rights, complaint routes and liability terms are written so that a data subject can invoke them directly, and that the wording matches what the group actually promises.
Narrow audit scope
Article 47(2) expects the rules to set out data protection audits, and assessors look for audit plans that cover every group entity and every transfer covered by the BCRs. Audits limited to the privacy office or to one country leave gaps. Confirm who audits, how often, how findings reach the group board, and whether the audit reports can be provided to the supervisory authority on request.
Training misses staff with access
The rules must include training for staff who have permanent or regular access to personal data. Many programs reach only head office or only staff who completed a general course. Map which roles in each entity handle covered transfers, assign training to them specifically, and keep completion records that show coverage rather than a single annual sign-off.
No third-country legal reporting process
Article 47(2)(m) requires a mechanism to report to the supervisory authority any third-country legal requirement that is likely to have a substantial adverse effect on the guarantees in the rules. Groups that have not defined who receives a foreign authority request, who assesses its effect, and how the regulator is told often cannot show the mechanism works. Document the trigger, the escalation path and the reporting timeline before submission.
Questions buyers ask about binding corporate rules
Can we prepare binding corporate rules in-house without an outside partner?
Yes, a group can draft its own binding corporate rules, but the work is substantial and must satisfy Article 47(2), which lists at least 14 required elements. Binding corporate rules must be legally binding on every group member, expressly confer enforceable rights on data subjects, and be approved by the competent supervisory authority through the consistency mechanism. Your legal team owns the rules and the intra-group commitments, while your IT and security teams own the evidence behind them. An implementation partner can help prepare systems, audit trails, training records and technical measures, but only the supervisory authority approves the rules, and only an independent auditor can issue audit reports. Ask any partner to show which parts of the work it prepares and which parts remain with your own counsel.
How long does BCR approval take in general terms?
Approval runs through the consistency mechanism, so the timeline depends on the competent supervisory authority, the complexity of your group structure and how many transfers the rules cover. The EDPB's Recommendations 1/2022 on controller binding corporate rules, in version 2.0 finalized on 20 June 2023, set out the application and approval content that authorities expect to see. Processor binding corporate rules follow a separate track, and the EDPB's Recommendations 1/2026 on processor binding corporate rules were open for public consultation from 19 January to 2 March 2026. Plan for the approval process to be the longest phase, and ask your lead authority to confirm its current expectations before fixing any internal deadline.
What does a BCR project need from legal and IT teams?
Legal teams carry most of the drafting and governance work, and IT teams carry most of the evidence work. Legal typically defines the group structure, the transfers covered, the liability arrangements for an EU-based member, the complaint procedure and the mechanism for reporting third-country legal requirements that could have a substantial adverse effect on the guarantees, as Article 47(2)(m) requires. IT and security teams typically document data flows, describe the security measures applied to covered data, operate the access controls and logging that support audits, and maintain records of staff training. Both teams should agree early on one register of transfers, because the rules must match what systems actually do.
Can a partner prepare the evidence that BCRs require?
A partner such as DeployOpen can prepare systems, controls and evidence for the audit and approval work, including documented data flows, configuration baselines, access control records, logging, backup and restore procedures and training materials. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the evidence comes from systems you control. DeployOpen does not issue audit reports, attestations or approvals. The organization owns its controls, the supervisory authority approves the rules, and independent auditors issue any reports. Engagements are typically fixed-scope, so ask for the deliverables, the evidence list and the acceptance criteria in writing before work starts.
How do binding corporate rules compare with standard contractual clauses?
Binding corporate rules are a group-wide tool for intra-group transfers, while standard contractual clauses are contracts between a data exporter and an importer, usually adopted for individual relationships. Binding corporate rules require approval by a supervisory authority and cover every group member once approved, which suits a large group with many internal flows. Standard contractual clauses can be put in place without that approval process, but each contract needs its own transfer assessment and supplementary measures where needed. Many groups use both, depending on whether a flow is internal or external. Compare the approval effort, the number of entities involved and the ongoing monitoring each tool requires before choosing.
What ongoing obligations do BCRs create after approval?
Approved binding corporate rules are not a one-time filing. Article 47(2) requires data protection audits and training for staff with permanent or regular access to personal data, so these activities recur throughout the life of the rules. Group members must also keep a mechanism to report third-country legal requirements likely to have a substantial adverse effect on the guarantees, and changes to the group structure or transfers may need to be reflected in the rules. Budget for recurring audit cycles, training refreshes, record maintenance and change management, and ask any partner to describe which of these it supports under a retainer.
Do binding corporate rules reduce the need for transfer impact checks?
Binding corporate rules must include a mechanism to report third-country legal requirements that could have a substantial adverse effect on their guarantees, so the assessment of local law does not disappear. The rules shift the framework for intra-group transfers, but the group still needs to know what laws apply in each destination and how they affect the protection of data. Confirm with your counsel and lead supervisory authority how the transfer assessment is documented within the rules, and do not assume that approval removes this analysis.
How DeployOpen prepares evidence for binding corporate rules
DeployOpen works on Article 47 binding corporate rules as an implementation partner. We prepare the systems, documentation and evidence that a group needs to present to its competent supervisory authority, while the group owns its rules and the authority decides on approval. Each engagement starts from a written scope that the group agrees before work begins.
How we scope
- Agree in writing which group entities, transfer flows and processing activities the rules must cover before any work starts.
- Map the Article 47(2) elements against the group's existing policies, contracts and controls to identify gaps.
- Confirm which legal counsel, privacy office and supervisory authority contacts own each decision, and record that ownership in the scope.
How we build
- Prepare technical measures for security of processing, access control and logging that the binding rules describe for each group member.
- Configure self-hosted open-source platforms in the group's own infrastructure to record transfers, data flows and audit trails the rules rely on.
- Set up data protection audit schedules and staff training modules, and test that completion records can be produced on request.
How we hand over
- Deliver documentation that maps each rule and control to the system, owner and evidence that shows it operates.
- Provide a register of third-country legal requirements and the internal process for reporting them to the supervisory authority.
- Walk the group's team through the evidence pack so they can answer an authority or independent auditor without outside help.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, agreed in writing.
- Update systems and evidence when the EDPB recommendations on controller or processor binding corporate rules change, with the group deciding what to adopt.
- Remember that DeployOpen prepares evidence but does not issue approvals, audit reports or certificates; those come from the supervisory authority or an independent auditor.

