GDPR compliance software: open-source options and limits

Can GDPR compliance software be open source and self-hosted?

Yes, a controller can run open-source or free GRC software inside its own infrastructure and use it to keep GDPR records, risk registers, controls and evidence. CISO Assistant, licensed under AGPL-3.0-only, ships a GDPR framework among more than 200 frameworks and can run assessments against it, keep risk assessments, applied controls, evidence and remediation action plans, and hold a third-party risk module. eramba is also self-hostable, but its Community edition is not open source: its June 2024 license update forbids modifying, selling, licensing or distributing the software, so treat it as free-to-use software under restrictive terms. Confirm the exact license text for any product you shortlist, and check whether the enterprise directory of CISO Assistant, which falls under a separate commercial license, contains the features you need.

No software makes an organization compliant. The GDPR requires no audit, attestation or certificate, and it places the duties on the controller or processor, not on the tool. The records the Regulation names, including the record of processing activities under Article 30, DPIAs for likely high-risk processing under Article 35, breach documentation under Article 33(5) and written processor contracts under Article 28(9), must be accurate and available to the supervisory authority on request. A GRC tool can hold them in electronic form, but someone must write the content, decide the lawful bases and risk levels, and sign off the outcomes. Fines under Article 83 can reach EUR 10 million or 2% of worldwide annual turnover for some infringements and EUR 20 million or 4% for others, and they have applied since 25 May 2018, so the decision to deploy a tool should be backed by a named owner and a review cycle.

The right answer depends on your processing volume, your role as controller or processor, and whether a customer or regulator is asking for evidence. A small organization with few processing activities may manage records in a self-hosted tool with modest internal effort. A processor serving many controllers needs contract, sub-processor and customer-audit records that a framework mapping alone will not produce. Ask whether the tool's audit trail, access control and export formats will satisfy a customer questionnaire or a supervisory authority request, and whether your DPO can review the records without relying on the vendor. Budget for the one-time setup and the recurring work of keeping records current, not only for the software itself.

What compliance software can and cannot do for GDPR

A GRC tool can organize the paperwork and evidence that the GDPR expects, and it can keep remediation visible over time. It cannot make the legal decisions, carry the DPO's judgment or make the systems secure. The cards below separate those two halves so you can scope a tool and a partner against what the regulation actually asks for.

Framework mapping and its limits

CISO Assistant ships GDPR as one of more than 200 frameworks and can run assessments with automatic mapping between frameworks. That mapping is a starting point, not an answer. Before you rely on it, check each mapped control against the GDPR article it cites, especially Article 32 and Article 30, because a control that satisfies ISO 27001 does not automatically satisfy a GDPR obligation. Record who reviewed each mapping and when.

Risk registers and treatment links

A GDPR risk register records the processing risks to individuals, their likelihood and impact, and how each risk is treated. eramba links asset, third-party and business risks to treatments through internal controls, policies, exceptions or projects. Use this to show that risk-based decisions under Article 32 were made and reviewed, and confirm that the tool can record the risk owner and review dates you need.

Applied controls and evidence

Tools hold the list of controls you have actually applied, along with the evidence that each one works, such as access review exports, backup restore test records or encryption configuration screenshots. Evidence should be attached to a dated control record. The GDPR does not prescribe a format, but it does require that you can demonstrate compliance to the supervisory authority on request, so an evidence trail matters more than the number of controls listed.

Remediation action plans

When an assessment finds a gap, such as missing encryption at rest for a processing system or no documented retention period, the tool can track the action plan, owner and due date until closure. This matters because regulators look at whether gaps were identified and fixed in a reasonable time, not only at the state of the system on the day of inspection. Confirm whether the tool supports status history, not just a current status field.

Processor and third-party risk

A third-party risk module can track processors, sub-processors and their contract status, including whether a written processor contract under Article 28 is in place and what security assurances the processor has provided. The tool records the register; it does not negotiate the contract, verify a processor's controls on site or decide whether a transfer is lawful. Those tasks stay with your legal and security staff.

Decisions the software cannot make

A tool cannot choose the lawful basis under Article 6, decide whether a legitimate interest assessment passes, judge whether a DPO's advice was followed in good faith, or make a system resistant to attack. Those decisions require named people with authority and documented reasoning. Use the tool to store those decisions and their rationale, and treat any output that looks like a legal conclusion as a draft for review by the DPO and counsel.

Which open-source GDPR tools are worth evaluating?

Two open-source candidates deserve a hands-on evaluation for GDPR work: CISO Assistant and eramba. They sit in different licensing positions, so the first check is legal, not functional. CISO Assistant is released under AGPL-3.0-only for the files outside its top-level enterprise directory, while files inside that directory fall under the proprietary intuitem Commercial Software License and need a contract with intuitem. Confirm which components you would actually deploy by reading the CISO Assistant README and the license file in the same repository before you plan any customization.

