When software is hosted in the cloud, security and reliability duties do not vanish. They are divided. The shared responsibility model describes that division: which party designs, operates, monitors, and remains accountable for each layer, from physical facilities to application logic and data. Mapping the model for hosted software is a control-by-control assignment, not a marketing diagram. The boundary moves with the service model, with configuration choices, and with the sensitivity of the data the software processes. Organizations that treat the map as an operating document reduce the gap between what they assume is covered and what they still must do. Those that treat it as a vendor slide leave identity, encryption, backups, and incident response unowned when an event occurs.
Sourced factual references
Title: Shared responsibility in the cloud - Microsoft Azure ([source](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility)).
Title: Shared Responsibility Model - Amazon Web Services (AWS) ([source](https://aws.amazon.com/compliance/shared-responsibility-model/)).
Title: What Is a Shared Responsibility Model? ([source](https://www.zscaler.com/fr/resources/security-terms-glossary/what-is-shared-responsibility-model)).
> **Key points** > > - The software owner remains accountable for data, identities, access decisions, and tenant configuration even when another party operates the infrastructure. > - The service model shifts who performs day-to-day work, but it does not transfer business, legal, or customer-facing risk. > - A usable map names an internal owner or a contractual duty for every control, then tests that assignment with logging, restoration, and incident drills.
Why the model exists and what it does not transfer
The model exists because hosting separates ownership of facilities and hardware from ownership of business processes and records. A software owner that once ran servers in a private data center previously held every layer: building access, power, hardware lifecycle, hypervisor, operating system, network path, identity, application code, and data. Once those servers are replaced by a remote service, some layers become the hosting party’s job. Others remain with the software owner. Confusion appears when teams assume that “in the cloud” means that someone else has already secured the workload.
The model does not transfer business risk. If customer data is exposed because an application role was over-privileged, the software owner still faces contractual, legal, and reputational consequences even if another party operated the underlying compute. The model also does not automatically assign a control just because a service includes a feature. Encryption at rest may be available, and it may even be enabled by default, yet key custody, rotation, and access to plaintext may still sit with the customer. Availability language in a service description does not replace application-level backup, recovery objectives, or the duty to test restoration.
A useful way to read the model is as a division of labor plus a division of accountability. Labor can be outsourced. Accountability for outcomes that affect customers, employees, and regulated records generally cannot. Mapping therefore needs two columns that should not be collapsed: who performs the control, and who is accountable if the control fails. When those columns differ, the accountable party still needs evidence that the performing party did the work, on a schedule, and with a defined exception path.
Conditions that change the map include the service model, shared tenancy, customer-managed cryptographic keys, customer-supplied identities, custom code, and any integration the software owner deploys. None of these conditions should be inferred from a generic picture. They should be read from the actual service description, the configuration in use, and the data flows of the hosted software. If a control cannot be evidenced, it is not mapped; it is hoped for.
How the service model moves the operational boundary
The service model is the coarsest, and most useful, first cut of the map. Infrastructure-style hosting typically leaves the customer with the operating system, runtime, network configuration inside the virtual boundary, identity of users and workloads, application stack, and data. The hosting party typically retains physical facilities, hardware lifecycle, and isolation of the compute fabric. Platform-style hosting usually lifts operating-system patching and some middleware. Application-style hosting usually lifts the application itself, leaving the customer with tenant configuration, identity federation, data classification, user access, and often encryption-key choices.
These are typical patterns, not guarantees. Two offerings in the same category can place logging, backup, or network filtering on different sides of the line. The map must follow the actual service, not the category label. A platform that patches the operating system but leaves database firewall rules, backup retention, and administrative roles entirely to the tenant is not “fully managed” for those controls, regardless of how the catalog describes it.
The main trade-off is operational load versus inspectability. More managed service usually means fewer patching tasks and a smaller customer-operated surface. It also usually means less ability to insert custom controls, less access to raw logs, and slower or narrower forensic access after an incident. Less managed service means more control and more work. Teams should choose the boundary based on skills, recovery needs, and the requirement to inspect or customize, not based on a preference for a fashionable category.
Implementation starts with an inventory of hosted components, not with a single company-wide slogan. For each component, record the service model in use, list layers from facility to data, and mark who operates each layer. Then mark residual customer duties that survive even in the most managed models: identity, access reviews, data retention, lawful processing, vendor oversight, and secure configuration of whatever the tenant can still change. Where a component is composed of several services, map each service; a single “cloud” row hides the places where duties actually split.
Controls that remain with the software owner
Regardless of hosting style, several control families almost always remain with the software owner. Data classification and handling sit here: what may be stored, where it may be stored, how long it is kept, who may see it, and when it must be deleted. Hosting does not classify records. The owner of the software and of the business process does. If classification is vague, encryption, access, and retention decisions will be vague as well.
Identity and access management sit here too. The hosting party may provide directories, tokens, or role primitives. The software owner still decides who is a user, who is an administrator, which workloads may call which interfaces, and how quickly access is removed when a role changes. Over-broad tenant-admin roles, long-lived secrets in application configuration, and unused service accounts are customer-owned failures even when the directory service is operated elsewhere.
Application configuration and custom code remain customer-owned whenever the customer can change them. That includes feature flags, integration endpoints, storage locations, logging verbosity, and any extension or script the tenant deploys. A secure platform with an insecure tenant configuration is still an insecure system. The map should list every configuration surface the tenant can touch and assign an owner, a change process, and a review cadence.
Endpoint and client-side hygiene often sit outside the hosting contract entirely. Users still authenticate from devices the hosting party does not control. If the software is reachable from unmanaged devices, the residual risk belongs to the software owner unless a separate control (conditional access, managed devices, or equivalent) is explicitly in place. Backup of tenant data, export, and restoration testing likewise remain customer duties unless the contract states a restoration objective the customer can actually invoke and verify.
Vendor oversight is a customer control. Due diligence, contract clauses, subprocessors, data location, and the right to receive incident notice do not become automatic because a workload moved. The map should show which internal role owns the commercial relationship and which internal role owns technical assurance, because those are frequently different people.
Controls that typically stay with the hosting party
Physical and environmental security typically stay with the hosting party: facilities, power, cooling, hardware destruction, and physical access to racks. Customers generally cannot and should not attempt to operate those controls themselves. What they can do is require contractual statements, independent assurance reports where available, and a clear notice path if those controls fail.
The compute and storage fabric below the customer-visible interface typically stays with the hosting party as well: hardware lifecycle, hypervisor or equivalent isolation, and the availability of the underlying regional infrastructure. Customers remain responsible for using those primitives correctly—choosing regions, configuring redundancy, and not assuming that a single instance is a resilient design.
For platform and application hosting, operating-system patching, some middleware hardening, and the security of the provider-operated control plane usually sit with the hosting party. The customer still must confirm what “usually” means in the actual service description. If patch windows, shared-tenancy isolation, or control-plane authentication are described only in general language, the map should record that uncertainty rather than convert it into a false assignment.
Trade-offs appear when customers ask the hosting party to take more of the stack. That can reduce toil, but it can also concentrate failure modes and reduce the customer’s ability to compensate for a provider outage with its own runbooks. Dual-running a control (for example, customer backups in addition to provider backups) is often rational for high-value data. Duplicating a control without a recovery objective is waste. The map should state, for each duplicated control, which copy is authoritative in an incident.
Customers should not treat provider-operated logging as a complete audit trail. Provider logs often cover the control plane and infrastructure events. Application logs, data-access logs, and business-process traces frequently remain a customer design problem. If an investigation would need to answer “who viewed this record,” the map must show where that evidence is produced and who retains it.
Building a control map teams can operate
A publication-ready map is a table that operations, security, legal, and engineering can all read. Rows are controls or control objectives, not technologies. Columns should include at least: control name, layer of the stack, who performs the work, who is accountable, evidence produced, review frequency, and residual customer action. Optional columns that repay the effort are data types in scope, environments (production versus non-production), and the contract clause or service description paragraph that supports the assignment.
Start from data flows, not from a blank framework. Identify the software’s users, administrators, integrations, stored records, secrets, and administrative interfaces. For each flow, list the components it touches. For each component, apply the service-model cut, then walk the layers. Assign every layer. Unassigned layers are the usual source of incidents that later get described as “a cloud misconfiguration.”
Keep language operational. “Provider” and “customer” are too coarse once more than one internal team is involved. Replace “customer” with a function: application engineering, identity operations, data protection, procurement, or incident command. A control with three implied owners has no owner. Where a provider performs the work, name the service and the internal role that checks the evidence. The internal role is what you can manage in a performance review; the provider is what you can manage in a contract.
Use qualitative criteria when evidence is incomplete. If a service description does not state who rotates keys, write “unverified — treat as customer until confirmed” rather than guessing. If restoration has never been tested, write “backup exists; restore unproven.” Conditional wording is more honest than a green status. Status colors without tests train leaders to trust the map more than the map deserves.
Short lists help only for the inventory of residual customer duties that almost always appear:
- Identity lifecycle, privileged access, and secret storage - Tenant configuration, custom code, and integration security - Data classification, retention, encryption-key custody, and lawful deletion - Backup restore tests, incident detection using customer-visible logs, and vendor notice handling
Develop the rest in the table and in runbooks. A map that is only a list of slogans will not survive a real event.
Governance, evidence, and incident use of the map
The map earns its keep when it is used outside the security team. Change management should refuse a new hosted component that cannot be placed on the map. Procurement should refuse a contract that leaves encryption, logging, or incident notice unstated if those controls are material to the software. Engineering should refuse a production release whose administrative interface has no named access owner. These gates are process, not tooling. They work only if the map is short enough to read and specific enough to argue with.
Evidence should match the assignment. If the hosting party performs a control, the customer still needs a way to know it was performed: assurance reports, configuration exports, health dashboards, or ticketed attestations, according to what the contract actually provides. If the customer performs a control, evidence is logs, tickets, review records, and test results. Do not invent a reporting cadence the provider does not offer; record the cadence that exists and the gap that remains.
Incidents are the hardest test. Before an event, the map should answer who can isolate a tenant, who can rotate keys, who can pull logs, who can notify customers, and how long each of those actions is expected to take. During an event, teams should not renegotiate the model. They should execute the assignments. After an event, the map should be updated where reality disagreed with the document. A control that could not be performed in the time assumed was mis-assigned or under-resourced.
Trade-offs in governance are real. A detailed map that is updated quarterly is more useful than a perfect map that is stale. Over-centralizing the map in one function produces a document nobody else trusts. Over-distributing it produces inconsistent assignments. A practical pattern is a single canonical table with named row owners and a scheduled review tied to architecture changes, not only to the calendar.
None of this requires a particular product. It requires inventory, contracts read as control documents, and the discipline to treat unowned layers as open risk. The shared responsibility model is simple to draw and easy to misuse. Mapping it for hosted software means writing down, in language an operator can execute, which duties moved, which duties never moved, and which duties are still unverified. When that record is current, hosting can reduce toil without creating a silent gap between the software and the people who are still accountable for it.