Mattermost FIPS-compliant images

Which compliance requirements Mattermost FIPS-compliant images help you meet

If your government, defense, justice or regulated team runs Mattermost in Docker, Docker Compose or Kubernetes and must show FIPS-validated cryptography, the FIPS-compliant image addresses the cryptographic module requirement. For criminal justice information, the control facts supplied for the FBI CJIS Security Policy version 6.1 point to SC-13 and SC-28, which call for FIPS 140-3 certified modules or FIPS 197 AES with 256-bit keys for CJI in transit and at rest outside physically secure locations. The same validated-cryptography expectation appears in the NIST-based baselines. The rest of the control set, the authorization decision and the audit remain your organization's responsibility. Before you rely on the image, ask Mattermost which validation certificate covers the exact image tag you run, and record that evidence in your system security plan.

Several other requirements are relevant to the same deployment, but the image does not satisfy them on its own. SP 800-53 Rev. 5 baselines, selected through SP 800-53B at the low, moderate or high level, cover access control, audit, configuration management, contingency planning and many other families, and those controls are design and operating work in your environment. Under 32 CFR 2002.14(h)(2), federal agencies point to NIST SP 800-171 when protecting controlled unclassified information on non-federal systems, unless the CUI category's own authority prescribes other safeguards, so confirm which CUI categories your channels will carry. For CMMC, 32 CFR 170.17(c)(5) sets cloud-service rules for CUI, and a Mattermost server you operate in your own infrastructure is assessed within your own scope. FedRAMP scope under OMB M-24-15 covers cloud services that handle federal information on behalf of an agency, and a single agency's system on cloud infrastructure that is not offered as a shared service falls outside it. Document that boundary explicitly.

NIS2 applies to central government entities regardless of size and lists public administration as a sector of high criticality, but it excludes entities working in national security, public security, defense or law enforcement, and Member States may extend it to local public administration. A defense or justice team may fall outside it entirely, so ask your legal or compliance function which entity category applies before you map NIS2 obligations. WCAG 2.1 Level A and AA under the ADA Title II rule applies to state and local government web content and mobile apps from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts. Internal chat is usually not public web content, but confirm whether any Mattermost-hosted pages, embeds or public channels reach the public, because that content would fall under the rule.

The platform stops at the edge of the cryptographic module. The FIPS image runs Boards, Playbooks and Agents in FIPS mode, but any additional plugins you install keep running in non-FIPS mode, so inventory every installed plugin and decide which ones may touch CJI or other regulated data. Linux package and tarball installations have no FIPS equivalent and cannot migrate in place, so the deployment target must be one of the supported container platforms. From Mattermost v11.7, the PostgreSQL password used by the server must be at least 14 characters when running the FIPS image, which belongs in your secrets and configuration review. Your next steps are to write a boundary statement listing every component that handles regulated data, confirm the validation evidence, and assign owners for monthly vulnerability scanning under RA-5 and the remaining control evidence.

Mapping each requirement to Mattermost capabilities and configuration

This table maps each requirement in scope to what the Mattermost FIPS-compliant image provides, what the platform does not provide, and the configuration your organization must complete. Read the middle column as the platform's contribution and the last column as your work. The main takeaway is that the FIPS image addresses cryptographic module requirements, while vulnerability scanning, control selection, system boundaries and applicability remain with your organization.

Requirement	Platform capability	Configuration needed
CJIS Security Policy v6.1, SC-13 and SC-28: encryption of CJI in transit and at rest	FIPS image runs the server in FIPS mode. FIPS 140-3 compliance is listed for the Enterprise plan.	Deploy the FIPS image, confirm the validation certificate for your exact build, use 256-bit AES keys for storage encryption, and enforce TLS for all client and database connections.
CJIS Security Policy v6.1, RA-5: vulnerability scanning at least monthly	None. Mattermost does not perform scanning of your hosts, containers or database.	Your team schedules monthly scans of the Mattermost hosts, containers, images and PostgreSQL servers, and tracks findings to remediation.
NIST SP 800-53 Rev. 5 control baselines (low, moderate, high)	Supplies inputs only: release notes, deployment guides and configuration options that map to controls.	Select the baseline with SP 800-53B, confirm the control catalog version, and write evidence for each control that applies to your system boundary.
32 CFR 2002.14(h)(2) and NIST SP 800-171: protecting CUI on non-federal systems	Encryption and FIPS mode support some SP 800-171 requirements. The platform does not satisfy SP 800-171 on its own.	Define the Mattermost deployment as the non-federal system, then document access control, audit logging, configuration management and incident handling for your environment.
32 CFR 170.17(c)(5) and FedRAMP: CUI stored or processed by a cloud service in CMMC Level 2	None. FedRAMP applies to the cloud service that hosts or stores CUI, not to the software by itself.	Confirm whether your cloud provider holds FedRAMP Authorized status at Moderate or higher, or equivalent, and record the result for your assessor.
NIS2 applicability to your organization	None. The FIPS image does not determine whether NIS2 applies to an entity.	Confirm your entity type, sector and size with your national competent authority, since NIS2 excludes national security, defense and law enforcement entities.

