Dify for government and public sector

Why public sector teams look at self-hosted Dify for AI services

Agencies are under pressure to offer AI-assisted services to residents, caseworkers and internal staff, yet data residency, records retention and public accountability rules still apply in full. The first question is rarely whether a model can answer a question. It is where prompts, retrieved documents, conversation logs and embeddings are stored, who can administer the platform, and whether the agency can show that to an auditor or an oversight body. Self-hosting Dify in infrastructure the agency controls changes the design questions from vendor trust to architecture: which cloud accounts, data centers or air-gapped networks host the stack, which model endpoints it can reach, and which records it must keep.

Dify is an LLM application platform for workflows, RAG pipelines and agents, and it ships with components that a public body will want to inspect before approval. The Docker Compose stack runs the api, worker, web and plugin daemon alongside PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy, so each one needs an owner, a patch routine and a place in the accreditation boundary. Confirm early whether the agency's hosting standard allows the default vector store or requires another option, and whether the license terms fit a single-workspace community install or a multi-workspace deployment. Those answers decide the architecture before any prompt is written.

This page covers four decisions that public bodies face: sovereign or air-gapped hosting, citizen-facing assistants with web app access control, accessibility of embedded apps, and how to buy support for an open-source AI platform. Each one shapes the others. A hosting choice determines which support contracts are possible, and an access model determines what a public-facing assistant can reveal. Read the sections on hosting and access first if your system is already in scope for a formal assessment, then use the procurement section to set the questions you will put to a delivery partner.

Which public sector requirements shape a Dify build

This table maps the public sector rules most likely to apply to a Dify build to what each one means for hosting, encryption, logging and public web apps. Read each row alongside the jurisdiction note, because many of these rules apply only to certain agencies, contractors or regions. Confirm applicability with your legal, procurement and security owners before choosing a hosting design.

Requirement	What it means for a Dify build	What to confirm
NIST SP 800-53 Rev. 5 and SP 800-53B baselines	Low, moderate and high baselines select 149, 287 and 370 controls and enhancements. Map Dify's hosting, access, logging and backup settings to the baseline your system is categorized under.	Your system categorization and which baseline your authorizing official has accepted
FISMA and OMB Circular A-130	Federal agency systems need documented risk management and independent assessment by Inspectors General. Dify deployments need a system security plan, configuration records and evidence that controls work as described.	Whether your agency is a federal entity and which Inspector General reporting applies
FedRAMP scope (M-24-15)	FedRAMP covers cloud products that handle federal information on behalf of an agency. A Dify instance run only for one agency on its own cloud infrastructure may fall outside that scope, while a shared Dify service offered to several agencies may not.	Whether your Dify hosting is a shared service, and whether your agency requires a FedRAMP-authorized provider
CJIS Security Policy v6.1	For criminal justice information, encryption in transit and at rest outside physically secure locations must use FIPS 140-3 validated modules or AES with at least 256-bit keys. Vulnerability scanning must run at least monthly, which affects the Dify host, containers and plugin images.	Whether any Dify data includes CJI, and the FIPS validation status of each cryptographic module in your build
32 CFR 2002.14(h)(2) (CUI on non-federal systems)	When Dify handles controlled unclassified information on non-federal systems, agencies apply NIST SP 800-171 requirements unless the CUI category sets other safeguards. Dify hosting, access and logs would fall under those requirements.	The CUI categories in scope and any agency-specified safeguards that override SP 800-171
32 CFR 170.17(c)(5) (CMMC cloud rule)	Defense contractors may store or process CUI in a cloud service only if it is FedRAMP Authorized at Moderate or higher, or meets equivalent requirements. A self-hosted Dify in the contractor's own boundary is assessed within that boundary.	Whether your Dify environment is inside your assessed scope and which CMMC level applies
ADA Title II web and mobile rules (28 CFR 35.200)	Public Dify web apps, embedded assistants and any mobile wrappers must meet WCAG 2.1 Level A and AA. Compliance dates are 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts, and the rule also covers content provided through contracts.	Your population category, your compliance date, and whether vendor-supplied chat widgets are included in your conformance testing
NIS2 (Directive (EU) 2022/2555)	Central government entities fall under NIS2 regardless of size, and Member States may extend it to local administration. Dify availability, access control, incident reporting and supply chain security become governance duties for the operator.	Whether your entity is covered, whether national security, defense or law enforcement exemptions apply, and how your Member State transposed the rules
GDPR transfer rules (Article 44 and Chapter V)	Remote access from a third country, including screen display for support, and storage in a cloud outside the EEA count as transfers. Hosting Dify model endpoints, vector stores, backups and vendor support access in the EEA reduces this exposure but does not remove it.	Where support staff, backups and model providers are located, and whether any processor is subject to third-country law
CLOUD Act (18 U.S.C. 2713)	US-headquartered providers must preserve or disclose data in their possession, custody or control wherever it is stored. For EU public bodies, this affects selection of cloud hosts, managed databases, and support providers that have US parent companies.	Which providers in your Dify stack have US parent companies, and whether your legal team has assessed that exposure
EU Data Act Article 32 and switching rights	Providers must take measures against third-country government access to non-personal data held in the EU. Customers have switching rights, so Dify exports, database backups and storage should be portable to on-premises or another provider.	Your provider's Article 32 measures in writing, and whether your exit plan covers Dify apps, DSL exports, knowledge bases and vector data