For CISO Assistant, the core question is whether its GDPR framework content is current and complete enough to drive your assessment. The platform advertises more than 200 frameworks, including GDPR, with automatic mapping between frameworks. Treat that mapping as a starting point you verify, not a finding you can cite to a regulator. Check the GDPR content against the Regulation text, confirm how records of processing (Article 30) and DPIAs (Article 35) are modeled as objects with their own evidence, and test whether the risk register, applied controls and action plans can hold the records the GDPR expects. Confirm hosting requirements, database and backup needs and upgrade paths in the vendor documentation before committing.

For eramba, the Community edition is free to use, but its license forbids modifying, selling, licensing or otherwise distributing the software, and eramba staff state it should not be called open source. If your plan requires internal changes or redistribution to a service provider, eramba Community will not fit, and a commercial license becomes the realistic path. Within the platform, the risk management module links asset, third-party and business risks to treatments through internal controls, policies, exceptions or projects. Confirm in the eramba Risk Management course and the current license terms whether the modules you need, including processing records and DPIA workflows, exist in the edition you can legally run.

Licensing traps that change what you can deploy

CISO Assistant is an open-core product, so its license depends on which files you are looking at. The community code outside the top-level enterprise directory is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0-only). Files inside the enterprise directory fall under the proprietary intuitem Commercial Software License, and using them requires a contract with intuitem. The split matters because the GDPR framework, risk register and evidence features you plan to use may sit on either side of that line.

Community files: Code outside the enterprise directory is available under AGPL-3.0-only, which carries copyleft obligations if you modify and distribute or host the software for others.
Enterprise files: Code inside the enterprise directory needs a commercial agreement with intuitem, regardless of how you deploy it.
Hosted use by partners: If an implementation partner or processor runs a modified copy for you, confirm how AGPL source-offer obligations and the enterprise terms apply.
Feature mapping: Ask which GDPR-related modules and integrations sit in the enterprise directory before you commit to a design.
Internal changes: Custom connectors or framework content you write may need to be published under AGPL terms, so review the scope with counsel first.

Before you build, read the LICENSE.md file in the project repository and map each module you need to its license location.

Which records the GDPR expects you to keep in writing

The GDPR does not require a specific product, but it does require several records to exist in writing and to be produced for the supervisory authority on request. Each card below covers one record, what it must show, and what to check before a tool is chosen to hold it.

Record of processing activities

Article 30 requires controllers and processors to keep a record of their processing activities, covering purposes, categories of data subjects and data, recipients, transfers and security measures. Article 30(3) and (4) require it to be in writing, including electronic form, and available to the supervisory authority on request. Check that the tool can export the record in a readable form and keep version history of each entry.

Data protection impact assessments

Article 35 requires a DPIA before processing that is likely to result in a high risk to individuals, such as large-scale processing of special categories of data. The assessment must describe the processing, its necessity, the risks and the measures taken to address them. Confirm that the tool links each DPIA to the processing entry it covers and tracks the review dates.

Personal data breach documentation

Article 33(5) requires controllers to document every personal data breach, including its facts, effects and the remedial action taken, whether or not the breach was notified to the supervisory authority. This is a separate duty from the 72-hour notification. Ask whether the tool keeps incident records that cannot be silently deleted and that show who changed each entry and when.

Written processor contracts

Article 28 requires a written contract or other legal act between a controller and each processor, and Article 28(9) confirms that this may be in electronic form. The contract sets out the subject matter, duration, instructions and security obligations. A GRC tool can track which contract covers which vendor and when it expires, but it does not replace the signed agreement itself.

Compelling legitimate interest transfers

Where a transfer to a third country relies on the compelling legitimate interests derogation in Article 49(1), Article 49(6) requires the controller to document the assessment and the suitable safeguards applied. This is a narrow case, so the record should state why no other transfer mechanism was available. Confirm that the tool can hold this assessment as a linked record rather than a free-text note.

What the tool can and cannot hold

A self-hosted tool is a place to store, link and produce these records, and it can hold evidence for them. Responsibility for accuracy, approval and completeness stays with the organization and, where appointed, its DPO. Before selecting a platform, confirm the licence allows your intended use, the data is stored in your own infrastructure, and exports meet the supervisory authority's request for records in writing.

How to roll out a self-hosted GRC tool for GDPR

This sequence takes a self-hosted GRC tool from an agreed scope to a working GDPR evidence set that the controller owns, reviews on a set cadence and can show to a supervisory authority on request.