How Mattermost FIPS-compliant images change a running deployment

For a running Mattermost deployment, moving to FIPS starts with the image reference. From v11, each release ships as a standard Enterprise image and a FIPS-compliant image (published as mattermost/mattermost-enterprise-fips-edition) under the same release tags. On Docker, Docker Compose or Kubernetes, the switch is a change to the image in your deployment definition, followed by a rolling restart of the server containers or pods through your normal change process. Your database, file storage, configuration and user data stay in place. Linux package and tarball installations have no FIPS equivalent and cannot be migrated in place, so those environments need a separate plan before any image change is considered.

Treat the change as a change to a live system and rehearse it on a copy first. Confirm the exact release tag you run today, then confirm that the FIPS image exists under the matching tag in every registry you pull from. If you run a private registry or an air-gapped network, mirror the FIPS image as part of the same release package, since the standard image alone will not give you the FIPS build. Record the current image digest so rollback is a known step. Your change record should name both the old and new image references, the restart order for each node, and who approves a rollback.

Inside the FIPS image, Boards, Playbooks and Agents run in FIPS mode. Any other plugin you have installed still runs, but in non-FIPS mode. That makes your plugin inventory a compliance decision that you make before the image change. Export the list of installed and enabled plugins from the System Console, then classify each one as required and within FIPS mode, required but outside it, or removable. For every plugin that stays outside FIPS mode, record what data it handles, who owns it, and who accepted the residual risk. Review integrations alongside plugins, because a bot or connector outside FIPS mode may still touch the same messages.

Do not infer certification from the image name. The FIPS label describes the build, but it does not by itself show which cryptographic modules are validated or what their validation status is. Ask Mattermost which cryptographic module certificates the FIPS image carries for your release, how those certificates are identified, and where that documentation is published. Confirm whether the documentation covers Boards, Playbooks and Agents and whether it names the plugins that remain outside FIPS mode. Mattermost's pricing page lists FIPS 140-3 compliance as an Enterprise feature, which you should check against the module documentation rather than accept as a summary. An independent assessor decides what evidence is sufficient. DeployOpen can prepare the configuration and change evidence, but it does not issue audit reports or certifications.

Mattermost FIPS-compliant images: version and platform limits

FIPS-compliant images start with Mattermost v11. From that major version, each release ships a standard Enterprise image and a FIPS image (mattermost/mattermost-enterprise-fips-edition) under the same release tags, so the version you choose decides whether a FIPS option exists at all. Before you pick a target, review where each release sits in the support calendar, because an upgrade that lands on a release close to end of support creates a second upgrade within a short period.

v11.7 is an Extended Support Release. It was released on 2026-05-15, with support ending 2027-05-15. It is the release line to plan around for a regulated deployment that changes slowly.
v10.11 reached end of life on 2026-08-15. The previous Extended Support Release no longer receives support, so a deployment still on it needs an upgrade path to v11 mapped before any other FIPS work begins.
The PostgreSQL password has a minimum length from v11.7. When running the FIPS image, the password the server uses must be at least 14 characters. Check the value in your secrets store before the image swap, because a shorter password will block startup.
Monthly releases carry their own support dates. Mattermost publishes a new server binary on the 16th of each month, so check the support end date of any monthly build you consider, along with its release date.

Ask Mattermost to confirm in writing which release line your entitlement covers and which upgrade steps it requires from your current version.

What evidence Mattermost FIPS-compliant images produce for an audit

