| TL;DR: Managed services contracts fail at the boundaries, not in the middle. Most disputes start with a task both sides assumed the other owned. Scope splits cleanly into three layers: the facility, the infrastructure, and your applications and data. Agree on the dividing lines before signing, not during an incident. Six operational domains cover nearly everything a provider can run for you: monitoring, maintenance, incident response, security operations, backup and recovery, and reporting. An SLA without a stated measurement point, an exclusion list and a credit formula is a marketing number, not a commitment. |
A managed services agreement is two lists: a list of tasks and a list of names against them. Data center managed services goes wrong when those lists do not line up. An alert fires at 02:00, the provider’s engineer acknowledges it, and nobody is certain whether acknowledging means fixing. The failure is rarely technical. It is a boundary nobody wrote down.
This checklist gives you a way to write those boundaries down. It covers what a provider should handle at the facility and infrastructure layers, what stays with you, and what only works when both sides act together. Use it as an evaluation framework during procurement and as a scope document after you sign.
Where the provider’s job starts and where yours begins
Infrastructure responsibility stacks in three layers, and managed services occupies the middle one.
The facility layer is power, cooling, fire suppression, physical access control and the network entry into the building. You already buy this when you take colocation services. No customer action is involved beyond following site access rules.
The infrastructure layer is the server itself: hardware health, firmware, operating system, hypervisor, storage, backup jobs, monitoring agents and the network configuration that reaches your rack. This is the layer managed services buys you. On a self-managed high-performance dedicated server, the provider hands you hardware with KVM over IP and a replacement SLA, and the rest is yours.
The application and data layer is your code, your database schema, your user accounts, your data classification and your decisions about who may see what. This stays with you by default. It moves only when you buy a named engagement for it, such as SAP HANA hosting or managed database servers.
Most arguments happen at the seam between the second and third layers. A kernel CVE is infrastructure. The application that breaks when the kernel is patched is yours. Both need to move at the same time, which makes patching a shared action rather than a handoff.
Figure 1. Facility, infrastructure and application layers, with the default owner of each.
The six domains a managed services scope should name
A scope document that lists “24×7 support” and “proactive monitoring” has told you nothing you can hold anyone to. Break it into six domains and insist on a named owner, a defined trigger and a measurable output for each.
Figure 2. The six domains every managed services scope document should address by name.
Monitoring: what is watched, and who gets woken
Ask for the metric list before you ask about uptime. A provider that cannot produce one is not monitoring, it is pinging.
Four categories matter. Availability checks reach the service, not just the host: ICMP to the IP proves the NIC is alive and nothing more, while a port or HTTP check proves the application answered. Capacity covers CPU, memory, disk space, IOPS and bandwidth, and it needs trend retention, because the value of a capacity metric is in its slope. Hardware health comes from the out-of-band controller and covers RAID state, disk SMART attributes, power supplies, fans and inlet temperature. Environment is the facility’s own instrumentation and is reported to you rather than acted on by you.
Then ask the three questions that decide whether monitoring is useful at 02:00:
- Does a threshold breach open a ticket automatically, or does a human have to notice the dashboard?
- Who acknowledges out of hours, and what is the acknowledgement time commitment?
- Which alerts route to your team instead of the provider’s, and how is that routing changed?
RackBank includes ping monitoring and 24×7 email and SMS reporting with its dedicated servers. Confirm in writing which additional metrics are added under a managed plan, because the baseline and the managed tier are not the same list.
Maintenance: patching, firmware and change control
Maintenance is where a well-run provider quietly earns its fee, and where an under-specified contract quietly accumulates risk.
OS patching needs a stated cadence, a stated approval path and a separate emergency route. Monthly rollups are fine for most workloads. A remotely exploitable CVE with a public proof of concept is not a monthly item, so agree now on who can authorise an out-of-band patch and reboot, and how fast.
Firmware is the part most teams forget. BIOS, BMC, RAID controller, NIC and drive firmware all drift, and a controller running three-year-old firmware is a data-loss event waiting for a power anomaly. Ask for the firmware baseline and the review interval.
Hardware lifecycle covers failure replacement and planned refresh. RackBank’s dedicated server inclusions list free hardware replacement under SLA, which answers the failure case. Planned refresh at end of support is a separate conversation and belongs in the contract.
Change management ties the three together. Every change needs a request record, a maintenance window, a rollback plan and a named approver on your side. If a provider can change your production configuration without a ticket, your audit trail has a hole in it.
Incident response: severity, escalation and the clock
Severity is a measure of business impact, not of component type. A failed drive in a healthy RAID set is low severity. The same drive in a degraded array is not. Write severity definitions around impact, and the right engineer gets assigned without an argument.
Two numbers govern every severity level, and they are not interchangeable. Response time is how long until a qualified engineer is working the ticket. Resolution target is how long until service is restored, and it is a target rather than a guarantee, because some resolutions depend on parts, vendors or your own approval. A contract that states only one of the two is incomplete.
Figure 3. Incident lifecycle and a severity ladder. Intervals and targets are commercial terms to agree, not fixed values.
The escalation ladder needs time triggers, not goodwill. Specify which tier owns the ticket at each stage, how long it may hold it before escalating, and which named role on your side is notified when severity rises. Add one more clause that is routinely missed: what happens when the ticket is blocked waiting on you. The clock should pause, and both sides should see that it has.
Finally, agree on the post-incident review. For the top severity level, a written root cause analysis within an agreed number of working days is reasonable, and it is the single most useful document you will get from a managed provider.
Security operations: access, remediation and coordination
Security scope divides into three practices, and only one of them is fully the provider’s.
Access reviews are a joint exercise. Every console, KVM, IPMI and jump host credential should appear on a list, with an owner and a last-reviewed date. Review quarterly. More importantly, agree on the offboarding path: when your engineer leaves on a Friday, the provider should have a defined route to revoke that access without waiting for a support queue.
Vulnerability remediation needs a split by layer. The provider remediates OS and firmware findings inside agreed windows by severity. You remediate application and library findings. Scan cadence, scan scope and who receives the report all belong in the scope document, because an unread scan is a compliance artifact rather than a control.
Security incident coordination is where roles must be rehearsed. The provider can isolate a host at the network layer, preserve logs and images, and hold evidence. You decide what is in scope, whether to notify a regulator and when to bring in counsel. RackBank’s managed services cover vulnerability assessment and remediation, regulatory compliance management against ISO 27001, SOC 2 and TIA-942, and audit-ready documentation.
| Read the certification scope carefully. A provider’s certification covers the provider’s controls. Your application’s compliance posture is still yours to evidence, and an auditor will ask you for both. |
Backup and recovery: real only when restores are tested
A backup job that reports success is not a recovery capability. The test is a restore, performed on a schedule, with a measured completion time.
Start with two numbers and derive everything else from them. RPO is how much data you can afford to lose, which sets backup frequency. RTO is how long you can afford to be down, which sets backup topology, because a restore from offsite object storage and a failover to a warm standby are different orders of magnitude.
Figure 4. RPO and RTO bracket the incident, and the chain beneath shows who owns each link.
Then pin down five things:
- Job monitoring. Who watches failed and missed jobs, and within what window does a failure become a ticket?
- Restore testing. How often, who performs it, which systems are sampled, and is the restore time recorded?
- Retention and immutability. How long is each tier kept, and is at least one copy offsite and not deletable by a compromised administrator account?
- DR invocation. Who is authorised to declare a disaster, and what is the notification chain?
- Runbook ownership. Who maintains the recovery runbook, and when was it last executed end to end?
The provider can own job monitoring, media handling and the infrastructure side of a failover. Declaring a disaster and validating that the application came back correctly are yours.
Reporting and SLAs: how uptime is measured and what it is worth
An uptime percentage means nothing until you know where it is measured. Facility power availability, network edge availability, server availability and application availability are four different numbers, and a provider may quote whichever is highest.
Pin the measurement point, then pin the arithmetic. 99.9 percent of a 30-day month allows roughly 43 minutes of downtime. 99.99 percent allows about 4 minutes. The gap between those two commitments is the gap between a single reboot and no reboots at all, which is why the exclusion list matters as much as the number.
Figure 5. What an uptime percentage actually measures once exclusions are removed, and what each commitment allows.
| SLA clause | Why it matters | What to verify |
|---|---|---|
| Measurement point | Facility, network, server and application uptime are different numbers | The exact monitored object and the polling interval used for the calculation |
| Measurement window | A monthly window and an annual window give very different credit outcomes | Calendar month, rolling 30 days, or annual, stated in the contract |
| Exclusions | Scheduled maintenance is usually excluded, and this is reasonable | Notice period, maximum window length per month, and whether emergency work is also excluded |
| Customer-caused downtime | Protects the provider, but needs a definition | Who adjudicates, and what evidence is required |
| Reporting cadence | An SLA you cannot see is an SLA you cannot claim against | Monthly availability report and incident summary, delivered without being requested |
| Service credits | The only contractual consequence of a miss | Credit tiers, monthly cap, claim deadline, and whether credits are automatic or claimed |
Two figures on RackBank’s dedicated server page are worth raising in your own commercial conversation: the inclusions table lists 99.99 percent uptime, while the network enhancements block lists 99.98 percent network and power availability SLAs. Ask which figure attaches to the service you are buying and have it written into the agreement.
The responsibility matrix
Print this, fill in your provider’s answers, and treat every blank cell as a risk item. Blank cells are where incidents stall.
| Function | Provider handles | You own | Shared action |
|---|---|---|---|
| Power, cooling, physical security | Yes | No | Site access approvals |
| Hardware health and replacement | Yes | No | Agreeing a maintenance window |
| Firmware and BIOS updates | Yes | No | Application compatibility sign-off |
| OS patching and reboots | Yes, on agreed cadence | Compatibility testing | Emergency CVE patching |
| Hypervisor and host networking | Yes | Guest and in-app networking | Firewall rule changes |
| Infrastructure monitoring and alerting | Yes | Application-level monitoring | Alert routing and thresholds |
| Incident response and escalation | Yes, infrastructure layer | Application triage | Severity classification |
| Vulnerability scanning | Yes, infrastructure scope | Application and library CVEs | Remediation scheduling |
| Access control and reviews | Provider-side credentials | Your users and roles | Quarterly review and offboarding |
| Backup execution and monitoring | Yes | Policy and retention decisions | Restore testing |
| Disaster recovery | Infrastructure failover | Declaring a disaster | Runbook maintenance |
| Compliance evidence | Provider control attestations | Application and data compliance | Audit response packs |
| Capacity planning | Trend reporting | Growth forecasting | Upgrade decisions |
Using the checklist in a procurement review
Send the matrix to shortlisted providers before the commercial conversation rather than after it. Two things become visible quickly. First, which provider answers in specifics and which answers in adjectives. Second, which functions nobody has claimed, since those are the gaps you would otherwise discover at 02:00 in month four.
Keep the completed matrix as an annexure to the contract. It is the document your on-call engineer will reach for, and it is the one a new account manager will need eighteen months from now.
FAQs
What should a data center managed services provider handle?
A provider should handle the facility layer and the infrastructure layer: power, cooling, physical security, hardware health and replacement, firmware, OS patching, infrastructure monitoring, incident response, vulnerability remediation at the OS level, backup execution and SLA reporting. Your applications, data, user access policy and compliance evidence for your own software stay with you.
What is included in data center managed services?
Scope varies by provider, so compare against six domains: monitoring, maintenance, incident response, security operations, backup and recovery, and reporting. RackBank’s managed services list infrastructure management, database and application management including SAP and ERP, and managed security and compliance covering ISO 27001, SOC 2 and TIA-942.
How is uptime measured in a data center SLA?
Uptime is measured against a defined monitored object over a defined window, usually a calendar month, with agreed exclusions subtracted from total minutes. Confirm whether the figure applies to facility power, the network edge, the server or the application, and confirm the polling interval, since a five-minute poll cannot evidence a two-minute outage.
Who is responsible for OS patching in managed hosting?
The provider applies OS patches on an agreed cadence under a managed plan, and you own application compatibility testing. Emergency patching for a critical CVE is a shared action: the provider proposes and executes, you approve the reboot window. On an unmanaged dedicated server, OS patching is entirely yours.
What is the difference between colocation and managed services?
Colocation gives you space, power, cooling, physical security and connectivity, and you manage everything inside the rack. Managed services adds operation of the infrastructure layer: OS, firmware, monitoring, patching, backup and incident response. Many customers buy colocation first and add managed services for a subset of their estate.
Define the scope before you need it
The useful output of this exercise is not a signed contract. It is a one-page matrix that two teams agreed on while nobody was under pressure, because the value of a clear boundary only shows up on the day something breaks. A provider that engages with the blank cells rather than talking around them is telling you how the relationship will run.
| Next step. Bring your filled matrix to the conversation. Review RackBank’s managed services scope against it, mark what is covered, what is not and what needs a named owner on both sides, then talk to the team about the functions still left blank. |
