Why self-hosted HR software for EU data sovereignty changes the platform decision
When a works council or data protection officer asks where employee files and payroll data sit and who can see them, a US-controlled HR SaaS tenant is hard to defend on its own terms. The most direct route to sovereignty is a self-hosted open source HRIS running in an EU cloud or data center that the employer controls, with support access granted, logged and revoked by the company. Within that route, the choice between Frappe HR and Odoo depends mainly on payroll localization for each country where you employ people and on whether you need Odoo Enterprise features such as mobile apps, upgrades and hosting. Frappe HR is part of the Frappe ecosystem that runs ERPNext, so confirm the HR module scope against your own requirements before deciding.
The GDPR transfer rules do not turn only on where the server is racked. The EDPB's Guidelines 05/2021 (version 2.0) treat remote access from a third country, even just displaying data on a screen for support or administration, as a transfer, and they also treat storage in a cloud outside the EEA as a transfer. A self-hosted system in Frankfurt can therefore still involve a transfer if a vendor engineer in another country opens employee records during an incident. Map every support path, including EDPB Guidelines 05/2021 (version 2.0), backups, log shipping and monitoring tools, before you sign a support contract.
The practical decision is therefore the support model as much as the hosting. Ask your implementation partner and any retained support provider where engineers are located, whether they can reach production data from outside the EEA, how privileged sessions are approved and recorded, and which entities could receive a government request for the data. Confirm the contractual transfer basis with your counsel, and record the assessment for the works council. Hosting in an EU data center is a necessary starting point, not evidence that the arrangement is sovereign on its own.
Which EU rules and constraints shape the HR build
This table maps the EU rules that most affect where employee data sits, who can reach it and how it is protected. Read each row as a design question: what the rule means for hosting location, vendor access, encryption and logging. The main takeaway is that a self-hosted system only helps sovereignty if the support, backup and remote access paths are also kept inside the EU boundary.
| Rule or constraint | What it requires or signals | What it means for hosting, vendor access, encryption and logging |
|---|---|---|
| GDPR Article 44 and Chapter V transfers | Every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions | Hosting in the EU is not enough on its own. Confirm that vendor support staff outside the EEA cannot view or administer the data, and map every onward transfer in the processor chain |
| Remote access as a transfer (EDPB Guidelines 05/2021) | Remote access from a third country, even only displaying data on a screen for support, counts as a transfer | Support sessions from outside the EEA need the same assessment as data copies. Log vendor sessions, restrict them to named accounts and require approval for access to employee records |
| Article 83 fine levels | Up to EUR 20 million or 4% of worldwide annual turnover for transfer and principle infringements, and up to EUR 10 million or 2% for infringements such as Articles 25 to 39 | Transfer failures sit in the higher tier. Document hosting locations, transfer assessments and processor terms before go-live so the controller can show compliance |
| Article 32 security of processing | Requires controller and processor to apply measures appropriate to the risk, including encryption and the ability to restore data | Encrypt backups and replicas, keep keys under the company's control where feasible, test restores and keep administrative activity logs for review |
| Article 48 limits on third-country disclosure | A third-country court or authority order to disclose personal data is recognized only if based on an international agreement in force with the Union or a Member State | When a US-controlled vendor receives a foreign demand, the EU data may still be exposed. Ask vendors how they handle such requests and what notice they give controllers |
| US CLOUD Act (18 U.S.C. 2713) | Providers must preserve or disclose data in their possession, custody or control, wherever it is located | A US parent company or US-controlled provider may be compelled regardless of hosting location. Assess this exposure before engaging the provider, and confirm which entity holds the keys and admin access |
| Data Act switching right and Article 32 safeguards | Customers may switch to another provider or to on-premises infrastructure, and providers must take measures against third-country governmental access to non-personal data | Keep exports of HR data in open formats and document the configuration so the system can move to another host or on-premises. Ask vendors for their switching and exit terms in writing |
| Certification and evidence | GDPR requires no audit, attestation or certificate. Article 42 certification is voluntary and does not reduce the controller's or processor's responsibility | Certifications are not a shortcut. Build the evidence yourself: records of processing, transfer assessments, access logs, backup tests and retention settings, then confirm with counsel and any independent auditor you engage |
Frappe HR, Odoo or an HR SaaS: how the options compare on sovereignty
Frappe HR runs on ERPNext, which is licensed under GPL-3.0, and sits on the Frappe Framework, which is licensed under MIT. Both licenses allow the company to install, host and modify the software inside its own EU infrastructure without a per-employee license fee. The sovereignty question shifts to operations: who runs the servers, who holds the database and who can reach the system during an incident. Frappe publishes supported versions, and according to its supported versions page, version 14 reached end of life on January 31, 2026, version 15 is planned to be supported until the end of 2027 and version 16 until the end of 2029.
- Licensing: ERPNext is GPL-3.0 and the Frappe Framework is MIT, so the software itself carries no subscription that would route data through a vendor.
- Version choice: Pick version 15 or 16 at the start and write the end-of-life dates into the upgrade plan.
- Warranty: Frappe's supported versions policy ties warranty coverage to a listed version and a matching Frappe Cloud support plan. A self-managed EU deployment without that plan needs its own support arrangement with a named provider.
- Hosting choice: Frappe Cloud is one hosting route. Self-hosting with Docker Compose or the bench tool keeps the data in the company's own cloud account or data center.
- Implementation: The pricing page says implementation is available through certified partners, so confirm each partner's scope in writing.
Ask the implementer which support contract covers the exact version in production and who holds the operating-system and database patching duties.
Odoo is published under the GNU LGPL version 3, and Odoo Community is the open source core on which the licensed Odoo Enterprise edition is built. Community can be installed on EU infrastructure, which keeps the core payroll-adjacent data under the company's control. Enterprise adds features that matter for HR operations, and the Odoo editions page lists mobile apps, Studio customization, version upgrades and hosting as Enterprise capabilities. Hosting and upgrades are therefore paid features, which changes who operates the system and who is responsible for updates.
- Community scope: Confirm which HR, leave and attendance features the target use case needs and whether they are available in the Community edition.
- Enterprise features: Check whether mobile self-service, Studio customization or the upgrade path are needed. Each one moves part of the operating model to an Enterprise contract.
- Hosting: Odoo's own hosting is an Enterprise feature. A self-hosted EU deployment keeps hosting in the company's control, but the team must run backups, upgrades and monitoring.
- Upgrade path: Major Odoo releases, including Odoo 20 released on September 24, 2026, need a tested migration plan for HR data and custom code.
- AI features: Odoo says all AI features in Odoo 20 require credits bought as in-app purchases, so confirm that no AI feature sends employee data to a service the company has not assessed.
Ask the partner to list which features depend on Enterprise and whether any of them are required by the sovereignty design.
A US-based HR SaaS platform usually stores employee files, payroll inputs and performance data in cloud regions chosen by the vendor, and its operations are run by a company subject to US law. Under the GDPR, the EDPB Guidelines 05/2021 state that storage in a cloud outside the EEA and remote access from a third country, even only displaying data for support, are transfers. Each transfer needs a valid transfer mechanism, and the company must assess whether the vendor could be compelled to disclose data under US law. Whether a specific vendor qualifies under the Data Privacy Framework depends on its listing, which the company must check directly.
- Data location: Confirm where the production data, backups and logs are stored, including sub-processors.
- Support access: Ask which staff in which countries can open customer records, and whether that access is logged and time-limited.
- Legal exposure: The CLOUD Act at 18 U.S.C. 2713 applies to providers regardless of data location, so a transfer assessment should cover that exposure.
- Framework status: Commission Implementing Decision (EU) 2023/1795 covers only US organizations on the Data Privacy Framework List, and an appeal in Case C-703/25 P is pending.
- Exit terms: The Data Act gives customers the right to switch providers or move to on-premises infrastructure, with switching charges banned from 12 January 2027.
Ask the vendor for its current transfer documentation, its sub-processor list and a written description of support access in writing.
Which open source HR platforms fit an EU sovereignty brief
Three self-hosted options and one structural note cover most EU sovereignty briefs for HR. Each option is a different trade between an existing estate, HR scope and payroll coverage, so the choice should follow where your records must sit and which payroll rules you must meet.
Frappe HR within ERPNext
Frappe HR runs inside ERPNext, so HR, accounting and projects share one database and one hosting boundary. This fits when HR must sit with the general ledger and cost centers in one stack. The payroll localization for each country is the check to make first, because payroll rules and statutory filings differ by country and are not something to assume from the HR module alone. Confirm with the vendor and your implementation partner which payroll components cover your countries, and where payslip data is stored. Keep in mind that Frappe Cloud hosting is a separate choice from self-hosting, so confirm which hosting location and support access model your sovereignty brief allows.
Odoo Community and Enterprise
Odoo Community is published under LGPL-3.0 and can be self-hosted in EU infrastructure. Odoo Enterprise adds features such as mobile apps, Studio customization, version upgrades and hosting, so the edition decision should be made against your required features and support model. This fits when your organization already runs an Odoo estate and HR should extend it. Odoo 20 states that all AI features require credits bought as in-app purchases, so check whether any AI-assisted HR feature is in scope and budget for it separately. Confirm payroll coverage and localization modules for each country with Odoo before you commit.
OrangeHRM for HR-only scope
OrangeHRM suits organizations that need HR records, leave and workflows without a full ERP stack. Self-hosting keeps employee files inside your own infrastructure, which is the core of the sovereignty brief. The main risk is scope creep: if payroll, accounting or recruitment must be integrated later, confirm during evaluation that the product covers those needs or that a clean integration path exists. Ask the vendor which edition includes the features you need, how it is licensed, and what the upgrade and backup procedure looks like for a self-hosted deployment. Confirm payroll coverage for each country before assuming the HR module can handle payroll runs.
Payroll provider may stay outside
A local payroll provider can remain the system that calculates and files pay even when the HR record is self-hosted. This split keeps statutory payroll expertise where it already exists, but it creates a data flow that the sovereignty assessment must cover. Identify which employee fields leave the HR system, whether the provider is established in the EU, and how it handles support access to pay data. Define the interface in writing, including file format, sync frequency and who owns the reconciliation when the two systems disagree. Confirm the provider's hosting location and sub-processor list before you finalize the architecture.
Hosting and support access patterns that keep data under company control
The hosting decision determines who can reach employee files, payroll data and performance records, and under which law. The patterns below connect the hosting location, the operator, support access and key custody to the components of a Frappe production stack, so each choice can be checked against the transfer rules that apply to HR data.
EU-region cloud account owned by the employer
The employer holds the cloud subscription in an EU region and deploys the Frappe production stack there, including MariaDB, Redis, background workers, the scheduler, Socket.io and Nginx. Ownership of the account decides who can grant access to the storage volumes and database backups. Check that the provider's contract and support model do not give a non-EU parent or affiliate standing access to the tenant, and confirm where backups and logs are replicated.
On-premises or EU colocation
Running the stack in the employer's own data center or a colocation facility inside the EU gives full physical control over racks, network paths and removable media. The trade-off is that the team must operate patching, failover and backups for every service in the stack. Confirm the facility's staff access procedures and that replicated backups stay within the EU.
Managed partner inside the employer's account
A managed partner operates the Frappe stack inside the employer's own cloud account, with its administrative identities granted through the employer's identity provider. The employer can revoke those identities without the partner's cooperation. Require written confirmation that no partner staff member outside the EU can view HR records, including by screen sharing, because displaying data from a third country is treated as a transfer under EDPB guidance.
Time-limited support access with logs
Support access should be granted as named, time-limited sessions that the employer approves, and each session should be recorded in an audit log that the employer can read. This keeps vendor engineers out of Server Script and database access unless a ticket requires it. Ask the partner how session approval, expiry and log export work, and whether database console access is included in the support scope.
Encryption with employer-held keys
Encrypt traffic between users, Nginx and the application with TLS, and encrypt data at rest on database and file volumes, including MariaDB backups. Keep key material in a key management service or hardware security module that the employer controls, so the operator cannot decrypt data without the employer's approval. Confirm which keys protect Redis persistence and uploaded attachments, since these are easy to overlook.
Demo setup is for evaluation only
The single-file demo configuration in the Frappe Docker repository is marked for short-lived evaluation only. It bundles services without the hardening, backup schedule and access controls that a production deployment needs. Use it to test the Data Import flow and screens, but never load live employee or payroll records into it. Move to the production Compose files or a managed deployment before any real data is entered.
How a sovereign HR rollout runs, phase by phase
The sequence turns a US-hosted HR SaaS exit into a self-hosted EU platform where every transfer, access path, payroll input and deletion can be shown to a DPO, works council and auditor.
Map data flows and transfer exposure
The project team inventories every system, vendor, sub-processor and person that can touch employee data today, including the SaaS vendor's support staff, its backups, analytics pipelines and any US-based parent access. For each path the team records whether it is a transfer under Chapter V of the GDPR, following the EDPB's view that remote access from a third country counts even when data is only displayed on screen. The output is a signed transfer inventory and a list of processing activities that the DPO accepts as the baseline.
Design hosting and access with DPO sign-off
Engineers and the DPO agree where the Frappe HR or Odoo instance runs, which EU-controlled cloud accounts or data centers host it, who holds administrator and database access, and how vendor support is granted only through logged, time-limited sessions with data kept in the EU. The design also addresses backups, encryption keys and any third-country authority exposure the DPO wants assessed before a processor is engaged. Sign-off is recorded as a written access design that names roles and controls, not only a diagram.
Consult the works council and fix the scope
HR and the employee representative body review the data categories, purposes, monitoring features such as attendance capture, and the access model before build starts. Questions about which fields are mandatory, how long records are kept and what managers can see are settled here, and any changes are written into the agreed scope. The output is a scope document and a consultation record that the project can point to when a feature is later questioned.
Build and harden the EU environment
The implementation partner installs ERPNext or Odoo in the agreed environment, using a supported version and a deployment method such as Docker Compose or the bench command line tool, then configures roles, document permissions, leave and payroll-relevant masters, and a restricted set of server-side customizations. Hardening covers network segmentation, TLS, MFA for administrators and logging, and Server Scripts remain disabled unless the team has a documented reason to enable them. Completion is shown by a configuration baseline and a test report against the access design.
Import employee records in controlled batches
Records move from the legacy system using the ERPNext Data Import tool with downloadable templates, loading CSV or Excel files in batches of a few thousand records, as the documentation advises. Each batch is reconciled against source counts, child table rows such as contracts and leave allocations are checked, and rejected rows are fixed at source rather than edited ad hoc. The output is a reconciliation log per batch and an approved master data set.
Run a parallel payroll cycle with the local provider
Payroll inputs from the self-hosted system are sent to the local payroll provider for one or more parallel runs alongside the existing payroll, so gross-to-net results, statutory deductions and employer contributions can be compared line by line. Differences are traced to master data, attendance or leave inputs, and the provider's own rules, and each must be cleared before cutover. The output is a signed variance report and an agreed file interface specification.
Cut over and decommission the SaaS tenant
The team freezes changes, runs the final data load, switches users and integrations to the EU platform, and confirms identity and access works for employees and managers. The SaaS tenant is then closed under the vendor's termination terms, and the team requests written confirmation of deletion of employee data, including backups and sub-processor copies where the contract allows. Evidence is kept for the DPO: the export archive, the vendor's deletion confirmation and the cutover record.
Evidence the DPO, works council and auditors will ask for
This table lists the records a data protection officer, works council or external auditor is likely to request for a self-hosted HR deployment, the component or team that produces each one, and where gaps usually appear. DeployOpen prepares these artifacts and controls for assessment, but independent auditors and certification bodies issue any audit reports or certifications.
| Evidence | What it shows and who produces it | Where it usually fails |
|---|---|---|
| Processing register and transfer inventory | Records of each HR processing activity, lawful basis, recipients and any third-country transfer, including remote support access (GDPR Article 30 and Chapter V). Owned by the controller's DPO, drafted with the implementation team. | Support vendor or payroll provider access from outside the EEA is not listed as a transfer. |
| Hosting location and vendor access records | Named data centers, regions and cloud accounts holding HR and payroll data, plus the legal entity and jurisdiction of each operator. Produced by the infrastructure team and DeployOpen's deployment documentation. | Backups or log shipping quietly replicate to a region outside the EEA. |
| Support access logs and approvals | Who accessed production, when, from where, for what ticket, and who approved it. Produced by the bastion or VPN logs, the ticketing system and the client's approval workflow. | Vendor engineers hold standing credentials with no per-session approval or log review. |
| Encryption configuration | Evidence of encryption in transit and at rest for the database, file storage, backups and inter-service links, with key ownership stated. Produced by the server configuration, the key management record and the deployment runbook. | Keys held by the hosting provider or stored beside the encrypted data. |
| Backup location and restore tests | Where each backup copy sits, retention periods per record type, and dated test restores showing records can be recovered. Produced by the backup tooling logs and restore test reports. | Restores have never been tested, or backups cannot be decrypted by the client's own staff. |
| Change and upgrade records against supported Frappe versions | Version in use, upgrade tickets, test evidence and confirmation the version is on Frappe's supported versions list. Produced by the change management system and the Frappe version record. | Production runs an end-of-life version, or upgrades are applied without a documented test run. |
| Article 33 breach procedure | Written steps for detecting, assessing and reporting a personal data breach to the supervisory authority, with the contact chain and a tested tabletop exercise record. Owned by the controller, supported by the incident runbook. | Procedure names no owner for the 72-hour clock or excludes the vendor's notification duty. |
What EU employers ask before hiring a partner for self-hosted HR
How much does a sovereign self-hosted HR build cost and what drives it?
The build cost is set by the written scope, not by a list price, so no figure applies to every employer. The main components are the software itself, which is free to download for Frappe HR and ERPNext and carries licensing terms for Odoo Enterprise if you need Enterprise features, plus infrastructure in your EU cloud account or data center, implementation and configuration, payroll localization for each country you employ people in, data migration from your current HRIS, integrations with identity and accounting, testing, and documentation. Edition fees, the number of payroll countries and the number of integrations are usually the largest drivers. Ask each bidder for a fixed-scope quote that separates one-time work from recurring hosting, support and upgrade costs, and state which payroll countries and integrations it covers.
How long does a self-hosted HR rollout take in the EU?
Duration depends on the number of payroll countries, the volume and quality of employee data to migrate, the number of integrations, and how many works council or data protection reviews must finish before go-live. A single-country rollout with clean data and one payroll provider usually runs on a different timeline than a multi-country group with legacy records and several local payroll providers. Ask the partner for a phased plan with milestones for design, data mapping, a parallel payroll run, and cutover, and confirm which steps depend on your internal approvals. No duration should be accepted without a written scope that lists these dependencies.
What does the company have to provide for an HR implementation?
Several roles on the employer side must be filled before the build starts, and a partner cannot supply them. Expect to name a data protection officer or privacy lead who signs off on the lawful basis, retention periods and transfer assessment, HR process owners who define leave, attendance and approval rules, and a works council contact where one exists and must be consulted. You also need a signed contract with each local payroll provider that defines data formats, file exchange and cutover timing, plus an internal owner for identity and infrastructure. Agree these responsibilities in the written scope so that delays on either side are visible early.
Can our IT team run a self-hosted HR system without a partner?
A capable platform or IT team can run Frappe HR, ERPNext or Odoo, but the work is continuous rather than a one-off project. Recurring tasks include applying minor and major version upgrades on supported releases, testing upgrades before production, maintaining backups and periodically proving that restores work, patching the operating system and database layers, monitoring availability, and running access reviews for HR, manager and administrator roles. Payroll-related changes such as tax table updates also need testing before each payroll run. Decide which of these tasks your team will own, which a retainer will cover, and how the arrangement works during a payroll deadline.
Does self-hosting remove our GDPR obligations for employee data?
No. Self-hosting changes where the data sits, but the employer remains the controller and keeps the duties for lawful basis, transparency, data subject requests, retention, security of processing and breach notification under the GDPR. Hosting on EU infrastructure also does not settle every transfer question, because remote access from a third country, including support sessions that only display data, can still count as a transfer under EDPB guidance. Your data protection officer should map each record type, each access path and each support channel before design starts. Certification or a vendor statement does not replace that assessment.
Does the EU Data Act switching right apply to a self-hosted HR tool?
This depends on how the HR service is classified, and you should confirm it with counsel before relying on it. The Data Act, applicable since 12 September 2025, gives customers of data processing services a right to switch to another provider or to on-premises ICT infrastructure, with switching charges banned from 12 January 2027. Whether an open-source tool you run yourself, or a managed hosting or support arrangement you buy from a partner, falls within that definition is a legal question. Ask your counsel and any hosting or support provider to state in writing how the Data Act applies to each contract, and record what exit assistance and data export terms you can rely on.
How do we check that a partner handles support access to employee data safely?
Ask the partner to describe every path by which its staff could see employee records, including screen sharing during support, log access, database consoles and backup restores. Each path should be limited to named roles, logged, time-bound and performed from inside the EU where the data is stored, with the reasons documented. Request the written access procedure, the list of who holds access, and how emergency access is approved and reviewed. Because remote access from a third country counts as a transfer under EDPB guidance, these answers belong in the transfer assessment before the contract is signed.
What to ask an implementation partner about EU hosting and support access
Start with a single question: where does every copy of employee data live? Ask the partner to list each location for the production database, file attachments (contracts, medical certificates, performance notes), search indexes, Redis caches, email queues, exports, staging copies and test data, and then the backups, snapshots, replicas and logs that capture the same records. Logs deserve particular attention because application and web server logs often contain names, IDs and payslip references. Ask which regions the cloud accounts or data center contracts sit in, whether any managed service, monitoring tool or error tracker transmits personal data outside the EU, and how the partner would prove it. Under GDPR Article 44, an onward transfer is a transfer, so a backup copy in another country counts even if nobody opens it. Ask for a data flow diagram that the partner maintains and updates at each release. Next, ask who can reach production, from which countries, and through which path. A partner engineer viewing a payroll record on a screen from a third country is treated as a transfer under the EDPB's Guidelines 05/2021, so remote support access belongs in the transfer assessment, not only in the security review. Require a named list of support staff, their home countries and their access method, such as a bastion host, just-in-time elevation or a session recording tool. Ask how support approval works: who at your company approves a ticket that touches employee data, how long access lasts, and whether the partner can run a support session without seeing personal fields. Confirm that these approvals and sessions are logged in a form your DPO and works council can inspect. Finally, settle the evidence and the exit terms before signing. Ask how payroll localization is delivered for each country, who maintains the tax tables, and how changes are tested before a payroll run. Ask which Frappe or Odoo versions the partner supports and what the upgrade policy is, including whether the partner will apply security fixes within a stated window and how it notifies you. For Frappe, confirm the listed version and support plan on Frappe's supported versions page. Ask what evidence the works council and DPO receive, such as access reports, configuration baselines and restore test results. Finally, ask how exit works: the format of the data return, the deletion schedule for every copy listed in the first answer, written confirmation of deletion, and how backups age out. Confirm each answer in the written scope before work begins.