Assessors will ask for the same core records: which image runs where, how it got there, which plugins run outside FIPS mode, how the database and keys are configured, and whether the system is scanned and restored. These cards map those questions to the artifacts you must keep current through monthly releases and ESR upgrades. DeployOpen prepares this evidence, and independent auditors and certification bodies assess it.

Image references per environment

Record the Mattermost Enterprise FIPS edition tag and the image digest running in each environment, including development, staging and production. Tags can be repointed to a different image, so the digest shows what actually ran. Keep the Kubernetes manifests, Helm values or Docker Compose files that reference the image under version control, and confirm that no environment still pulls the standard Enterprise image. Refresh the record at each monthly release on the 16th and at each ESR upgrade.

Release notes and FIPS migration record

Retain the release notes for each server version you run, along with a dated migration record stating the source deployment, the FIPS image adopted, the steps taken and who approved them. FIPS images are supported on Docker, Docker Compose and Kubernetes only, and Linux package or tarball installations cannot migrate in place, so the record should name the deployment type that was migrated. Add an entry for each monthly release and each ESR upgrade, and confirm the upgrade path with Mattermost before planning.

Plugin inventory with FIPS status

List every installed plugin with its version and whether it runs in FIPS mode. The FIPS image runs Boards, Playbooks and Agents in FIPS mode, while other installed plugins keep running in non-FIPS mode. Assessors will ask how each non-FIPS plugin is justified, restricted or removed from regulated workloads. Recheck the inventory at every monthly release and ESR upgrade, because plugin versions can change independently of the server version.

PostgreSQL password and TLS settings

Document the PostgreSQL password length rule in effect: from v11.7, the password the server uses must be at least 14 characters when running the FIPS image. Record where the password is stored, who can read it and when it was last rotated. Pair this with the TLS and key settings in use, including protocol versions, certificate sources and key lengths. If CJI is in scope, CJIS Security Policy v6.1 requires FIPS 140-3 certified modules or AES with at least 256-bit keys, so confirm these settings against that requirement.

Vulnerability scan results and cadence

Keep scan reports for the FIPS image and the host and database layers, with the scan date, scanner, findings and how each finding was resolved or accepted. Define the scan cadence in writing and show that scans ran on schedule. If CJI is in scope, CJIS Security Policy v6.1 requires vulnerability scanning at least monthly, so align the scan schedule with the monthly release cycle. Confirm the scanner, scope and acceptance process with your assessor before the first review.

Restore tests and change records

Store dated backup and restore test results for PostgreSQL and the file storage, showing what was restored and what was verified afterward. Pair these with change records for each upgrade, configuration change and plugin decision, linking the ticket, the approver and the rollback plan. Repeat restore tests after each ESR upgrade, because the server and database versions change together and a restore that worked before may need to be proven again.

The PostgreSQL password rule for Mattermost FIPS-compliant images

From Mattermost v11.7, the PostgreSQL password that the server uses must be at least 14 characters when you run the FIPS-compliant image. This is the credential requirement you must plan for during a FIPS migration, and it concerns the database password the server connects with. Confirm the exact wording, scope and version boundary in the Mattermost FIPS migration documentation before you cite it in a control narrative, because an assessor will ask for the source. Do not describe the rule as stricter or looser than that wording.

The check can fail in two common situations. The first is a deployment still on a version earlier than v11.7 that you plan to move to a FIPS image, where the password was set under older assumptions and has never been reviewed against this rule. The second is a deployment that has moved to v11.7 but still uses a password that was not rotated as part of the upgrade. Inventory every environment, including development, test, production and disaster recovery, because a single stale copy in a non-production Compose file or pipeline can cause a failure that appears only after promotion.

The password lives in three places. The first is the secrets store, such as a Kubernetes Secret source, a vault or a Docker secret. The second is the mechanism that hands the value to the server, which is usually an environment variable or a configuration override that builds the database connection string. The third is the manifest, Compose file or Helm values that reference the secret. Rotate in that order. Create the new value in the secrets store, change the role password in PostgreSQL, then update the references and restart the application. In a high availability cluster, restart application servers one at a time so that at least one node keeps serving. On a single node, schedule a short restart window and confirm with your PostgreSQL team whether existing connections will drop when the role changes.