Confirm scope and roles
The controller's privacy lead and DPO, with the platform owner and the implementation partner if one is engaged, agree which entities, processing activities and processors the tool will cover. They also name who owns each record, who approves changes and who answers for the tool's hosting. The output is a short written scope note with a named owner for every GDPR record area. The step is done when no area is left without an owner.
Select and license the tool after reading its license
Shortlist candidate tools and read each license end to end before installation, including any enterprise directory, commercial component or restriction on modification and redistribution. Confirm with the vendor which features you need, such as a GDPR framework, risk register, evidence storage and a third-party module, and whether they are in the licensed edition. The output is a licensing memo that the legal team has reviewed and a tool choice that fits the scope note.
Deploy the tool inside your own environment
The infrastructure team installs the chosen platform in the organization's own cloud account, data center or network, with access controls, backups and logging set up before production use. Where the GDPR framework is shipped by the tool, the team checks that it loads and that its controls can be seen in the interface. The output is a tested instance and a record of its configuration, which becomes evidence for Article 32 measures.
Load the GDPR framework and processing inventory
Load the GDPR framework into the tool and map your existing controls to it, using the tool's mapping features only where you have checked each link yourself. Build the record of processing activities under Article 30 with the business owner for each activity, including purposes, categories, recipients, transfers and retention. The output is a populated processing inventory with each entry linked to its risks, controls and DPIA where one is required.
Migrate existing records and evidence
Move existing risk registers, DPIAs, processor contracts, breach logs and policies from spreadsheets or shared drives into the tool, keeping original documents as attachments with dates and version numbers. Compare every migrated record against the source to catch gaps, duplicates and lost approvals. The output is a migration log that shows which records moved, who checked them and which items still need signed originals. Processor contracts under Article 28 and transfer documentation under Chapter V should stay traceable to the original signed copy.
Set the review cadence with the DPO
The DPO and the platform owner agree how often each record type is reviewed, who signs off changes and how breach documentation and DPIA reviews are triggered. The schedule should cover the record of processing, retention, processor reviews and access rights requests, so that evidence does not go stale between reviews. The output is a written review calendar and a sign-off workflow configured in the tool, with the DPO's role recorded so that its independence and tasks stay visible.
Hand over evidence and confirm supervisory readiness
Export the complete evidence set in a readable format, check that every record can be produced in writing and in electronic form, and run a walkthrough for staff who will answer a supervisory authority's request under Article 30. Record how backups and access logs are retained so the team can show them later. The output is an evidence index, a handover record signed by the controller's owner, and a list of items the organization still needs to confirm with its own counsel or auditor.

Pitfalls that make open-source GDPR tooling fail

A compliance tool records what the organization decided and shows the evidence behind it, but it cannot make those decisions for the organization. The pitfalls below share one cause: the tool is treated as the compliance programme instead of a place where the programme's records live.

Treating framework mappings as legal advice

Many GDPR tools ship a framework with article-level controls and mappings to other standards. A mapping is a starting point for the organization's own analysis, not a legal conclusion about whether a processing activity is lawful or a measure is appropriate under Article 32. Before relying on a mapping, have the DPO or counsel confirm each control's wording against the regulation text and record who approved it.

Customizing without checking the license

Forking or extending an open-source compliance tool can break its license terms. CISO Assistant's enterprise directory is under a proprietary commercial license, not AGPL-3.0, so code changes there need a contract. eramba Community forbids modifying and distributing the software under its own license terms. Confirm the license file for each component before any change, and keep customizations in documented, separate layers where the license allows.

Letting records fall out of date

The record of processing activities must be kept in writing, including electronic form, and made available to the supervisory authority on request. When a new vendor, feature, data category or transfer appears, the entry has to change with it. Set a named owner for each processing record, tie updates to change management and procurement, and check the tool's last-reviewed dates during each DPO review.

Disconnecting DPIA outcomes from controls

A DPIA that ends in a list of risks but no linked measures is a document, not a control. Each mitigation identified in a DPIA should appear in the tool as an applied control with an owner, an action plan where work remains open, and evidence that it operates. Where high risk remains after mitigation, the outcome also needs to trigger prior consultation with the supervisory authority under Article 36.

Self-hosting without backups or access control

The GDPR tool holds personal data about staff, contractors and processing details, so it falls inside the scope of the organization's own security obligations. Self-hosting it means the organization owns backup, restore testing, encryption, patching and access control for the tool itself. Restrict administrator roles, enforce MFA, log access to records, and test a restore before relying on the instance as the record of compliance.

Questions buyers ask about GDPR compliance software

Can I meet the GDPR with free compliance software?

Free software can support GDPR compliance, but it cannot meet the obligations on its own. The GDPR places duties on the controller or processor: deciding lawful bases, answering data subject requests, securing processing, notifying breaches and documenting decisions. A tool records and organizes that work. Open-source options such as CISO Assistant ship a GDPR framework and can hold risk registers, controls and evidence. eramba Community is free to use, but its license restricts modification and redistribution, so check it against your plans. Effort depends on scope: the number of processing activities, systems and processors you must cover. Confirm that scope in your own environment before choosing a tool.

