Managed DBA SLA Checklist: Response, Resolution, Coverage and Escalation

A managed DBA SLA is only as useful as its definitions. Before you sign, make sure the contract states, in measurable terms: what counts as each severity level, when the response and resolution clocks start and stop, which hours are covered, who is escalated to and when, who owns your RPO and RTO, what access the provider gets and how it is audited, what you receive in reports, and how you leave. If any of these is “to be agreed later”, you do not have an SLA yet.

This is a vendor-neutral buyer’s checklist. It does not quote industry averages or “typical” response times, because those numbers depend on your systems and risk. Instead it lists what to specify and what to ask, so you can fill in the numbers that match your business. If you are still choosing a provider, start with our guide on how to choose a managed SQL Server DBA service, then use this page to review the contract.

Response Time, Resolution Time and Restoration: Three Different Promises

SLA disputes often start because these words were left undefined. Agree on each one in writing.

1. Severity Definitions

Severity levels decide which clock applies, so they must be written in terms of business impact and agreed before an incident, not argued during one. Use your own scale; the table shows the structure to demand, with the numbers left for you to fill in.

Ask these questions about severity:

• Who assigns severity? If only the provider can, you need a way to challenge it. One workable arrangement is that the customer sets it and the provider may propose a change with a reason.
• Can severity change during an incident? Define when it is raised or lowered, and whether the clock restarts.
• Are production and non-production treated differently? They usually should be, but say so explicitly.
• What about alerts the provider detects itself? Decide whether proactive detection starts the same clock as a customer report.

2. When the Clock Starts and Stops

Two incidents with identical response targets can behave very differently depending on the clock rules. Specify:

• Start: when the ticket is logged, the call is answered or the monitoring alert fires, and through which channels. Is a phone call required for critical issues, or is email enough?
• Pause: which situations stop the clock (for example, waiting for your approval or access) and who records the pause. Without limits, a paused clock can hide delay.
• Stop: who confirms restoration or resolution, you or the provider, and what evidence is required.
• Measurement: which system is the source of truth for timestamps, and whether you can see it.

3. Coverage Hours

“24×7” can mean very different things. Pin down the details:

• Hours and time zone: which hours and which time zone the coverage follows, and how public holidays in both countries are handled.
• Monitoring versus human response: 24×7 monitoring does not mean 24×7 DBA response. State separately who watches the alerts and who acts on them.
• Per severity: critical issues may need round-the-clock response while low-severity requests are business hours only. Write the coverage into the severity table.
• Channels: phone, ticket portal, chat or email, and which are valid for which severity.
• Named people or a pool: whether you get a named primary engineer and a backup, and what happens when that person is unavailable.
• Language and skills: the languages of support, and the platforms covered, for example specific SQL Server versions and cloud services.
• Scope outside the contract: work such as application tuning, migrations or projects that sit outside the monthly service and how they are scoped.

4. Escalation Path

An escalation path that is not written down will be improvised during the worst moment. The contract should include:

• Levels: from first-line engineer through senior DBA to a service manager and an executive contact, with names or roles and phone numbers on both sides.
• Triggers: time-based triggers (no update or no progress after an agreed interval) and impact-based triggers (severity raised, repeated failure). Specify the interval for each severity.
• Your side: who on your team can approve changes, give access or declare an incident over, and who is the backup when they are away.
• Major-incident handling: a defined way to open a bridge or call, who communicates to your stakeholders, and how often.
• Post-incident review: a written root-cause analysis for critical incidents, delivered within an agreed time, with actions and owners. Our guide on the first 30 minutes of a SQL Server outage shows what the response itself should look like.

5. RPO and RTO: Who Owns What

Recovery point objective (RPO) is how much data you can afford to lose, and recovery time objective (RTO) is how long you can afford to be down. A DBA service can help you reach them, but it cannot promise numbers the architecture cannot deliver. The SLA should say who owns each piece:

• Who sets RPO and RTO per database? It should be the business owner, written down per system, not a provider default.
• Who designs and operates the mechanisms? Backup schedule and retention, log backups, replication or availability groups, and failover procedures.
• Who tests? The frequency of restore tests, who runs them, and how the result is reported to you. A backup that was never restored is an assumption.
• What is outside the provider’s control? Hardware, network, cloud platform, storage and your application. The SLA should separate what the provider does from what it depends on.
• What does the provider commit to if the target is missed? Remediation plan and timeline, not only a credit.

For the technical side, see our guide to building a SQL Server backup plan with RPO, RTO, schedules and testing.

6. Access and Security

A DBA with access to your databases has access to your data. The SLA, or a schedule attached to it, should say:

