What the Customer Still Owns Even With Managed Services
Goal
This section turns shared responsibility into a review method. A managed service is ready for production only when the team can name, implement, and verify the responsibilities that remain.
The Durable Customer Responsibilities
Business intent and risk
The customer defines what the workload is allowed to do, what failure means, and which legal or contractual obligations apply. A provider cannot decide the acceptable loss of orders, exposure of records, or length of an outage.
Identity and authorization
The customer controls who may administer the service and which workloads may use its data plane. This includes federation, role design, least privilege, credential lifecycle, privileged access, and periodic review.
Data and privacy
The customer classifies data, selects allowed locations, controls collection and retention, configures protection features, and decides recovery requirements. It must understand how data enters, leaves, is copied, and is deleted.
Configuration and integration
Managed services expose choices for network access, encryption, versions, scaling, backups, logging, and retention. Defaults are not a workload-specific design. Integrations can also bypass an otherwise sound boundary.
Application behavior
The customer owns code, dependencies, schemas, input validation, authorization logic, retry behavior, and handling of partial failure. A reliable managed component cannot make an unsafe application reliable.
Operations, recovery, and cost
The customer needs service-level indicators, actionable alerts, incident ownership, capacity and quota awareness, restore tests, change procedures, budgets, and usage review. Provider health information is an input to operations, not the entire operating model.
Scenario: The "Fully Managed" Order Store
A product team selects a managed database and reports that backups, security, scaling, and availability are solved. A readiness review asks for evidence:
| Claim | Review question | Required evidence |
|---|---|---|
| Backups are solved | Can an order be restored within the required time and loss tolerance? | Retention configuration and restore-test result |
| Security is solved | Which identities can administer or query production data? | Role assignments, access review, and audit logs |
| Scaling is solved | What happens at quotas or downstream bottlenecks? | Load test and quota/capacity plan |
| Availability is solved | How does the application behave when the database is slow or unavailable? | Timeout, retry, degradation, and recovery test |
| Cost is solved | Who sees abnormal usage and can act? | Budget signal, owner, and response procedure |
The review does not reject the managed database. It makes the service usable by connecting provider capabilities to customer-owned outcomes.
A Production-Readiness Test
Before approving a managed service, ask:
Who owns the business outcome and service configuration?
Which human and workload identities can use each plane?
What data enters the service, where can it reside, and how is it removed?
Which failure modes must the application handle?
Which signals prove healthy, secure, and cost-appropriate operation?
How are configuration and data restored?
Which provider limits, maintenance events, or regional dependencies matter?
When was the full recovery and incident path last exercised?
Common Mistakes
Listing enabled features as evidence that outcomes are met.
Monitoring provider uptime but not the user journey.
Delegating platform operations while leaving no internal service owner.
Assuming automated recovery has been tested because it is documented.
If Someone Asks You
What does the customer still own with managed services?
The customer owns business risk, identities, data use, configuration intent, application behavior, integration, monitoring, recovery validation, and cost. The provider can operate more layers, but the customer must connect those layers into a safe workload.
What You Should Remember
Managed services remove tasks; they do not remove customer accountability.
Questions to Check Your Understanding
Why is an enabled backup feature not sufficient recovery evidence?
Which responsibilities connect provider availability to user-visible reliability?
What should a managed-service readiness review produce?
Further Study
AWS Shared Responsibility Model - Use the service-dependent responsibility guidance during workload reviews.
Shared responsibility in the cloud - Review the responsibilities Microsoft identifies as customer-owned across service types.