Choosing sovereign, air-gapped or cloud hosting

Running Dify on agency hardware keeps the platform, its databases and its files inside a boundary the agency already monitors. The Docker Compose stack starts the api, worker, web, plugin daemon, Nginx, a code sandbox and an SSRF proxy, plus PostgreSQL, Redis and Weaviate by default. The agency must supply the host capacity, storage, backups and patch process for all of them, and the official documentation sets only minimum resources, so sizing needs its own test.

Offline install: Confirm how images, plugins and dependencies reach the network before the first install, and who approves each transfer across the boundary.
Model endpoints: Models running on local inference servers keep prompts and retrieved content inside the boundary. Any hosted provider model, reached over an outbound path, breaks that assumption.
Outbound controls: The SSRF proxy settings block internal and private ranges, but the agency must still decide which destinations the sandbox and plugins may reach.
FedRAMP scope: An agency-operated system used only for its own operations is generally outside FedRAMP's cloud scope, so the question shifts to the agency's own authorization process.

Confirm with the agency's authorizing official which baseline applies to the data before choosing this option.

Settings that matter for a government Dify deployment

Most of the government-relevant decisions in a self-hosted Dify deployment are made in configuration, not in the app builder. The six settings below connect where data is stored, how secrets are protected, how outbound and agent traffic is contained, and who can reach the apps. Confirm each one against your agency's control baseline before the first production user.

Metadata database and file storage

Dify defaults to PostgreSQL for metadata, and file storage can use OpenDAL, S3-compatible storage, Azure Blob, Google Cloud Storage and other providers. For a public body, the choice determines where uploaded citizen documents, prompts and app records physically sit and who administers them. Ask which backend your storage team can encrypt, back up and restore under your own key management, and confirm that the provider runs inside the jurisdiction your records rules require.

Vector store choice and data location

The vector store holds embeddings derived from agency documents, so it carries much of the same sensitivity as the source files. Dify defaults to Weaviate, with options including Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch. Record which store holds each knowledge base, where its nodes run, and how it is backed up. Confirm that deleting a source document also removes its embeddings, because retained vectors can keep restricted content retrievable after its legal retention ends.

SECRET_KEY and workspace encryption keys

SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, so it is a root secret for the instance. Changing it after deployment logs out all users, which makes its generation and storage a planned change with an owner. Workspace encryption keys can be stored locally or in Azure Key Vault. Agencies with key custody rules should decide who holds these keys, how they rotate, and whether a hardware-backed or agency-controlled vault is required before production.

SSRF_PROXY and outbound filtering

Dify's SSRF_PROXY setting routes outbound requests through a proxy that blocks internal and private IP ranges. This limits the chance that a workflow tool or HTTP node reaches internal administrative services, which is a common concern for networks that host both public-facing assistants and back-office systems. Test the policy with a deliberately internal address, record the result, and confirm that every approved external model or API endpoint is allowed by name rather than by a broad exception.

Agent sandbox network isolation

