Practical Guidance

Define what "response" means

Some providers count an automated email as a response. A more useful definition is the time until a qualified engineer acknowledges the request and begins work. Ask any provider to state its definition in writing.

Agree on priority levels in advance

Each priority level should have a plain description and a target. A common structure is:

• Critical: a business-wide outage or a suspected security incident.
• High: a department or key system is impaired.
• Normal: a single user is affected but can keep working.
• Low: requests, changes and questions that can be scheduled.

Confirm hours of coverage

Check whether targets apply around the clock or only during business hours, and how after-hours emergencies are reported. If your organization runs evenings or weekends, coverage hours matter as much as the targets themselves.

Ask how performance is reported

A regular report showing requests by priority and the time to response lets you check the agreement is being met, rather than relying on impressions.

Follow the 3-2-1 approach

Keep at least three copies of important data, on two different types of storage, with one copy held off-site or in a separate cloud account. At least one copy should be protected from alteration or deletion.

Decide how much loss is acceptable

For each key system, agree how much recent data you could afford to lose and how long you could be without it. Those answers determine how often backups run and how recovery is planned.

Test restores on a schedule

A backup is only proven when it has been restored. Schedule test restores of files, databases and whole systems, and record the results and the time each took.

Write down the recovery steps

During an outage, nobody should be working from memory. A short, current recovery procedure, stored somewhere reachable when your main systems are down, saves time when it matters most.