Open source HR software for public sector organizations

Agencies and municipalities that need HR records, leave and attendance on infrastructure they control can use self-hosted open source HR platforms, provided hosting, identity, access and retention rules are settled first. This page explains which rules matter and which platforms fit.

On this page

Why open source HR software for public sector organizations needs different groundwork

A public sector HR lead usually inherits employee records, leave and attendance data, a payroll run that cannot slip, and an identity estate that already decides who can sign in. Self-hosted Frappe HR, OrangeHRM or Odoo can fit that environment, but only when hosting, access and retention are designed before the software is installed. The platform is rarely the hard part. The hard part is deciding where the records live, who may see them, how long they are kept, and how each decision can be shown to an auditor later.

Public sector HR differs from private sector HR in three ways that change the groundwork. First, the records are often subject to public records rules, so retention schedules and disclosure exemptions must be mapped to record types before go-live. Second, the software is usually bought through open procurement, which means scope, hosting location and support obligations must be written down in the tender file and not left to a vendor's default. Third, inspectors general, internal audit or external auditors may test access controls, change history and payroll outputs, so the audit trail has to exist from the first day of data entry. Confirm each of these with your legal, records and audit owners, because the rules differ by jurisdiction and by agency type.

The short platform answer is this: Frappe HR, OrangeHRM and Odoo can all be self-hosted inside the agency's or municipality's own infrastructure, which keeps employee data under the organization's control. Whether any of them fits depends on the payroll localization you need, the role model your HR and line managers require, and the integrations with the existing payroll and identity systems. DeployOpen plans, implements, hardens and documents these systems and prepares evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies.

Which public sector requirements shape the HR build

This table lists the public sector requirements most likely to change how a self-hosted HR system is hosted, accessed and designed, with the source of each rule. Read each row as a question to settle with your legal, security and records teams before choosing a platform, since many rules apply only when a specific data type, funding source or entity category is present.

Requirement and sourceWhat it asks forWhat it means for the HR build
NIST SP 800-53 Rev. 5 baselines (SP 800-53B)Low, moderate and high baselines select 149, 287 and 370 controls and enhancements respectively, per SP 800-53B for Release 5.2.0.Confirm which baseline your agency or authorizing official requires, then size hosting, logging and access controls to match. Ask your partner to map controls to the chosen baseline.
FISMA oversight by Inspectors GeneralInspectors General independently assess agency system security and report to OMB, per NIST's Risk Management Framework FAQs.Keep system documentation, access reviews and change records in a form an IG assessor can sample, including HR access logs and admin actions.
FedRAMP scope under OMB M-24-15Cloud products that store or process federal information for an agency fall in scope; single-agency systems on cloud infrastructure not offered as a shared service are out of scope.Decide early whether a hosted HR service is a shared offering. Self-hosting in your own cloud account may change the assessment boundary, so confirm with your authorizing body.
CJIS Security Policy v6.1 in HR filesCriminal justice information needs FIPS 140-3 validated modules or AES-256 outside physically secure locations, plus at least monthly vulnerability scanning, per California DOJ bulletin 2026-ISRS-001.Where background check results or police-related leave records touch HR files, segregate them, encrypt at rest and in transit, and schedule scans. Confirm whether your agency is a CJIS-regulated user.
NIST SP 800-171 for CUI under 32 CFR 2002.14(h)(2)Agencies use NIST SP 800-171 when setting protections for controlled unclassified information on non-federal systems, unless the category's authority prescribes other safeguards.If a contractor or outside host runs your HR system, the 800-171 requirements may flow down. Ask the implementation partner how it handles CUI in tickets, backups and support access.
WCAG 2.1 AA for self-service under 28 CFR 35.200State and local web content and mobile apps, including those provided by contract, 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.Test leave requests, payslip views and profile pages against WCAG 2.1 AA before go-live. Vendor-supplied forms and mobile apps count, so include accessibility terms in the scope.
NIS2 coverage of public administration (EU)Central government entities fall in scope regardless of size, public administration is a high-criticality sector, and Member States may extend coverage to local bodies; national security, defense and law enforcement are excluded.Determine whether your body is in scope and whether HR systems fall under your incident reporting and supplier security duties. Document hosting, patching and access controls accordingly.

How hosting and procurement rules decide the deployment