Dify 1.16.1 release notes describe agent sandbox network isolation through a Squid proxy, along with token-based API authentication between services and sandboxed Jinja2 template rendering. These changes narrow what code run by an agent can reach on the network. Agencies should treat the release as a reason to pin a tested version, confirm the isolation behavior in their own environment, and document which agent tools are enabled for each public-facing app.

Enterprise SSO scopes for workspace and web app access

Dify Enterprise SSO documents separate scopes for workspace access and web app access, supporting protocols such as OpenID Connect, SAML and OAuth2. Staff editing workflows and citizens using a published assistant need different identity paths and different authorization. Confirm with your identity team which provider governs each scope, how external users are onboarded, and how access is removed when a staff member leaves, since these scopes are configured separately.

How web app access control shapes citizen-facing assistants

Decide early whether an assistant is a staff tool or a public service, because Dify handles the two differently. Staff-facing apps sit behind workspace sign-in, so only people with a workspace account can open them. Public-facing web apps are reached by citizens who have no agency account, so the agency must choose an access level for each app: open to anyone with the link, restricted to people who sign in, or limited to named groups. Write down, for every app, who may open it, what identity the assistant uses when it calls models or knowledge bases, and what the transcript records. Confirm with Dify how web app access levels and external users are set in your version, and whether an unauthenticated public app can be rate limited and blocked from abuse at the edge of your own network.

The citizen identity question is the one most often left vague. A public assistant usually should not impersonate a staff member or reuse a service account with broad rights. Plan a low-privilege service identity for model and retrieval calls, and decide whether a citizen who signs in through a government identity provider should carry that identity into the app or remain anonymous. Logging follows the same choice. Conversation records can contain personal data the citizen typed, so define retention, redaction and who may read logs before launch. Ask the vendor which logs record the end user, which record only the app, and how to export or delete them.

Separation between agencies or departments is a workspace question. The Community edition of Dify is limited to a single workspace, so one self-hosted instance cannot give several departments isolated workspaces without a different setup. The Enterprise edition adds multiple workspaces and SSO with separate scopes for workspace access and web app access, which is the feature set that maps to a department-by-department model. Confirm with the vendor whether each agency needs its own instance or workspace, how administrators are kept out of other departments' data, and which SSO protocols your identity provider supports, such as OpenID Connect, SAML or OAuth2.

Making embedded apps meet the ADA Title II web rule

State and local agencies that publish Dify-built assistants on public web pages or in mobile apps need to meet the ADA Title II web accessibility rule. The work breaks into an audit of what Dify actually renders, testing with assistive technology, review of generated content, and a standing process that keeps pace with monthly releases.

Scope the WCAG 2.1 requirement

The ADA Title II rule requires state and local government web content and mobile apps to meet WCAG 2.1 Level A and AA. It also covers content provided through contracts or licenses, so a Dify assistant built by a vendor or hosted under a license is still in scope. Confirm with counsel which agency pages, portals and embedded apps count as government web content, and record that decision in the accessibility plan.

Track the population-based deadlines

The rule sets 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts. An agency should confirm which date applies to its own population count and to each separately operated unit. Plan the audit so that the earlier date is met for any Dify app that serves residents of a larger jurisdiction.

Audit Dify front-end pages

Walk through the Dify web app interface, login pages, chat screens, feedback controls and any admin pages that citizens or staff reach. Check color contrast, keyboard focus order, form labels, error messages and dynamic updates when streamed answers appear. Record each finding against the WCAG 2.1 success criterion it affects, and note which items come from Dify itself and which come from your theme or embedding page.

Test embedded apps with assistive technology

Automated scanners find only part of the problems. Test the embedded assistant with a screen reader, speech input and keyboard-only navigation on the browsers and devices residents use. Check that the chat transcript is announced, that citations and attachments are reachable, and that the assistant works at high zoom. Keep the test scripts and results so that the evidence can be repeated after each change.

Review knowledge base outputs

Accessibility also covers what the assistant says. Generated answers can contain tables, lists, links and abbreviations that screen readers handle poorly, and source documents may be scanned PDFs without text layers. Set a review standard for answer formatting, check that cited documents meet the same accessibility level, and assign an owner for correcting the source material that produces repeated barriers.

Keep the audit current across releases