Record the change so that an assessor can follow it without asking the engineer who made it. Capture the Mattermost version and image tag, the date, the secret version identifiers before and after (not the values), the person who approved the change, the rotation steps, the rollback plan and the startup log that shows the server connected with the new credential. Keep the password out of tickets and chat. DeployOpen prepares these records as part of implementation and hardening, but independent auditors and certification bodies assess them, so confirm with your assessor which evidence format they accept.

What Mattermost FIPS-compliant images do not cover

The FIPS image changes how the Mattermost server handles cryptography and plugin runtime. It does not change your compliance obligations, which stay with your organization and its assessors. The cards below list the work that remains with your team or your partner, with control references where they apply.

Certification and authorization package

The image does not carry a certification, accreditation or authorization to operate. Those decisions belong to the authorizing official and independent assessors, who review your system boundary and evidence. Your team must still select SP 800-53 Rev. 5 controls from the low, moderate or high baseline that fits your data, which SP 800-53B defines as 149, 287 and 370 controls and enhancements respectively, and write the system security plan. Ask the vendor for the FIPS validation details that apply to the exact image version you deploy.

Monthly vulnerability scanning

CJIS Security Policy v6.1 control RA-5 requires vulnerability scanning at least monthly. The FIPS image does not select scanners, run scans or keep scan records for your environment. Your team must scan the running Mattermost server, the PostgreSQL database, container images and hosts, then retain reports and track remediation to closure. Confirm with your assessor what scan history and remediation evidence they expect to review.

Plugins running outside FIPS mode

The FIPS image runs Boards, Playbooks and Agents in FIPS mode. Any other plugin you install keeps running, but in non-FIPS mode. Inventory every installed plugin, identify which ones can touch criminal justice information or controlled unclassified information, and remove or replace those that cannot meet your requirement. Record each decision in the system security plan so the boundary is documented.

FedRAMP authorization scope

The FIPS image does not provide FedRAMP authorization. Scope depends on whether your deployment is a cloud service offered to agencies. FedRAMP covers cloud products that create, process or store federal information on behalf of an agency, while a system used only for one agency's own operations on cloud infrastructure, and not offered as a shared service, is out of scope under OMB memo M-24-15. Confirm the position with the authorizing body before you define the boundary.

Accessibility and NIS2 applicability

The image does not decide whether accessibility or NIS2 rules apply to your organization. For state and local government web content and mobile apps, the ADA Title II 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. NIS2 covers central government entities regardless of size and excludes entities working in national security, public security, defense and law enforcement. Obtain legal advice on your entity type before planning.

Infrastructure outside Mattermost

The image does not configure hosting, network segmentation, identity or key management around the server. Your team owns the cluster or hosts, ingress and egress rules, the identity provider and SSO settings, and the keys that protect PostgreSQL and file storage. CJIS v6.1 expects AES keys of at least 256 bits for CJI at rest outside physically secure locations. Each of these controls needs its own evidence in the system security plan, checked against your boundary diagram.

Configuration sequence for moving to the FIPS image

This sequence moves a Docker, Docker Compose or Kubernetes Mattermost to the FIPS-compliant Enterprise image in a controlled order. Each step produces a record your security and compliance reviewers can check, and the final step leaves production on the FIPS image with its evidence set filed.