The first decision is whether the self-hosted HR system stays entirely inside the agency's own boundary. If the agency runs Frappe HR, OrangeHRM or Odoo on infrastructure it owns or controls, for its own staff only, the deployment is usually a question of the agency's internal security authorization, not a cloud authorization question. The cloud test is the key check: if a vendor or partner hosts the system as a shared service for multiple agencies or customers, the FedRAMP scope question has to be answered in writing. FedRAMP's scope covers cloud products that process federal information on behalf of an agency, and it excludes systems used only for a single agency's operations on cloud infrastructure that are not offered as a shared service. Confirm with procurement and the agency's authorizing official which category applies before choosing a hosting model, and record the answer in the system security plan.

Support access is the second area where procurement rules bite. Ask who holds administrative and database access, whether a vendor or implementation partner can reach production data remotely, and how each session is approved, logged and revoked. Under a fixed-scope engagement, these terms belong in the statement of work, and the agency should require logs of every privileged session to be retained in its own log store. Also confirm the agency's obligations for any non-cloud service provider, which are assessed within the agency's own scope. For CJI-adjacent or controlled unclassified data, confirm the specific baseline or safeguard set by the governing authority before any hosting decision is final.

Customization choices also depend on the hosting model. In ERPNext, Server Scripts run Python on document events or as API endpoints, and from version 15 they are disabled by default and must be enabled with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them at all, so any custom HR logic such as leave accrual rules, approval routing or attendance validation that depends on Server Scripts cannot run there. If the agency needs that logic, it should either plan for a self-managed deployment with Docker Compose or bench, or confirm that the logic can be built as a controlled app with its own review and change management. Settle this before the requirements are signed off, because it changes both the hosting contract and the build estimate.

Which open source HR platforms fit public sector work

Public sector HR teams usually choose between an application inside a broader ERP and a dedicated HR-only tool, and the licence, release cadence and edition model decide how much of the platform the agency must own. The cards below compare four routes on fit, limits and the payroll and access questions to settle in your own environment before procurement.

Frappe HR within ERPNext

Frappe HR runs as an application inside ERPNext, which is licensed under GPL-3.0 and built on the Frappe Framework under MIT. For agencies, the value is one self-hosted stack for HR, leave, attendance and accounting, with the source available for review. Check that the version you deploy is still supported: v16 is supported until the end of 2029 and v15 until the end of 2027. Confirm payroll localization for your jurisdiction, because payroll rules are not a generic feature. Also confirm how role permissions map to your HR, manager and auditor roles, and whether Server Scripts, which are disabled by default from version 15, are needed for your workflows.

Odoo Community for core HR

Odoo Community is the open source core, published under LGPL-3.0, and it covers employee records, leave and attendance modules that agencies can self-host. It fits teams that want the source under their control and can staff their own upgrades and hardening. The limits are practical: Community does not include the mobile apps, Studio customization, version upgrades and hosting that the licensed Enterprise edition adds. Confirm which HR and payroll functions your country needs are in the Community scope, and whether the agency will run upgrades itself. Also confirm that Odoo 20 AI features require paid credits, so they should not be assumed in a budget.

Odoo Enterprise for mobile and upgrades

Odoo Enterprise is licensed on top of the Community core and adds mobile apps, Studio customization, version upgrades and hosting. For agencies with self-service needs for field staff, such as leave requests from a phone, this edition can be the deciding factor. Procurement should treat the edition fee as a recurring licence line, separate from the one-time implementation. Confirm with the vendor which Enterprise features your deployment depends on, whether mobile access is allowed under your hosting model, and whether the Enterprise hosting option satisfies your data location and access rules. Ask for the terms of the upgrade path in writing before choosing a version.

OrangeHRM for an HR-only scope

OrangeHRM suits agencies that want a dedicated HR system without the accounting, procurement and inventory modules of a full ERP. A narrow scope reduces the number of systems that hold employee data and the number of teams with administrative access. Before you select it, confirm that its payroll support, leave policy engine and attendance capture meet your jurisdiction's rules, and that integration with your accounting and identity systems can be built to your standards. Confirm also how its role-based access handles records for managers, HR staff and external auditors, and how it exports records for retention and audit requests.

Deployment patterns for agencies and municipalities

Running the HR platform in the agency's own data center keeps physical custody, network paths and administrative access under the agency's control. The usual install paths are Docker Compose with the production images from the frappe_docker repository, which bundle MariaDB, Redis, background workers, the scheduler, Socket.io and Nginx, or a manual install with the bench command line tool. The single-file demo setup in that repository is marked for short-lived evaluation only and should not carry employee records.

  • Agency operates: hypervisors, storage, backups, TLS certificates, the identity provider connection and the change calendar for ERPNext or Frappe HR upgrades.
  • Partner operates, under written scope: installation, hardening baseline, configuration of the bench or Compose files, backup and restore testing, and upgrade runbooks, only for the systems named in the statement of work.
  • Evidence to retain: installed image and version records, configuration files under version control, access review records, backup restore test results and change tickets for each upgrade.
  • Lifecycle: Frappe's supported versions page lists which major versions receive support, so the agency should confirm the listed version and support arrangement before go-live.

