MSP Governance and Partner Management

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.

Swipe sideways to see the whole table

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

STACKIT experience

Does the MSP have demonstrable experience with STACKIT? Are there reference customers from similar industries? STACKIT-certified partners provide a structured entry point.

Compliance expertise

Does the MSP understand the regulatory requirements of your sector? GDPR, TISAX, BAIT, KRITIS — an MSP without compliance expertise is unsuitable for regulated environments.

Transparent processes

Can the MSP present their incident response process, change management procedures and security concept? Providers who evade these questions are a risk.

Exit readiness

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 of the affected workloads. The internal Service Catalogue defines which services IT delivers itself and which the MSP assumes.