Dify's minor releases arrive roughly monthly, so a front-end audit can go stale quickly. Schedule a regression pass for each upgrade before it reaches production, and retest the pages and flows that changed. Ask any implementation partner to deliver the audit in a form your team can rerun, and ask who owns the open findings after handover.

Rolling out a public sector Dify deployment

This sequence moves a Dify deployment from legal scoping to a citizen-facing launch and ongoing operations, with a checkpoint at each stage so the agency can show what was decided, tested and approved before any public access is granted.

Classify data and confirm legal scope
Before any design work, the agency's legal, records and security leads list the data each planned app will touch, including citizen personal data, controlled or sensitive categories and any criminal justice or defense information. They confirm which frameworks apply, such as NIST SP 800-53 baselines, FedRAMP scope questions, WCAG obligations under the ADA Title II rule, or EU transfer rules if the agency is in Europe. DeployOpen can help map these to a written scope, but the agency's counsel decides the legal position. The step closes with a signed data classification register and a list of frameworks that the design must satisfy.
Design hosting, network and model paths
Decide where Dify runs (an agency data center, a government cloud tenancy, or an air-gapped network) and which model endpoints it can reach. Plan the Docker Compose or Kubernetes layout, external PostgreSQL, Redis and object storage, the vector store choice, and outbound controls such as the SSRF proxy settings and an agent sandbox boundary. Confirm with the vendor and your own environment which components can run fully offline, and which model providers or self-hosted inference servers the approved list permits. The output is an architecture diagram, a data flow map showing every external call, and a list of open questions for the security team.
Define identity, roles and web app access
Map which users are staff and which are citizens, and decide how each group signs in. Staff workspace access and public web app access are controlled separately in Dify Enterprise, so the design should state who may build apps, who may publish them, and who may use each published app. Confirm with the vendor whether the Community edition's login options meet the agency's requirements, since Enterprise SSO is listed as an Enterprise feature. The step produces a role matrix, an access review schedule, and a decision on how external or anonymous citizen users are handled.
Pilot with staff-only apps
Build one or two internal assistants, such as a policy lookup tool for caseworkers, behind the staff sign-in path. Load only documents that the data classification register allows, and test retrieval quality, error handling and logging with real staff users under supervision. Record the model settings, prompts and knowledge base connections, and export the app definitions as DSL files so the pilot can be reproduced. The step closes when staff have run agreed test cases and the agency has documented which behaviors it accepts and which it blocks before release.
Test accessibility and security
Run accessibility testing of every embedded or citizen-facing app against WCAG 2.1 Level A and AA, which the ADA Title II rule sets for state and local government web content and mobile apps. Commission security testing of the Dify instance, its APIs, the access model and the AI behavior, including prompt injection and data leakage checks. Fix findings, retest, and keep the reports with the version and configuration they tested. The step is done when accessibility and security findings are either closed or formally accepted by the named owner.
Prepare assessment evidence
Assemble the records an assessor or Inspector General will ask for: the classification register, architecture and data flow diagrams, role matrix, change history for each app, test reports, backup and restore results, and the SECRET_KEY and encryption key custody procedure. DeployOpen prepares systems, controls and evidence, but independent auditors and certification bodies issue any audit report or authorization. The output is an evidence index that maps each artifact to the control or requirement it supports, reviewed by the agency's compliance lead.
Launch citizen-facing assistants in stages
Publish the first citizen-facing web app only after the evidence index is accepted and the agency's approving authority signs off. Start with a limited set of apps and a defined audience, monitor conversations and errors, and keep a rollback path that disables a published app without taking down the platform. Confirm how the public app is linked to the agency's website and how users are told they are interacting with an automated assistant. The step closes with a go-live record listing the approved apps, versions, owners and monitoring contacts.
Operate with backups and the upgrade guide
Run the deployment on a recurring cycle of monitoring, access reviews and retesting. Dify releases arrive roughly monthly, so each upgrade should follow the upgrade guide for the target version, start with a backup, and check .env.example for new variables after the upgrade. Test restores on a separate environment before relying on them, and retest accessibility and security when an app or model changes. The cycle is in place when the agency has a documented upgrade calendar, a tested restore record and an owner for each recurring check.

Compliance questions agencies must answer before launch