Confirm with the agency's security office which administrators can reach the database host and whether privileged access is logged centrally.

How a public sector HR rollout runs in phases

The sequence turns a records-retention inventory and a hosting decision into a tested, audited HR system that payroll and identity can rely on, with each phase closing on a named output the agency signs off.

  1. Inventory records and map retention schedules

    Start by listing every HR record type the agency holds, including personnel files, leave, attendance, timesheets, payroll inputs and separation records, and identify the owning office for each. Map each type to its retention schedule as set by the agency's records authority and any applicable federal, state or local rules. Confirm the schedule with the records officer and legal counsel, because the schedules, not the software, decide what must be kept and for how long. The phase closes with a signed records inventory that lists each record type, its schedule, its system of record and its disposition rule at separation. Ask the implementation partner to show how each retention rule will be enforced in the target system, not just documented.

  2. Record the hosting and procurement decision

    Document where the system will run, who operates it, who holds administrator access and which procurement route applies. Cover the hosting boundary, the data location, the support access model and any cloud authorization requirement that applies to the agency's data category. Where the agency handles controlled data, confirm which standard governs non-federal systems and whether a cloud provider must meet a specific authorization baseline. The output is a hosting and procurement decision record approved by the CIO or security lead, with open items assigned to named owners before any build work starts.

  3. Design identity integration and role mapping

    Decide how staff sign in and how roles in the HR system map to the agency's directory groups. For Frappe-based deployments, confirm whether the agency will use LDAP integration, social login keys or both, and test the behavior with the identity team's own directory. Map each HR role, such as HR administrator, payroll clerk, line manager and employee, to a directory group and to the minimum permissions it needs. Confirm that multi-factor authentication applies to every administrator path. The output is an identity design document with a role matrix and a test plan, reviewed by the identity owner and the HR process owner.

  4. Import legacy records in small batches

    Load legacy employee and leave records in batches rather than one large file. The ERPNext Data Import documentation advises importing only a few thousand records at a time, so the team should plan batch sizes with that limit in mind and load into a non-production environment first. Each batch is reconciled against the source extract for record counts, required fields, leave balances and child table rows, and exceptions go to a named data owner. Keep the original extracts under the records inventory's retention rule. The output is a reconciliation report per batch and a sign-off from the HR data owner that the migrated population matches the source.

  5. Run a parallel period with payroll

    Run the HR system alongside the existing payroll process for at least one full pay cycle, using the same inputs, and compare outputs line by line. Differences in leave accrual, overtime, pay codes, deductions and effective dates are traced to their cause before go-live. Where payroll is provided by an external provider or another system, confirm the file or interface format and the exception handling with that provider in writing. The output is a parallel run report listing every variance, its root cause and its disposition, signed by the payroll owner and the finance office.

  6. Test access controls and the audit trail

    Test the role-based access model with real test accounts for each role, confirming that managers see only their own reports, HR staff see only their assigned population and employees see only their own records. Verify that the audit trail records who viewed, changed and exported sensitive records, and that logs are retained and protected from administrator alteration. Check that server-side customizations, including any Server Scripts, are reviewed and that the change process is recorded. The output is a test report with pass or fail results for each role and each audit event, and open defects assigned with target dates agreed in writing.

  7. Cut over and archive the legacy system

    Set a cutover date with the payroll and HR owners, freeze changes in the legacy system, run the final incremental import and confirm the reconciliation totals. Switch identity and self-service access to the new system, keep the legacy system in read-only mode for the retention period set in the records inventory, and export a sealed archive with its access controls documented. The phase closes with a cutover record, a legacy archive manifest and a documented decommissioning plan that the records officer has approved. Confirm with the implementation partner who supports the system after go-live and how upgrades will be tested before they reach production.

Which integrations public sector HR systems usually need

How do public sector HR systems connect to the agency's identity directory?

