Why a government open data portal is a different build
A self-hosted CKAN portal fits most ministries, regions and cities that need control over where their data and hosting sit, and the build is shaped less by the software than by who publishes, who approves and which accessibility and security rules apply. A ministry or city with many departments, each holding its own datasets, faces a different problem from a single team running a catalog. The first decisions are the publishing workflow (who drafts a dataset, who checks its metadata and licence, and who has the final say before it goes public), the identity model for staff, and the hosting boundary that defines which infrastructure and operators may touch the data. These decisions carry more weight than the choice between platforms.
On platforms, CKAN is the most common open-source choice for this job. It is licensed under the GNU Affero General Public License v3.0, which means that if you modify CKAN and make the modified version available to users over a network, you must offer those users the corresponding source. Confirm with your legal team how that obligation applies to any custom extensions your suppliers write, and check whether the agency's procurement rules require a particular licence treatment. Other open-source content platforms exist, but a CKAN portal already includes dataset cataloging, a DataStore for structured data and a Data API, which removes much of the custom work a general-purpose CMS would need.
Before you compare vendors, write down three things: the roles each department needs (publisher, reviewer, administrator, read-only partner), the staff identity provider the portal must trust, and the environment the portal must run in, whether a government cloud, a national data center or an air-gapped network. Ask each candidate partner to show how their design maps those answers to CKAN configuration, extensions and infrastructure, and which parts of the accessibility obligation under the ADA Title II rule they will test, with the compliance dates the ADA Title II web and mobile accessibility rule sets for your entity size.
Which legal and security requirements shape the portal build
This table maps each legal or security requirement that can apply to a government portal to its source, its scope, and what it means for the build. Use it to identify which rules bind your body, then confirm applicability with counsel, your security office and your assessor before fixing the architecture.
| Requirement | What it asks for and who it applies to | What it means for the portal build |
|---|---|---|
| ADA Title II web accessibility (WCAG 2.1 Level A and AA) | State and local government web content and mobile apps, including content provided through contracts or licenses. Compliance dates are 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts (28 CFR 35.200). | Make the catalog, search, dataset pages and any vendor-supplied widgets meet WCAG 2.1 A and AA. Confirm which population threshold applies and whether third-party extensions are in scope. |
| NIST SP 800-53 Rev. 5 control baselines | Federal control catalog. SP 800-53B selects 149 controls and enhancements at low, 287 at moderate and 370 at high. Used by federal agencies and by many state and local bodies as a reference. | Choose the baseline that matches your data impact, then map hosting, identity, logging and backup controls to the control IDs your assessor uses. Confirm whether your jurisdiction requires it. |
| FedRAMP scope under OMB M-24-15 | Covers cloud products and services that handle federal information on behalf of an agency. A system used only for one agency's operations on cloud infrastructure and not offered as a shared service is out of scope. | A portal run only for your own agency on your own cloud tenancy may fall outside FedRAMP. A portal offered to other agencies, or hosted by a shared provider, may not. Confirm scope in writing before selecting hosting. |
| FBI CJIS Security Policy v6.1 | Applies where criminal justice information is stored, processed or transmitted. Version 6.1 took effect 26 June 2026 and requires FIPS 140-3 validated modules or AES with at least 256-bit keys, plus vulnerability scanning at least monthly. | Keep any dataset that touches criminal justice information out of the public catalog, or isolate that environment. Specify encryption modules and scan schedules in the hosting and DataStore design. |
| NIST SP 800-171 for CUI on non-federal systems | 32 CFR 2002.14(h)(2) requires federal agencies to use SP 800-171 when setting CUI safeguards on non-federal systems, unless the CUI category sets other rules. | Applies to federal bodies or contractors that hold controlled unclassified information in the portal. Restricted datasets need access control, logging and separation that match the requirement set. |
| NIS2 Directive (EU) | Covers central government entities of any size and lists public administration as a high-criticality sector. Member States may extend it to local administration. It excludes entities in national security, public security, defense and law enforcement. | Central government bodies should treat the portal as in scope for incident reporting and supply chain security. Local bodies must check national transposition. Confirm the exclusions with legal counsel. |
Which platforms fit public sector open data
Most government portals are judged on how well they publish, describe and exchange datasets, not on how they look. The options below separate a dedicated dataset catalog from the web and learning tools that sometimes sit next to it, so teams can compare them on the requirements that matter.
CKAN as the primary fit
CKAN is an open-source data management system built for data hubs and portals, licensed under AGPL-3.0, and used by catalog.data.gov and open.canada.ca/data. Its DataStore holds structured resource data in PostgreSQL with a read-only user and a Data API for filtering and SQL queries, which suits publication at national scale. Check that your hosting, Solr and Redis setup matches the source install requirements before committing.
DCAT metadata for national exchange
The ckanext-dcat extension provides DCAT-AP v1, v2 and v3 schemas, RDF endpoints and an RDF harvester, so a portal can publish to and import from national or European catalogs. This is what lets datasets appear in other catalogs without manual re-entry. Confirm which DCAT-AP version and national profile your catalog requires, and test the output against it, because the extension supports the schemas but not your local profile rules.
AGPL obligations and counsel review
AGPL-3.0 requires that changes to CKAN, including those made to run it as a network service, are made available to users under the same license. Custom extensions, theme changes and integrations may trigger this depending on how they are built and distributed. Ask counsel to review your procurement model, contractor terms and whether any code will stay private before the build starts.
Drupal inside a wider web estate
Drupal fits when the open data portal must sit within a larger government website with shared navigation, content workflows and accessibility governance. Drupal 11.4.10 and 11.3.19 were released on October 14, 2026, and Drupal 7 support ended on January 5, 2025, so any legacy estate needs a migration plan. Datasets still belong in a catalog like CKAN, with Drupal handling the surrounding pages.
Headless CMS and LMS tools
Headless CMS platforms and learning management systems manage content and courses, but they do not provide dataset metadata, versioned resources, harvesting or DataStore-style query APIs. Using one as the catalog usually means building those capabilities yourself. Treat them as sources of pages or training material that link to the catalog, and confirm with your team which system owns each dataset record.
How publishing workflows differ across departments and roles
The central data office runs the portal as a shared service. It sets catalog standards, decides which organizations exist, and controls the site configuration and extensions. In CKAN, this group usually holds sysadmin rights, which reach every organization and every setting, so the group should stay small and its membership should be reviewed on a regular schedule. Most of its work is configuration, quality checks and harvesting rather than publishing individual datasets.
- Site administration: creates organizations, maintains the metadata schema and manages which extensions are enabled.
- Quality review: checks completeness, licence fields and resource formats before datasets are treated as ready for the public.
- DataStore oversight: decides which uploaded tables are loaded into the DataStore and which downstream tools may query them.
- Catalog exchange: operates harvesters and metadata exports for national or regional catalogs.
Confirm which staff need sysadmin rights in your deployment, and whether CKAN's standard roles cover the central office's duties or whether the partner must add custom controls.
Departmental publishers are the people who create and maintain datasets for their own organization. They should be able to add and update records for their department without seeing or changing another department's content. In CKAN, this is typically modeled with one organization per department and member or editor roles inside that organization. Publishers reach the DataStore through uploads and the loader, with no direct database access, so their work stays inside the portal's controlled paths.
- Dataset creation: adds metadata, resources and licence terms for datasets owned by their organization.
- Resource uploads: uploads files that the loader can convert into DataStore tables for the Data API.
- Draft and private states: keeps datasets hidden until a release decision is made.
- Ownership boundaries: cannot edit datasets in other organizations, which keeps accountability clear in audits.
Confirm how each department's publishing team maps to organizations and roles, including who may delete data, and how staff changes are handled.
Approvers and legal reviewers check that a dataset can be released. They confirm the licence, the personal data assessment, the retention statement and the agreed publication date. CKAN core controls visibility through private and public datasets and supports draft states, but a formal multi-step sign-off is usually built with a review step, an extension or a process outside the portal. The partner should document where that approval is recorded so it can be produced during an assessment.
- Read access to pending content: reviewers see private datasets in their organization without publishing them.
- Release control: moves a dataset from private to public only after sign-off.
- Data checks: reviews sample rows in the DataStore through read-only access, without changing the data.
- Decision record: keeps the approval evidence in a system the auditor can inspect.
Confirm which approval steps your legal framework requires, who signs off each one, and whether the record must be kept inside the portal or in a separate system.
Public users and reusers browse, search, download and query published data. They need no write permissions, and the portal should make read access fast and dependable for anonymous visitors. The DataStore separates roles in the database: the write user loads tables, while the read-only user serves queries. This means a public query path cannot change stored records, even if a query is malformed. Accounts are optional for most reusers, and the partner should decide whether API keys are needed for heavier use.
- Anonymous access: browses and downloads published datasets without signing in.
- Read-only queries: runs filtered searches and SQL queries through the read-only DataStore role.
- API use: calls the Data API for filtering, pagination and full-text search.
- Accessibility: public web content must meet WCAG 2.1 Level AA for state and local government entities serving 50,000 or more people from April 26, 2027.
Confirm how your public query path authenticates, which usage limits apply, and whether your entity falls under the earlier or later ADA Title II compliance date.
How a public sector portal rollout runs in phases
The sequence moves from legal scoping and data inventory through identity, hosting and build to a publishing workflow, migration and go-live, then into long-term support. Each phase closes with a written output that the agency's own security, legal and data owners can sign off before the next one starts.
Scope legal obligations and inventory data
DeployOpen works with the agency's legal, records and data teams to identify which statutes, open data rules and sector duties apply, then builds a data inventory listing each dataset, its owning department, its licence and whether it is open, restricted or withheld. The output is a signed scope document with the dataset inventory, the metadata fields each publisher must complete and the list of decisions the agency still owns. Done means the agency has approved the inventory and the in-scope items are fixed in writing.
Design identity and hosting with security
Together with the agency's security team, DeployOpen maps which roles can publish, edit, approve and only view datasets, how staff sign in through the agency's existing single sign-on, and where the portal will run inside government infrastructure. The design records the hosting location, network zones, backup location, and any control baseline the agency must demonstrate. Done means the security team has accepted the architecture document and the identity model, and the open items have named owners.
Build and install on government infrastructure
DeployOpen installs CKAN from source on the agency's servers or cloud accounts, using Python 3.10 or newer, PostgreSQL 12 or newer, Solr 9 (recommended) or Solr 8, and Redis, with uWSGI and Nginx for production. The DataStore runs with separate write and read-only database users. Done means the staging environment passes the agreed functional checks, configuration is stored as code, and the build is documented well enough for the agency's own staff to reproduce it.
Configure publishing workflow and test accessibility
DeployOpen configures organizations, roles and approval steps for each department, sets up XLoader for loading files into the DataStore, and tests dataset pages, search and downloads against WCAG 2.1 Level AA with manual and automated checks. Findings are logged with severity and fixed before go-live. Done means each department has completed a supervised publishing run and the accessibility test report lists every open issue with an owner. Agencies should confirm their own compliance date with counsel, since the ADA Title II rule sets different dates by population served.
Migrate existing datasets and set up harvesting
Existing catalog entries and files are mapped to CKAN fields, cleaned and loaded in batches, with checksums and record counts compared against the source. Where other catalogs must be connected, DeployOpen configures harvesters and, where required, DCAT output through the ckanext-dcat extension. Done means reconciliation reports show matching counts for every batch, and the agency has signed off the migrated records it considers authoritative.
Assemble evidence pack and go live
DeployOpen compiles the evidence the agency's assessors will ask for: configuration records, access control lists, test results, backup and restore logs, vulnerability scan output, the accessibility report and the operating runbook. The pack is prepared for review by the agency's internal assessors or independent auditors, who make their own determinations. Done means the agency accepts the evidence pack, the cutover plan is executed, and the production portal is handed over with a runbook and named support contacts.
Operate, patch and support after launch
After go-live, the agency or a support retainer applies CKAN patch releases, which do not break backward compatibility and exclude schema changes or new features. Minor upgrades are planned separately because they can include backward-incompatible changes. CKAN supports the latest patch of the current minor version and the previous minor version, so the agency should track which minor series it runs. Done means each patch is tested in staging, deployed with a recorded change, and the support scope and response terms are written in the agreement.
Evidence auditors and regulators ask for from the portal
This table maps each piece of evidence that assessors, auditors and regulators typically request to the portal component that produces it. Read each row as a question to answer before go-live: who produces the record, where it lives, and how often it is refreshed. DeployOpen prepares this evidence, but independent auditors or certification bodies issue any assessment, attestation or certification.
| Evidence | Produced by | What the assessor checks |
|---|---|---|
| Access control records | SSO identity provider logs and CKAN organization and role assignments | Who can publish, edit or harvest datasets in each department, and whether leavers were removed |
| DataStore access configuration | Separate read-only and write database users for the DataStore | Public versus restricted resources, and that the read-only user cannot alter stored records |
| Accessibility test reports | Manual and automated WCAG 2.1 AA testing of the portal theme and publishing forms | Conformance to WCAG 2.1 Level AA, with open defects logged and dated against the ADA Title II timeline |
| Control mapping to NIST SP 800-53 or CJIS | Written mapping of portal hosting, identity, logging and backup controls to the chosen baseline | Each control has an owner, an implementation statement and a pointer to the evidence that supports it |
| Vulnerability scan records | Scheduled scans of the CKAN host, Solr, Redis, PostgreSQL and reverse proxy | Scan frequency, findings triage and closure dates; CJIS-scoped portals need at least monthly scanning |
| Patch and version logs | Change records for CKAN core, extensions, operating system and Python dependencies | Current supported CKAN minor and patch level, and proof that outdated patch releases were upgraded |
| Backup and restore tests | Scheduled database, file storage and Solr index backups, plus documented restore exercises | Restore results against a stated recovery point, with dated test logs and named test operators |
| Metadata validation output | DCAT-AP validation of exported RDF from ckanext-dcat before publication | Mandatory fields present, controlled vocabularies used and exports accepted by the national or EU catalog |
What do government teams ask before hiring a portal partner?
What drives the implementation effort for a government open data portal?
The effort is driven by how many departments publish, how many datasets and legacy catalogs must be migrated, how complex the staff sign-in setup is, and how much accessibility remediation the existing public pages need. Each department adds its own publishing roles, approval steps and metadata conventions, so the number of organizations is usually the first thing to pin down. Legacy catalogs add mapping and cleanup work, and SSO adds configuration and testing across identity providers. Accessibility work depends on how many pages and documents fall under the WCAG 2.1 Level AA expectations in the ADA Title II rule. Ask any partner to show how each driver is counted in the written scope before work starts.
What must our own staff provide during a portal project?
Your staff must supply decisions and sign-offs that no implementer can make for you. Data owners in each department confirm which datasets are published, their licences and their update schedules. Approvers define who may publish and who reviews metadata before release. Your security team reviews the hosting design, access model and logging, and gives written sign-off before go-live. Your identity team provides the SSO details and test accounts. Ask the partner to list these roles by name in the plan, with the expected turnaround for each review, so that delays are visible early.
How long does a government open data portal rollout take?
The timeline depends on the agreed scope, and the written plan is the only reliable source for it. The main variables are the number of organizations onboarded, the volume and quality of existing metadata, the migration effort, the SSO integration and the accessibility and security reviews. Phases such as design, pilot with one or two departments, and wider onboarding each have their own dependencies on your staff. Ask the partner for a phased plan with named milestones, the review steps that depend on your teams, and the conditions that would move a date.
Can our staff run the portal themselves after go-live?
Often yes, but only if the roles and procedures are handed over deliberately. CKAN gives administrators, organization editors and dataset editors separate permissions, so day-to-day publishing can stay with department staff. Platform operations, such as database backups, search index maintenance, scheduled jobs and upgrades, need an operator with Linux, PostgreSQL and web server skills. Ask whether the engagement includes documented runbooks, training for administrators and editors, and a clear list of tasks that remain with your operations team or a retained support provider.
How are support, security patches and CKAN releases handled?
Support depends on which CKAN version you run and who applies the changes. CKAN targets about two minor releases a year, supports the latest patch of the current minor version and the previous minor version, and patch releases do not include schema changes or new features. Minor releases may include backwards-incompatible changes, so they need testing in a non-production environment first. For example, CKAN 2.12.0 was released on August 26, 2026, alongside maintenance releases 2.11.6 and 2.10.11. Ask the partner how they track CKAN release notes, test upgrades, apply security patches within your change process, and whether post-launch support is a fixed-scope service or a retainer.
Can the portal run in an air-gapped or sovereign environment?
CKAN is open-source software that can be installed from source inside your own network, so it does not require a vendor-hosted service. A typical stack includes Python 3.10 or newer, PostgreSQL 12 or newer, Solr 9 or 8, Redis, and uWSGI with Nginx in production. Air-gapped installs need offline copies of packages, container images and any extensions, plus a plan for updates delivered through approved media. Sovereign hosting requires that data residency, access by administrators and backups all stay within the jurisdiction your rules require. Confirm the exact package sources, update path and log retention with your security team before choosing an architecture.
Which compliance evidence will the portal help us produce?
The portal can produce configuration records, access role definitions, logs and accessibility test results that your auditors or assessors may review, but it does not certify compliance on its own. Depending on your legal regime, relevant frameworks can include NIST SP 800-53 control baselines for US federal and some state systems, and the WCAG 2.1 Level AA requirement under the ADA Title II rule, which applies to state and local government web content on compliance dates set for April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities. Ask the partner which evidence they prepare and which assessments remain with independent auditors or certification bodies.
What to ask an implementation partner before signing
Start with government hosting experience: ask the partner to name the hosting models it has run for public bodies, including whether it has deployed CKAN inside a ministry or city data centre, a government cloud tenancy or an air-gapped network, and who on its team holds the access those environments require. Ask how it would handle the boundary between its own administrative access and your staff's, and whether it will work under your change control and incident procedures. Ask for references you can verify with the public body concerned, and confirm they are free to describe the scope in general terms.
Next, test the fixed scope itself. A written scope for a portal should list each department and organization that will publish, the dataset types each one will supply, the metadata profile in use, the roles assigned to each (publisher, editor, administrator), the harvesting and API endpoints, and the staff SSO method. Ask the partner to show how datasets are counted and what happens to a new department added after go-live. For accessibility, ask how the partner tests against WCAG 2.1 Level AA: which automated tools it runs, whether it uses manual testing with assistive technology, who signs off the findings, and how defects are tracked to closure. Ask whether the test covers the publisher interface as well as the public catalogue, since both fall under the ADA Title II rule for state and local government web content.
Ask how staff SSO is integrated. Confirm the protocol (for example SAML 2.0 through an extension such as ckanext-saml2auth, or another method the partner has tested), how roles are mapped from the identity provider to CKAN organizations, how accounts are deprovisioned, and what fallback exists if the identity provider is down. Ask for the evidence delivered at handover: configuration records, architecture and data flow documents, backup and restore test results, vulnerability scan reports, accessibility test reports and the operating procedures your auditors will request. Ask which of this material is customized for your assessment and which is generic. Finally, ask for support terms after go-live in writing, including who patches CKAN, the response expectations for security issues, and how CKAN upgrades are planned. CKAN publishes its release policy, so ask the partner how it will track the latest patch of the current minor version and the previous minor version, and how it will schedule the move between minor releases, which may include backwards-incompatible changes.
How DeployOpen scopes and supports a public sector portal
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the agency's or city's own infrastructure. The cards below follow a portal from written scope through testing, evidence and long-term operation, which is where most public sector portal projects succeed or stall.
Fixed scope agreed in writing
Most engagements are fixed-scope, so the publishing workflows, organizations, roles, harvesting targets, metadata profiles and accessibility work are agreed in writing before build starts. Ask for the list of departments and publishers in scope, the number of CKAN organizations and roles, which datasets are migrated and which are only linked, and what counts as acceptance. A quote follows from this written scope rather than from a price list.
Hosting inside government infrastructure
The portal runs in the agency's own cloud account, data center or air-gapped network, so DeployOpen works within the hosting rules the government already applies. Confirm early which environment is approved, who holds administrator access, where backups are stored and whether the portal must be isolated from other services. These decisions shape the architecture more than any feature list does.
Staff sign-in and role design
Publishers in each department need single sign-on, and read-only access for the public must stay separate from editorial rights. DeployOpen can integrate identity providers with CKAN and check that roles map to the agency's directory groups. Ask which identity protocol the central IT team supports, how deprovisioning works when a staff member leaves, and who approves new publisher accounts.
Security testing of portal and APIs
The public website, the CKAN API, the DataStore query endpoints and any upload paths are tested before launch and after major changes. Testing covers application and API flaws, cloud and infrastructure configuration and the admin interface. Agree the test scope, the retest process and who receives the findings, and confirm that test environments never hold live personal data.
Evidence for compliance assessments
DeployOpen prepares systems, controls and evidence for assessments such as federal or state security reviews, but it does not issue audit reports, attestations or certifications. Independent assessors and certification bodies make those decisions. Ask for the evidence list the assessor will request, including configuration baselines, access reviews, backup restore records and test results, and agree its format before work begins.
Retainers for upgrades and support
After go-live, the portal needs patching, CKAN upgrades, backup checks and accessibility re-testing as the law and the platform change. These are handled under a retainer agreed separately from the build. Ask what response times the retainer commits to in writing, how minor and patch releases are tested before rollout and who is accountable for the hosting layer.
