The buyer remains accountable for the runtime environment, because the licence does not transfer infrastructure ownership. The vendor may support the software, but patching, database operations, availability, and incident handling still sit with the organisation.
Who owns the runtime when support and hosting are split?
Accountability stays with the organisation that runs the gateway. A vendor-supported enterprise licence can change who helps troubleshoot or how fixes are delivered, but it does not move operational ownership away from the buyer. If the gateway is self-hosted, the enterprise still owns the environment that keeps it patched, available, monitored, and recoverable.
The practical distinction is between software support and service accountability. Vendor support may cover defect handling, guidance, and escalation paths, while the enterprise remains responsible for the database, host OS, backups, network exposure, and incident response. That division matters because the failure of any of those components is still an enterprise risk, even when the gateway product itself is licensed and supported externally.
When teams confuse licence support with infrastructure ownership, they often under-estimate who must approve change, who must restore service, and who must answer for downtime. The support contract can help reduce mean time to resolution, but it does not remove the need for local operational control over configuration, patch cadence, and recovery readiness.
What changes when the vendor supports the software but not the environment?
The answer changes very little in governance terms and a lot in operating terms. The vendor may be the party that understands product defects best, but the enterprise still decides how the gateway is deployed, which network boundaries it sits behind, which credentials it uses, and how it is recovered after failure.
This split creates a shared-responsibility pattern: support is externalised, control is not. The organisation needs named owners for the runtime stack, because support tickets do not close gaps in patching, backup integrity, or service continuity. If the gateway depends on a database or reverse proxy, those dependencies also remain part of the buyer’s accountability chain.
For self-hosted gateways, the strongest operational assumption is simple: if the enterprise can interrupt it, misconfigure it, or leave it exposed, the enterprise owns the consequence. That includes maintenance windows, failover design, certificate renewal, and the decision to accept degraded service during an incident.
What accountability should be documented in the contract and runbook?
Teams should document who owns patching, who owns backups, who approves emergency changes, and who leads incident coordination. The contract may define support entitlements, but the runbook should define operational custody. That is especially important for escalation, because a fast vendor response is not the same thing as a restored service.
- Define the runtime owner for the gateway host, database, and network path.
- Record the patch and upgrade cadence, including who can authorise emergency maintenance.
- State who tests restore procedures and how often recovery evidence is reviewed.
- Assign incident lead responsibility, including communication with the vendor and business stakeholders.
This division is easier to manage when the operational boundary is explicit. If the vendor is only supporting the product, the organisation should treat the gateway like any other self-managed production service, with internal accountability for availability, change control, and incident closure.
Risk and Threat Considerations
Self-hosted, vendor-supported deployments often fail at the boundary between responsibility and expectation. The most common exposure is that teams assume support implies operational safety, then delay patching, weaken monitoring, or leave recovery paths untested until the first serious outage or compromise.
Failure mechanism: Support coverage can mask local ownership gaps, especially where the gateway sits on an underspecified host, stale database, or weakly monitored network segment. If the environment is not actively managed, service failure or compromise still lands on the enterprise even when the software publisher is engaged.
Impact: The result can be prolonged downtime, incomplete recovery, delayed containment, and confusion over who is authorised to act. In security incidents, that confusion increases blast radius because the team may wait for vendor input before rotating credentials, isolating the host, or restoring service from backup.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SA-9 — External System Services | The gateway is vendor-supported but self-hosted, so service responsibilities must be contractually defined. |
| CP-10 — System Recovery and Reconstitution | Self-hosted runtime ownership includes restoring the gateway and its dependencies after failure. | |
| Recommendation — Define vendor support boundaries and retain internal ownership for patching, recovery, and availability. Test restore procedures and keep recovery evidence for the gateway stack and database. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Vendor support makes supplier responsibility and escalation terms material to the operating model. |
| A.8.14 — Redundancy of information processing facilities | Availability of a self-hosted gateway depends on the buyer’s resilience and failover design. | |
| Recommendation — Document supplier support terms without transferring operational accountability for the hosted environment. Build redundancy and failover for the self-hosted gateway and its dependencies. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | The buyer controls hardening and maintenance of the self-hosted runtime. |
| Recommendation — Maintain secure configuration and patching for the gateway host and supporting services. | ||
Practitioner Guidance
What to verify: Confirm that the operating model names a clear owner for patching, backup restore, uptime, and incident response. If those duties are not explicitly assigned, the support contract is probably being over-read.
Decision rule: If the gateway is self-hosted, treat it as an internal production service regardless of who supplies the licence. Use vendor support as an escalation path, not as a substitute for local operational control.
What good looks like: The organisation can show who approves changes, who restores service, and who can execute emergency remediation without waiting for contractual clarification.
Practitioner takeaway: Support can improve response quality, but accountability follows the runtime owner; if the enterprise runs the gateway, it owns the outage, the patch, and the recovery.
Related resources from NHI Mgmt Group
- What is the difference between a self-hosted AI gateway and a broader enterprise AI control plane?
- Why is single-provider AI agent governance not enough for enterprise security?
- How should security teams treat self-hosted SSO in enterprise environments?
- Who is accountable for authorization in a self-hosted deployment?