Most agencies connect the HR system to their existing directory so staff sign in with their normal credentials. In Frappe HR and ERPNext, the LDAP integration documentation covers directory-based sign-in, and social login keys cover federated sign-in through an external identity provider. The data moved is the user identity (username, email, group membership) from the directory into the HR system, and sometimes role mappings. The directory team owns the account source and group design, while the HR team owns which groups map to which HR roles. Confirm with the identity team which attribute is the login key, whether groups or only attributes are read, how disabled accounts are handled, and whether a service account with read-only rights is permitted under the agency's policy.

What payroll data must be exported to the existing payroll provider?

The HR system typically exports employee master data, pay-period attendance and leave, overtime, and pay element changes to the payroll provider, which calculates pay and tax. The payroll team owns the file layout, the cutoff dates and the reconciliation of totals, while the HR team owns the accuracy of source records. Many agencies still run payroll through a separate provider, so the export is often a scheduled CSV or a documented API call rather than a live link. Confirm the exact file specification with the payroll vendor, the cutoff calendar for each pay run, how corrections after cutoff are handled, who signs off on the reconciliation report, and whether the export must be retained as evidence of what was paid.

How does HR data feed the finance system for postings and budgets?

Payroll cost postings, position budgets and headcount figures usually flow from the HR or payroll output into the general ledger or the agency's financial management system. The data moved is summarized cost by fund, cost center, department and pay element, plus position and vacancy counts for budget reporting. The finance team owns the chart of accounts and posting rules, and the HR team owns the position and cost center assignments. Confirm with finance which account codes are used, whether postings are journal-level or summarized, how reversals and retroactive pay are posted, and who approves the batch before it reaches the ledger. If the agency uses an ERP such as Odoo or ERPNext in-house, check whether the HR and accounting modules are part of the same installation.

What training and certification records need to sync with HR?

Mandatory training, licence renewals and professional certifications often need to be tied to an employee record so that compliance checks and role eligibility can be reviewed. The data moved is the course or certificate type, completion or expiry date, issuing body and the employee identifier. The HR or learning team owns the requirement list for each role, while the training provider or internal academy owns the completion evidence. Confirm whether records arrive by file import, by a provider API, or by manual entry, how expiry alerts reach managers, and how long completed training evidence must be kept under the agency's retention schedule. Ask whether certificates are stored as documents in the HR system or only referenced.

Which public reporting exports do agencies need from HR data?

Agencies commonly produce headcount, vacancy, leave liability, workforce composition and pay-band reports for oversight bodies, legislatures and public transparency portals. The data moved is aggregated, and in some cases anonymized, extracts from the HR system. The HR analytics or reporting team owns the report definitions, while legal or information governance owns the decisions about what may be published and at what level of detail. Confirm the mandated report formats and deadlines, the small-cell suppression rules that prevent individuals from being identified, who can run exports, and whether each export is logged. Ask whether reports must be reproducible for a later audit, which affects how report definitions are versioned.

How does joiner-mover-leaver provisioning reach the identity governance tool?

The HR system is usually the source of truth for who is employed and in which role, so joiners, movers and leavers can trigger account creation, access changes and removal in the identity governance layer. A typical pattern feeds HR records into an identity governance tool such as midPoint, which then provisions accounts in a directory such as Keycloak. The data moved is employee identifier, status, department, manager and role or position, with the effective date of each change. The HR team owns the employment events, the identity team owns the provisioning rules and the access entitlements. Confirm the event triggers and their timing, how a rehire is matched to a prior identity, how leave of absence is treated, and how access removal is evidenced for audit.

Which integrations should be confirmed first in a public sector HR scope?

Start with the integrations that gate a pay run or an access decision, because errors there affect staff immediately. In practice this means the payroll export, the identity sign-in path and the joiner-mover-leaver feed, followed by the finance posting feed and then reporting and training links. Agencies should write down each interface with its owner, data fields, frequency, cutoff and evidence before build starts, since the scope is usually fixed in writing before work begins. Ask the implementation partner to document each interface in the agreed scope and to name who in the agency signs off on test results for each one.

Can the agency's own team build these integrations without a partner?

Some agencies have in-house developers who can build simple file exports and directory sign-in, particularly on Frappe HR or ERPNext where LDAP and social login are documented features. The harder work is usually the payroll mapping, reconciliation, provisioning rules and testing against live pay runs, which need both HR and IT sign-off. Server scripts in Frappe are disabled by default from version 15 and must be enabled deliberately, which is a governance decision as well as a technical one. DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside the client's own infrastructure, and most engagements are fixed-scope with the scope agreed in writing before work starts. Confirm internally who will own each interface after handover.

Which evidence auditors and inspectors ask for

