---
title: "MSP Governance and Partner Management"
description: "How organisations select, manage and contractually secure managed service providers for cloud operations on STACKIT — without losing operational control."
sidebar:
order: 8
label: "MSP Governance"
source_url: "https://framework.stackit.cloud/adoption/adapting-operating-models/msp-governance/"
source_file: "docs/adoption/adapting-operating-models/msp-governance.mdx"
---
## Why MSP governance is often underestimated
Many organisations decide to outsource parts of their cloud operations to a managed service provider (MSP). The decision is often correct — operations become more reliable, and internal teams can focus on strategic topics.
What is frequently underestimated: governing the MSP relationship is itself a demanding task. Anyone who does not build a structured steering process gradually loses control of their own cloud environment — without noticing.
## What an MSP typically takes over
**Operational tasks MSPs frequently assume:**
- Monitoring and alerting: 24/7 surveillance of infrastructure and applications
- Incident response: first response and escalation for production incidents
- Patch management: OS updates, security patches, Kubernetes upgrades
- Backup management: backup verification, recovery tests, retention management
- Compliance reporting: creation of audit evidence for regulatory reviews
- Cost optimisation: monitoring for resource waste, rightsizing recommendations
**What should remain internal:**
- Strategic cloud decisions (architecture, provider selection, investments)
- Access management and IAM configuration (no root delegation to MSPs)
- Data protection and GDPR responsibility (accountability cannot be delegated)
- Budget responsibility and FinOps decisions
- Crisis management and communication with regulators
## The four critical governance elements
### 1. Contract structure and SLAs
An MSP contract must cover more than price and scope. Critical contract elements:
**Service Level Agreement (SLA):**
- Availability SLA for the managed service (typical: 99.5% to 99.9%)
- Response time by severity (P1: 15 minutes, P2: 1 hour, P3: 4 hours)
- Resolution time targets with escalation path
- SLA reporting frequency and format
**Penalties and credits:**
Without economic consequences for SLA violations, SLAs have little steering effect. Typical: credits of 10–30% of the monthly service fee for demonstrated SLA shortfall.
**Subcontractor provisions:**
Which tasks may the MSP further delegate? Every sub-delegation must be transparent and must meet the same data protection and security standards — relevant for GDPR Art. 28 para. 4.
**Exit provisions:**
How is the handover to another provider or back to the internal team governed? Timelines, knowledge transfer obligations, documentation handover, access return.
### 2. Access management
The most common governance error: the MSP has too many rights, for too long.
**Best practice for MSP access:**
- No permanent admin rights — instead just-in-time access for maintenance windows
- Dedicated MSP accounts (no use of employee accounts)
- All MSP activities visible in the audit log
- Monthly review of active MSP permissions
- Immediate deactivation at contract end
The internal IAM team (or CCoE) retains owner rights on all projects. The MSP operates with editor rights in defined scopes — never with owner rights.
### 3. Service review rhythm
MSP governance requires structure. Without regular review, the relationship drifts in a direction that the client does not notice — until there is a problem.
| Review format | Frequency | Participants | Agenda |
| ----------------------- | --------- | ---------------------- | --------------------------------------------------------- |
| Operational status call | Weekly | IT lead + MSP delivery | Open incidents, tickets, ongoing changes |
| SLA review | Monthly | CIO + MSP management | SLA report, deviations, improvement measures |
| Strategic review | Quarterly | Board + MSP leadership | Roadmap, contract adjustments, make-or-buy |
| Security audit | Annual | CISO + MSP security | Penetration test results, certifications, incident report |
### 4. Knowledge management and documentation
MSP lock-in is often not contractual but knowledge-based: the internal team no longer knows how its own infrastructure functions.
**Documentation requirements:**
- All architecture decisions documented in writing, maintained in the internal wiki
- Runbooks for all operational processes — ownership lies internally, not with the MSP
- Change log for all configuration changes, maintained by MSP and accessible internally
- Quarterly knowledge transfer sessions: MSP explains to the internal team what has changed
## MSP selection — what really matters
Does the MSP have demonstrable experience with STACKIT? Are there reference customers from
similar industries? STACKIT-certified partners provide a structured entry point.
Does the MSP understand the regulatory requirements of your sector? GDPR, TISAX, BAIT, KRITIS —
an MSP without compliance expertise is unsuitable for regulated environments.
Can the MSP present their incident response process, change management procedures and security
concept? Providers who evade these questions are a risk.
A reputable MSP actively shapes the exit clause — because it knows that a good relationship is
the best client retention. Anyone who blocks exit provisions is creating dependency.
## Implementation steps
1. **Define scope** — What is outsourced, what remains internal? In writing, as the basis for the tender.
2. **MSP tender or selection** — At least three offers, a structured evaluation matrix, reference conversations with existing clients.
3. **Contract negotiation** — SLAs, penalties, subcontractor provisions, exit clause, GDPR data processing agreement. Legal counsel specialised in cloud contracts is recommended.
4. **Implement access concept** — Set up MSP accounts, define permission scope, activate audit logging, establish review process.
5. **Establish review rhythm** — Weekly, monthly and quarterly reviews anchored in the calendar. Create agenda templates.
6. **Agree documentation requirements in writing** — What does the MSP deliver, in what format, at what interval? As a contractual component, not a verbal assurance.
## Connection to other chapters
The SLA requirements for MSPs are derived from the **[DR tier classifications](/adoption/adapting-operating-models/disaster-recovery/)** of the affected workloads. The internal **[Service Catalogue](/adoption/adapting-operating-models/service-catalogue/)** defines which services IT delivers itself and which the MSP assumes.