Agencies usually face four questions before a Dify assistant reaches residents or staff: whether the platform falls under a cloud authorization program, which control baseline applies, how criminal justice or controlled unclassified data changes encryption and scanning, and where data or remote support crosses a border. The answers depend on who operates the system, what data it touches and where it runs, so they should be settled in writing before the build starts.

FedRAMP scope for the platform

FedRAMP covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A Dify instance run only for one agency's internal operations on infrastructure it controls may fall outside that scope, but a shared hosted service offered to several agencies may not. Confirm the operating model with your authorizing official and contracting office before deciding whether a FedRAMP route applies to the hosting provider, the model provider or both.

Mapping NIST SP 800-53 to the stack

Choose the control baseline first, then map each control to a Dify component: the api and worker services, PostgreSQL, Redis, the vector store, object storage, the code sandbox and the SSRF proxy. Access control, audit logging, configuration management and secrets handling usually land on the platform team, while identity, network boundary and vulnerability management depend on the hosting environment. Keep a control-to-component matrix so assessors can trace each claim to a configuration or record.

CJI and CUI encryption and scanning

Criminal justice information and controlled unclassified information change the cryptography and monitoring work. CJIS Security Policy version 6.1 expects FIPS 140-3 validated modules or AES with 256-bit keys for data outside physically secure locations, and monthly vulnerability scanning. Under 32 CFR 2002.14(h)(2), agencies apply NIST SP 800-171 to CUI on non-federal systems unless the category sets other safeguards. Confirm which Dify encryption paths, including the workspace key store and database volumes, can meet these requirements.

EU transfers and third-country access

Under GDPR Chapter V, storing personal data in a cloud outside the EEA, or letting a remote support engineer in a third country view data on screen, counts as a transfer. A Dify deployment that calls an external model API or sends logs abroad needs a transfer basis, and any provider subject to foreign government access laws needs a documented assessment. Map where each data class is stored and who can reach it, including support sessions, before signing any processor contract.

Evidence DeployOpen prepares

DeployOpen plans, configures and documents the Dify deployment, prepares control evidence such as configuration records, access listings, backup tests and scan results, and maps that evidence to the frameworks you name. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors, assessors and certification bodies make those determinations, so ask each one early which evidence formats and sampling they expect.

What agencies ask before hiring a partner for Dify

How much does it cost to run Dify for an agency?

The self-hosted Community edition is free to download and run, but it is limited to a single workspace. The self-hosted Enterprise edition is custom priced by Dify and adds SSO, multiple workspaces, advanced security, a commercial license and professional support, so quote it separately. A partner engagement is a third cost and is priced from a written scope, not from a price list. Ask every bidder to split one-time work (design, build, hardening, testing, migration) from recurring work (upgrades, support retainers, model usage, hosting, and staff time). Dify Cloud list prices are not relevant to a self-hosted agency deployment, so do not use them as a baseline.

How long does a Dify deployment for a government team take?

Duration depends mainly on the number of workspaces and web apps, whether SSO and accessibility testing are in scope, the hosting model (connected cloud, data center or air-gapped), and how quickly the agency approves architecture, security review and access rules. Model provider approval and knowledge base content preparation often take longer than the software installation itself. Ask each partner for a phased plan with milestones and the assumptions behind each phase, and check that the plan includes a pilot with real users before any public launch.

What must the agency provide before a partner starts work?

The agency usually needs to provide the hosting environment and its approvals, identity provider access for SSO, named owners for the business process and the knowledge content, the approved list of model providers or self-hosted models, and a decision on data classification for each app. Security reviewers should also be available to approve network rules, secrets handling and logging. Write these inputs into the statement of work so that a delay on any of them is visible and does not become a hidden cost overrun.

Can our own staff run Dify after the engagement?

Yes, if the agency has platform engineers who can operate Docker Compose or Kubernetes, manage PostgreSQL, Redis and object storage, and follow a release process. Dify ships minor releases roughly monthly, so the team needs a standing upgrade routine, a tested backup before each upgrade, and a check of the environment variable example file after each change. Agencies with small teams often keep application ownership in-house and buy operations support for upgrades and incidents. Ask the partner which tasks they would hand over and which they would keep, and make the handover a named deliverable.

How do upgrades and support retainers work for Dify?