Confirm the current version and release line
The platform engineering lead confirms the exact server version in use and whether that version sits on a supported release line. Check the Mattermost server releases page for the support end date of your line. For example, v11.7 is an Extended Support Release with support ending 2027-05-15, and v11.11 ends 2026-12-15. Linux package and tarball installations have no FIPS equivalent and cannot migrate in place, so stop here if that is your deployment method. Done when the migration record shows the version string, deployment method and support end date, and the version is on a supported line.
Confirm the plan entitlement for FIPS migration
The account owner or licensing contact confirms in writing that your plan includes FIPS migration. Per the FIPS migration documentation, migration is available on Entry, Enterprise and Enterprise Advanced, but not on Professional. A Professional subscription needs an upgrade decision before any technical work begins. Ask your Mattermost account team to confirm the entitlement against your subscription and seat licenses, then file the response. Done when the written confirmation is on file under the subscription name that the deployment uses.
Inventory every installed plugin and its FIPS status
The Mattermost administrator lists every plugin installed on the server, including those enabled by default and any custom or third-party plugins. For each one, record the version, the owning team and whether it runs in FIPS mode after migration. Per the FIPS migration documentation, Boards, Playbooks and Agents run in FIPS mode on the FIPS image, while other installed plugins keep running in non-FIPS mode. Done when the inventory covers every plugin shown in the System Console and each row has a FIPS status and an owner.
Check the PostgreSQL password length
The database administrator confirms that the password the Mattermost server uses to connect to PostgreSQL is at least 14 characters. From v11.7, the FIPS image requires this length. Check the value in the secret store or configuration source that the server actually reads, not only the database user's default. Rotate any shorter password, update every deployment that uses it, and restart the server. Done when the server starts and connects with the updated credential in the current environment. Confirm the requirement for your version in the FIPS migration documentation.
Take and test a full backup
The operations lead takes a backup of the PostgreSQL database and the file storage before any change is made. Include file storage, because the server depends on it alongside the database. Record the backup time, its location and an integrity check value such as a checksum. Restoring the copy to a separate test host is what proves recoverability, so restore it and confirm the restored server starts and serves expected channels and files. Done when a restore has completed on the test host and the results are recorded in the change record.
Move to the FIPS image in staging
The platform engineer changes the staging deployment to the FIPS-compliant Enterprise image, mattermost/mattermost-enterprise-fips-edition, using the same release tag as the standard Enterprise image for that release. Change only the image reference in the Docker Compose file or Kubernetes manifests, and keep the configuration and database connection otherwise unchanged. Roll out the change and confirm the server starts and passes its health checks. Run a smoke test covering sign-in, posting, file upload and search. Done when staging runs the FIPS image on the matching tag and the smoke test passes.
Verify FIPS mode and review non-FIPS plugins
The Mattermost administrator confirms that Boards, Playbooks and Agents run in FIPS mode on the staging server and saves the evidence. The security team then reviews each plugin that still runs in non-FIPS mode. For each one, record a decision: keep it with a documented exception, replace it, or disable it. Assign an owner and a review date through your own governance process. Done when every non-FIPS plugin has a recorded decision and the FIPS mode verification is saved with the staging test results.
Promote to production and capture the evidence set
The change owner schedules the production cutover using the same image reference, tag and configuration validated in staging. After the change, repeat the smoke test against production. Store the evidence set in the change record: the version and tag, the plan entitlement confirmation, the plugin inventory with FIPS status, the PostgreSQL credential check, the backup and restore result, the FIPS mode verification and the plugin decisions. An independent assessor decides whether this evidence meets any requirement. Done when production runs the FIPS image and the evidence set is filed where auditors can retrieve it.

Questions buyers ask before hiring help with Mattermost FIPS-compliant images

What drives the cost and effort of moving Mattermost to FIPS images?

The main drivers are the number of plugins, the version gap, the number of environments and the evidence scope. Each installed plugin needs a decision, because plugins outside Boards, Playbooks and Agents keep running in non-FIPS mode. Each one must be kept, replaced, or documented as an accepted gap. A large version gap adds upgrade steps and testing before the FIPS image can be reached. Every environment, including staging and disaster recovery, repeats the work, and the PostgreSQL password rule for v11.7 and later must be checked in each one. Evidence scope sets how much configuration, logging and change records you must produce. Ask whether a compliance assessment follows the migration, because that adds preparation work the migration itself does not cover. Ask for these factors itemized in the written scope rather than as a single lump figure.

Which costs are one-time and which recur after a FIPS migration?

The migration work is one-time. Inventory, plugin decisions, cutover, testing and documentation are paid once under the written scope. Mattermost licensing is separate and recurs. Mattermost sells Professional, Enterprise and Enterprise Advanced plans as prepaid annual subscriptions priced by seat licenses, and its pricing page lists no public prices, so request the figure for your seat count directly from Mattermost. Operations also recur. Mattermost releases a new server version each month on the 16th, and Extended Support Releases such as v11.7, supported until 2027-05-15, follow a longer cycle. Each release needs the FIPS image pulled, tested and rolled out for as long as you run Mattermost. Ongoing upgrade support is available as a retainer, and the written scope should state exactly what it covers.

How long does a Mattermost FIPS migration take?

