SM8 management in conjunction with its clients have agreed to the following recovery time objectives:
| Description | Recovery Time assessment – analysis |
| Major catastrophe in NZ/Australia | Assuming the catastrophe does not affect the Amazon Web Services “AWS” in Sydney then 2 working hours would be required to complete a back-up and restore. Assuming the catastrophe does affect the AWS physical location or physical servers then, in the worst-case scenario, the application would need to be hosted by an alternative Internet Service Provider. SM8 would utilise Microsoft Azure Cloud Services. A rebuild of the application plus restore and test of last off-site back-up estimated to likely take at least 24 hours. |
| External attack on website | Time factors to rectify external attack on website: Discovery of attack – (usually informed by CloudWatch or other monitoring service)Evaluation of effect on data and performance (2 ~ 4 hours)Determination if an appropriate patch or fire-wall needs to be deployed (2 ~ 4 hours)Implementation of patch (2 – 4 hours + smokescreen)Authority to Release with notes (1 hour) Target 6 to 8 hours – delay will be relative to finding attack “loophole” and then implement an appropriate fix |
| Website overload (no website service) | Historic penetration and performance testing have determined load-balancing requirements to maintain efficiency through peaks and troughs; the SM8 server load has been tested to 1,000 concurrent applications every second. In the event of an overload and the application becomes non-responsive, general remedy has been a re-boot of the server operating system and flush of cache. Historic trial suggest 1 to 2 hours should be ample time for discovery and then rectification. |
| Website hacked or penetrated | Any breach must be rectified before the website can be redeployed. In determining the RTO, more-often than not, there will be no visible sign that the website has been hacked or penetrated “unless” the website actually fails or becomes non-responsive. On determining an illegal hack or penetration, the most important factor is the learn the how we were hacked, and then determine the how to prevent. In most instance the website will continue to function, so importantly the RTO is a factor of demining an appropriate patch. Provided we can ascertain that no health information is at risk, 48 hours is required to investigate and remedial action. |
| Hosting provider experiences problems | Most SLA’s require SM8 to provide continued service for 99.8% of time. Server down-time that cannot be rectified immediately will attract a Vendor notice and appropriate action plan. In the event the hosting provider’s server is going to take longer than 8 business hours to recover, an action plan to migrate to Azure or Ali-Cloud can be implemented. Ideally AWS should rectify the down time within 1 to 2 hours. AWS maintains that its service is available 99.99% of the time. |
| Maintenance or patch requires break in service | Scheduled patch management or code deployments in most circumstances can be deployed: Between the NZ hours of 6:00am to 8:00am NZ time In a planned and controlled manner Ordinarily, if the server or connection between client and server is required to “go down” due a scheduled patch implement, then a 60-minute window is deemed acceptable to implement and restore the server. A maintenance notice will be posted. If the maintenance window exceeds 90 minutes then the Roll back plan should be actioned by default. |
| Internet connectivity problems | Internet connectivity problems are largely beyond the control of SM8. The application cannot function “off-line”. Where connectivity problems are determined to be under Sm8rtHealth control, such connectivity problem is likely to affect all users, and will be rectified as a matter of necessity. A 4-8 hour window is an acceptable RTO objective to meet. |
Summary of RTO’s
SM8 management in conjunction with its clients have agreed to the following recovery time objectives:
| Description | RTO | Comments |
| Major catastrophe in NZ/Australia | 24 to 48 Hours | Recover from off-site back-up |
| External attack on website | 48 Hours | Review how breach occurred, then look restore |
| Website overload (no website service) | 1 to 3 Hours | |
| Website hacked or penetrated | 24 Hours | Breach must be rectified before website can be made functional |
| Hosting provider experiences problems | 1 to 2 hours | In accordance with AWS SLA |
| Maintenance or patch requires break in service | Max 60 minute | Patches for a client will be applied outside of standard business hours |
| Internet connectivity problems (Solely in relation to services provided by SM8) | 4 to 8 hours | During the client’s standard business hours |
