“The Provider Handles That” Anti-Pattern

“The provider handles that” is the most common shared-responsibility anti-pattern because it turns ambiguity into default trust. A team sees that a workload runs on a managed platform and silently assumes the provider now owns adjacent controls like guest hardening, log retention, tenant configuration, identity governance, key rotation, or incident response. The control is not transferred. It is merely forgotten.

This assumption is dangerous because it feels reasonable in the moment. Managed services are real. Provider-owned controls are real. But the anti-pattern appears when a team stops asking where the boundary actually sits and begins treating any abstracted layer as fully provider-owned.

The failure path usually looks like this:

    flowchart LR
	    A["Managed service or cloud feature"] --> B["Assumption that provider owns adjacent controls"]
	    B --> C["Customer control left unassigned"]
	    C --> D["Gap in operation, evidence, or response"]
	    D --> E["Preventable incident or audit finding"]

What to notice:

• the anti-pattern starts with a mental shortcut, not a technical failure
• a control gap appears before the incident does
• the provider may be operating its side correctly while the customer side goes unowned

Why Teams Fall Into It

Teams fall into this pattern when:

• the service is more abstract than what they used before
• provider documentation is read at a marketing level instead of an operational level
• the organization has not built control maps for each service model
• nobody asks who proves the control is working

The key mistake is confusing provider capability with provider accountability for the customer’s workload.

A Practical Ownership Check

 1ownership_check:
 2  control: audit_log_retention
 3  service: managed_database
 4  provider_owns:
 5    - database_service_operations
 6  customer_owns:
 7    - enablement_of_relevant_logs
 8    - retention_period
 9    - alerting_and_review
10  evidence_required:
11    - logging_configuration
12    - retention_policy
13    - review_record

What this demonstrates:

• even a highly managed service still needs explicit control mapping
• the strongest way to defeat the anti-pattern is to name evidence, not just owners
• if the customer cannot point to evidence, the control is probably not truly owned

The Anti-Pattern Usually Appears in Ordinary Language

Teams rarely announce that they are abandoning ownership. They say things that sound efficient and reasonable:

• “The vendor covers that now.”
• “It is a managed service, so the security pieces are built in.”
• “The platform team turned it on, so we inherit it.”
• “The provider has a certification, so that part should be fine.”

Those sentences are dangerous because they hide the missing question: which part is actually provider-operated, and which part still depends on customer configuration, review, evidence, or response? The anti-pattern is therefore often detectable long before an incident, simply by listening to how teams explain the boundary.

Common Mistakes

• assuming managed means fully outsourced
• using provider health or certification claims as proof of customer-side control performance
• failing to document customer responsibilities for each service model
• discovering ownership questions only after an incident or audit request

A Stronger Replacement Habit

The most effective replacement for this anti-pattern is a forced boundary statement during design and review work. Instead of saying “the provider handles that,” teams should be pushed to say:

• which layer the provider operates
• which customer configuration or workflow still activates the control
• which team reviews the control and how often
• which evidence proves it is working

That habit changes the conversation from assumption to operable ownership. It also exposes when the control is not actually understood yet, which is valuable information before the system reaches production.

Design Review Question

A platform team moves a workload onto a managed data service and says backup, encryption, logging, and access review are now mostly the provider’s concern because the service is fully managed. The team has not documented which parts still require customer configuration or review. Is that a strong interpretation?

No. The stronger answer is that managed services change the boundary, but they do not erase the need to map customer-owned controls explicitly. If ownership is not named and evidenced, the anti-pattern is already present.

Check Your Understanding