Why an open source phone system for the public sector is a different build
For a public sector agency or municipality, the build is driven by data location, control evidence and support procurement more than by features. Procurement teams will ask where call data and recordings are stored, what evidence the agency can produce that the system is controlled, and who is contractually responsible for patching and after-hours support before they compare feature lists. The telephony itself carries specific obligations: citizen-facing lines need routing and queues that hold up during public hours, staff phones must reach 911 from every office, and multi-site trunks link city halls, public works yards and field offices into one dial plan.
The usual starting point is Asterisk with FreePBX as the telephony core, with ticketing and asset tools around it: a helpdesk such as Zammad, FreeScout or osTicket for citizen requests and staff tickets, and GLPI or iTop to record phones, handsets and circuits. The right mix depends on the agency's data classification and hosting rules, so settle those first. Public records, personal data and criminal justice information each change where recordings can be stored and how they are encrypted. As an illustrative case, if a police records or dispatch line carries criminal justice information, the CJIS Security Policy version 6.1, which took effect June 26, 2026, calls for FIPS 140-3 validated modules or AES with 256-bit keys for that data in transit and at rest outside physically secure locations. Ask your CJIS Systems Officer whether call content counts before you choose a storage design.
Which public sector requirements shape the telephony design
This table maps the federal, criminal justice, accessibility and EU rules most likely to touch an agency or municipal phone system to what each one asks for and how it changes the PBX build. Whether any row applies depends on the data handled, the jurisdiction and the agency's contracts, so confirm scope with counsel and your assessor before designing around a row.
| Requirement | Where it comes from | What it means for the build |
|---|---|---|
| Federal control catalog | NIST SP 800-53 Rev. 5 (Release 5.2.0) with SP 800-53B baselines; the moderate baseline selects 287 controls and enhancements | If the agency adopts this catalog, the PBX, its servers, logs and call recordings need documented control implementations and evidence. Confirm which baseline your authorizing official expects. |
| Federal information security law | FISMA and OMB Circular A-130, which NIST lists as laws behind SP 800-53; Inspectors General assess agency system security | Expect annual independent review of the telephony system as part of the agency's wider security program. Keep configuration baselines, change records and access reviews ready for that review. |
| CUI on non-federal systems | 32 CFR 2002.14(h)(2) and NIST SP 800-171, unless the CUI category sets other safeguards | If calls or voicemail carry controlled unclassified information and run on a contractor or municipal-hosted system, the telephony environment may need SP 800-171 safeguards. Confirm with the agency which CUI categories apply. |
| Encryption of criminal justice information | FBI CJIS Security Policy v6.1 (effective 26 June 2026), controls SC-13 and SC-28; FIPS 140-3 modules or AES with at least 256-bit keys | Calls, recordings and logs that carry CJI need encrypted SIP/TLS signaling, SRTP media and encrypted storage using approved modules. Confirm the cryptographic modules your Asterisk and OS builds use. |
| Vulnerability scanning of CJIS systems | CJIS Security Policy v6.1, control RA-5, which calls for scanning at least monthly | Scan the PBX host, FreePBX web interface and SIP-facing services on a recurring schedule and keep the results. Plan patch windows that match the Asterisk and FreePBX support lifecycle. |
| Accessibility of self-service call paths | ADA Title II rule, 28 CFR 35.200: WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people, and 26 April 2028 for smaller entities and special districts | Where IVR menus are mirrored in web or mobile self-service, such as callback request forms or payment pages, those pages fall under the rule. Test them against WCAG 2.1 AA and document the result. |
| EU public administration | NIS2, Directive (EU) 2022/2555: central government covered regardless of size; public administration listed as a high-criticality sector; Member States may extend to local administration | Agencies in scope need risk management, incident reporting and supply chain controls for telephony. Expect to document vendor support and update processes. Confirm national transposition and whether your entity is covered. |
Which open source platforms fit a government phone and service stack
Each platform below covers one job in the stack: call control, asset records, citizen tickets and voicemail storage. They connect through shared data, so a change to a phone number, device location or mailbox affects more than one system. Decide early which platform owns each record and which license terms your agency can accept.
Asterisk and FreePBX for call control
Asterisk is the PBX engine that handles call routing, queues, IVR and trunk connections. FreePBX is the web administration layer most agencies use to manage extensions, inbound routes and emergency calling settings. Before you build, confirm the Asterisk release line against your support and long-term maintenance requirements, because end-of-life dates drive upgrade cost and risk. Ask the partner which FreePBX release pairs with that Asterisk line and how dial plan changes are tested before cutover.
GLPI or iTop for handset records
Keep an inventory of every handset, softphone and phone number in GLPI or iTop, with the assigned location of each device and a change record for every move. Dispatchable location for 911 depends on these records being accurate, so asset data should feed emergency calling directly. GLPI is licensed under GPL-3.0 and iTop under AGPL-3.0, and both can tie changes to approvals. Confirm which tool your change control process and audit team already use before you add a second system of record.
Zammad or FreeScout for citizen inquiries
Route citizen callbacks and inquiries that start on the phone line into a ticket queue, so every request has an owner and a response record. Zammad and FreeScout are both licensed under AGPL-3.0, which carries source sharing duties if you modify the code and offer it to users over a network. Check whether the ticket system can store caller identifiers under your records schedule and whether it can attach call metadata from your telephony. Set the retention rules for ticket data before go-live.
Stalwart or mailcow for voicemail delivery
Voicemail arrives as audio delivered to a mailbox, so the mail server becomes part of your records system. mailcow is licensed under GPL-3.0, while Stalwart is licensed under AGPL-3.0 with an optional Enterprise License from Stalwart Labs. Confirm which edition gives the support, audit logging and retention features your agency requires. Ask how voicemail messages are retained, deleted and searched, and who can access recordings that contain personal data.
Where the phone platform can run under public sector hosting rules
The agency's own staff run the hosts in a data center or server room that the agency owns or leases and controls directly. The PBX, its media servers and its call data stay in a facility the agency physically controls. Because no cloud provider holds agency telephony data, FedRAMP scope questions usually do not arise for the core system, but the agency still owns patching, backups, physical access and emergency location data.
- Who operates the hosts: Agency IT or a contracted implementer runs the Asterisk and FreePBX servers on hardware the agency controls, with change records kept in agency systems.
- Recordings and CDRs: Call detail records, voicemail and any call recordings are written to agency storage, with retention set by the agency's records schedule and administrative access logged.
- Carrier links: SIP trunks still reach an outside carrier, so the carrier's handling of call metadata and its contract terms need separate review.
- Resilience: Power, cooling and a second site for failover are the agency's responsibility, which matters for emergency and public-facing lines.
- Scope: A system the agency runs itself is generally not a cloud service offered on behalf of an agency, but confirm this with the agency's authorizing official and counsel.
Check who holds physical and administrative access, where backups are stored, and whether any vendor support session can reach call data.
The PBX runs in a cloud region that a provider operates for government or sovereign use, and the agency controls its tenancy, identities and data location. The provider runs the underlying infrastructure, while the agency or its implementer configures the telephony platform inside that tenancy. This model reduces the hardware the agency must manage, but it adds a third party to the chain of custody for call data, so the agency needs written answers on where that data lives and who can reach it.
- Who operates the hosts: The provider operates the physical and hypervisor layers, and the agency or its implementer operates the PBX software, dial plans and monitoring.
- Recordings and CDRs: Recordings and call detail records sit in storage volumes or buckets in the government region, so confirm whether backups, logs and support copies replicate elsewhere.
- Encryption keys: Confirm who holds the keys and whether the cryptographic modules meet the FIPS 140-3 requirements that apply when the data is criminal justice information.
- Traffic path: Map how SIP signaling, media and 911 traffic route between the carrier, the cloud region and the agency's sites.
- Authorization: The provider's authorization status is not implied by the region name, so request its current authorization listing and boundary diagram in writing.
Compare the provider's boundary diagram with the agency's own data flow diagram before signing, and confirm the authorization status and baseline directly with the provider.
An implementation partner builds and maintains the PBX inside a cloud account or tenancy that the agency owns. The agency keeps ownership of the account, identity provider, logging and encryption keys, while the partner receives delegated access limited to the agreed scope. DeployOpen works this way, implementing and supporting self-hosted platforms inside the client's own cloud accounts. The main questions are who can reach the environment and whether the partner's service is offered to anyone else.
- Who operates the hosts: The partner deploys and maintains the PBX under a written scope, using named staff whose access the agency can revoke.
- Recordings and CDRs: Data stays in the agency's account, partner access is logged in the agency's logging service, and no copies leave the tenancy without written approval.
- Support access: Use time-limited, approved sessions, with session recording and break-glass accounts controlled by the agency.
- FedRAMP scope: FedRAMP's scope guidance says a system used only for one agency's operations on cloud infrastructure, and not offered as a shared service, is out of scope. If the partner's managed service serves other customers, scope may apply, so confirm this with the agency's authorizing official.
- Commercial terms: The cloud provider bills the agency directly for the account, while the partner's fees follow the written scope.
Confirm who owns the cloud account, where the partner's support tooling stores data, and whether the managed service is offered to other customers.
Why call data location decides the hosting model
Call audio, voicemail, call detail records and caller location data often become regulated records the moment a public agency handles criminal justice information. A recorded call that includes a case number, a name tied to an investigation or a dispatch address can carry CJI, and voicemail left by a victim or witness is treated the same way. Call detail records that show who called which number and when can also reveal investigative activity. Before you design anything, list each data type your phones will create, mark which ones may touch CJI, and record where each one travels and where it is stored. That inventory decides whether the PBX is in scope for the FBI CJIS Security Policy at all.
The current version, CJIS Security Policy v6.1, took effect on June 26, 2026, and requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations. A PBX that carries CJI must meet that bar in every place the traffic and storage run: the SIP and RTP paths between handsets, the PBX, the SIP trunk and the recording and voicemail stores. Confirm with your CJIS Systems Agency and your assessor which encryption modules your SIP stack, media path and storage layer use, and whether the trunk provider's links are covered. Expect to document this as evidence, not assume it.
A hosted or SaaS phone plan can be out of reach for these data types. Its provider may store call audio, voicemail and metadata in regions or subprocessors you do not control, and its encryption modules may not meet the CJIS bar. Before you use any hosted service for agency calls, ask the provider for its written FedRAMP authorization status and its CJIS position, including whether it will sign the CJIS security addendum and where each data type is stored. Self-hosting Asterisk or FreePBX inside your own cloud tenancy or data center keeps those answers in your hands, but it moves the control burden onto your team and your implementation partner.
How the rollout moves from scoping to a documented 911 and citizen line cutover
The sequence turns an agency's data, security and records requirements into a hardened PBX, tested 911 and notification paths, and a citizen line cutover with a rollback plan, each stage closing with a written output. The schedule follows the written scope agreed before work starts.
Scope the environment and classify call data
DeployOpen works with the agency's security officer, records officer and telecom lead to define the sites, user groups, citizen-facing numbers, trunks and the hosting environment, whether that is the agency's own data center, a government cloud tenancy or an air-gapped network. The team classifies what call data exists (call detail records, recordings, voicemail, queue logs) and which retention rules apply to each. The output is a signed scope document with a data classification register and a retention schedule that the records officer has approved. Work does not start until both are in writing.
Select the control baseline for the impact level
The team maps the agreed data classification to a control baseline in NIST SP 800-53B, which defines low, moderate and high baselines, and confirms with the agency's assessor or governing body which baseline applies. Telephony controls are traced to the platform, the hosting layer and the operating processes, and gaps are logged as named items with owners. The output is a control matrix that lists each selected control, the implementing component, the responsible party and the evidence that will be collected. Where state or local rules add requirements, the agency confirms them at this stage.
Build and harden the PBX in the agreed environment
Engineers install Asterisk and FreePBX inside the agreed environment, configure SIP transport and media encryption, restrict management interfaces, set up administrator accounts with multi-factor authentication where the platform supports it, and align logging with the audit requirements from the control matrix. Encryption choices, including the cryptographic modules used for signaling, media and stored recordings, are recorded with the versions and the agency's sign-off, and the agency confirms that these modules meet its own standards. The output is a build record, a configuration baseline and a hardening report that a second engineer has reviewed.
Test 911 location and notification with documented results
The team tests direct 911 dialing from every line type in scope, verifies that the central notification path reaches the designated staff, and checks the dispatchable location data each phone sends for fixed, non-fixed and remote devices. Each test case records the expected result, the observed result, the tester, the date and any corrective action, and the agency's public safety liaison reviews the outcomes. Test results are retested after each change that touches routing or location. The output is a signed 911 test report and a location register that identifies the source of each location value.
Pilot and cut over citizen lines with a rollback plan
Citizen-facing numbers, IVR menus and queues move first in a limited pilot with a set of internal test callers and selected departments, with queue behavior, after-hours routing and voicemail checked against the approved call flows. The cutover runbook names the order of number porting or forwarding, the trigger for each step, and the rollback steps that return traffic to the prior system, with a named decision owner. Operations staff rehearse the rollback before the production change. The output is a go or no-go record, a completed pilot log and a rollback rehearsal record.
Hand over runbooks and evidence files
DeployOpen delivers operational runbooks for routine administration, incident response, backups, patching, user provisioning and 911 retesting, and assembles the evidence files that map each control in the matrix to its artifact. The agency's staff are trained on the runbooks and the handover is recorded against the scope. The output is a handover package with the control matrix, configuration baseline, test reports, change log and runbooks, stored in the agency's own repository. Ongoing support, upgrades and retesting can be scoped separately as a retainer if the agency wants them.
What auditors and oversight bodies ask to see from the phone platform
This table lists the evidence items an assessor usually requests from a self-hosted PBX, what each item proves and which platform component produces it. Read it as a checklist to agree on before build starts, since missing logs or undocumented changes are the most common gaps. DeployOpen prepares these artifacts, and independent auditors assess them.
| Evidence item | What it proves | Component that produces it |
|---|---|---|
| Configuration baselines and hardening records | The PBX, operating system and FreePBX or Asterisk settings match an approved, dated standard, and deviations were accepted in writing | Versioned configuration repository, hardening checklist, sign-off record from the system owner |
| Encryption settings and key length evidence for CJI | Where CJIS applies, SIP/TLS, SRTP and storage encryption use FIPS 140-3 validated modules or AES-256, as the CJIS Security Policy v6.1 requires | TLS and SRTP configuration files, cipher policy, key management records, vendor module documentation where available |
| Vulnerability scan reports at monthly cadence | Scans of the PBX, admin interfaces and ticketing tools run at least monthly where CJIS applies, with findings tracked to closure | Vulnerability scanner output, scan schedule, remediation tickets linked to each finding |
| Administrator access and change logs | Only named, authorized staff administered the PBX, and privileged actions can be traced to a person and time | Asterisk and FreePBX admin audit logs, central syslog, directory group membership reports |
| Call-record and recording access logs | Access to call detail records and recordings is limited to authorized roles and reviewed, supporting the audit controls expected under NIST SP 800-53 | CDR database, recording platform access logs, review records from the data owner |
| 911 test records with location and notification results | Each fixed and non-fixed extension dialed 911 correctly, delivered the registered location and triggered the expected internal notification | Dated test scripts, call logs from the carrier or emergency gateway, notification delivery records, signed results |
| Dial plan and trunk change records | Each change to routing, emergency dialing, trunks or numbers was requested, tested, approved and reversible | Change tickets, dial plan version history, trunk configuration diffs, pre-cutover test results |
| Support contract and patch history | The PBX and its ticketing tools receive supported releases and security fixes, and the agency can name who is responsible for each | Support agreement, Asterisk and FreePBX upgrade records, patch log, incident tickets in the helpdesk system |
| Data residency and call-data location | Call records, recordings and voicemail stay in agency-controlled infrastructure and in the jurisdictions the policy names | Architecture diagram, storage location records, backup and replication configuration, hosting contracts |
Questions to ask an implementation partner before procurement
Start procurement with questions about where call data lives and who can reach it. Ask the partner to describe every system that holds call detail records, recordings, voicemail, SIP logs and provisioning data, the country and facility where each sits, and whether any of it leaves agency infrastructure for vendor tooling, monitoring or support. Then ask how remote administrative access is granted, who approves it, how sessions are recorded, and whether SIP trunks and administrative interfaces are reachable from the internet at all. A partner that cannot answer these in writing is not ready to bid on a government deployment, whatever its PBX experience.
Ask the partner to map its implementation to the control baseline the agency has adopted, whether that is a NIST SP 800-53 low, moderate or high profile or a state framework built on it. Request a control-by-control worksheet that names which controls the partner configures, which the agency owns, and which evidence each produces, such as access reviews, audit log samples and change records. Ask how they test 911 routing and dispatchable location for staff phones, including who places the test calls, which locations are tested, and how results are documented. Finally, ask what support model covers the Asterisk and FreePBX versions in use, who answers after hours, what response is committed in writing, and what evidence the agency receives at cutover. Write every answer into the statement of work so it can be scored against procurement criteria and enforced after award.
What agencies ask about cost, effort and support for open source phone systems
What drives the implementation effort for a public sector PBX?
Effort rises with four factors: the sensitivity of the data the phones will carry, the number of sites and trunks, the 911 design, and how far call data must flow into case or ticket systems. A single headquarters with one trunk and no citizen queues is a small job. A county with dozens of offices, a non-emergency queue, a records system to integrate and a requirement to keep recordings inside government infrastructure is a much larger one. Ask any partner to break the written scope into these four areas so you can see where the hours go. Any figure for effort should appear in the signed scope, not in a verbal estimate.
What does our agency need to provide before a PBX project starts?
The agency carries most of the decisions that determine schedule. Plan to name a telephony owner, a security approver, and a contact for each site and for the carrier. Provide network access to the sites and to the hosting environment, a written data classification for call recordings, voicemail and call detail records, and confirmed change windows, since cutovers usually touch live citizen lines. Also provide copies of current trunk contracts and number inventories so porting can be sequenced. Delays in these inputs tend to move the schedule more than any technical problem, so confirm them in the written scope before work begins.
Can our IT team run an Asterisk or FreePBX system internally?
Yes, if the team has real telephony skills and security skills, not only general server administration. Confirm that staff can configure SIP trunks, dial plans and queues, perform SIP security hardening, manage TLS certificates and monitor call quality. For a public sector deployment, also confirm they can build and document 911 routing tests, run patch cycles on a published lifecycle, and restore the system from backup. If those skills are thin, a partner can cover design, hardening and handover while your staff take over day-to-day operations. Write down which tasks belong to each side before the project starts.
What is one-time and what recurs in an open source phone system budget?
One-time costs cover design, build, configuration, number porting, dial plan migration, testing and documentation, plus any handsets and hardware you purchase. Recurring costs cover the hosting environment, SIP trunks and phone numbers billed by carriers, support and patching, periodic 911 and failover testing, and any commercial add-on licenses. The open source software itself carries no license fee for the core platform, but the modules and support you choose may. Ask every bidder to split the quote into one-time and annual lines, and to list which lines depend on your call volume or number of users.
How does procurement evaluate support for open source PBX software?
Procurement teams usually ask for a named support model, documented response expectations, and evidence that the vendor or partner follows a published release lifecycle. For Asterisk, the lifecycle is published by its maintainers, so confirm which major version you will run and when security fixes stop. Ask the partner how it handles patching, what testing happens before a dial plan change goes live, who answers after hours, and how knowledge transfers to your staff. Request these terms in the written statement of work rather than relying on a general support description. DeployOpen provides support and upgrades as retainers under agreed terms, so ask for those terms in writing.
How do FedRAMP and CJIS requirements affect where we host the PBX?
The hosting choice depends on what data the system carries and whose infrastructure it runs on. FedRAMP applies to cloud products that process federal information on behalf of an agency, and a system used only for one agency's own operations on cloud infrastructure, not offered as a shared service, is generally outside that scope. The FBI CJIS Security Policy applies when the phones carry criminal justice information, and version 6.1 took effect on 26 June 2026 (per the California DOJ bulletin 2026-ISRS-001), requiring FIPS 140-3 certified modules or AES with at least 256-bit keys for CJI outside physically secure locations. Confirm with your information security officer and the CJIS Systems Agency which controls apply before choosing a cloud, data center or on-premises design.
How DeployOpen scopes, builds and supports a government phone system
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the agency's or municipality's own infrastructure. For public sector telephony, that means the PBX, trunks, 911 routing and call records stay under the client's control, with the written scope defining every deliverable before work starts.
How we scope
- Inventory sites, staff phones, citizen lines, queues and existing trunks before any design decision is made.
- Agree in writing which 911 routing, dispatchable location and notification tests are in the engagement.
- Define where call data, recordings and voicemail will be stored and who holds administrative access.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Deploy Asterisk and FreePBX in the client's data center, cloud account or private network as scoped.
- Configure multi-site trunks, dial plans, citizen-facing call routing and queues to the agreed design.
- Harden SIP access, enforce encrypted signaling and media, and restrict administrative interfaces.
- Test 911 call paths and location handling per site, and record the results as evidence.
How we hand over
- Document architecture, dial plans, runbooks and configuration baselines in a form the client's staff can maintain.
- Deliver the test records for 911 and failover scenarios alongside the configuration documentation.
- Walk administrators through routine changes, number management, backups and upgrade procedures.
- Prepare controls and evidence for compliance assessments, while independent auditors issue any formal reports.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan Asterisk and FreePBX upgrades around published lifecycle dates and retest dial plans before cutover.
- Confirm response expectations, maintenance windows and escalation paths in the written support scope.
- Repeat 911 and failover tests after changes to trunks, sites or call routing.
