Cloud infrastructure, application support and customer administration have different owners. A credible offer makes those boundaries visible and prices the work required for the supported service.
A defence software company can buy cloud infrastructure and still sell a product whose most important customer responsibilities remain unclear. The infrastructure provider, application vendor, integration partner and end customer may each manage a different part of the service. The commercial offer needs to explain those boundaries in terms the buyer can use.
The question is not simply whether the product runs in a recognised cloud. It is who maintains the application, controls customer access, manages the chosen service configuration and supplies evidence when something changes. Those responsibilities affect staffing, price and the customer's confidence that the purchased service will remain supportable.
The NCSC's cloud shared-responsibility guidance explains that the allocation depends on the service and its implementation. It identifies continuing customer responsibilities for suitability, chosen configurations and the data placed in the service. It also treats a managed service provider as an additional participant whose access and ways of working need consideration.
AWS's own explanation illustrates the distinction with named services. For EC2, it places guest operating-system and installed-application management with the customer. For more abstracted services such as S3 and DynamoDB, AWS manages additional underlying layers while the customer retains responsibilities involving its data and permissions. These examples describe AWS's model; they should not be assumed to define every vendor's finished application offer.
A software supplier may itself be the cloud provider's customer while supplying a managed application to another organisation. In that arrangement, tasks assigned to the cloud customer may belong commercially to the application supplier. A generic diagram with only two parties can conceal this extra relationship.
A useful commercial record identifies the service component, the party carrying out the relevant work and the evidence or communication supplied to the customer. The record should reflect the offer being purchased, rather than an idealised architecture used in a sales presentation.
For example, an application vendor may manage the application release while a specialist partner administers the hosting account. The end customer may manage its own staff identities and decide who can access particular information. The offer should make those roles understandable without requiring the buyer to reconstruct them from several suppliers' documentation.
The distinction between carrying out work and approving it also matters. A supplier may implement a customer-requested change, but the customer remains responsible for deciding that the request is appropriate. Conversely, a customer might approve a maintenance window while the supplier remains responsible for delivering the supported update correctly. A single “shared” label gives little help with either case.
The record need not become a large consulting document. For a bounded application, a concise responsibility table and a named service owner can be sufficient if they cover the material customer decisions. The goal is to remove ambiguity from the offer, not to reproduce every internal task performed by the provider.
Consider a hypothetical maintenance-planning product available as a managed subscription or as software installed in the customer's own cloud account. The feature list may be almost identical. The staffing and assurance burden can be quite different.
In the managed edition, the supplier might undertake application maintenance and the administration of its selected hosting services. In the customer-hosted edition, the buyer may need its own team or another contractor to perform some of those functions. A lower licence price therefore does not establish a lower cost for the working service.
The purchasing comparison should include the duties required to keep each edition within its supported configuration. It should also identify which optional services are necessary for the customer's intended use. Otherwise one offer can appear cheaper because work included by another supplier has been left with the customer without a corresponding estimate.
Our profile of Second Front Systems describes a business operating across software delivery and supporting infrastructure. For any such offer, the buyer should identify the application-specific responsibilities that remain alongside the platform service. A provider's role can be substantial without covering every part of the finished customer workflow.
A cloud provider's assurance material can support confidence in the infrastructure and services within its scope. The customer also needs evidence about how the application supplier uses those services and manages the part of the product it controls. A document covering one layer should remain attached to that layer in the commercial explanation.
This becomes particularly important when a proposal uses several badges or assessment names without explaining their scope. The buyer should be able to identify the assessed organisation or service, the relevant period and the relationship to the purchased edition. A broad claim of compliance is difficult to evaluate if those details remain unstated.
The application supplier can help by organising its evidence around customer questions. Which party maintains the release? How are customer permissions administered? What information is available for the customer's own review? Who reports a material service change? This lets the buyer combine evidence from several layers without mistaking one document for a complete assurance of the assembled service.
The same approach applies to software composition. A maintained SBOM tied to the delivered product can clarify the application boundary, while leaving separately managed platform services documented through their own evidence. The two records should fit together rather than claim identical scope.
A customer experiencing a problem needs a route into the service, even before the responsible layer is known. The supplier should explain who maintains that customer conversation and how it coordinates with infrastructure or integration partners. Requiring the buyer to determine the technical cause before accepting a support request is a weak service design.
The commercial record should distinguish the application's support commitment from the cloud provider's support entitlement. A customer buying a managed application may have no direct relationship with the underlying infrastructure vendor. It needs the application supplier to explain what coordination is included and which information it will receive.
Our guide to vulnerability disclosure and product support examines a related handoff. A newly reported product issue may require assessment across several suppliers. The existence of a well-known cloud provider does not remove the need for the application vendor to maintain release-specific information and an accountable customer contact.
Support arrangements should also address changes in subcontractors. The buyer needs to understand whether a new managed service provider changes access, evidence availability or the customer escalation route. A continuing service can evolve, but its responsibility record should evolve with it.
Even a heavily managed offer leaves the customer with decisions about its users, information and intended use. The supplier can make those decisions easier through clear product defaults, documentation and an intelligible administration experience. Those features have commercial value because they affect the work required to adopt and maintain the service.
During evaluation, the buyer can follow one ordinary business change through the proposed arrangement, such as a new team joining the application or an integration being retired. The exercise should identify who requests the change, who performs it, what record remains and how the supported service boundary is maintained. It need not involve security probing or access to live customer data.
A strong cloud software offer makes responsibility visible at the point of purchase. It connects infrastructure, application and customer duties to real service commitments and evidence. That allows buyers to compare total adoption effort and gives suppliers a clearer basis for pricing the work they actually undertake.
NCSC provides the general framework and AWS supplies named service examples. Neither source is presented as certifying a particular defence application; the commercial analysis is BDI interpretation.
Suggest a correction