About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
An independent software vendor (ISV) hosting an application needs two responsibility agreements: one with its infrastructure supplier and another with its customer. Name who maintains each component, who leads an incident, and who can approve a change. These can be different people.
For ordinary infrastructure as a service (IaaS), the ISV normally manages the guest operating system and application. Buying a virtual machine does not, by itself, buy guest OS patching. A managed-OS service can delegate specified work to the host, but its scope must be explicit. Keep the customer-facing incident owner in place while technical teams investigate.
Start with the service actually purchased
NIST SP 800-145 distinguishes infrastructure, platform and software services by the capabilities supplied and the controls retained by the consumer. It is a vocabulary for comparing services, not a substitute for your support agreement.
Microsoft's shared responsibility guidance makes the IaaS boundary explicit: the customer manages virtual machines, operating systems and applications. In its PaaS model, the provider manages the underlying OS while the customer deploys applications. Data, identities and customer-controlled configuration still require customer attention. This is Azure guidance; another provider's product and contract must be checked separately.
An ISV is the infrastructure customer's operator on one side and the software customer's service provider on the other. For example, a host may keep a managed database engine patched while the ISV owns schema changes, query behaviour and application compatibility. The business customer may control its identity provider and staff devices. Nobody should infer the complete support boundary from the word “cloud”.
Separate four kinds of ownership
Use a responsibility matrix with named teams and contacts. The following distinctions are our recommended operating model:
| Responsibility | Question the agreement must answer |
|---|---|
| Maintenance | Who patches, renews, monitors and tests this component? |
| Initial investigation | Who gathers the first evidence and starts diagnosis? |
| Remediation | Who has permission and capability to repair it? |
| Customer communication | Who gives updates and confirms restored service? |
A RACI chart can record who is responsible, accountable, consulted and informed. Do not let the chart obscure operational detail: a team name without an out-of-hours contact, access route and escalation trigger will not help during an incident.
For each component, record its owner, service coverage, maintenance notice requirements, change approver, emergency authority and acceptance test. Include the guest OS, endpoint protection, application, database, certificates, DNS, network controls, backups and integrations. These are suggested checklist entries, not a claim that a particular provider includes them.
Route symptoms without assigning blame
A symptom identifies where investigation can begin. It does not prove which organisation caused the fault.
| Observed symptom | Suggested first investigation | Evidence to exchange |
|---|---|---|
| Application returns HTTP 500 | ISV application support | Correlation ID, affected operation, timestamp and redacted application error |
| Database connections fail after maintenance | ISV and relevant database operator | Connection error, maintenance changes and independent service checks |
| Certificate warning | Operator of the endpoint presenting that certificate | Hostname, expiry, certificate chain and where TLS terminates |
| Guest OS disk is full | Named guest-OS operator, with application owner | Volume, growth pattern, large-file ownership and agreed retention |
| Customer-site connection fails | Both endpoint network teams | Affected paths, time window, tunnel/routing state and permitted diagnostic results |
| Federated sign-in fails | ISV identity integration owner and customer identity team | Sign-in event, correlation ID, tenant and mapping changes |
For a full guest disk, the hosting supplier might provide the storage while the ISV controls application log growth. Neither fact alone establishes the cause. Do not delete files or expand disks merely to close the ticket; use the authorised change process and preserve evidence.
Request only the information needed. Redact credentials, tokens and unrelated customer content. Agree how sensitive diagnostic material is transferred, retained and removed.
A worked incident example
Consider an illustrative hosted invoicing application that starts returning errors after a maintenance window. No real customer incident is being described.
The ISV remains the customer-facing incident lead. Its engineer identifies database connection failures and supplies the time window and correlation IDs. The database operator checks service health and the changes made during maintenance. The network operator checks the specific permitted path if the connection evidence points there.
If investigation identifies an application configuration error, the ISV proposes and tests the correction. If it identifies a platform fault, the platform operator owns that repair. The timing of maintenance is a useful lead, not proof of causation. After a repair, the ISV validates representative business transactions with the customer; a running service alone does not establish that invoicing works.
The useful outcome is an agreed investigation path that can change with evidence, while one person remains responsible for communicating progress.
Agree emergency boundaries before an outage
Document who may isolate a workload, revoke an account, block a network path or restart a component. Specify when customer approval is required and how emergency action is recorded. Avoid a vague grant to “do whatever is needed”, particularly where shared systems could affect other customers.
Our recommendation is to rehearse a small incident scenario using synthetic evidence. Check that contacts respond, required logs are accessible, decision authority is clear and each handoff preserves context. Do not turn a rehearsal into an unapproved production fault injection.
Where several suppliers provide out-of-hours support, confirm how their coverage fits together. A support label alone does not establish a joint response time. Record the actual contracted targets and their conditions rather than inventing a combined guarantee.
What to put in the agreement
Before accepting a hosting arrangement, resolve these questions in writing:
- Is guest OS management included, and which patching, testing and rollback tasks does it cover?
- Who operates each application dependency and manages its privileged access?
- Who leads a multi-supplier incident and communicates with the business customer?
- What evidence and escalation contacts are available outside normal hours?
- Who authorises emergency changes, and how is business recovery verified?
- Which responsibilities remain with the customer, including identity, devices and integrations?
Software vendor hosting is the relevant service area for discussing these requirements. This article does not assert a particular NetLeverage support package or response commitment.
Limits and sources
This is source-researched planning guidance, not a tested incident runbook or legal interpretation. The example matrix is an editorial starting point. Your actual architecture, contract and delegated authority determine the working boundary.
- NIST SP 800-145: The NIST Definition of Cloud Computing, September 2011. Service-model definitions; accessed 14 November 2026.
- Microsoft: Shared responsibility in the cloud, accessed 14 November 2026. Azure governance guidance; its matrix does not amend a contract.
Learning notes
Guest OS management is not automatically included with IaaS. Initial investigation, technical repair and customer communication need separate owners. A useful handoff carries evidence without abandoning the customer's incident.
This article was originally published on .