No single duration applies to every environment, so confirm a timeline in the written scope before work starts. The duration follows the same factors that drive cost: the number of plugins needing decisions, how far the server is behind the current release, how many environments must move, and how much evidence must be gathered. Change windows matter as well. Production cutover depends on approved maintenance periods, and any Docker, Compose or Kubernetes change needs a rollback plan agreed in advance. Scheduling also interacts with the release calendar, since a new monthly server version lands on the 16th of each month. A plan that spans a release needs a decision about which version to target. Ask for the milestones, the client dependencies at each one, and the points where the timeline depends on your inputs.

What does a Mattermost FIPS migration need from our team?

The work needs four kinds of access and ownership. Environment access means accounts for the Docker, Compose or Kubernetes hosts, the PostgreSQL database and the file storage the server uses, with permission to change images and configuration. Change windows need named approvers who can book production downtime or a supervised cutover. Plugin owners must confirm whether each installed plugin is still needed and who can test it after the switch. Evidence owners, usually security or compliance staff, decide which logs, configuration records and approvals an assessment will request. Linux package and tarball installations have no FIPS equivalent and cannot migrate in place, so confirm your deployment method early. Name these people before scoping, because a missing approver can stall the plan.

Can our own engineers migrate Mattermost to the FIPS image?

Yes, if your team has the skills and the documented path. Mattermost publishes a guide for migrating existing deployments to FIPS-compliant images, and from v11 each release ships a FIPS image with the same release tags as the standard Enterprise image. Your engineers need container or Kubernetes administration skills, PostgreSQL experience, and the ability to test each plugin and integration after the change. Completing the image swap does not establish compliance on its own, so independent assessment is still required. DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Some teams handle the image change internally and bring in outside help for the inventory, testing and evidence package.

Does the FIPS image put every installed Mattermost plugin into FIPS mode?

No. The FIPS image runs Boards, Playbooks and Agents in FIPS mode. Other plugins you have installed keep running, but in non-FIPS mode. That affects your compliance position, so each plugin needs a recorded decision before cutover: remove it, replace it with a supported alternative, or document it as an accepted gap for your assessor. Check the plugin list on the current server, including plugins added by teams outside IT, since these are often missed. Test every retained plugin on a staging copy of the FIPS image, because behavior can change with the new build even when the plugin is unchanged. Confirm with Mattermost which plugins it supports in FIPS mode before you finalize decisions, since support status can change between releases.

Does a FIPS migration on its own satisfy a compliance assessment?

No. A FIPS image changes the server build, but an assessment reviews the whole system: configuration, access control, logging, retention, backups, plugins and how changes are approved. Confirm with your assessor which framework applies and which evidence it requires. The migration gives you a documented baseline and a record of the change, which the assessment can use. Whether a compliance assessment follows the migration is a scope question to settle before work starts, because it adds preparation, sampling and evidence work. DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and independent auditors or certification bodies make those determinations.

How DeployOpen scopes, configures and documents Mattermost FIPS-compliant images

DeployOpen starts each Mattermost FIPS engagement with a written scope that names the deployment type, Mattermost edition and plugins in use. We then move Docker, Docker Compose or Kubernetes installs to the FIPS-compliant image and verify the result in your environment. Engagements are fixed-scope, and the handover includes documentation your compliance team and independent auditors can review. DeployOpen prepares evidence but does not issue certifications.

How we scope

The written scope names your deployment method: Docker, Docker Compose or Kubernetes.
We confirm your current install type, since Linux package and tarball installs cannot migrate in place.
The scope lists each installed plugin, since plugins beyond Boards, Playbooks and Agents keep running in non-FIPS mode.

How we build

We confirm your Mattermost edition and plan, because FIPS migration is not available on Professional.
We check the PostgreSQL password length against the 14-character minimum required on v11.7 and later FIPS images.
We move the image to the FIPS edition with the matching release tag, then test startup and login.

How we hand over

The handover documents the image tags, deployment manifests, database settings and each plugin's FIPS mode status.
Evidence packs organize configuration records for the auditors and assessors you engage.
Your team receives an upgrade runbook, since each release ships a FIPS image with matching tags.

How we support

Ongoing support, upgrades and testing are available as a retainer after handover.
Upgrade work checks plugin status and PostgreSQL settings again before each new image is adopted.
Confirm in the quote which deployment types and plugins the retainer covers before signing.