Open data portal for the US OPEN Government Data Act

It depends on who the portal serves and what kind of service it is, so confirm the answer with your agency's authorizing official before you build. FedRAMP under OMB M-24-15 covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A CKAN catalog that stores public dataset metadata and files for your agency is still federal information in the agency's hands, so the question is whether the hosting arrangement falls inside that scope. Ask your authorizing official to classify the system before you select a cloud account or region.

Possibly, but the answer depends on the cloud service provider, the service model and whether the system is offered as a shared service. The scope rule excludes systems used only for a single agency's operations on cloud infrastructure that are not offered as a shared service. A catalog run for one agency inside that agency's own cloud account may fit that exclusion. If the same platform serves several agencies or the public as a shared service, the exclusion is less likely to apply. Confirm the classification in writing with your authorizing official and your cloud provider's documentation.

A system becomes a shared service when more than one organization relies on the same deployed instance or when a provider offers it to others as a service. Illustrative cases include a catalog that hosts datasets for several bureaus under one operator, a hosted portal sold to other departments, or a managed service where a vendor runs the instance for many customers. A single agency running its own CKAN instance for its own datasets is a different case. Ask your authorizing official to define how your agency's governance, tenancy and any outside operator affect this test.

Yes, in most federal settings the agency's authority to operate process still applies, and the catalog is assessed against NIST SP 800-53 Rev. 5 under the agency's baseline. FISMA and OMB Circular A-130 sit behind that control catalog, and Inspectors General assess agency system security independently. SP 800-53B defines low, moderate and high baselines that select 149, 287 and 370 controls and enhancements respectively. Ask your security team which baseline the catalog's data categorization supports and which control inheritance the hosting environment provides.

The service model determines which parts of the stack the provider authorizes and which parts your agency must assess. Infrastructure, platform and software arrangements divide responsibility differently, and a catalog running on a self-managed virtual machine carries more control ownership than one built on a managed database. Map each component of the CKAN stack, including the web application, the DataStore PostgreSQL databases, the search index and the backup store, to its owner. Confirm with the provider which of those components already carry a FedRAMP authorization at the level your authorizing official requires.

The agency's authorizing official makes the determination, with input from the chief information security officer and the program owner. DeployOpen does not issue FedRAMP authorizations, attestations or certifications, and the cloud provider's own authorization status does not transfer automatically to your deployment. DeployOpen can prepare the system description, data flows, control mapping and evidence the authorizing official will review, and can plan the architecture so the classification question is settled early. Ask for that classification as a written deliverable in the scope before the build begins.

Prepare a short written description of the system, the data it holds, the users it serves and the arrangement under which it runs. Include the cloud account and region, the service model for each component, whether any outside operator administers the instance, and whether other agencies or the public use it. Add the data categories in the portal, such as public datasets, metadata and any operational logs that contain personal information. This package gives the authorizing official enough detail to reach a defensible scope decision and avoids a second review after the build.

The effort depends on how many data assets the agency creates, collects, controls or maintains, and how many of those already have owners and documented metadata. 44 U.S.C. 3511(a) requires each agency head to develop and maintain a comprehensive inventory with a description, variable definitions, access method, last update date, owner and location for each asset. Most of the work is discovery and metadata collection across program offices, not software setup. Ask any partner to break the scope down by system and business unit, and to state which assets are in the first publication and which follow later.

Yes, many teams run CKAN in-house, but the platform has real operating parts: Python, PostgreSQL, Solr, Redis, a web server and a DataStore that needs separate write and read-only database users. The installation guide covers Ubuntu 20.04 and 22.04 for package installs, and source installs work on other systems such as Red Hat, Fedora and CentOS. Check whether your team has the skills to patch, back up and monitor each component, and whether it can keep pace with CKAN's release schedule. An implementation partner can take on some or all of these tasks under a written scope, and the split should be stated in the agreement.

No duration can be stated from the supplied facts, so ask for a timeline tied to your inventory, hosting approval and internal review steps. The path usually runs through installation, metadata setup, a DCAT-US data.json file that lists public datasets and APIs, and submission to the Federal data catalogue that GSA maintains under 44 U.S.C. 3511(c). Hosting and security approvals often set the pace more than the software. Ask a partner to show which steps depend on your agency, and what each milestone needs before it can start.

Data owners need to supply the facts that the inventory and data.json file require: a plain description, field definitions, how the data is accessed, when it was last updated, who is responsible for it and where it lives. They also need to confirm whether each asset is public, restricted or not for release, because only public assets belong in the published catalog. Expect review cycles, since a dataset with unclear ownership or stale update dates will delay publication. Agree on a named contact per dataset and a schedule for updates before the work starts.

CKAN targets about two minor releases a year, and the tech team supports the latest patch of the current minor version and the previous minor version. Patch releases do not break backwards compatibility and exclude schema changes and new features, while minor releases may include backwards-incompatible changes. CKAN 2.12.0 was released on August 26, 2026, with maintenance releases 2.11.6 and 2.10.11 on the same day. Ask whether a support retainer covers patch upgrades, minor upgrades with testing, and rollback. Each minor upgrade needs regression testing of custom extensions such as ckanext-dcat, so budget for that work each cycle.

The authorization timeline depends on the agency's system authorization process under FISMA and NIST SP 800-53, and on whether a cloud service is involved. FedRAMP applies to cloud products that process federal information on behalf of an agency, while a system used only for one agency's operations on cloud infrastructure, not offered as a shared service, is out of scope. Ask your authorizing official and your security office which path applies, which control baseline (low, moderate or high) they will assess against, and what evidence they need. No duration is supplied here, so confirm the schedule with them before committing to a launch date.

The main drivers are the number of data assets, the state of existing metadata, the number of data owners, the hosting model, the baseline your security controls must meet, and how many custom integrations or harvests are needed. Cost is split between one-time work, such as installation, metadata setup and authorization documentation, and recurring work, such as upgrades, backups, monitoring and dataset updates. Ask any quote to list each component, who performs it, what is one-time and what recurs, and which assumptions could change the total. DeployOpen does not publish a price list, and a quote follows from a written, fixed scope.

A fixed-scope engagement sets out, in writing, the deliverables, timelines and responsibilities before work begins, and it should name what happens after go-live. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms inside the client's own infrastructure, and prepares evidence for compliance assessments without issuing audit reports or authorizations. Ongoing support, upgrades and testing are available as retainers. Ask for the support hours, response expectations and the handover of documentation and credentials, so you know what your team owns on day one.