This table lists the evidence a public sector assessor or inspector is likely to request for a self-hosted HR and leave system, and the platform component that produces each item. Use it to decide which logs, exports and records must be designed in from the start rather than rebuilt during an audit. DeployOpen prepares this evidence, but an independent auditor or inspector issues any opinion on it.

Evidence itemComponent producing itWhat the assessor checks
Access reviews by roleFrappe HR role permissions, user and role exports, identity provider group membershipWho holds HR, manager and administrator roles, and whether each role still matches the job
Audit logs of record changesFrappe document version history and activity logs, database and reverse proxy logs forwarded to a central storeWho changed an employee, leave or attendance record, when, and from which value to which value
Export and download logsReport and data export records, web server access logs, Data Import historyWhich staff exported employee data, what they took, and whether exports were authorized
Retention schedule mapped to archiveWritten retention schedule, archive jobs or exports of leaver records, storage location and access controlsEach record type has a period, an owner and a tested method to keep it past the system's active life
Backup restore test resultsBackup jobs for the database and file store, restore runbook, restore test logA dated restore into a separate environment, with checks that employee and leave data match the source
Upgrade change recordsUpgrade tickets, test environment results, release notes for the ERPNext version in use such as v16.51.1 or v15.123.0Each upgrade was tested, approved, and reversible, and the version in production is on a supported line
Vulnerability scan resultsScanner reports for the host, containers and Frappe application, remediation trackingScans run on schedule, findings were triaged, and open high-severity items have a documented plan
Penetration test resultsIndependent test report covering the web application, API and access controls, retest evidenceThe test covered employee self-service and manager views, and findings were fixed and retested
Encryption configuration evidenceTLS settings on the reverse proxy, database and storage encryption settings, key management recordsData in transit and at rest is encrypted with approved algorithms and key lengths, and keys are controlled by the agency

What to ask an implementation partner before hiring

Start with procurement and hosting. Ask the partner to show, in writing, how the proposed deployment fits your procurement rules, including whether the agency must buy a commercial edition for features it needs, and which parts of the stack are paid for and by whom. Require a hosting boundary statement that names every location where employee records, backups and logs will sit, and every party that can reach them. Ask for the support access model in the same document: who connects to the production database, through which account, under what approval, and where each session is logged. If the partner cannot produce that logging evidence for a test environment, expect the same gap in production. Next, test the claims that matter most for a public employer. Ask how payroll is localized for your jurisdiction, which tax tables, deduction rules and pay calendars the partner will configure, and who maintains them when rules change. Confirm the identity design: which directory is authoritative, how LDAP or social login is configured, and what happens to a leaver's access in the HR system and in the directory. For self-service screens, ask for WCAG 2.1 Level A and AA test results against the criteria that apply to your entity and the date your obligations start under 28 CFR 35.200, and ask who fixes defects found after go-live. Finally, ask about lifecycle and control. Request the upgrade policy against the Frappe support versions list or the vendor's equivalent, including the end-of-life dates the partner will plan around. Ask for a backup and restore test, run on a schedule and documented with a timed result, not only a backup job log. Ask how Server Scripts are governed: whether server_script_enabled is set, who may author and approve scripts, how changes are reviewed and tested, and whether any script can alter payroll or leave balances without an audit trail.

What do public sector teams ask before a self-hosted HR rollout?

How much does a self-hosted HR rollout cost for a public agency?

The software licence is often the smallest line item, and for ERPNext the self-hosted software itself is free under GPL-3.0, according to the ERPNext pricing page. The cost is paid elsewhere: hosting inside your own cloud or data center, the payroll and localization work for your jurisdiction, integration with your existing payroll and identity systems, data migration, testing, training, and the staff time your HR and IT teams spend. Frappe Cloud shared site hosting starts at 5 US dollars per month, per the same pricing page, but a public sector hosting decision usually moves to your own infrastructure, so ask for that cost separately. One-time work (design, migration, cutover) differs from recurring work (hosting, patching, support, upgrades). Ask every bidder for a fixed-scope quote that lists these components separately.

How long does a self-hosted HR rollout take in a public sector body?

The timeline is set by the number of employee record types, payroll rules, the number of integrations, and how much historical data must move. Payroll cutover is usually the fixed point the rest of the plan works around, so it should be chosen early and tested in parallel runs. Procurement, hosting approval, security review and accessibility testing of self-service pages often take longer than the software configuration itself. Ask each partner for a written schedule with milestones, the staff they need from you, and the assumptions behind each phase. Any duration you are given should trace back to the scope, not to a generic template.

