sourcing · version 2026.1

Internal Team vs MSP Responsibility Model

A retained-organization view that separates internal accountability from delegated provider execution.

Internal Team vs MSP Responsibility Model. A retained-organization view that separates internal accountability from delegated provider execution.
PNG preview2400 × 1018 px26 KBVersion 2026.1 · reviewed 2026-09-08
Explore semantic layers
Internal Team vs MSP Responsibility Model previewdelegatessets constraintssets conditionsreportsperformanceretained oversightInternal service owner: Outcome accountabilityInternal service ownerOutcome accountabilityInternal architecture authority: Technical decisionsInternal architecture authorityTechnical decisionsInternal risk authority: Risk acceptanceInternal risk authorityRisk acceptanceVendor management: Performance and escalationVendor managementPerformance and escalationManaged service provider: Delegated build / run executionManaged service providerDelegated build / run executionProvider evidence: Performance, controls, actionsProvider evidencePerformance, controls, actions
Accessible diagram transcript

Objects

  • Internal service owner: Outcome accountability (Service ownership)
  • Internal architecture authority: Technical decisions (Authorities)
  • Internal risk authority: Risk acceptance (Authorities)
  • Vendor management: Performance and escalation (Governance)
  • Managed service provider: Delegated build / run execution (Providers)
  • Provider evidence: Performance, controls, actions (Operations)

Directed relationships

  • ownermsp: delegates (handoff)
  • architecturemsp: sets constraints (authority)
  • riskmsp: sets conditions (authority)
  • mspevidence: reports (handoff)
  • evidencevendor: performance (handoff)
  • ownerevidence: retained oversight (accountability)
01

When to use it

Use before finalizing an MSP scope, RFP or operating responsibility matrix.

02

What to challenge

  • Separate accountable authority from delivery execution.
  • Make every important handoff directional and reviewable.
  • Treat this reference pattern as a starting point, not a prescription.
03

Adapt it responsibly

  1. Rename functions to match the organization vocabulary.
  2. Remove elements that are genuinely out of scope.
  3. Validate decision rights and handoffs with accountable stakeholders.
04

Model contents

6 objects and 6 directed relationships. Every object keeps a stable semantic ID.

One model, multiple representations

The browser view and editable file are generated from the same canonical graph, so labels, roles and relationship direction stay aligned.

Clear visual grammar

Shape, color and connector style distinguish actors, governance, authorities, services, engineering, operations and providers.

Make this model your own.

Rename objects, adjust the scope and download an editable version. Your changes stay in this browser; no account is required.

Customize this diagram