• Least privilege: the minimum access needed for the scope, who approves elevated access and for how long.
• Named individual accounts: no shared logins, with multi-factor authentication and a controlled access path such as a jump host or VPN.
• Audit trail: logging of provider activity, how long logs are kept and whether you can review them.
• Change control: how changes are requested, approved, tested and rolled back, and which changes the provider may make without approval.
• Data protection: a data processing agreement where the applicable law requires one (for example KVKK or GDPR), where data and backups are stored, which sub-processors are used, and how a breach is reported and within what time.
• Personnel: background checks, confidentiality terms and what happens when the provider’s staff change.
• Break-glass access: how emergency access is granted and reviewed afterwards.

7. Scope of Proactive Work

An SLA that covers only incidents leaves out the work that prevents them. List the routine work with a frequency and an evidence of completion:

• Backup monitoring and restore tests
• Integrity checks (DBCC CHECKDB)
• Patching and update planning, including who approves maintenance windows
• Performance review, index and statistics maintenance
• Capacity and growth review
• Security review and permission audits

8. Reporting and Review

You cannot manage what you cannot see. Specify:

• Report content: tickets by severity, response and restoration times against targets, breaches and causes, backup and integrity-check status, capacity trends and open risks.
• Frequency and format: for example a monthly report plus a service review meeting, and an incident report after every critical incident.
• Data access: whether you can read the raw ticket data and monitoring history yourself.
• Review cadence: how often targets, scope and the risk list are revisited, and how changes to the SLA are agreed.

9. Remedies and Exclusions

• Remedies: what happens when a target is missed, such as service credits, a corrective action plan, and a right to terminate after repeated or serious breaches. Check that a credit is not the only consequence.
• Exclusions: planned maintenance, issues caused by your changes, third-party or cloud-provider outages, and issues in applications outside the scope. Exclusions should be listed, not open-ended.
• Liability: limits and carve-outs for data loss or security breaches, reviewed by your legal adviser.

10. Exit and Offboarding

The best time to define the exit is before you sign. The contract should cover:

• Notice and transition period: how long, and whether service levels apply during it.
• Handover deliverables: documentation, runbooks, scripts, monitoring configuration, job and schedule inventories and the current risk list, in formats you can use.
• Credentials and access: removal of the provider’s accounts, rotation of shared secrets and confirmation in writing.
• Data: return or deletion of your data, backups and logs held by the provider, with a confirmation and a timeline.
• Knowledge transfer: sessions with the incoming team or your own staff, and who bears their cost.
• No lock-in: tools or scripts the provider installed should be documented and transferable, or removable.

Red Flags in a DBA SLA

• Response targets but no restoration or resolution commitments.
• Severity defined by the provider alone, or defined in technical terms with no business impact.
• “24×7” with no statement of who responds and by what channel.
• RPO and RTO described as goals with no owner, test or evidence.
• Shared accounts, no audit trail, or no data-protection terms.
• Monthly reports that contain only ticket counts.
• No exit clause, or an exit that depends on the provider’s goodwill.

Copy-and-Use Checklist

• Severity levels defined by business impact, with an owner for classification and a way to dispute it
• Response, restoration and resolution targets written for each severity
• Clock start, pause and stop rules, with a named source of timestamps
• Coverage hours, time zone, holidays, channels and who responds outside business hours
• Escalation levels with names, triggers and intervals on both sides
• Major-incident communication and a post-incident report timeline
• RPO and RTO per database, with owner, design responsibility and restore-test schedule
• Least-privilege, named accounts, MFA, audit logs and change control
• Data-protection terms, sub-processors and breach notification
• Scheduled proactive work with frequency and evidence
• Reports, review meetings and access to the underlying data
• Remedies, exclusions and termination rights
• Exit: notice, handover deliverables, credential removal and data return

FAQ

How Aryasoft Approaches Managed DBA SLAs

At Aryasoft we recommend writing the SLA around your systems rather than around a standard package: classify your databases by business impact, set RPO and RTO per database with an owner, agree coverage and escalation with names on both sides, and review the reports together every month.

Our own managed DBA service is built the same way: senior-only engineers, a monthly report, and HELT360 health scans with timestamped findings, so both sides can see the state of the estate rather than only the ticket count. Our managed DBA services page describes how our service is organized, and our guide to choosing a managed SQL Server DBA service covers the questions to ask before you sign.

Sources and Method

This checklist is a practical framework for reviewing a managed database service contract. It does not rely on, or quote, any industry statistic or benchmark, and it gives no recommended response or resolution times, because the right values depend on your systems and risk. It is not legal advice; have your legal adviser review the final contract.