Why self-hosted team chat for the public sector starts with records and sovereignty
For most agencies, self-hosted team chat on infrastructure the agency controls is the usual route once records retention, cryptographic requirements such as those in the FBI CJIS Security Policy, and sovereignty rules apply. Staff, ministers' offices and inter-agency teams want fast messaging, but a chat thread can be a public record, and it can carry controlled information that a US SaaS tenant or a shared cloud region may not be authorized to hold. Moving the platform into the agency's own cloud account, data center or disconnected network puts retention, access logs and encryption keys under the agency's governance instead of a vendor's default settings.
On platforms, the short answer is this. For a single agency that needs SSO, directory sync and compliance features in one product, Mattermost is the common starting point, with its paid tiers gating capabilities such as high availability and FIPS 140-3 compliance. Where agencies must federate with each other or with outside partners, Matrix on Synapse fits better, because federation is built into the protocol and can be restricted to listed domains. The choice depends on which paid features the agency needs and on the deployment constraints covered later on this page, so confirm both before shortlisting. DeployOpen plans, implements and hardens these platforms inside the agency's environment, but it does not issue audit reports or certifications. Those come from independent assessors, and the agency should ask its assessor early which evidence the chat platform must produce.
Which public records, CJIS and FIPS rules shape a team chat build
This table maps the records, criminal justice, control catalog, CUI and accessibility rules that agencies most often raise for team chat to what each one means for the build. Read each row as a question to settle with your security office and records officer before choosing an edition or hosting model.
| Requirement | Source | What it means for the build |
|---|---|---|
| FIPS 140-3 validated modules and AES with at least 256-bit keys for criminal justice information in transit and at rest outside physically secure locations | FBI CJIS Security Policy v6.1, effective 26 June 2026, controls SC-13 and SC-28 | Confirm that the chat server, database, file storage and TLS termination use validated cryptographic modules. Confirm that the FIPS-validated option is available in the edition you plan to run, since Mattermost lists FIPS 140-3 compliance in its Enterprise tier according to its pricing page. |
| Monthly vulnerability scanning of systems that process criminal justice information | FBI CJIS Security Policy v6.1, control RA-5 | Plan scanning for the chat host, container images, database and any Matrix or Mattermost add-ons. Scan results become evidence, so assign an owner and a remediation path for findings. |
| Control baseline selection: low, moderate or high baseline of NIST SP 800-53 Rev. 5 | NIST SP 800-53B, which selects 149, 287 and 370 controls and enhancements for the low, moderate and high baselines | Ask the agency which baseline applies to the chat system. Map each chat control (identity, logging, encryption, backup) to a control ID so the design reads as a control set rather than a feature list. |
| Audit controls that record and examine user activity in systems holding sensitive data | NIST SP 800-53 audit and accountability family; HIPAA-style audit language is a comparable pattern for health agencies | Confirm that message-level audit, admin actions and login events are logged and forwarded to the agency log store. Check which of these events a given edition exposes before committing to a design. |
| Protection of controlled unclassified information on non-federal information systems | 32 CFR 2002.14(h)(2), which points agencies to NIST SP 800-171 unless the CUI category sets other safeguards | If contractors or agency partners post CUI in chat, the hosting environment may need to meet NIST SP 800-171 requirements. Confirm whether the agency applies this to its chat enclave or only to file repositories. |
| Retention and disposition under the agency records schedule and public records law | Agency records schedule and state or federal public records statutes (confirm with the records officer) | Retention is set per channel, team and message type, and legal hold must override deletion. Confirm the retention period for chat messages with the records officer, since public records rules differ by jurisdiction, and test that deletion jobs honor holds. |
| Admin access and privileged account control for the chat platform | NIST SP 800-53 access control family, applied through the selected baseline | Restrict system admin roles to named staff, use SSO with MFA for administrators, and keep break-glass accounts sealed and logged. Confirm which admin role separations the chosen edition supports. |
| Accessibility of web and mobile content provided by or for state and local government, WCAG 2.1 Level A and AA | ADA Title II rule, 28 CFR 35.200; compliance from 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts | Chat clients, web administration pages and any agency-built mobile or web front ends fall within scope when provided under contract or license. Ask vendors and partners for their WCAG 2.1 conformance evidence and include accessibility testing in the rollout. |
How FedRAMP scope decides whether a hosted chat can hold federal information
FedRAMP applies to cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. OMB memo M-24-15, dated 25 July 2024, also sets out the exclusion that matters most for a self-hosted chat: a system used only for one agency's operations on cloud infrastructure, and not offered as a shared service, falls outside the program's scope. For a public sector buyer, the first question is therefore not which chat product is used but who operates the service, for whom, and whether the same instance is offered to other agencies or to outside parties. A shared SaaS chat serving many agencies sits squarely in scope. A single-agency instance on the agency's own cloud tenancy may not, but that conclusion depends on facts the agency has to document, including how the instance is administered and whether any vendor or integrator runs it as a service.
That scope question changes the questions the agency must answer. If the chat will carry controlled information, the agency should map which data classes reach the platform, including messages, uploaded files, search indexes, push notification payloads and audit logs, and confirm whether each class falls under FISMA, CJIS Security Policy or CUI requirements. The agency's authorizing official makes the risk decision, and the agency's Inspector General reviews the agency's system security posture and reports to OMB under FISMA, so the chat's control evidence must be assembled as part of the agency's own package. Ask the implementation partner to produce a data flow diagram, a list of hosting and administrative access paths, and the control mapping against the applicable baseline, with the component owner named for each item.
Do not assume any chat product or hosting arrangement holds a FedRAMP authorization. Authorization status belongs to a specific cloud service offering at a specific impact level, and it is listed by FedRAMP rather than inferred from a vendor's marketing or a license choice. Before shortlisting, ask each vendor and each hosting provider for its current FedRAMP status and authorization boundary in writing, and confirm with the agency's authorizing official whether that status is relevant to the proposed architecture. Where an open-source platform runs in the agency's own tenancy, the authorization question shifts to the infrastructure layer and the agency's own assessment, so the cloud provider's authorization and the chat team's configuration evidence both need to be checked.
Which team chat platforms fit agencies and why
Agencies usually narrow the field by three questions: whether the platform can run fully inside government infrastructure, how it handles identity and retention, and whether the cryptographic modules meet the agency's certification requirements. The four options below answer those questions differently, and the paid edition or build you choose determines which answers hold.
Mattermost for controlled government tenancy
Mattermost ships compiled binaries under MIT and its source under AGPL-3.0 for custom builds, and runs as a single Linux binary backed by PostgreSQL, which keeps the operational footprint small. SSO and AD/LDAP sync start at the Professional plan, while high availability and FIPS 140-3 compliance require Enterprise and air-gapped deployment requires Enterprise Advanced. Confirm which FIPS 140-3 build the vendor will deliver, and whether it covers your hosting environment. The v12.0 release came out on 2026-10-16 with support ending 2027-01-15, so plan for upgrades. v11.7 is an Extended Support Release supported until 2027-05-15, which suits agencies that cannot upgrade every month.
Synapse for federated inter-agency messaging
Synapse, the Matrix homeserver developed by Element, is licensed under AGPL-3.0 and is the option most suited to messaging between agencies that each run their own server. Federation can be restricted through an allow-list of domains, and an empty list disables it entirely, which lets agencies control who they talk to. Commercial AGPL exceptions and the Element Server Suite are available from Element, so confirm with the vendor which support and compliance terms apply. Production deployments require PostgreSQL 14 or newer for version 1.143.0 and later, and the current release is v1.163.0, published October 14, 2026.
Rocket.Chat for mixed open and licensed use
Rocket.Chat is MIT licensed outside its ee directories, which fall under a separate enterprise license, so agencies must map which features they depend on to the code under each license. Its paid tiers and any FIPS or air-gap support should be confirmed in writing, since feature availability differs by edition. Version 8.9.0 was published on October 5, 2026. Ask the vendor whether the features your agency needs, such as directory sync, retention and audit export, sit in MIT code or in licensed code before you commit to a design.
openDesk as the wider workplace context
The digital workplace suite places chat inside a larger stack of files, office, mail, video, wiki and projects under one identity layer. Element is part of the suite's messaging component, but the exact components, versions and their supported configurations must be confirmed with the vendor before an agency relies on them. Ask whether the chat component uses the same identity provider as the rest of the suite, how it aligns with your records and retention rules, and who supports the bundle as a whole. Treat the suite as a decision about the whole workplace rather than the chat product alone.
How federation and identity change the build for each agency model
A single agency with one identity provider usually needs no federation at all. The build centers on connecting the chat platform to the agency's directory so that staff sign in with their existing credentials and leave the system when they leave the agency. On Synapse, single sign-on can use OpenID Connect providers (oidc_providers), SAML2 (saml2_config) or CAS. On Mattermost, SAML, OIDC and AD/LDAP user sync are the relevant paths, and the pricing page places SSO and directory sync in the Professional plan and above. Federation stays off by setting federation_domain_whitelist to an empty list, which disables it, and the federation listener should still be firewalled so that nothing answers on port 8448 by accident.
- Identity path: Confirm which protocol the agency's identity provider speaks and whether group membership, not only login, must control channel access.
- Federation off: An empty
federation_domain_whitelistdisables federation, and the docs recommend firewalling the federation listener as well. - Server name: The
server_namesetting fixes how user IDs such as @user:agency.example are formed, so it must be chosen once and kept stable. - Account lifecycle: Confirm how deprovisioning works when an employee leaves, since sign-in removal alone may not end active sessions or API tokens.
- Retention scope: Confirm which channels and direct messages fall under the agency's records schedule.
Check with the identity team which protocol and attribute mappings they will support, and check with the records officer whether chat is a record that needs retention and export from day one.
A group of agencies or ministries that must message each other needs federation between domains the group controls. Each agency runs its own homeserver under its own server_name, and each homeserver lists the others in federation_domain_whitelist, so that messages only move between known parties. Matrix federation uses port 8448 by default, and delegation lets a user ID such as @user:agency.example be served from another host on port 443, which helps when agencies want their public endpoints behind their own DNS and certificates. Identity still belongs to each agency, so the group must agree how users from one agency are recognized by another without handing over credentials.
- Allow-list design: List only the domains in the agreed group, and review the list whenever an agency joins or leaves.
- Port and delegation: Plan port 8448 reachability between agencies or use delegation to serve federation on port 443.
- Identity mapping: Each agency keeps its own provider, so agree on how display names, roles and departments are shown across domains.
- Retention on both sides: Each agency keeps the copies its own records rules require, so a message exchanged across domains may be retained in more than one place.
- Admin ownership: Name who can change the allow-list and who approves a new partner domain.
Confirm with each agency's identity team how their provider will be trusted or mapped, and confirm with each records officer which copies of cross-agency messages their schedule requires.
An agency that exchanges messages with outside contractors or other governments faces the widest exposure. External parties rarely share a directory with the agency, so the identity path usually relies on guest accounts, separate provider trust or invitation controls, and the federation list must stay narrow. Federation with a foreign or commercial domain also raises questions about who holds the copy of each message and under which law it can be requested. Federation should be enabled only for named domains, with the federation listener firewalled so that only those peers can reach it, and the agency should treat the allow-list as a controlled security decision rather than a convenience setting.
- Named peers only: Add each external domain to
federation_domain_whitelistafter review, and remove it when the contract ends. - Guest identity: Decide whether external users sign in through their own provider, an agency-issued guest account, or a bridge, and document which path applies.
- Network scope: Limit port 8448 reachability to the agreed peers and confirm the firewall rules with the network team.
- Jurisdiction of copies: Confirm where each partner homeserver stores data and which legal processes could reach it.
- Bridges: Any bridge to another platform creates a second copy of history, so review it separately.
Confirm with the identity team how external identities are issued and revoked, and confirm with the records officer whether messages with outside parties fall under a separate retention or disclosure rule.
Which integration points carry the most risk in an agency build
Most failed or delayed agency chat deployments trip on integration points, not on the chat application itself. Identity, storage, records and notifications each touch systems the agency already governs, so each needs an owner and a written decision before the build starts.
Identity and group mapping
Decide which directory is the source of truth for accounts, how SSO is federated, and how directory groups map to team channels and administrator roles. Mattermost lists SSO (SAML, OIDC, OAuth) and AD/LDAP user sync as included from its Professional plan, so confirm the edition before design. Test deprovisioning: a user removed from the directory must lose access to channels and sessions on a schedule your security team accepts. Map roles narrowly so channel creation and system administration are not inherited by every member of a broad group.
PostgreSQL and shared file storage
Treat the database and file store as one design, since the chat server depends on both. Plan a primary PostgreSQL database with read replicas if concurrent load justifies them, and confirm with the vendor which operations are sent to the primary. In a Mattermost high availability cluster, every node must mount the same shared file storage, such as an S3-compatible service or NAS. Local file system storage will not work correctly and risks corrupting files, so this is a hard requirement for any multi-node design.
Records retention and export
Decide how messages, files and edits are retained, how legal hold is applied, and how exports reach the agency's records system in a format the records officer can accept. These requirements come from public records law and agency policy, not from the chat vendor, so write them down first and then test each one against the platform. Ask the vendor which retention, legal hold and export features sit in which edition, and confirm how deleted and edited messages are preserved. Also confirm who may run exports and how those actions are logged.
Mobile push and upgrade path
Push notifications often route through a public gateway, which can expose metadata or content in agency-controlled networks. Design notifications so they signal activity without carrying message text, and confirm how the platform behaves when outbound gateways are blocked. For Synapse deployments, plan upgrades with care: the upgrade notes warn that rolling back can be difficult because of database schema changes between releases. Keep a tested backup and a staging rehearsal before every production upgrade.
How an agency chat rollout moves from pilot to records-ready go-live
This sequence takes an agency from a written records and data boundary to a chat platform that is tested for failover, retains and exports records as the schedule requires, and is kept current on a release rhythm the agency has approved.
Scope the records and data boundary
The agency's records officer, privacy lead, security team and the business owners agree which conversations count as records, which retention schedule applies to each category, and whether any channel may carry criminal justice information (CJI) or controlled unclassified information (CUI). DeployOpen maps the applicable security baseline, such as a NIST SP 800-53 baseline selected under SP 800-53B or the FBI CJIS Security Policy where CJI is in scope, to the chat design. The output is a signed scope document with the baseline, the records schedule per channel type and a clear statement of which data may and may not enter the platform. Confirm with the agency's counsel how the schedule applies to chat before any build begins.
Select the platform and paid edition
Using the scope document, the team compares Mattermost, Rocket.Chat and Matrix with Synapse against the requirements, including records export, federation with other agencies, and mobile push in restricted networks. Each feature the design depends on, such as SSO, high availability, FIPS 140-3 validated cryptography or air-gapped deployment, is checked against the vendor's current edition documentation and written into the quote. The agency signs off the platform, edition, licence terms and the list of features confirmed in writing by the vendor. Where a feature is not confirmed, the decision is recorded as an open risk rather than assumed.
Design identity and federation allow-lists
DeployOpen designs how staff authenticate through the agency's identity provider, how directory groups map to teams and roles, and how guest access is issued. For Matrix deployments, the design sets the server name, federation settings and an explicit list of partner domains allowed to exchange messages, with the firewall rules that match. The allow-list is written as a versioned document that names each partner, the business reason and the owner who approves changes. The agency signs off the identity design and the allow-list, and the security team confirms that the federation listener is restricted to those domains.
Build and harden with audit logging
The platform is deployed in the agency's own infrastructure with the cryptographic modules, protocols and key lengths set to the baseline the agency approved, and FIPS-validated configurations applied where the edition supports them. Audit logging is enabled and forwarded to the agency's log platform, and administrative actions are recorded. Vulnerability scanning runs at least monthly, which is the cadence the CJIS Security Policy v6.1 sets for systems in its scope, and findings are tracked to closure. The output is a hardening record with configuration evidence, the scan schedule and the audit log test results that the agency's security assessor can review.
Migrate and run a controlled pilot
A small pilot group uses the platform for real work under the approved scope, while any history migration from an existing tool is loaded and checked against source counts and sample threads. The team tests that retention rules delete or hold content as designed, that legal hold blocks deletion, and that a compliance export produces the fields the records officer needs in a format the agency can read. Mobile push, notifications and access from managed devices are tested in the agency's network conditions. The output is a pilot report that lists defects, retention and export results, and the agency's decision to proceed or fix and re-test.
Test failover and approve go-live
Before go-live, the team runs failover tests on the high availability design, including loss of an application node, database failover and file storage availability, and records recovery times against the agency's continuity targets. Backup restores are tested against a clean environment, and the communication plan for incidents that affect chat is agreed. The agency signs a go-live approval that references the test results, the records configuration, the federation allow-list and the open risks. Confirm that the paid features needed for high availability are licensed for the production size before testing begins.
Operate on a monthly release rhythm
After go-live, DeployOpen applies vendor releases through a documented change process: each release is reviewed against the security advisories, tested in a staging environment that mirrors production, and deployed in an approved window. The agency and DeployOpen agree a rule for supported version windows, so the platform never runs a server version past the vendor's published support end date, and the upgrade plan is ready before that date. Scans, audit log reviews and retention checks continue on the agreed schedule. The output is a release register, the signed version policy and a quarterly evidence pack for the agency's assessors.
What auditors and records officers ask for and which component produces it
This table maps the evidence that auditors, records officers and authorizing officials typically request from a public sector chat deployment to the component that produces it. Read each row as a question to answer before go-live, and note that DeployOpen prepares the artifacts while independent assessors or the agency's authorizing official decide whether they are sufficient.
| Evidence | Who asks for it | Component that produces it |
|---|---|---|
| Cryptography configuration showing FIPS 140-3 validated modules or AES with 256-bit keys for CJI (SC-13, SC-28) | Agency security officer, assessor reviewing CJIS Security Policy controls | Chat server TLS and database encryption settings, FIPS-enabled build or validated crypto library, key management records. Confirm the validated module certificate with the vendor. |
| Monthly vulnerability scan reports (RA-5) | Assessor, authorizing official, agency ISSO | Scanner configured against the chat hosts, container images and database, with dated reports and remediation tickets. Scan cadence must be at least monthly for CJI systems. |
| Audit logs of user and admin activity (AU family, audit controls) | Inspector general, records officer, HIPAA-style audit reviewers where ePHI is involved | Server audit logging, SIEM forwarding, admin console change logs, retained for the period the agency sets. Confirm which events each edition logs. |
| Retention and legal hold settings with export logs for public records requests | Records officer, public records office, general counsel | Retention policies and legal hold configuration in the chat platform, plus export job records showing who exported what and when. Confirm export coverage for each edition. |
| SSO configuration and periodic access reviews | Identity team, assessor checking account management controls | OIDC or SAML configuration, directory sync settings, and access review exports from the identity provider. Deprovisioning test records support the review. |
| Federation allow-list configuration with change records | Agency CISO, partner agencies, assessor reviewing boundary protection | Homeserver domain allow-list settings, firewall rules on the federation listener, and a dated change log approved by the data owner. |
| Version and patch records against vendor support windows | Assessor, authorizing official, vendor management | Upgrade runbooks, test records, deployed version inventory and support end dates for each release. Confirm the support window for the chosen edition with the vendor. |
What to ask an implementation partner before an agency signs
Start with the boundary. Ask the partner which baseline they design to, and whether that is NIST SP 800-53B low, moderate or high, or a stricter profile set by the agency's authority to operate or by a state framework. Ask them to show, in writing, which chat components hold CJI or CUI (message stores, file uploads, search indexes, backups, push relays and log pipelines) and how each is mapped to control IDs such as SC-13, SC-28 and RA-5 where the FBI CJIS Security Policy applies. The written answer should be a control matrix that names the owner of every mapped control, not a generic statement of compliance. Ask which FIPS 140-3 validated modules the chosen edition uses for TLS, database encryption and file storage, and who verifies that: the partner, the vendor's published documentation, or the agency's own assessor. Mattermost lists FIPS 140-3 compliance among Enterprise plan features, so ask the partner to confirm that the edition and build in scope carry it, and to name the evidence file they will deliver.
Ask how retention, legal hold and public records exports are tested before go-live, not described afterward. The partner should provide a written test script covering retention policies per channel, a hold placed on a named user, an export that a records officer can read without vendor help, and proof that deleted or edited messages are preserved where the records schedule requires it. Confirm which of these depend on a paid edition. For federation, ask how allow-lists are set and reviewed: in Synapse, the federation_domain_whitelist setting restricts federation to listed domains, and the partner should show who approves each entry, how changes are logged, and how the firewall rule on the federation listener is documented. On upgrades, ask for the release calendar the partner will follow, how Mattermost monthly releases and Synapse versions are checked against published support end dates, and whether they will run an upgrade test on a staging copy before each production change.
Finally, ask whether the partner performs air-gapped updates, how packages reach the disconnected network, and who signs off on each one. Ask how WCAG 2.1 Level A and AA are checked for the web and mobile content that sits beside the chat, such as the admin portal, intranet pages and any connected forms, and whether accessibility testing is in the fixed scope or a retainer. Separate the fixed-scope deliverables (architecture, deployment, configuration, hardening, migration, test evidence) from recurring work (upgrades, monitoring, patching, control reviews, retesting), and ask for each recurring item to be priced and time-bounded in the written scope. Ask the partner to state in writing what they will not do, including any attestation or certification, which remains with the agency's independent assessor.
What agencies ask before hiring help with self-hosted team chat
What drives the cost of self-hosted team chat for an agency?
The biggest drivers are the edition, the number of users, the high availability design, and the migration and records work. Chat platforms such as Mattermost sell paid plans, and the features agencies often need sit above the entry tier. The Mattermost pricing page lists SSO and directory sync from the Professional plan, high availability clustering and FIPS 140-3 compliance from Enterprise, and air-gapped deployment in Enterprise Advanced. Other cost components are infrastructure and storage, a one-time migration of existing history, the records integration and testing, and recurring upgrades and support. Ask any partner for a quote that lists each component separately, states which features it depends on, and names who holds each license.
Can our own team run self-hosted chat without a partner?
Yes, if the agency already has operators for PostgreSQL, identity and Linux, and the staff time to apply monthly releases. The platform itself is a manageable application, but the surrounding work is the part that tends to slip. You will need to confirm that the paid features you require, such as SSO, clustering or FIPS 140-3 validated modules, are included in the edition you buy. Confirm the FIPS validation status of the specific build and its cryptographic modules with the vendor and your security team, rather than assuming it from the plan name. A partner can also be engaged for a defined piece of the work, such as the initial build or the records integration, while your team runs the platform.
How long does a public sector chat deployment take?
The duration depends on scope more than on the software. The main variables are the number of users, whether high availability is required, how much history must be migrated, how many integrations and identity sources are involved, and how long the records and security reviews take inside your organization. Agencies often lose more time waiting for sign-off than for technical build. Ask for a written timeline tied to named milestones, and check which dependencies sit with your teams, such as directory changes, firewall approvals and test user availability. A fixed-scope engagement is agreed in writing before work starts, so the timeline should follow from that scope.
What does the agency need to provide during the engagement?
The work needs input from several roles, and naming them early prevents most delays. Typical contributions include a records officer who defines retention periods and export expectations, an identity team that provides SSO and directory access, a security team that approves the architecture and signs off on hardening, and a group of test users who validate messaging, notifications and migrated history. You will also need an accountable owner who can make decisions on scope changes. Ask any partner to list these roles in the written scope with the expected time each contributes, so the agency can plan staff availability before work begins.
Does federation with other agencies change the design?
Yes. Matrix federation lets an agency exchange messages with partner servers, but it also creates a trust decision that affects the whole architecture. In Synapse, the federation_domain_whitelist setting restricts federation to listed domains, and an empty list disables it. The Synapse documentation recommends also firewalling the federation listener, which typically runs on port 8448 by default. Federation also affects identity, retention and moderation, because messages from another server may be stored under a different records regime. Confirm with your records and legal teams which partner domains are approved before the server_name and federation settings are fixed, since changing server_name later is difficult.
Does DeployOpen issue certifications for our chat platform?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. In practice, DeployOpen can help configure access controls, logging, retention settings and documentation so that your assessor has the evidence to review. Ask any partner to state clearly which parts of the work are readiness preparation and which parts depend on an independent assessment, and to name the assessor or accrediting body your agency uses.
Can chat alone meet FedRAMP or CJIS requirements?
No single chat platform meets FedRAMP or CJIS on its own. Whether a service falls under FedRAMP depends on its scope, and FedRAMP's scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency, with some single-agency systems out of scope. For criminal justice information, the FBI CJIS Security Policy sets requirements, including FIPS 140-3 certified modules or AES encryption with 256-bit keys for CJI in transit and at rest outside physically secure locations. Confirm with your agency's authorizing official how the cloud model, data types and hosting location affect the required authorization, and which controls apply to your environment.
How are quotes produced for a chat implementation?
Quotes follow from a written scope. DeployOpen does not publish a price list, and most engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts. To get a comparable quote, prepare a list of users and guest groups, identity sources, high availability needs, air-gap or federation requirements, migration sources and volumes, records and export requirements, and the integrations to be connected. Ask for the quote to separate one-time build work from recurring support, upgrades and retainers, and to state which third-party licenses are excluded. Comparing quotes from several partners is easier when each uses the same written requirements.
How DeployOpen scopes and supports public sector chat
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the agency's own infrastructure. For public sector chat, that means starting from the records, identity and network rules that apply to your organization before any platform is installed.
How we scope
- Written scope covering the chat platform choice, user populations, identity sources and retention rules for your agency.
- Inventory of which federation partners, bridges and external guests the scope includes or excludes.
- Confirmation of the cryptographic and hosting requirements your authority or accreditor expects before design begins.
How we build
- Deployment in your cloud accounts, data center or disconnected network, with the edition your scope requires.
- Configuration of SSO, directory sync, retention settings, audit logging and federation allow-lists to the agreed design.
- Security testing of the deployed platform and its integrations before go-live, with findings tracked to closure.
How we hand over
- Runbooks for administration, backup, restore, upgrades and records export, written for your own operations staff.
- Evidence packages describing configured controls, prepared for your assessors and records officers to review.
- Knowledge transfer sessions with your administrators, followed by a clear list of what remains your responsibility.
How we support
- Ongoing support, upgrades and continuous testing available as a retainer, agreed separately from the initial fixed scope.
- Scheduled review of vendor release notes and support end dates so monthly or long-term releases are planned, not missed.
- Periodic retention and access reviews, with changes handled through the same written scope and change process.
