Open source HR software and GDPR for employee data

A reviewer expects a written record of processing activities that lists each HR purpose (payroll, leave, attendance, performance, recruitment), the categories of employee data, the recipients, the retention period and the security measures for each activity. The GDPR sets these record-keeping duties on controllers and processors, so the record must be kept by the employer and, where DeployOpen or another partner operates the system, reflect the processor arrangement. The platform itself does not produce this document. Build it from the HR system's field inventory and module list, then keep it under version control. Confirm with your data protection officer or legal counsel which activities need to be recorded and how often the record is reviewed.

Document one lawful basis per record type, such as contract performance for payroll, legal obligation for tax and social security filings, and legitimate interests or consent only where the purpose and balance of interests support it. Consent is rarely a sound basis for employment data because employees cannot freely refuse it in most employment relationships, so confirm this position with counsel. Store the mapping in the record of processing and reference it in each module's configuration notes, such as Frappe HR leave types or OrangeHRM custom fields. Any new field added during customization should trigger a review of its basis before go-live.

Provide a retention schedule that states, for each record type, the retention period, the legal or business reason, the trigger that starts the clock (often employment end) and the disposal method. Pair it with deletion logs that show when records were erased or anonymized, which fields or documents were affected, and who approved the action. Payroll and tax retention periods depend on national law, so confirm them locally. In the platform, deletion logs come from the application audit trail or a dedicated disposal workflow, while backups hold copies until their own rotation expires. Your backup policy should state how deleted employee data ages out of backup sets, and whether restores can reintroduce records that should have been erased.

Keep periodic access review records that list each user, role, manager scope and data category, with the reviewer's sign-off and the changes made. Role definitions in Frappe HR, OrangeHRM or Odoo show what each role can read and write, and the platform audit log records permission changes and record access where the application supports it. Group membership and single sign-on assignments come from the identity provider logs, which should match the application roles. Review manager scopes after reorganizations and check that departed HR staff lost access on their last working day. Confirm with each platform's vendor which access events are logged by default and which need configuration.

Maintain a request log for every access, rectification, erasure, restriction and portability request from employees or former employees, with the receipt date, identity check, scope, decision, response date and any extension or refusal reason. The GDPR sets response deadlines and requires the controller to document how the request was handled, so a ticketing system with a defined workflow usually serves better than email threads. Link each ticket to the affected records and to the export or deletion logs. Export jobs from the HR platform should be traceable to a ticket, and the log should record who ran them and what they contained.

Article 32 requires appropriate technical and organizational measures for the security of processing, and a reviewer will ask for evidence of each one. Typical evidence includes encryption settings for data in transit and at rest, access control configuration, multi-factor authentication for administrative and HR access, patch and upgrade records, backup and restore test results, and vulnerability assessment reports. Penetration tests and vulnerability assessments from DeployOpen or another tester are one source of evidence, and they should be dated and tied to the scope tested. Note that the GDPR requires no certificate. Article 42 certification is voluntary, issued for at most three years, and it does not reduce the controller's responsibility, so present the measures themselves rather than a badge.

The runbook should describe how a suspected breach is detected, triaged, contained, assessed and reported, including who decides whether to notify the supervisory authority within the timescale set by Article 33 and whether affected employees must be informed under Article 34. It should list the logs to preserve first, such as platform audit logs, identity provider sign-in logs and hosting access records, and the contacts at the hosting provider and any support partner. Test the runbook with a tabletop exercise and record the results. Confirm the internal escalation path and the national supervisory authority contact with your legal team before the test.

Yes, if personal data is accessed or stored outside the EEA, including by support engineers, backup providers or managed hosting staff in third countries. Chapter V of the GDPR governs transfers to third countries, so document each transfer, its safeguard (such as an adequacy decision or standard contractual clauses) and any supplementary measures. Commission Implementing Decision (EU) 2023/1795 covers the EU-US Data Privacy Framework and is one adequacy route to check against the recipient's certification. Keep support access restricted, logged and time-bound, and record every remote session in the ticketing system. Confirm the current status of any transfer mechanism with counsel, because the legal position changes over time.

The main drivers are the scope of record types, the number of countries and legal entities, the number of integrations, the volume of data to migrate and the support model after go-live. Each country adds its own retention rules and payroll setup, and each integration to identity, accounting or time tools adds build and test work. Costs fall into one-time work (design, configuration, migration, testing, documentation) and recurring work (hosting, backups, patching, upgrades, support). Ask any partner for a written scope that lists these items separately, so you can compare quotes on the same basis.

The duration depends on the number of record types, the countries covered, how clean the existing employee data is and how many approval and access rules must be designed. The record inventory and role matrix are usually the slowest steps, because they need decisions from HR, legal and works councils before configuration starts. Migration and parallel testing follow, and go-live timing often avoids payroll cutover dates. DeployOpen agrees timelines in writing as part of a fixed-scope engagement, so ask for the milestones and the decisions each one depends on.

Three inputs matter most. The first is a record inventory listing each HR data type, where it is stored today, who owns it, the lawful basis you rely on and the retention period you have set. The second is a legal review of those decisions by your data protection officer or counsel, because the partner cannot set your lawful basis or retention periods for you. The third is a role matrix that maps each job, such as line manager, HR administrator, payroll and auditor, to the records and actions it needs. Missing inputs usually extend the schedule more than any technical issue.

A capable internal team can run a self-hosted HR system, but it needs skills across application administration, database and backup operations, identity integration, access control and security patching. Most teams underestimate the effort to keep upgrades on schedule and to document access rules and deletion routines well enough to show an assessor. Ask yourself whether you have staff who can own the platform after go-live, cover absences and keep a test environment current. A partner can take on part of that work under a retainer, while your team keeps the decisions on records and access.

Yes. Odoo Community is LGPL-3.0 licensed, but the Enterprise edition is required for several features that matter here, such as the upgrade service and on-premise use under a subscription. Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise and that only Custom includes multi-company, Odoo Studio, external API access and custom modules. Standard support on Odoo 20.0 is planned until September 2029, and major upgrades are mandatory every two years on Odoo Online and Odoo.sh, so plan a recurring upgrade and test cycle that re-checks access and retention settings. Confirm current edition terms directly with Odoo before you choose.

DeployOpen does not give legal opinions on GDPR, employment or works council obligations, and it does not issue audit reports, attestations or certifications. Those come from your counsel, your data protection authority guidance, and independent auditors or certification bodies. What DeployOpen can deliver is the technical side: configuring and hardening the self-hosted system, documenting access roles, retention routines and deletion steps, and preparing evidence for an assessment. Under the GDPR, certification under Article 42 is voluntary and does not reduce the controller's responsibility, so the decisions stay with you.

Recurring costs usually include hosting and backups, security patching, version upgrades, monitoring, access reviews and support for payroll runs, plus any changes to integrations with identity, accounting or time systems. Support can be arranged as a retainer, so ask a partner to split the quote into one-time build work and a monthly or annual support scope with defined response expectations. Confirm response times and what counts as an in-scope change in writing, because these terms drive the long-term cost more than the initial build.

Migration effort depends on the number of employee records, the number of historical years to bring across, how many child records such as leave allocations and contract history must be linked, and how much cleanup the source data needs. ERPNext's Data Import tool, for example, documents importing only a few thousand records at a time, so large histories are usually split into batches and validated after each one. Ask a partner to show how it will handle retention for records you must keep in the old system, and how it will test a migrated copy before the live cutover.