Maintenance & support: what belongs in a good contract?

A maintenance and support contract should be practical. It sets expectations: what the provider will do, how quickly, and how success is measured. Good contracts cover SLA metrics, response times, update policy, backups and security monitoring.

Below you’ll find clear definitions you can adopt, examples of clauses, and a checklist to use in negotiations. This is aimed at owners of sites and web apps as well as product owners who need to understand trade‑offs.

What a useful contract includes

• Measurable SLA items (uptime, response, MTTR).
• Prioritisation and response rules for incidents.
• Update policy and change management process.
• Backup frequency, retention and restore tests.
• Security monitoring, alerts and incident response.

SLA: make metrics explicit

An SLA must define how you measure. Common metrics:

• Availability: monthly uptime percentage (e.g. 99.5% for standard sites, 99.9% for critical commerce).
• Server response times and percentiles (average and p95).
• MTTR: expected recovery time for critical services.

Specify the tools and windows used for measurement. If you include performance targets, define the exact test method — synthetic tests, real user monitoring, or lab tests. Core Web Vitals are suitable performance metrics if you agree on measurement methodology. See Core Web Vitals for context.

Priorities and response times

Use at least three priority bands:

• Critical: site down, checkout broken, or major data breach. First response: 1 hour. Resolution target: 4–24 hours depending on complexity.
• High: major feature broken (forms, integrations). First response: 4 hours. Target: 24–72 hours.
• Normal/Low: cosmetic issues, content updates. First response: 1–3 business days. Fix in next release window.

Clarify that ‘response’ means a diagnostic or workaround, not necessarily a full fix.

Updates and change management

Separate security patches from feature changes.

• Security patches: apply within 24–72 hours for critical vulnerabilities; document rollback plans.
• Functional changes: go through change requests, approvals and scheduled releases. Define maintenance windows (for example: Tuesdays 02:00–05:00) and testing steps.

For CMS platforms like WordPress, follow platform hardening and backup best practices. See guidance on Hardening WordPress and WordPress backups.

Backups: how to specify them

Minimum backup clause:

• Frequency: daily for dynamic sites; weekly for mainly static sites.
• Retention: at least 30 days; extend if required by law.
• Storage: encrypted at rest, geo‑redundant locations.
• Tests: perform restore tests at least quarterly and share a report.

Also define RTO (Recovery Time Objective) and RPO (Recovery Point Objective).

Security monitoring and incident handling

Monitoring is only useful with a clear escalation and response plan:

• Specify monitoring tools (WAF, IDS, uptime monitors) and alert thresholds.
• Define who gets notified and how (SMS, email, phone) for each priority.
• Document forensic steps and timelines for advising customers and authorities.

Use OWASP Top 10 as a checklist to decide what to monitor and harden first: injection, broken auth, misconfigurations, etc. See the OWASP Top 10 for a quick reference.

Pricing guidance

Not every site needs 24/7 support. Offer tiers:

• Basic: €50–€200/month — monitoring, weekly backups, email support.
• Standard: €200–€600/month — SLA in business hours, monthly updates, daily backups.
• Enterprise: €600–€2,500+/month — 24/7, fast response times, full security monitoring.

These are indicative ranges and vary by stack, integrations and compliance needs.

SLA tiers at a glance

Practical checklist to include in the contract

• Define incident and priority levels in plain language.
• State exact measurement method and tools for SLA metrics.
• Separate ‘first response’ and ‘full resolution’ timeframes.
• Mandate backup frequency, retention and quarterly restore tests.
• Define update windows and emergency patch SLA.
• Allocate a block of hours for unplanned fixes or set ad‑hoc rates.
• Provide an out‑of‑hours contact and escalation path.
• Add SLA remedies or credits for repeated SLA misses.
• Include a data breach notification clause in line with GDPR.

Final notes

A maintenance contract reduces risk but does not remove it. Treat it as a living document: review after incidents and adjust SLAs based on real metrics. If you want help drafting or auditing your current agreement, check our maintenance offering at /onderhoud-en-support or get a quote and contact us.