What does the agency's own staff need to provide during the rollout?

Your team needs to supply decisions and data that only the agency can give. Typical inputs include:

  • Approved leave policies, pay rules and collective agreement provisions for each employee group
  • Employee master data extracts and a named data owner who signs off each mapping
  • Access to the current payroll provider, identity directory and accounting system for integration testing
  • Business owners for approvals, reporting and records retention decisions
  • Staff for user acceptance testing and payroll parallel runs in the months before cutover

Delays usually come from slow sign-off on these inputs rather than from technical work. Confirm the list, the named people and the review turnaround in the statement of work before work starts.

Can a public sector IT team run a self-hosted HR system without a partner?

Some teams can, but the answer depends on skills you already have in-house. Running ERPNext, for example, can be done through Docker Compose or the bench command line tool, and the frappe_docker repository provides production images, but production operation also needs database backups, patching, monitoring, and access controls that you must maintain yourself. Frappe's supported versions policy also says that warranty coverage from Frappe requires a listed version and a matching Frappe Cloud support plan. Many agencies keep day-to-day operation in-house and buy a partner for design, payroll localization, integration, hardening and upgrades. Ask any partner which parts you would own after handover and what documentation you receive.

Does FedRAMP apply to a self-hosted HR system used by a state or local agency?

Usually not on its own terms. FedRAMP's scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency, and systems used only for a single agency's operations on cloud infrastructure, not offered as a shared service, are out of scope, according to FedRAMP's scope guidance under M-24-15. Your HR system may still face federal or state requirements if it handles federal grant, contract or criminal justice data, so confirm with your records officer and counsel. If your agency is a defense contractor storing controlled unclassified information, the CMMC rules apply to cloud service use. Ask your partner to map each data type to the rules that govern it before hosting is chosen.

How do WCAG deadlines affect employee self-service pages?

Employee self-service pages for leave requests, payslips and timesheets are state or local government web content, so they fall under the ADA Title II rule. The rule requires 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, according to 28 CFR 35.200. This applies to content provided through contracts or licenses, so configuration and customizations from a partner count too. Ask for accessibility testing of each self-service form and document the results as part of the handover. Confirm the population threshold that applies to your entity with your legal team.

Which security controls should an agency ask for in a self-hosted HR system?

Start with the controls that match your records and access obligations. Role-based access for managers, HR staff and payroll staff, audit logs for changes to employee and pay records, multi-factor authentication for administrators, encryption in transit and at rest, and tested backups are the common baseline. If your state or agency follows NIST SP 800-53 through a state framework, map each control to its baseline (low, moderate or high) using the control catalog, which lists 149, 287 and 370 controls and enhancements for those baselines. Ask for penetration testing before go-live and for the evidence file that proves each control works.

How DeployOpen scopes and supports public sector HR systems

DeployOpen works on a fixed-scope basis for public sector HR deployments. Before any work starts, the written scope sets out which HR modules are in play, such as employee records, leave and attendance, and whether payroll is in scope or handled by an existing system, along with the integrations to the identity directory and payroll, the data migration boundaries, the deliverables and the timelines. Procurement and legal teams can then compare the statement of work against their own requirements and tender rules. Because the scope is written before work begins, the agency knows what it is buying, and the quote follows from that document rather than from a standard package. Items the agency must decide, such as which records are retained in the HR system and which move to an archive, should be listed as client responsibilities in the same document.

Delivery happens inside the client's own infrastructure, whether that is a government cloud tenancy, a data center or an air-gapped network. DeployOpen configures the chosen platform, such as Frappe HR, OrangeHRM or Odoo, for role-based access, hardens the hosts, database and application settings, connects the directory and single sign-on, sets up backups with a restore test, and documents the architecture, runbooks and administrator procedures. Hardening and backup work should be checked against the agency's own baseline, including the control catalog it adopts, for example the NIST SP 800-53 baselines if it operates under federal rules. Agencies should confirm which environment, access paths and logging the assessors will require before the build starts.

Once the system is live, agencies can place the platform under a retainer for upgrades, patching, support and continuous testing. Upgrades are planned around the vendor's supported versions and the agency's payroll and leave calendar, so changes do not land during a pay run. For compliance, DeployOpen prepares systems, controls and evidence, such as configuration records, access reviews, audit log samples and backup test results, that an agency's internal audit, an independent auditor or a certification body can review. DeployOpen does not issue audit reports, attestations or certifications. Agencies should confirm with their assessor which evidence they need, who owns each control and how long records must be retained before signing the statement of work.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.