Upgrades follow the upgrade guide for each target version, and Dify recommends a backup before every upgrade. Version jumps that change architecture need planning beyond pulling new images, so the upgrade plan should be a separate scoped item. A support retainer usually covers monitoring, patch and release review, upgrade execution, incident response and changes within an agreed scope, and it recurs for as long as the agency wants that cover. Ask for the retainer's response expectations in writing, the change request process, and what happens when a major release arrives.

Can a partner help us produce evidence for procurement and compliance reviews?

A partner can prepare the system design, configuration records, access model, logging setup, backup and restore evidence, and test results that your reviewers ask for. A partner cannot issue audit reports, attestations or certifications, because only independent auditors and certification bodies do that. Before work starts, confirm which frameworks apply to your system, such as the federal control catalog or the criminal justice security policy, and ask the partner to map the deliverables to those requirements in your own words. Your assessor decides what counts as sufficient evidence.

What should an agency check in a fixed-scope proposal?

Check that the proposal lists the deployment target, each deliverable, the named Dify editions and features in scope, the integrations and identity providers, the testing included (including accessibility testing for any citizen-facing web app), the handover items, and the acceptance criteria. Fixed-scope work should state what is excluded, the change request process, and who pays for model usage and hosting. If a proposal cannot be tied to written deliverables, ask for a revised version before you compare prices.

How to procure support for an open-source AI platform

A procurement file for self-hosted Dify should start with a written scope that names the workspaces, environments, model endpoints, knowledge bases and citizen-facing web apps the partner will touch, along with the edition (Community or Enterprise) each one runs on. The Community edition is limited to a single workspace, so any plan that gives several departments or agencies separate workspaces on one installation needs a licensing answer before the scope is signed. The Dify Open Source License forbids operating a multi-tenant environment, where one tenant is one workspace, without written authorization from the licensor. Ask the vendor to confirm in writing whether the planned layout is permitted, and ask the partner to list every component whose license terms they have reviewed.

Next, the file should divide responsibilities for support and upgrades. Dify ships minor releases roughly monthly, and the Docker Compose documentation asks operators to read the upgrade guide for each target version, take a backup before every upgrade and check .env.example for new variables. The contract should say who performs each step, who tests in a non-production environment, who signs off on the change window and who responds when an upgrade breaks a workflow. Confirm with the vendor which versions receive security fixes and for how long. Also ask whether the Enterprise edition's professional support is available to your agency directly or only through a partner, since that determines who is accountable for a patch.

Exit terms matter as much as delivery terms. DSL exports carry app configuration, workflow nodes, model parameters, prompts and knowledge base connections, but not third-party API keys, knowledge base content or usage logs, so the contract must name who holds the knowledge base documents, the vector index and the database backups, and in what format they can be returned. Where the agency is subject to the EU Data Act, Articles 25 and 29 give customers switching rights with a maximum two-month notice period and a 30-day transition, and switching charges are banned from 12 January 2027. Ask the partner to commit to a documented export procedure and to list the items the agency keeps at all times, such as its encryption keys, object storage and infrastructure credentials.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For Dify in government, the work starts with the hosting boundary, the data classes and the citizen-facing access model, and each of those is written into the scope before build begins.

How we scope

Map which data classes the assistants touch and which hosting boundary, sovereign cloud or air-gapped network, each one must stay inside
Agree the written scope, deliverables and timelines before work starts, since most engagements are fixed-scope
Confirm with your compliance and accessibility owners which frameworks, procurement clauses and web app audiences the Dify deployment must satisfy

How we build

Deploy Dify in your environment with the metadata database, file storage, vector store and secrets handling chosen for your boundary
Configure SSO for workspace access and web app access separately, and test that citizen-facing apps cannot reach staff-only workspaces
Test outbound request filtering, agent sandbox isolation and API exposure, and document the results alongside the build record

How we hand over

Deliver architecture, configuration, access and backup runbooks written for your operators and your security reviewers
Provide an evidence pack that shows controls and settings in place, which your independent assessors then evaluate
Walk your team through the upgrade procedure, including backups before each release and checks of new environment variables

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, sized to your release cadence and risk appetite
Track minor releases and security changes, then plan and test each upgrade in a staging environment before production
Confirm with us in the quote which support hours, response expectations and testing cadence the retainer covers