Shared Responsibility and Service Model Boundaries at a Hybrid Insurer
Northvale Insurance runs its policy administration system on 620 virtual machines across two owned data centres. A central cloud centre of excellence proposes managed Kubernetes (containers-as-a-service) on provider A for a new claims portal, provider B object storage for scanned documents, and a SaaS CRM. Annual cloud spend is $4.2M, and an internal audit reports 14% waste, 38% of resources without an owner tag, and 11 orphaned load balancers. The application team argues that because the provider patches the worker nodes operating system, the team no longer needs CIS hardening or vulnerability scanning. Security insists all nodes be scanned by an on-premises tool that cannot route to private subnets. Two business units already run production workloads in provider A without centre-of-excellence involvement. The CIO wants a 90-day decision on the target operating model and accountability boundaries.
1. Classify each of the three offerings (managed Kubernetes, object storage, SaaS CRM) on the IaaS-PaaS-SaaS spectrum and state the practical shared-responsibility boundary for each. Explain why the application team's claim about CIS hardening is only partly correct.
Read the worked answer
Managed Kubernetes sits between IaaS and PaaS: the provider owns the control plane, physical hosts, and often the node image patching, while the customer owns workload configuration, images, admission control, network policies, identity bindings, secrets, and data. Object storage is closer to IaaS/PaaS: the provider owns durability and infrastructure, but the customer owns bucket policies, encryption-key choices, classification, lifecycle, and public-access settings. SaaS CRM shifts application maintenance to the vendor, but the customer still owns identity lifecycle, data classification, integration security, configuration, and retention.
The team's claim is only partly correct because responsibility is allocated, not eliminated. If the provider patches the node OS, the customer still must harden the Kubernetes layer: restrict privileged containers, enforce pod security standards, scan images, control network egress, and audit RBAC. CIS hardening shifts from host benchmarks to Kubernetes and workload benchmarks. The on-premises scanner that cannot reach private subnets is also a design constraint: either use an agentless or API-based scanning model, private connectivity, or a scanner deployed inside the account. Keeping a tool that cannot see the estate creates false assurance.
For the 90-day decision, map each offering to a responsibility matrix with named owners: platform team for cluster baseline, application teams for workloads and data, security for control validation, procurement for contract terms. The presence of unsanctioned production workloads means the operating model must include account vending, exception handling, and audit rights, not just a service catalogue.
2. Recommend decision rights and a RACI for the tagging and orphaned-resource problem, and specify two guardrails that would prevent recurrence without slowing delivery.
Read the worked answer
Tagging fails when it is treated as a reporting exercise rather than a provisioning control. Decision rights should be split: the cloud centre of excellence owns the tag taxonomy and policy-as-code; finance owns the cost allocation rules and showback; each application team owns the lifecycle and correctness of its resources; security owns validation of sensitive-data and exposure tags; internal audit samples compliance. In RACI terms, the platform team is accountable for enforcing tags at account and pipeline level, application owners are accountable for resource-level values, and FinOps is consulted on allocation logic.
The first guardrail is preventive: infrastructure-as-code pipelines reject production resources that lack mandatory owner, cost-centre, environment, and data-classification tags. Console creation is limited to break-glass roles with automatic notification and a 24-hour remediation window. The second guardrail is detective with a deadline: a daily orphan report identifies unattached load balancers, idle addresses, and untagged resources, notifies the named owner, and moves resources into a 14-day termination queue unless ownership is confirmed. This avoids both silent waste and surprise deletion.
These controls address the audit findings because 38% untagged and 11 orphaned load balancers are symptoms of missing provisioning controls and unclear ownership. A monthly tag-compliance report alone would not have prevented them. The guardrails should be piloted on the claims portal, then extended to provider B storage and the SaaS CRM integration so that the same ownership model applies across service models.