How to use this AI gateway requirements checklist
If several teams call model providers directly with their own keys, nobody can see total spend, which models hold client data, or who changed what. The answer is a single gateway in your own infrastructure that every application calls, and the checklist below tells you what that gateway must do before you pick one. Treat it as a list of decisions to make, not a feature comparison to skim. The main open-source options covered are LiteLLM, which is a Python SDK and proxy server, and Apache APISIX, which is a general API gateway with AI gateway plugins. Each has a different operating model, so the same requirement can land in very different places depending on which one you choose.
The checklist separates must-have requirements from requirements that depend on your risk profile. Virtual keys, per-team budgets, logging and SSO for the admin UI are usually non-negotiable once more than one team uses the gateway. Guardrails and PII filtering, prompt retention periods and fallback rules depend on which data classes flow through the gateway and which regulators apply. Licensing changes which features are free. For example, LiteLLM's enterprise directory uses a separate license from the MIT-licensed remainder, and SSO and audit features may sit behind an enterprise license. Confirm each feature's license status in writing before you assume it is available.
Verify every requirement in a proof of concept with your own models, identity provider and log volumes. A datasheet tells you that a feature exists, not that it blocks a prompt containing a test identifier, expires a team budget correctly, or keeps routing when a provider returns errors. Ask each candidate to demonstrate the specific behavior your team needs, record the configuration used, and test failure cases such as losing the database or a second gateway instance. Ask your implementation partner to include these tests in the proof of concept scope so the results can be reused as compliance evidence later.
Functional requirements: which models, keys and routing rules the gateway must handle
This table lists the functional requirements an AI gateway must meet for model routing, keys, budgets, rate limits and failover, with how to verify each one. Read it as a test plan: each row names what to ask for and what evidence a reviewer should see before accepting the design. The main takeaway is that routing, keys and budgets depend on shared state, so they need a verified PostgreSQL and Redis design before rollout.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Model providers and self-hosted endpoints | Applications should call one OpenAI-format endpoint while the gateway maps requests to hosted APIs and to in-house vLLM or Ollama servers. | Confirm each provider and internal endpoint is registered, and send a test request to each through the gateway. |
| Virtual keys per team and application | Keys separate callers so spend, access and audit records can be attributed to a team or application instead of a shared credential. | Create keys for two teams, confirm each key only reaches its own models, and check the key appears in spend records. |
| Budgets per key, user and team | Budgets cap unexpected spend and let finance charge usage to cost centers. LiteLLM virtual keys support per-key, per-user and per-team budgets. | Set a low test budget, exceed it, and confirm requests are blocked and the event is logged. |
| TPM and RPM rate limits | Token and request limits protect shared capacity, including self-hosted GPUs, from one noisy application. | Run a load test above each limit and confirm throttled responses and a unchanged behavior for other keys. |
| Model restrictions per key | Restricting keys to named models keeps regulated workloads on approved endpoints and blocks unapproved providers. | Attempt a call to a non-allowed model with a restricted key and confirm it is rejected. |
| Fallback, retries and cooldowns | Provider outages and rate errors should fail over without application changes. LiteLLM routing supports retries and cooldowns after repeated failures. | Disable the primary endpoint in a test environment and confirm traffic shifts to the fallback and the failure is recorded. |
| Priority failover and session affinity | Priority ordering sends traffic to the preferred endpoint first. Session affinity keeps a conversation on one backend where context or data residency matters. | Set a priority order, confirm the first endpoint is used when healthy, and confirm one session stays on one backend. |
| Routing strategy choice | LiteLLM offers simple-shuffle (recommended), usage-based, latency-based, least-busy and cost-based routing. The choice affects cost, latency and capacity use. | Document the chosen strategy per model group and confirm it in the routing configuration and test results. |
Which open-source gateway fits which requirement set
LiteLLM is built as an AI gateway first. It is both a Python SDK and a proxy server that calls more than 100 LLM providers, including OpenAI, Anthropic, Gemini, Bedrock and Azure, using the OpenAI request format. Its core is MIT licensed, and the latest release in the supplied facts is v1.105.1, published October 14, 2026. Only the enterprise/ directory uses a separate license, so review that boundary before you depend on any enterprise capability.
- Model access and routing: Routing options include simple-shuffle, usage-based, latency-based, least-busy and cost-based strategies, with retries, cooldowns, priority failover and session affinity.
- Keys and budgets: Virtual keys support per-key, per-user and per-team budgets, TPM and RPM limits, temporary budget increases and model restrictions. They require PostgreSQL.
- Scaling: PostgreSQL is the primary supported database. Redis 7.0 or newer is required once more than one proxy instance runs, for shared rate limits, router state and cache.
- Admin SSO: SSO for the admin UI is available with Google, Microsoft Entra ID, Okta and generic OIDC. From v1.76.0, SSO is free for up to 5 users, and an Enterprise license is needed beyond that.
- Enterprise-only items: SCIM, JWT authentication from identity provider tokens, audit logs, organization and team RBAC, IP allowlisting, secret manager integrations and team-level guardrails and logging sit behind the Enterprise license.
Confirm guardrail, PII filtering and logging retention behavior against your exact version, since the routing and key features depend on the database and Redis setup you choose.
Apache APISIX is a general-purpose API gateway, released under the Apache License 2.0, and it also ships AI gateway functions. It is a top-level Apache Software Foundation project built on NGINX and etcd. The supplied release facts include APISIX 3.19.0, published September 28, 2026. The downloads page does not mark any release as long-term support, so confirm the support policy with the project before you standardize on a version.
- Deployment modes: Traditional mode runs data and control planes together with etcd. Decoupled mode separates them over one shared etcd cluster. Standalone mode needs no etcd and reads configuration from
conf/apisix.yamlorconf/apisix.json, reloaded about every second. - Ports: In traditional mode, client traffic uses port 9080 and the Admin API uses port 9180.
- Authentication: The openid-connect plugin works with Keycloak, Auth0, Microsoft Entra ID, Google and Okta, and supports authorization code, client credentials, introspection and PKCE flows. This covers SSO for the gateway's own access paths, but it is not a substitute for model-level key budgets.
- Extensibility: Custom plugins can be written in Lua, through runners in Java, Go and Python, or as WebAssembly. Over 100 built-in plugins cover traffic control and observability.
- Gap to verify: Per-team virtual keys, token budgets and provider-specific failover usually need custom work or AI plugin configuration. Check each in the version you plan to run.
APISIX fits best where the organization already runs it for APIs and wants AI traffic under the same controls.
Kong Gateway is also licensed under Apache-2.0, and the supplied release facts list version 3.9.4, published October 12, 2026. It is a general API gateway, so its AI capabilities should be treated as a separate feature area to evaluate rather than assumed. Like APISIX, it may suit an organization that already runs Kong for API management and wants one control plane for model traffic.
- License check: The open-source edition is Apache-2.0. Enterprise features, and any AI plugins you rely on, must be checked against the edition and license terms that apply to them.
- Data stores: Confirm which database or declarative configuration mode your chosen release requires for high availability and shared state.
- Budgets and keys: Confirm whether per-team budgets and token-based limits are provided natively or through a plugin.
- Logging: Confirm where prompt and response logs are stored, how long they are retained, and whether redaction happens before logs are written.
- Identity: Confirm the admin SSO and OIDC options for the specific edition.
Do not treat a general API gateway as a finished AI gateway without a proof of concept against your requirements.
Security requirements the gateway must meet before production
The gateway holds every provider credential and sees every prompt, so it becomes a high-value target and a single point of policy failure. The cards below cover the controls to confirm before any team sends production traffic through it, and each one has a specific check you can run during evaluation.
SSO and role-based access for the admin UI
The admin UI controls keys, budgets, routing and logging settings, so anyone who can log in can change what the whole organization is allowed to do. LiteLLM's admin UI supports SSO with Google, Microsoft Entra ID (Azure AD), Okta and generic OIDC providers, but the free tier covers up to 5 users, and team and organization RBAC is listed among the Enterprise features. Confirm your identity provider's configuration, who holds the admin role, and whether your license level covers role separation before go-live.
Secrets handling for master key and credentials
The LITELLM_MASTER_KEY and every provider API key are the keys to the gateway, and a leak exposes the whole model estate. LiteLLM recommends keeping the master key in a secret manager, and Enterprise adds integrations with AWS, Azure, Google, HashiCorp Vault and CyberArk. Check that no credentials sit in config files or container images, that rotation has an owner and a procedure, and that the master key begins with sk- as the product requires.
Network controls and IP allowlisting
The gateway should accept traffic only from approved application networks and should reach only approved model endpoints. Decide which subnets may call the proxy, which egress paths may reach external providers, and whether the admin interface is reachable from anywhere but the corporate network. IP allowlisting is an Enterprise feature in LiteLLM, so confirm whether your version needs it or whether the network team will enforce the same rule at the load balancer or firewall.
Guardrails and PII filtering at input and output
Guardrails decide what reaches a model and what returns to the user, so they must run on both directions of every call. LiteLLM supports guardrails and team-level guardrails in Enterprise, and APISIX offers AI gateway plugins, but neither should be assumed to cover your PII categories. Test with prompts containing your own identifiers, confirm where redaction happens relative to logging, and confirm how a blocked request is recorded.
Tamper-resistant audit logs
Logs of prompts, model choices and key usage are evidence for security reviews and for the record-keeping duties in the EU AI Act, so they must be hard to alter after the fact. LiteLLM lists audit logs as an Enterprise feature and stores spend data in PostgreSQL, which needs its own access controls. Ask where logs are written, who can delete or edit them, how they are copied off the gateway host, and how long they are retained.
Vulnerability testing of the gateway itself
The gateway is internet-facing software that handles credentials and user data, so it needs the same testing as any other production service. Before launch, run application and API security tests against the proxy and admin UI, review the container images and dependencies, and check the configuration of PostgreSQL and Redis. Repeat testing after each upgrade, since LiteLLM publishes frequent releases such as v1.105.1 and supports only its four most recent stable minor versions.
How prompt logging and retention requirements are set
Set logging and retention as a documented decision per data class before the gateway goes live, because the gateway is where every model call is recorded. For each request, the minimum useful log entry covers the model and provider called, the team and virtual key that made the call, token counts, computed cost, and start and end timestamps. Prompt and response content is a separate decision. Many organizations record metadata for all traffic and store content only for approved applications, with the content fields disabled elsewhere. Confirm with the LiteLLM version you run which logging callbacks and content flags are available in the open source edition and which sit behind the enterprise license, since the topic facts do not settle that for every feature.
Decide where the records live before the first request is logged. LiteLLM uses PostgreSQL as its primary supported database, and virtual key spend is tracked there, so spend records and request metadata usually sit in the organization's own PostgreSQL instance under the same backup, encryption and access controls as other regulated databases. If content is logged to a separate log platform, treat that platform as a second system of record with its own access model. Ask the implementation partner who can read prompt content, how that access is granted and reviewed, and whether masking runs before the record is written.
Retention is set by legal, privacy and sector rules, not by the gateway's defaults. Privacy counsel usually drives limits on how long personal data in prompts may be kept, and sector regulators may require longer retention of access records. As one example, Article 12(1) of the EU AI Act requires high-risk AI systems to technically allow automatic recording of events over the system's lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. Those duties fall on providers and deployers in different ways, so deployers must confirm with counsel which obligations apply to their systems, and whether their gateway logs are the deployer's own records or part of the provider's duty. Write the retention period for each data class into the gateway runbook and confirm that the purge job is tested.
Integration requirements with identity, data and existing platforms
An AI gateway is only as controlled as its connections. Identity decides who gets a key, secret management decides where provider credentials live, and the database and cache decide whether limits and budgets hold across instances. The cards below cover the integrations to scope before a build, and what each one requires you to confirm in your own environment.
Identity provider for the admin UI and users
LiteLLM's admin UI supports SSO with Google, Microsoft Entra ID, Okta and generic OIDC providers, and APISIX can validate tokens through its openid-connect plugin with Keycloak, Entra ID or Okta. Confirm which identity provider is authoritative, how team membership maps to gateway teams and keys, and whether SSO for the admin UI requires an enterprise license at your user count. Check the free user limit before you size the license.
Secret manager for provider keys
Provider API keys and the LiteLLM master key must not sit in configuration files or environment variables on shared hosts. LiteLLM recommends keeping the master key, which must start with sk-, in a secret manager, and its enterprise tier adds integrations with AWS, Azure, Google, HashiCorp Vault and CyberArk. Confirm which secret manager your organization already operates, who rotates provider keys, and how gateway pods receive secrets at startup without writing them to logs.
Observability backend for traces
Gateway logs show which team called which model, but tracing and evaluation tools such as self-hosted Langfuse or Arize Phoenix show what happened inside an application's chain of calls. Langfuse is MIT licensed outside its ee directories, while Phoenix is under the Elastic License 2.0, which bars offering it to third parties as a hosted service. Confirm where trace data is stored, which fields are redacted before export, and whether the license fits your delivery model.
PostgreSQL and Redis dependencies
Virtual keys, per-team budgets and spend tracking need PostgreSQL, and LiteLLM names PostgreSQL as its primary supported database. Once more than one proxy instance runs, LiteLLM requires Redis 7.0 or newer for shared rate limits, router state and cache. Confirm backup and restore targets for the database, who operates Redis, and how a Redis outage degrades rate limiting so that budgets are not silently bypassed.
Cost center exports for finance
Chargeback needs spend records that map each key to a team, application and cost center in the finance system. Plan a scheduled export from the gateway database into the organization's ledger or FinOps tooling, and decide who owns the mapping when teams are reorganized. Ask finance which granularity they need, whether monthly or per request, and whether ticket references must travel with each charge. Confirm this with finance before the key naming scheme is fixed.
OpenAI-compatible client applications
Applications that already speak the OpenAI request format can be pointed at the gateway with minimal code change, but each client still needs its own virtual key, timeout and retry settings. Inventory which applications call which models today, including scripts and internal tools that may hold direct provider keys. Confirm how clients will be migrated, how stale direct keys will be revoked, and which applications must not be moved until guardrails are tested.
Operational requirements and how to verify high availability
This table lists the operational requirements for a self-hosted LiteLLM gateway and the evidence to request for each one. Read each row as a test to run before go-live, not a feature to assume. The main takeaway is that high availability depends on shared state in Redis and PostgreSQL, so failover tests must cover those components as well as the proxy pods.
| Requirement | What it asks for | How to verify |
|---|---|---|
| Multiple proxy instances | Run more than one LiteLLM proxy instance behind a load balancer so a single pod failure does not stop model access. | Terminate one proxy pod during a load test and confirm requests continue with no sustained error rate for clients. |
| Shared Redis state | Redis 7.0 or newer holds shared rate limits, router state and cache once more than one proxy instance runs. | Confirm an RPM limit set on a key is enforced across all instances, and check that Redis failover does not reset counters incorrectly. |
| PostgreSQL as primary database | PostgreSQL stores virtual keys, budgets and spend records, and virtual keys require it. | Ask for the replication and failover design, then restore a backup to a separate instance and confirm keys, budgets and spend history match. |
| One Uvicorn worker per pod | Run one Uvicorn worker per Kubernetes pod and scale horizontally by adding pods, as LiteLLM recommends. | Review the deployment manifest for the worker setting and confirm the horizontal pod autoscaler scales on load tests. |
| Starting resource sizing | The production guide suggests 1 vCPU and 4 GiB memory per worker as a starting point, to be tuned against real traffic. | Run a load test that reflects expected request volume and record CPU, memory and latency per worker before setting production limits. |
| Spend batching at scale | At scale, spend updates are batched to the database every 60 seconds, so recent spend may lag slightly behind real calls. | Confirm finance and budget owners accept this lag, and test whether a budget cap can be exceeded within one batch window. |
| Upgrade policy | LiteLLM supports the four most recent stable minor versions. Plan upgrades within that window and test each one in staging. | Ask the team to show the current version, the staging test record and the rollback steps for the last two upgrades. |
| Backup and restore | Back up PostgreSQL on a schedule that matches budget and audit needs, and store backups outside the gateway cluster. | Run a restore drill into an isolated environment and record the time taken and any data gaps. |
| Monitoring and alerting | Alert on proxy health, error rates, Redis and database availability, and budget thresholds reached by teams. | Simulate a database outage and a provider outage and confirm alerts reach the on-call team with the expected severity. |
| Edge gateway in front (where used) | If Apache APISIX sits in front, its traditional mode serves client traffic on port 9080 and the Admin API on port 9180, so restrict access to port 9180. | Confirm the Admin API is not reachable from application networks and that configuration changes are logged. |
How to verify the requirements in a proof of concept
This sequence turns the requirements checklist into tested evidence, so the team can see which requirements a gateway meets in its own environment before committing to a platform or an implementation scope. Each step produces a recorded result against a named requirement and a named owner.
Define the requirement list with owners
Before any installation, the security, platform and finance leads agree on the requirement list: model providers and self-hosted models to route to, virtual keys and budgets per team, rate limits, fallback and retries, guardrails and PII filtering, prompt log contents and retention, SSO for the admin UI, and high availability. Each line gets one owner and a pass condition written in plain terms, such as which teams must be blocked from which models. The step is done when every requirement has an owner and a written pass condition that the owner has accepted.
Build a test environment with two gateway instances
The platform team deploys the candidate gateway, such as LiteLLM or Apache APISIX, in the organization's own test infrastructure with two instances behind one endpoint. For LiteLLM, this includes the PostgreSQL database and Redis that shared rate limits and router state depend on once more than one proxy instance runs. Connect at least two model endpoints, including one self-hosted model if that is in scope. The step is done when a request sent to the shared endpoint is answered and both instances appear in the gateway's own health or status view.
Run failover tests against providers and endpoints
The test team disables one provider or endpoint while traffic runs through the gateway, then records whether requests move to the fallback, how many fail before the switch, and how the gateway behaves when the failed endpoint returns. Repeat with a single instance stopped to check high availability. Confirm the retry and cooldown settings match the written requirement. The step is done when the result log shows each failover scenario with the observed behavior and the configured rule that produced it.
Test budget exhaustion and key rotation
Using a test team, the finance and platform owners create a virtual key with a small budget and a restricted model list, send requests until the budget is reached, and confirm the gateway blocks further calls for that key only. They then rotate the key, confirm the old key is refused, and confirm the new key works with the same limits. Check that the gateway's spend records match the test calls. The step is done when the budget block, the model restriction and the rotation outcome are each recorded with a screenshot or log extract.
Confirm log contents and retention with a sample audit
The compliance lead picks a sample of test requests, including some that the guardrails should block or flag, and checks whether the gateway logged the caller, team, model, timestamp, outcome and any PII filter action. They confirm where prompts are stored, who can read them, and how long they are kept, comparing the result with the organization's retention policy and any record-keeping duty that applies. Ask the vendor or partner to confirm which logging features are in the open-source edition and which need an enterprise license. The step is done when the audit sample is traced end to end and any gaps are logged as open findings.
Run an SSO login test for the admin UI
The identity team connects the admin UI to the organization's identity provider, using the protocol and provider the requirement names, and tests login with a standard user, a user without admin rights and a user who has been removed from the directory. They confirm role mapping and that session expiry follows policy. For LiteLLM, the team confirms whether the planned user count falls within the free SSO limit or needs an enterprise license. The step is done when each test account produces the expected access result and the license position is confirmed in writing.
Record results against each requirement
The project lead consolidates the evidence into one table with one row per requirement, listing the test performed, the owner, the observed result, the pass or fail decision, and the open actions. Requirements that fail or are only partly met go to the vendor or implementation partner as written questions with the evidence attached. The step is done when every requirement has a recorded result signed off by its owner, and the table is stored where the assessors and auditors can later retrieve it.
Questions buyers ask about AI gateway requirements and effort
How much effort does an AI gateway requirements review and proof of concept take?
The effort depends mostly on how many model providers, teams and applications the gateway must serve on day one, and on how many identity and logging decisions are still open. A requirements review covers the model inventory, the team and budget map, the data classes allowed per provider, the log retention rule, and the identity model for the admin UI. A proof of concept then tests routing, a virtual key per team, a budget limit, one fallback path and a log export in a non-production environment. Ask any partner for a fixed-scope written proposal that lists the providers, teams, environments and integrations included, the deliverables for each phase, and the acceptance tests. Use that document to compare quotes, since no fair comparison is possible without the same scope.
Can an internal team build a self-hosted AI gateway without outside help?
A capable platform team can deploy LiteLLM or Apache APISIX, but the hard parts are usually operational and governance work rather than installation. The gateway needs a production database, a shared cache for rate limits and router state once more than one instance runs, secret handling for the master key, and a tested upgrade path. It also needs policy decisions that engineering alone cannot make, such as which data classes may reach which provider. Ask the internal team to list the skills it has in Kubernetes, PostgreSQL, Redis, identity federation and API gateway operations. Any gap in that list is a line item in either an internal hiring plan or an outside quote.
What does the gateway project need from our organization before work starts?
The project needs four inputs from your side: identity, network, data owners and a model inventory. For identity, you need the provider that will authenticate admins and, if you use it, the OIDC or SAML details for the admin UI. For the network, you need the subnets, DNS names, egress rules to each model provider and the path to any self-hosted model servers. Data owners must classify which prompts may leave the environment and set retention periods for logs. The model inventory lists every provider, model and internal application that already calls an LLM API, including keys stored in code or spreadsheets. Ask the partner to confirm this list in writing before estimating effort.
Which LiteLLM features need an enterprise license, and what does that mean for SSO and audit logs?
LiteLLM is MIT licensed outside its enterprise directory, and that directory uses its own license. According to the LiteLLM documentation, SSO for the admin UI is free for up to 5 users from v1.76.0, and an Enterprise license is needed beyond that. The Enterprise tier also adds SCIM, JWT authentication with identity provider tokens, audit logs, organization and team RBAC, IP allowlisting, secret manager integrations and team-level guardrails and logging. Confirm the current feature list against the LiteLLM Enterprise documentation and your user count before you budget, because the license is a recurring cost. If audit logs are required by your compliance program, plan for the Enterprise license or build equivalent logging yourself.
Does the AI gateway count as a compliance control on its own?
No. A gateway produces evidence and enforces technical rules, but it does not make an organization compliant. It can record model calls, block unapproved providers, apply budgets and keep logs, and those records can support controls in frameworks such as the EU AI Act record-keeping duties. Assessors still need documented policies, ownership, access reviews, retention decisions and proof that the controls operate over time. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, and independent auditors make that determination. Ask your partner which evidence each control produces and where it is stored.
How should we decide between LiteLLM and Apache APISIX for the gateway?
Choose LiteLLM when the main need is LLM-specific: calling many model providers through an OpenAI-format interface, virtual keys, token and request budgets, and LLM routing with fallback. Choose Apache APISIX when AI traffic must sit inside an existing API gateway estate that already handles authentication, rate limiting and partner access for other APIs, since APISIX is Apache-2.0 licensed and has more than 100 built-in plugins. Many organizations run APISIX at the edge and LiteLLM behind it. Check which budget, key and guardrail functions each option needs from your team, and confirm the current AI plugin behavior in the APISIX documentation before you decide.
What should we request in a quote for an AI gateway implementation?
A useful quote lists each item separately so you can see what is one-time and what recurs. Ask for the scope of providers and self-hosted models, the number of environments, the identity integration, the database and cache design, the high availability design, the guardrail and PII filtering scope, the logging and retention setup, the runbooks, the handover and the support period. Ask which third-party licenses, such as an enterprise license or hosting, are excluded and who buys them. Request the acceptance criteria and the change process for new providers. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen scopes and delivers an AI gateway selection and implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure. For AI gateway requirements, we turn model provider lists, team budgets, logging duties and identity needs into a written scope before any build starts.
How we scope
- Inventory the model providers and self-hosted models the gateway must route to, with the data each one may receive.
- Map virtual keys and budgets to teams, applications and cost centers, and record who approves changes.
- Agree in writing how prompt logs are stored, how long they are retained, and who can read them.
How we build
- Deploy the chosen gateway in the client's cloud account, data center or air-gapped network, with PostgreSQL and Redis where the design needs them.
- Configure routing, retries, fallback order and rate limits, then test failover against each provider in scope.
- Set up guardrails, PII filtering and SSO for the admin UI, and test each control against the written requirements.
How we hand over
- Deliver architecture diagrams, configuration records, the requirements traceability matrix and runbooks for the client's operations team.
- Document which features depend on a license, which secrets live in the client's secret manager, and where logs are kept.
- Walk the client's engineers through key rotation, budget changes, provider onboarding and log export before handover closes.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build.
- Review gateway version changes and provider updates, and retest routing and guardrail behavior after each upgrade.
- Prepare control evidence and configuration exports for internal reviews and external assessments, which auditors and certification bodies issue, not DeployOpen.
