Open data portal for the EU Open Data Directive and high-value datasets

An inventory that maps every dataset to one of the six high-value categories and to the specific datasets listed in Commission Implementing Regulation (EU) 2023/138 is the first item a reviewer asks for. In CKAN, each dataset is a package with its own metadata record, so the inventory is produced by exporting packages with their organization, tags and a custom field or extra that records the high-value category. Keep the export dated and versioned so you can show what was held when the regulation applied from 9 June 2024. Confirm with your national oversight body whether it expects a specific template, a list of datasets not yet published, or a reasoned exemption for datasets outside scope.

Licence records must show, per resource, a licence that is CC0 or CC BY 4.0, or an equivalent or less restrictive open licence, as the implementing regulation requires. CKAN stores a licence identifier on each dataset, so the evidence is a report that checks the licence field across all high-value packages and flags any dataset that is missing one or uses a different licence. Where a resource carries its own terms, keep those terms in the resource metadata and in the publishing record. Confirm with your legal team which licence identifiers your portal accepts and how exceptions are documented.

Keep dated test results showing that each high-value resource is reachable through an API and, where relevant, as a bulk download, and that the files are machine readable. For tabular resources loaded into the DataStore, the CKAN Data API should return records for filter, search, pagination and SQL queries, and the bulk file should match the source. Use XLoader for loading, since it is the officially supported tool and DataPusher is legacy. Script the checks against the production URLs, store the output with the date and the CKAN version, and repeat them after each upgrade. Confirm which download formats your oversight body accepts as machine readable.

Store the output of a validation run against the DCAT-AP profile your country uses, together with the RDF files it checked. The ckanext-dcat extension provides DCAT-AP v1, v2 and v3 schemas and RDF endpoints, so the evidence is the serialized catalog for each version in use, the validator report and the version of the extension. Record any harvested records from other catalogs separately, since they carry their own quality issues. Confirm with your national metadata authority which DCAT-AP version and national profile it requires, because the requirement differs between member states.

A reviewer will expect a record of the CKAN version in production, the patch level, and the dates of each upgrade and security fix. CKAN targets about two minor releases a year, supports the latest patch of the current minor and the previous minor, and drops outdated patch releases once a newer patch is out. Keep a change log per upgrade with the version installed, the release notes read, the test results after the upgrade, and the rollback plan. CKAN 2.12.0 was released on August 26, 2026, with maintenance releases 2.11.6 and 2.10.11 on the same day. Patch releases exclude schema changes, but minor releases may include backwards-incompatible changes, so the upgrade record must show which type was applied.

Access evidence covers the separate PostgreSQL database that holds DataStore tables, which uses a write user and a read-only user. Logs should show that the public Data API connects through the read-only role, that the write role is used only by the loading process, and that connections and failed attempts are retained for the period your oversight body sets. This evidence comes from the PostgreSQL logging configuration, the web server access logs for the Data API endpoints, and the CKAN activity stream for dataset changes. Confirm the retention period, the log location and who may review the logs with your security and records team before you agree on the monitoring design.

Your national open data authority, the body that supervises your public sector, and your internal audit or records function set what counts as sufficient evidence, so they should confirm the list before you collect it. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent auditors or certification bodies make those decisions. In a fixed-scope engagement, the written scope should name each evidence item, the CKAN component that produces it, the format, the owner and the retention period. Ask the oversight body whether it accepts exported reports, screenshots or only signed records.

The cost splits into one-time work and recurring work. One-time items include scoping the dataset inventory, configuring CKAN, the DataStore and the DCAT-AP mapping, loading and validating the first datasets, and any integration with existing sources. Recurring items include hosting, backups, patching, monitoring and dataset refreshes. The open-source software itself carries no license fee, because CKAN is licensed under the GNU Affero General Public License v3.0. Labor, infrastructure and support are the lines that move. Ask any provider for a quote split into these lines, with the hosting location, support hours and the named source of each recurring item. A written fixed scope lets you compare offers on the same basis.

The timeline depends less on the software than on the readiness of your data. The main drivers are how many of the six categories you hold, how many data owners must be consulted, how clean and documented each source is, and whether files must be converted for the DataStore. Platform setup is usually the shortest part. Ask for a timeline in the written scope with milestones for inventory review, licence decisions, metadata completion, loading, and validation. Use the Commission Implementing Regulation (EU) 2023/138, which applies from 9 June 2024, as the reference for which datasets must be available, and plan backwards from that date.

Most delays come from missing decisions, not missing software. Before work starts, the body should name an owner for each dataset in scope, confirm which of the six high-value categories each dataset falls under, and decide the licence for each dataset. Metadata must also be available: titles, descriptions, update frequency, contact points, and spatial or temporal coverage where relevant. Access to source systems, export formats and a point of contact for data quality questions are also needed. Confirm these inputs in the statement of work so that responsibilities are clear on both sides.

Yes, if the team has the skills and capacity. Running CKAN requires administration of Python, PostgreSQL, Solr, Redis and a web server such as Nginx, along with regular upgrades. CKAN publishes minor releases about twice a year and supports the latest patch of the current minor version and the previous minor version, so an upgrade calendar is essential. Patch releases do not break backward compatibility, but minor releases may. Decide before launch whether your staff will own patching, backups, dataset publication and incident response, or whether a retainer will cover part of that work. Staff time is the cost most often underestimated.

Under Commission Implementing Regulation (EU) 2023/138, high-value datasets must be available for re-use under CC0 or CC BY 4.0, or under an equivalent or less restrictive open licence. CC0 places the work in the public domain as far as the law allows, so re-users need no attribution. CC BY 4.0 requires re-users to credit the source. For a public body, CC BY 4.0 keeps attribution visible, which many agencies prefer, while CC0 removes friction for downstream services. Record the licence per dataset in the metadata, because a single portal often holds datasets under different licences. Have legal counsel confirm the choice for each dataset, especially where third-party rights or personal data are involved.

Validation should run as part of publication, not as a one-off check at the end. The ckanext-dcat extension supports DCAT-AP v1, v2 and v3 schemas, exposes DCAT RDF endpoints and includes an RDF harvester for importing from other catalogs. Test each dataset's exported RDF against the DCAT-AP version your national or European catalog expects, and fix missing mandatory fields before the dataset is released. Confirm with the receiving catalog which profile and version it accepts. Validation adds effort to the metadata stage, so budget time for data owners to complete fields they may not have filled in before.

NIS2 under Directive (EU) 2022/2555 covers central government entities regardless of size and lists public administration as a sector of high criticality. Member States may extend it to local public administration, and it does not apply to entities working in national security, public security, defense or law enforcement. Whether your body is in scope depends on your national transposition and your classification, so confirm this with your national authority or legal team first. If in scope, the portal becomes part of the body's risk management and incident reporting obligations, which adds work for logging, access control, vulnerability management and supplier oversight. Scope this with the provider before the fixed price is agreed.