What work does the GDPR expect the organization to do itself?

The organization owns its compliance, whatever tool it uses. The GDPR expects it to keep a record of processing activities under Article 30, carry out DPIAs for likely high-risk processing under Article 35, document all personal data breaches under Article 33(5) and hold written processor contracts under Article 28(9). Records must be in writing, including electronic form, and available to the supervisory authority on request. Staff still need to decide lawful bases, approve retention rules and review risks. A tool helps store these records. An implementation partner can prepare the system and evidence, but decisions and sign-off remain with your organization.

Is a GRC tool enough to complete a DPIA?

No. A tool can store the DPIA, link it to risks and track remediation actions, but the assessment itself needs a description of the processing, an analysis of necessity and proportionality, an assessment of risks to individuals and the measures chosen to address them. Those judgments come from people with the right knowledge, including your DPO where one is designated. Under Article 36, if high risk remains after mitigation, you must consult the supervisory authority before processing. Ask any vendor exactly which DPIA fields and workflow steps its product provides, and confirm them by testing with a sample assessment.

How does the software license affect changes a partner makes?

The license decides what you and your partner may modify, host and share. CISO Assistant is open core: files outside the top-level enterprise directory are under AGPL-3.0, while files inside it fall under the proprietary intuitem Commercial Software License and require a contract with intuitem. Changes to AGPL-covered code have obligations when the software is offered over a network, so have counsel review your plans. eramba is not open source. Its Community edition license, updated in June 2024, forbids modifying, selling, licensing or distributing the software. Before any customization starts, confirm the license terms in writing for each component.

Can a compliance tool or implementation partner issue a GDPR certificate?

No. The GDPR requires no audit, attestation or certificate. Where certification is used, it is voluntary under Article 42 and issued only by accredited certification bodies or supervisory authorities, for at most three years. Neither a software vendor nor an implementation partner can issue it. Certification also does not reduce the controller's or processor's responsibility for compliance. A partner can prepare systems, controls and evidence for an assessment, and your independent certification body or supervisory authority makes the decision. Ask any provider to state its role in writing.

How much effort does self-hosted GDPR tooling take to run?

Effort depends on scope, and you must confirm that scope in your own environment. Key drivers include the number of processing activities and systems, the number of processors and sub-processors, your hosting model, and how many people will maintain records. Self-hosting adds work your organization or partner must own: installation, access control, backups, upgrades and security testing of the tool itself, since it will hold sensitive records. Costs recur through staff time and hosting, while setup is largely one-time. When requesting a quote from a partner, ask for the scope, deliverables, handover steps and what ongoing support covers.

Which GDPR records must the tool be able to export for a regulator?

Your tool should export the records the GDPR expects you to produce on request: the record of processing activities under Article 30, DPIAs under Article 35, breach documentation under Article 33(5), processor contracts under Article 28(9) and documentation of transfers relying on compelling legitimate interests under Article 49(6). Records must be available to the supervisory authority on request. Test exports before you rely on them. Confirm in a trial that each record can be produced in a readable, dated and complete form, and keep copies outside the tool so evidence survives an upgrade or migration.

When to bring in an implementation partner

Bring in an implementation partner when the team needs a self-hosted GRC platform built, configured and documented inside its own cloud accounts, data centers or air-gapped network, and lacks the time or platform engineering capacity to do it alongside daily work. DeployOpen plans, implements, customizes, hardens, backs up, upgrades and documents self-hosted open-source platforms in the client's infrastructure, and it prepares systems and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and it does not decide what the organization's GDPR controls should be. The organization owns its controls. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any work starts.

Before signing, ask the partner to list every GDPR record the platform will hold and who populates each one. At minimum, that list should cover the record of processing activities under Article 30, DPIAs under Article 35, breach documentation under Article 33(5), and processor contracts under Article 28(9). For each record, confirm whether the partner will only configure the template and import existing data, or will also draft content, and who approves it. Ask in writing which fields the platform will support for each record and whether any of them need manual entry. Also confirm where the evidence is stored, how it is versioned, and how it can be exported for a supervisory authority that asks for it under Article 30(3) and (4).

Agree the sign-off model before the build starts. Decide who keeps DPO sign-off on DPIAs, risk acceptances and the record of processing, and write that decision into the scope document. If the organization uses an outsourced DPO, confirm that the DPO will review the platform's outputs and that the implementation partner's staff will not be asked to make legal determinations. Also confirm who holds the administrator credentials, who approves changes after handover, and how the partner's involvement ends. A written scope that names these roles keeps the organization accountable for its GDPR position and makes any later review or regulator request easier to answer.

GDPR compliance software: open-source and self-hosted options