Open source ERP for public sector: why the function differs here
A public finance director usually needs three things from an ERP at once: budget controls that stop commitments before funds are exceeded, procurement records that show every award followed the rules, and a way to receive supplier invoices in the structured formats the state or EU now requires, all without sending agency data outside national or agency infrastructure. The short answer on platforms is that Odoo Community, Odoo Enterprise and ERPNext can each cover this ground, but the choice depends on three constraints you must settle first: licensing, hosting and support. Odoo Community is LGPL-3.0 licensed, but on-premise Enterprise features, upgrades and extended support require an Enterprise subscription, while ERPNext is GPL-3.0 licensed and self-hosting is free, with support tied to a matching Frappe plan. Confirm with each vendor which features your budget and procurement modules depend on, and which edition they sit in.
Start by writing down where every piece of data must physically live. Odoo's own pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise, and that multi-company, Studio, external API access and custom modules sit in that plan too, so an agency that needs on-premise hosting with multiple entities should confirm that combination in writing before selecting an edition. For ERPNext, confirm which Frappe version your agency will run and whether its support window matches the agency's expected life of the system. Then decide which functions must run with no external calls at all, since some features in any ERP may depend on outside services, and test them in the target network before sign-off.
DeployOpen plans, implements, hardens, integrates and documents self-hosted open-source ERP inside your own infrastructure. It prepares systems, controls and evidence for compliance reviews, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, and the agency's internal audit or external reviewer should agree early which evidence they will request, such as access reviews, change records and configuration baselines. Ask any implementation partner, DeployOpen included, to show how that evidence is produced from the live system rather than assembled by hand after the fact.
Which public sector rules shape the ERP build
This table maps the public sector rules most likely to reach an ERP build, from e-invoice receipt and accessibility to security baselines for criminal justice and defense data. Read each row for what it changes in formats, hosting, logging, scanning and portal design, and check the jurisdiction column first, because several rules apply only to certain bodies or countries. Confirm applicability with your legal and compliance teams before fixing scope.
| Rule | What it means for the build | Where it applies |
|---|---|---|
| EN 16931 and Directive 2014/55/EU (e-invoice receipt) | The ERP must accept structured electronic invoices in the EN 16931 core data model for public buyers, validate them, and route them into payables and approval workflows. Plan for XML syntax validation, retention of the original file, and an audit trail from receipt to payment. | EU member states that have transposed Directive 2014/55/EU for public contracts. Confirm the national syntax and portal each contracting authority requires. |
| NIS2 (Directive (EU) 2022/2555) | Covered bodies need risk management, incident reporting and supply chain security measures. For the ERP, this means hardened hosting, vulnerability management, access logging and a documented patch process for the self-hosted stack. | Central government entities in EU member states regardless of size. Local administration only where a member state extends scope. Excluded for national security, public security, defense and law enforcement entities. |
| ADA Title II web and mobile accessibility (28 CFR 35.200) | Self-service supplier portals, invoice submission forms, employee expense apps and public procurement pages must meet WCAG 2.1 Level A and AA. Budget testing with assistive technology and keep accessibility evidence for each release. | US state and local governments. Compliance deadline is 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts. |
| FBI CJIS Security Policy v6.1 | Where finance records contain criminal justice information, such as payments tied to case files, the ERP needs FIPS 140-3 validated encryption or AES with 256-bit keys, MFA for all users, audit logging, and at least monthly vulnerability scanning. | US criminal justice agencies and contractors with access to CJI. Applies only where CJI enters the finance system, so keep it out of general ledgers where possible. |
| 32 CFR 2002.14 and NIST SP 800-171 (CUI) | Controlled unclassified information in purchase orders, contracts or drawings must be protected on non-federal systems using NIST SP 800-171 requirements, which drives access control, audit logging and boundary definition for the ERP. | US federal agencies setting requirements for CUI, and contractors handling it. Applies only where the CUI category does not prescribe other safeguards. |
| FedRAMP and CMMC cloud limits (32 CFR 170.17(c)(5)) | If the ERP or its hosting is a cloud service holding CUI for a defense contractor, the provider must be FedRAMP Authorized at Moderate or higher or meet equivalent requirements. Self-hosting in your own environment changes which party carries that obligation. | US defense contractors seeking CMMC Level 2. Not relevant to most public bodies that do not handle defense CUI. Confirm with the contracting officer. |
| NIST SP 800-53 Rev. 5 baselines | Federal and some state buyers may ask for control evidence aligned to the low, moderate or high baseline. Expect requests for documented access control, logging, configuration management and vulnerability scanning mapped to control IDs. | US federal systems under FISMA and agencies that adopt the catalog. Many state and local bodies use it as a reference, so confirm the requirement in each contract. |
Which open source ERP fits a public body and why
Public bodies usually shortlist a small set of ERP platforms and then test each against hosting rules, upgrade capacity and support terms. The cards below cover the three options most often considered for Odoo and ERPNext, plus one Java option to evaluate, and state what to confirm before a procurement decision.
Odoo Community as the open core
Odoo Community is the open source core, published under the GNU LGPL version 3, and it covers accounting, inventory, purchasing and other core applications. It is the lowest licensing cost route, but it has no access to the Odoo upgrade service and no Enterprise-only features. Confirm which modules your procurement, budget and reporting processes need, and whether your team can carry upgrades and security patching without vendor help.
Odoo Enterprise for on-premise upgrades
Odoo Enterprise is built on the Community core and adds features such as Studio, mobile apps and the upgrade service, which requires an Enterprise subscription for on-premise use. Only the Custom plan can be hosted on-premise and includes multi-company, Studio, external API access and custom modules. Ask the vendor or partner to confirm the plan, subscription code handling and whether your public body's entities need multi-company setup.
Odoo support windows and version planning
Odoo standard support covers the first three years after a major release, including security updates, and paid extended support afterwards is limited to Odoo.sh for select versions and on-premise. Odoo 17.0 standard support ended in September 2026, so any system still on that version needs a planned upgrade path. Ask how long your chosen version stays supported and who pays for extended support or security patches after that window.
ERPNext on the Frappe framework
ERPNext is licensed under GPL-3.0 and built on the Frappe framework, which is MIT-licensed, and self-hosting it carries no license fee. Frappe's warranty coverage depends on running a listed version with a matching Frappe Cloud support plan, so self-hosted sites rely on partners or internal staff for support. Check that your chosen version is still in its supported window, and ask who applies minor releases and security fixes.
Apache OFBiz as a Java option
Apache OFBiz is licensed under Apache-2.0 and includes ERP, CRM, supply chain and manufacturing resource planning components built on a Java framework. It suits public bodies with an existing Java platform team, but it has a smaller public app ecosystem than Odoo or ERPNext for finance and procurement. Confirm the modules you need against the OFBiz documentation, the skills available to maintain it, and the availability of implementation partners.
Support and hosting scope per option
Each option divides responsibility differently between the software publisher, a partner and your own staff, so the same budget line can cover very different work. Ask each candidate to state in writing who applies upgrades, who handles security patches, who hosts the database and backups, and who answers incidents at night. Procurement teams should compare these answers against the written scope of the implementation partner rather than the license price alone.
How a public sector ERP rollout runs in phases
The sequence turns legal and procurement obligations into a tested, reconciled and supported system, with a signed artifact at each stage so that the public body can show its decisions and evidence at every gate.
Map requirements to legal and procurement obligations
The public body's finance, procurement, IT and records owners work with the implementation partner to list entities, budget structures, approval chains, reporting obligations and the e-invoicing rules that apply to receiving invoices from suppliers. Each requirement is traced to the statute, regulation or internal policy that creates it, and records retention rules are written down alongside it. The step closes when the business owners sign the requirements baseline, which becomes the reference for every later test and change request.
Decide platform and hosting in an architecture record
The team compares Odoo Community, Odoo Enterprise on Custom plan terms, and ERPNext against the signed requirements, and records the choice with its hosting model, identity integration and upgrade path. Hosting options such as the public body's own data center, a sovereign cloud or an air-gapped network are assessed against data location and access rules. Licensing terms and support windows are confirmed in writing with the vendor, since the researched facts show that standard and extended support differ by edition and version. The output is an architecture decision record approved by the security and procurement owners.
Run fit-gap against budget and procurement processes
Consultants walk through each budget, commitment, purchase order, approval and payment process with the people who run it today, and classify every gap as configuration, report, integration or custom development. The public body decides which gaps change its process and which require a custom module, since custom code adds upgrade effort later. The result is a fit-gap register with an owner and a disposition for each item, signed by the finance lead. Ask the partner to show how each custom item would be kept upgradable.
Configure localization and test e-invoice formats
The team configures tax, chart of accounts, number sequences and approval workflows for the jurisdiction, then sends sample EN 16931 invoices through receipt, validation, matching and posting. Test cases cover valid files, malformed files, credit notes and suppliers that send non-compliant data, and each result is logged with the expected outcome. Confirm with the local e-invoicing authority or the public body's legal team which syntax and transmission route they require, because those rules change independently of the ERP. The step closes with signed test evidence for localization and invoice handling.
Migrate data and sign off reconciliation
Opening balances, open purchase orders, open invoices, vendor and employee master data are extracted from the legacy system and loaded in trial batches. Each trial load is reconciled to the legacy ledger by account, fund and period, and differences are explained before the next load. Historical records that must be retained but not used operationally are archived under the agreed retention rules rather than imported. Finance and internal audit sign the reconciliation report, and that signature is the gate for cutover planning.
Test accessibility, security and access controls
Security testers review authentication, role-based access, segregation of duties, logging and encryption against the architecture record, and the accessibility team tests public-facing portals and forms against WCAG 2.1 Level AA where the public body is in scope. Findings are triaged with owners and fixed or formally accepted with a documented risk decision. The output is a test report with remediation status and a list of accepted risks, which the body's auditors and compliance team can use as evidence. DeployOpen prepares these controls and evidence, but independent assessors make any audit conclusion.
Run parallel processing and rehearse cutover
For a defined period, transactions are processed in both the legacy system and the new ERP, and the outputs are compared for totals, approvals, payments and reports. Discrepancies are logged, root-caused and fixed in configuration or data before the next comparison. The cutover checklist is rehearsed on a copy of production, with timings, roles, rollback points and communication steps recorded. The step closes when the finance owner accepts the parallel-run results and approves the cutover checklist.
Cut over at period end and support after go-live
The cutover runs at a period close so that opening balances match the closed legacy ledger, and the reconciliation signed earlier is re-checked against live data before users are released. After go-live, the partner provides hypercare, a defined support route, and a plan for security patches, minor updates and major version upgrades, which the body should confirm against the vendor's current support terms. The output is a cutover record, a post-go-live issue log and an operating runbook held by the public body.
On-premise, government cloud or air-gapped hosting for public finance
Running Odoo or ERPNext in the agency's own data center keeps the database, backups and administrative access under the agency's direct control. The FedRAMP scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency, so a system the agency runs on its own hardware is generally not a FedRAMP question. The controls still apply, though, and the data owner's rules decide what the system must do.
- Licensing for on-premise: Odoo on-premise is available on the Custom plan according to Odoo's pricing page, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. Confirm the edition and plan before design starts.
- Encryption at rest and in transit: Criminal justice information needs FIPS 140-3 validated modules or AES with at least 256-bit keys outside physically secure locations, so the data center's storage and TLS stack must be checked against that requirement.
- Upgrade ownership: Odoo standard support covers three years after a major release on-premise, and the agency carries the upgrade work, including a tested upgraded database before production.
- Logging and access: The agency must produce its own evidence for multi-factor authentication, change management and logs of authorized user activity.
Confirm with the agency's security office and records owner which controls their assessor will test inside their own boundary.
A government or sovereign cloud can host an ERP for a public body when the provider holds the authorization that the data requires. In the United States, FedRAMP applies to cloud offerings that handle federal information for an agency, and systems used only for one agency's internal operations on cloud infrastructure, not offered as a shared service, fall outside that scope. Many public bodies outside the US use national or sovereign authorization schemes instead, and the same questions apply.
- Authorization level: Ask whether the hosting provider holds an authorization at the impact level the data needs. For CJI and CUI in cloud services, the baseline matters, and a defense contractor under CMMC needs FedRAMP Moderate or higher or an equivalent.
- Shared versus single-agency scope: If the ERP is offered as a shared service to several agencies, FedRAMP scope is more likely to apply than for a single-agency deployment.
- Managed Odoo and ERPNext hosting: Odoo.sh and Frappe Cloud are provider-run options, so the provider's authorization and location of data become part of the assessment.
- Contract terms: Confirm data residency, sub-processors, incident notification and audit rights in writing.
Confirm with the data owner which authorization they accept, and get the hosting provider's current authorization package before signing.
An isolated or air-gapped network runs the ERP with no route to the public internet, which limits remote access and external attack paths but moves patching, package delivery and support inside the enclave. Odoo on-premise Enterprise databases are activated with a subscription code, and Odoo documents packaged installers and source installation, so the activation and update flow must be planned for a network without outbound access.
- Offline packages: Plan how security updates, language packs and dependencies reach the enclave through a controlled transfer process with records of what was imported.
- Features that call external services: Some ERP functions, AI features and payment connectors reach outside services. Odoo 20 AI features need credits bought as in-app purchases, so they should be disabled or verified in an isolated design.
- Upgrades without vendor access: Major version upgrades on Odoo Online and Odoo.sh are mandatory every two years, but an isolated deployment upgrades on the agency's schedule, which must still stay within supported versions.
- Test copies: Database duplication with neutralization supports test environments without copying live records to lower-trust zones.
- Vulnerability scanning: CJIS v6.1 calls for scanning at least monthly, which requires a scanner and vulnerability feed that work inside the enclave.
Confirm with the data owner whether CJI or CUI may enter the enclave at all, and how their assessor will review transfers in and out.
Evidence auditors and oversight bodies ask for from the ERP
This table maps the evidence public sector auditors and oversight bodies typically request to the ERP or operations component that produces it. Read each row as a question to answer before go-live: which log, record or test will the assessor ask to see, and who keeps it. DeployOpen prepares this evidence inside the agency's environment, but independent auditors and assessors decide whether it meets the applicable requirement.
| Evidence | Produced by | What to confirm before go-live |
|---|---|---|
| Access reviews and user role listings | Odoo or ERPNext user and role records, reviewed through a documented periodic process | Who runs the review, how often, and whether approvers can see the roles they approve. Confirm the review cadence with the auditor. |
| MFA enrollment and sign-in logs | Identity provider in front of the ERP, connected through LDAP or social login | Native ERP login may not enforce MFA on its own. Confirm that every user path, including API and admin access, goes through the enforced control. |
| Change records for configuration and custom modules | Version control system, deployment pipeline and ticketing records for each release | Approval, test evidence and the release that carried each change. Custom modules must be traceable across upgrades. |
| Audit logs of authorized user activity | ERP activity or version logs, plus server, database and reverse proxy logs forwarded to central storage | Retention period, log integrity protection and who can alter or delete entries. Confirm the logging scope with the assessor. |
| Monthly vulnerability scan results | Scanner output for the ERP host, containers, database and dependencies, retained per scan cycle | Where CJIS applies, scans are expected at least monthly. Confirm the scope, the remediation tracking and the accepted-risk process. |
| Penetration test reports and remediation | Independent test of the ERP application, APIs and hosting, with retest evidence | Test scope, date, tester independence and closure of findings. DeployOpen performs security testing, but reports are reviewed by the agency's assessor. |
| Backup and restore test records | Database and file backups from the hosting environment, with documented restore exercises | Frequency of restore tests, who witnessed them, and whether a restored copy was reconciled to source totals. |
| Retained invoice and payment records | Accounting and invoicing modules, stored electronic invoices and their EN 16931 structured files | Retention period set by the public body and the records law that applies. Confirm storage format, search and the ability to reproduce a record as received. |
What does a public sector ERP implementation cost and need from us?
What drives the cost of a public sector ERP implementation?
Cost is driven by who is paid for what, and by how much of the work is configuration versus custom code. The main components are the software route (Odoo Community is free to self-host, while Odoo Enterprise requires a subscription, and ERPNext self-hosting is free), hosting, fit-gap analysis, configuration, localization and tax setup, data migration, accessibility work on any public-facing pages or portals, training, and yearly upgrade effort. Licenses and subscriptions recur, while fit-gap, configuration, migration and first-time training are largely one-time. Ask for each component as a separate line in a written quote, with the assumptions behind it, including which edition, plan and hosting model are priced. Odoo's pricing page lists per-user monthly prices for its plans, and ERPNext's pricing page lists Frappe Cloud hosting starting at 5 US dollars per month for shared site hosting, so ask vendors to confirm current figures in writing.
How long does a public sector ERP rollout take?
Duration depends on the number of entities and modules in scope, the volume and age of the data to migrate, how many integrations must be built, and how quickly the agency can approve design decisions and test cycles. Public procurement rules, accessibility remediation and the need to run parallel reporting for a full budget period can also extend the schedule. No duration is set by a researched fact here, so ask the implementation partner for a phased plan with milestones, named agency dependencies and a go-live window that avoids period-end and fiscal year-end close. A fixed-scope written agreement, which DeployOpen uses for most engagements, should state scope, deliverables and timelines before work starts.
What does the agency team need to provide during implementation?
The agency needs to provide named business owners for finance, procurement, budget and HR, a decision-maker who can sign off design choices, subject matter experts for each module in scope, and access to legacy systems and data extracts. It also needs an IT contact for hosting, identity integration and network rules, plus staff who can perform user acceptance testing and approve cutover. Ask the partner to list these roles, the hours each one is expected to commit per week, and the decisions that must be made before build starts. Also confirm who owns the e-invoice and tax configuration sign-off, since that output is a compliance record the agency will need to defend.
Can our own staff implement Odoo or ERPNext without a partner?
Staff can self-implement if they have the skills and time to run fit-gap, configuration, testing, data migration and operations, but this is a significant internal commitment for a public body. Odoo documents packaged installers and source installation for on-premise use, and ERPNext can be installed with Docker Compose or manually with the bench command line tool, so the technical install is within reach for experienced platform teams. The harder work is process design, localization, controls and evidence, plus upgrade planning. A useful test is whether your team can maintain the system through a major version change. Ask any partner, including DeployOpen, to separate the work your staff would do from the work they would take on.
How do Odoo and ERPNext support windows affect our planning?
Support windows set how often you must upgrade and what you can plan around. For Odoo, standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, including security updates. Odoo 20.0 has standard support planned until September 2029, Odoo 19.0 until September 2028, and Odoo 18.0 until September 2027. Extended support is limited to Odoo.sh for select versions and on-premise, and security patches are only provided during standard support. Odoo's upgrade service requires an Enterprise subscription for on-premise use. For ERPNext, version 14 reached end of life on January 31, 2026, version 15 is planned to be supported until the end of 2027, and version 16 until the end of 2029. Frappe warranty coverage requires a listed version and a matching Frappe Cloud support plan. Budget upgrade effort for each cycle and confirm which version your go-live will land on.
How are e-invoice format changes handled after go-live?
E-invoice format changes are handled as a controlled change, not a one-off fix. Your public sector ERP must issue and receive invoices that conform to EN 16931, the European standard referenced by Directive 2014/55/EU, and any national syntax or validation rule changes must be tested before production. The implementation partner should document how the invoice template, mapping and validation are versioned, who approves changes, how test invoices are validated against the current rules, and how the change is rolled out and rolled back. Ask whether the e-invoicing component is part of the core ERP or delivered through a separate access point, and what happens when the ERP vendor releases a new version that alters invoice output. Include these responsibilities explicitly in the quote and the support agreement.
What should a written quote for a public sector ERP include?
A usable quote lists scope by entity, module and integration, along with the edition and plan priced, hosting location and model, and the assumptions behind each estimate. It separates one-time costs (fit-gap, configuration, migration, accessibility remediation, training) from recurring costs (subscriptions or per-user fees, hosting, support retainers, yearly upgrades). It should name the data volumes and history to migrate, the number of test cycles, the document deliverables and the acceptance criteria. Ask for a statement of who performs each task, which items depend on agency input, and how change requests are priced. DeployOpen plans, implements, hardens and supports self-hosted platforms in your own infrastructure and provides fixed-scope agreements, but it does not publish a price list, so any figure comes from the written scope.
Does the implementation cover accessibility for public-facing ERP pages?
Yes, if it is written into scope. Under the ADA Title II rule, state and local government web content and mobile apps, including those provided through contracts or licenses, must meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts. Any public-facing supplier portal, invoice submission page or citizen-facing form built on the ERP falls within that assessment, so accessibility testing and remediation should be priced as a separate line. Ask the partner which screens are in scope, how they will test against WCAG 2.1 AA, and what evidence they will hand over. DeployOpen prepares systems and evidence for compliance assessments, but it does not issue audit reports or certifications.
Questions to ask an implementation partner before award
Start with e-invoicing, because it is where public bodies most often find gaps late. Ask the partner how they test EN 16931 format conformance for both sending and receiving, which validation artifacts they run against each release, and who owns the test files and the sign-off. Ask how inbound invoices are checked against purchase orders and budget lines before posting, and whether the test plan covers the national format your jurisdiction accepts, not only the core European syntax. Confirm that the partner will not treat an out-of-the-box connector as proof of compliance without written test results.
Next, press on accessibility and upgrades, two areas that recur for the life of the system. Ask how they verify WCAG 2.1 Level AA on customized screens and portal pages, which tools and manual checks they use, and whether results are delivered as a written report. For on-premise or air-gapped hosting, ask how they deliver updates and upgrade packages into the enclave, who runs the upgrade test database, and how custom modules are kept upgradable across major versions. Ask for the named components they will hand over, such as the upgrade runbook, the module inventory and the test scripts.
Finish with the evidence and the paperwork. Procurement teams should ask for an evidence pack listing configuration exports, role matrices showing segregation of duties between requesters, approvers and payment users, change logs for each configuration and code change, and backup and restore test records. Ask how support is delivered after go-live, including response channels and who holds the admin rights. Request every deliverable, acceptance criterion and timeline in a fixed-scope written statement of work before award, and confirm which items fall under a separate support retainer.
Procurement case for open licensing, by buyer type
Central government bodies usually have the largest procurement teams and the strongest exposure to NIS2, which covers central government entities regardless of size and lists public administration as a sector of high criticality. Open licensing changes the cost structure because the core software carries no license fee, so spending shifts toward hosting, integration, implementation, support and upgrades, which are contracted separately. The main lock-in risk moves from the license to the implementation partner and the custom modules, so exit terms matter as much as price.
- Cost structure: Odoo Community and ERPNext are free to self-host, while Odoo Enterprise is a subscription and Frappe Cloud is a hosting charge. Ask each bidder to price these lines separately.
- Exit rights: Require source code, configuration exports and data extracts in documented formats so the entity can move to another partner.
- NIS2 timing: Confirm with legal counsel how the directive applies to the specific body, since exemptions exist for national security, defense and law enforcement.
- Upgrade path: Odoo on-premise support covers three years after a major release, so budget upgrade work into the contract.
- Accessibility: Check whether the ERP self-service portals fall within scope of the ADA Title II rule for the entity's jurisdiction.
Check whether the bid separates license, hosting, support and exit obligations so that the cost comparison is like for like.
Local authorities and special districts usually run smaller teams with fewer in-house developers, so the open licensing case rests more on avoiding per-user fees across many staff and on keeping a supportable system. The accessibility timing differs here: under the ADA Title II rule, entities serving 50,000 or more people must meet WCAG 2.1 Level A and AA from 26 April 2027, while smaller entities and special districts have until 26 April 2028. This gap affects when resident-facing invoice and payment portals must be ready.
- Timing by size: Entities serving 50,000 or more people face the 26 April 2027 date, while smaller entities and special districts face 26 April 2028. Confirm the population count used by your legal team.
- Contracted web content: The rule covers content provided through contracts or licenses, so the ERP vendor and partner must commit to accessibility in writing.
- Support capacity: Favor a partner with a named support model and a clear handover to in-house staff, since small teams cannot absorb long outages.
- Hosting choice: Compare a local data center or cloud account with Frappe Cloud or Odoo.sh, and record which option the entity can operate.
- Shared services: Ask whether a group of authorities can share one instance and split the cost, and what governance that requires.
Confirm the population figure, the accessibility deadline that applies, and who signs off on the written vendor commitments.
Agencies handling security-sensitive data, such as criminal justice information, controlled unclassified information or federal records, face stricter hosting and evidence rules than general administration. Open licensing helps here because the entity can inspect the code and host the system in its own boundary. However, the hosting decision then becomes the main cost driver, and the evidence burden sits with the agency. Where a cloud service is involved, FedRAMP scope and the CJIS Security Policy set the baseline.
- Encryption baseline: The CJIS Security Policy version 6.1, effective 26 June 2026, requires FIPS 140-3 validated modules or AES with at least 256-bit keys for CJI outside physically secure locations.
- Scanning frequency: The same policy calls for vulnerability scanning at least monthly, which needs tooling and staff time that should be priced in.
- Cloud authorization: FedRAMP covers cloud services that hold federal information on behalf of an agency, so confirm whether a hosting provider falls in scope.
- Control baselines: NIST SP 800-53B defines low, moderate and high baselines of 149, 287 and 370 controls and enhancements, which helps set the procurement scope.
- Evidence: Require the implementation partner to deliver control mapping and logs, while independent assessors and authorizing officials make the formal determinations.
Before issuing a bid, confirm which framework applies to the data class and who in the agency owns the authorization decision.
How DeployOpen scopes and supports public sector ERP
DeployOpen works on fixed-scope engagements where the scope, deliverables and timeline are agreed in writing before any work starts. For a public body, that document is usually the first thing procurement and the security office will read, so it should name the edition or distribution (Odoo Community, Odoo Enterprise or ERPNext), the modules in scope, the entities and currencies, the interfaces to the e-invoicing gateway, identity and budgeting systems, and the hosting location. DeployOpen plans, implements and customizes the system inside the client's own cloud accounts, data center or isolated network, so the ERP database, attachments and backups stay where the agency's data rules require them. Quotes follow from that written scope. DeployOpen does not publish a price list, so the reader should expect the quote to itemize the same components the scope defines.
Beyond the initial build, the work covers hardening, backup and restore testing, upgrades, and documentation written for the people who will have to explain the system later. Hardening includes the parts that matter for public sector review: admin and server-script access, identity integration (for example through the LDAP options documented for Odoo and ERPNext), and logging of privileged changes. DeployOpen also runs security testing against the ERP itself, covering the web interface, APIs and custom modules, and reports findings in a form the agency can route to its own remediation process. Upgrade work is scheduled around the vendor support windows, which a reader should confirm for the chosen version before signing. Ongoing support, upgrades and continuous testing are available as retainers, and the agency should decide early whether it wants that cover or will run the system with its own staff.
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors, assessors or certification bodies make those determinations, so the reader should ask any partner, including DeployOpen, to say which evidence it will produce (configuration baselines, test results, change records, backup logs) and which assessor will review it. Before engaging, the reader should confirm with the relevant authority which framework applies to their data, since requirements such as WCAG conformance for public web content or CJIS controls for criminal justice data change what must be hosted, logged and tested.
