Group Structure and Background Checks: Consistency Across Subsidiaries
For international groups, the question is not whether background checks take place, but how they are orchestrated across the group so that the organization presents a unified approach while each local subsidiary still meets its regulatory obligations. If you miss that balance, you create two problems at once: inconsistent screening standards between subsidiaries and local regulatory findings because the central policy does not account for national specifics. This article shows how groups can harmonize background-check processes without compromising local compliance.
The core question: Who is responsible?
Every background-check program in a group structure starts with a fundamental data protection decision. The GDPR recognizes three roles: the controller (Art. 4 No. 7 GDPR), the joint controller (Art. 26 GDPR), and the processor (Art. 28 GDPR). Which arrangement applies between the parent company, the subsidiary, and Group Compliance determines liability, contractual documentation, and operational processes.
The subsidiary as an independent controller
The standard case: the subsidiary signs the employment contract, processes candidate data for its own purposes, and is the controller within the meaning of the GDPR. The parent company provides support services at most. This setup is clean, but it creates the harmonization challenge: if each subsidiary decides for itself, standards drift apart.
Joint responsibility under Art. 26 GDPR
If the parent and subsidiary decide jointly on the purposes and means of processing — for example, because the group sets a binding screening policy and operates central systems — joint responsibility arises. That requires an agreement under Art. 26 GDPR, clearly defining the respective obligations, especially regarding data subject rights. Data subjects can exercise their rights against either party (Art. 26(3) GDPR) — a risk that is often underestimated.
Processing on behalf within the group
If the parent company merely provides the subsidiary with a technical system or a shared-services team without pursuing its own purposes, this is classic processing on behalf. In that case, a data processing agreement (DPA) under Art. 28 GDPR is required between the parent and the subsidiary. The so-called "group privilege" does not exist under the GDPR — even intra-group data flows need a legal basis and, in the case of processing on behalf, a DPA.
International data flows: Binding Corporate Rules
As soon as applicant data crosses national borders — especially into third countries outside the EEA — Chapter V of the GDPR becomes relevant. Standard Contractual Clauses (SCCs) are the most common route, but for multinational groups often not the best option. Binding Corporate Rules (BCRs) under Art. 47 GDPR are binding internal data protection rules approved by the competent supervisory authority and used to legitimize group-wide data transfers.
BCRs are demanding to establish — approval processes typically take 18 to 24 months — but they offer three strategic advantages:
Once approved, they cover all intra-group transfers without the need to conclude SCCs separately for each legal relationship.
They signal a high level of compliance to regulators and reduce audit risk.
They create a binding internal governance architecture that has an impact beyond data protection.
For groups with subsidiaries in the UK, USA, or APAC, BCRs are usually a more robust solution than a patchwork of SCCs.
Group-wide policies vs. country-specific compliance
The key operational challenge: a central policy must set consistent minimum standards, but it must not be so narrow that it ignores local obligations or violates local prohibitions. This is especially true in regulated sectors.
What applies in Switzerland, Austria, and across the EU?
Germany: Section 25c KWG and BaFin requirements
The German German Banking Act requires institutions under Section 25c KWG to conduct a comprehensive assessment of the reliability and professional suitability of management board members and key functions. The BaFin specifies this further in its guidance on managing directors and management or supervisory bodies. Subsidiary banks in Germany must implement this regardless of what applies at group level. The central policy must reflect the BaFin standard as the minimum level for German subsidiaries.
Switzerland: Art. 3 BankA and FINMA fitness and propriety assessment
In Switzerland, Art. 3(2)(c) BankA governs the fitness and propriety assessment for license holders. The FINMA expects documented verification of fitness for proper business conduct for persons in senior positions. The Swiss Data Protection Act (revDSG, in force since 1 September 2023) differs in detail from the GDPR — for example, regarding mandatory information in privacy notices and data subject rights — but is compatible in its overall architecture. Groups can use GDPR standards as a baseline and add Swiss specifics; conversely, a process that is merely GDPR-compliant does not automatically meet Swiss requirements.
Austria: Section 5 BWG and FMA requirements
The Austrian Banking Act requires reliability and professional suitability of management board members under Section 5(1) no. 6 et seq. BWG. The FMA reviews this through the so-called fit-and-proper assessment. Austria follows EU harmonization (EBA guidelines) but has its own formal requirements. In practice, German and Austrian requirements are highly similar — but not identical. A joint "DACH policy" only makes sense if it explicitly addresses the national differences instead of flattening them.
Across the EU: EBA guidelines and CRD VI
At EU level, the EBA guidelines on fit & proper (EBA/GL/2021/06, together with ESMA) harmonize the requirements for suitability assessments in the financial sector. CRD VI (Directive (EU) 2024/1619) further sharpens the requirements and calls for stronger documentation of suitability assessments at group level. For unregulated industries, these standards do not apply directly, but they are de facto a benchmark for demanding screening programs.
Architecture example: German holding company with Swiss, Austrian, and EU subsidiaries
A typical scenario: a German holding company has subsidiaries in Switzerland, Austria, France, and the Netherlands. For a harmonized background-check program, the following architecture is recommended:
Group-Level Policy (central, German and English): defines screening categories, risk classes, minimum standards, data retention rules, and escalation paths.
Local annexes (per jurisdiction): specify screening scope, permitted sources of information, consent texts, and national supervisory requirements.
Central technical platform: a screening system used across the group, operated by the holding company or a group service entity — with a DPA for all subsidiaries, if applicable under BCRs.
Local data sovereignty: raw data (reports, documents) is generally stored in the subsidiary's country; only aggregated decisions and audit metadata are consolidated centrally.
Consolidated reporting for group audits
BaFin, FMA, and FINMA do not only review individual institutions; increasingly, they also assess groups. A Group Chief Compliance Officer needs consolidated evidence for supervisory discussions: How many screenings were conducted per quarter? What percentage triggered an alert? How were findings escalated and closed? Which subsidiaries deviate from the group standard — and why?
You can only generate this evidence if the system is designed for consolidated reporting from the outset. Aggregating it later from separate systems is error-prone and rarely withstands scrutiny in an audit.
Matrix: Central vs. local data storage
Data category | Storage | Reason |
|---|---|---|
Screening policies and risk classes | Central | Group-wide binding effect, version control |
Consent texts (national) | Local | Language, national law, DSG/GDPR specifics |
Raw reports (criminal record certificate, sanctions lists) | Local | Data sovereignty, deletion periods under national law |
Screening decisions (go/no-go) | Central (aggregated) | Audit trail, group reporting |
Audit logs and access logs | Central | Forensic integrity, supervisory requests |
Personal applicant data | Local | Deletion obligations, data subject rights, employment law |
Harmonizing screening depth — risk-based, not uniform
A common mistake in groups is the reflex to force all subsidiaries to the same screening level. That is neither efficient nor legally permissible. The GDPR requires data minimization under Art. 5(1)(c); screening depth must match the actual risk of the position. An intern in a sales subsidiary should not undergo the same check as a designated managing director of a BaFin-regulated bank subsidiary.
The solution: a group-wide risk matrix with three to five levels (for example, Basic, Standard, Enhanced, Senior Executive, Regulated Function), combined with mandatory local modules. That way, the logic remains consistent across the group while the actual implementation fits local requirements.
CSRD reporting at group level
The Corporate Sustainability Reporting Directive (CSRD, Directive (EU) 2022/2464) requires large companies to provide expanded sustainability reporting under the ESRS for financial years 2024 or 2025 onward. Under the "S1 – Own workforce" standard, governance processes related to employees are subject to disclosure, including processes for identity and integrity checks during hiring.
Background-check programs therefore become a CSRD topic. A consolidated, auditable screening program provides the data foundation for reporting obligations; a fragmented program forces costly retroactive data collection.
Governance recommendations for Group CCOs
For the Group Chief Compliance Officer, the findings can be translated into five concrete actions:
Clarify roles: document for each subsidiary whether it is an independent controller, joint controller, or processor — and put the right contracts in place.
BCR assessment: for subsidiaries in third countries or centrally operated platforms, assess whether Binding Corporate Rules are a more robust path than a patchwork of SCCs.
Two-layer policy: a group policy with minimum standards plus local annexes for each jurisdiction — never a flattened "one-size-fits-all" policy.
Consolidation architecture: design the technical platform from the start so that local data sovereignty and central reporting are not in conflict.
CSRD readiness: document screening processes with ESRS S1 disclosure obligations in mind, not only at the first reporting cycle.
Groups that address these points early reduce audit risk, save integration costs in M&A, and can connect new subsidiaries to group standards more quickly. If you leave it for later, you will pay for it with extra effort — or with findings in the supervisory report.
Typical mistakes in group rollouts — and how to avoid them
In practice, four mistakes recur frequently in group-wide background-check programs. If you know them, you can avoid most of the rework.
Mistake 1: Clarifying roles only after selecting the system. Many groups choose a screening platform first and only then address the data protection role allocation. The result is a system whose tenant separation, access rights, and data flows do not match the actual responsibility model. The right sequence: first roles, then contracts, then the system.
Mistake 2: A group policy without local validation. A policy written at group headquarters is rolled out without consultation with local compliance leads. By the time the first supervisory discussion takes place in Switzerland or Austria, it becomes clear that national specifics — Swiss DSG obligations, Austrian FMA forms, German BZR rules — have not been addressed properly. The remedy: circulate the policy draft to all local legal and compliance functions before approval, and document sign-off.
Mistake 3: A technical platform without multi-tenancy. Platforms that establish local data sovereignty through organizational access rules rather than technical tenant segregation rarely withstand a serious audit. What you need is an architecture in which each subsidiary receives its own logical instance with its own keys, its own data residency, and granular access control — with central aggregation only at metadata level.
Mistake 4: No communication to applicants and employees. Anyone who introduces screening across the group without transparent communication risks labor-law and employee-representation conflicts. In Germany, Section 87(1) no. 6 of the Works Constitution Act requires co-determination by the works council when introducing technical systems that can monitor employee behavior or performance. Early involvement of employee representatives saves lengthy proceedings later.
Conclusion
Harmonized background checks in a group are not an IT project, but a governance project with IT components. The key decisions are made in role clarification, the two-layer policy, and the group-wide trust framework — not in system selection. If you treat the regulatory differences between Germany, Switzerland, Austria, and the EU as design parameters instead of ignoring them, you build a program that is both manageable at group level and audit-ready locally.
Are you planning a group-wide background-check program or want to consolidate an existing one? Book a demo and we will show you how Indicium technically maps the balance between group standards and local compliance.
Read more — related articles
Nabil El Berr
