Availability and Service Continuity Management Procedure

1. Introduction

Availability is the ability of a service to do what it is meant to do when it is needed. Service continuity is the ability to keep or restore agreed services to an agreed level after a serious disruption. The two are managed together here because the same dependencies, monitoring and tests serve both, and because a continuity plan is only as good as the availability design it rests on.

This procedure sets the Organisation's method for services in the service catalogue. Business continuity of the wider Organisation, including premises and people, is in the BCP and DR Procedure; this procedure supplies the service-level targets and plans that procedure relies on.

2. Purpose

This procedure ensures that availability and continuity targets are agreed with customers, designed into services, measured, tested and reported, and that recovery from a disruption is planned in advance by named people with known contacts and rehearsed steps. It prevents the first test of a plan being the disaster it was written for.

3. Objectives

• Agree an availability target, hours of service and recovery objectives for each service in the catalogue within [30 days] of its introduction.
• Monitor availability of every in-scope service from the user's side and report it against target each month.
• Meet the agreed availability target for at least [95%] of services in each quarter.
• Hold a tested continuity plan for every service whose loss would breach a customer commitment or a regulatory duty.
• Test every continuity plan at least once every [12 months], and test critical plans every [6 months], with findings closed on time.
• Include supplier-provided parts of a service in the plan, with the supplier's commitments confirmed in writing.
• Review availability and continuity needs before every significant change to a service.

4. Scope

• In scope: all live services in the service catalogue and the infrastructure, applications, data, networks, suppliers and people they depend on.
• In scope: planned and unplanned unavailability, partial degradation that breaches the service level, loss of a site, of data, of a supplier, or of key staff.
• Out of scope: continuity of non-service business functions such as finance and premises, which are covered by the BCP and DR Procedure, though this procedure supplies service inputs to them.
• Applies to: service owners, the continuity manager, technical and operations teams, suppliers named in a plan, and the crisis team when a plan is invoked.

5. Terms and definitions

6. Roles and Responsibilities

7. Availability and Service Continuity Management Process

7.1 Requirements and strategy

Requirements are gathered from service level agreements, customer contracts, regulatory duties and the risk assessment. They are recorded per service and reviewed whenever the service or the contract changes, and at least every [12 months].

1. Gather requirementsThe service owner records the hours of service, availability target, RTO, RPO, and the minimum service level during recovery, agreed with the customer representative.
2. Assess riskThe continuity manager identifies threats to each critical service (power, hardware, software, network, cyber attack, supplier failure, loss of premises, loss of key staff) and records them in the risk register under the Service Management System risk process.
3. Analyse impactThe business impact of an outage over time is estimated, including customer harm and any contractual or regulatory effect, and the service is rated using the tier table below.
4. Set the strategyFor each tier, the continuity manager and service owner choose the way of meeting the objectives: design for redundancy, backup and restore, standby capacity, manual workaround, or accepting the loss. The cost and the choice are recorded and approved by the process owner.
5. Confirm resourcesPeople, sites, tools, data copies, licences and supplier commitments needed by the plan are named, and funded in the budget cycle.

7.2 Availability design and review

• New and changed services are reviewed for single points of failure, capacity headroom and recovery before go-live as part of the Service Design and Transition Procedure.
• Where a service is customer-facing and of Tier 1 or Tier 2, the design must withstand the loss of any single component without breaching its target.
• Maintenance windows are planned in advance, announced to users at least [5 business days] ahead, and kept out of peak periods; planned downtime is counted separately from unplanned downtime.
• Dependencies between services are mapped in the configuration records, so that the effect of a failure on dependent services can be seen.

7.3 Availability monitoring and targets

Availability is measured at the point where the user meets the service, using synthetic transactions or end-to-end checks every [1 minute] for Tier 1 and every [5 minutes] for other tiers. Server uptime alone is not accepted as evidence of availability.

1. DetectMonitoring raises an alert when a check fails on [two consecutive tests]. The alert opens an incident under the Service Incident Management Procedure.
2. RecordDowntime is taken from the first failed check to the first successful check after restoration, and is checked against the incident record by the availability manager.
3. AnalyseEach month the availability manager reviews outages by cause and service, and passes patterns to problem management.
4. ActA service forecast to miss its target in the quarter has an improvement plan agreed with the service owner within [10 business days].

7.4 Service continuity plans

Each Tier 1 and Tier 2 service, and any service named in a customer contract, has a continuity plan. The plan is short enough to be used under pressure, and each has the entries in the table below. The plans themselves are kept offline as well as in [the document management system], so that they can be read when systems are down.

7.5 Data protection and backup

Recovery depends on backups that work. The Backup Management and Retention Procedure sets the schedule, retention and restore tests; each plan names the backup set it relies on and the last successful restore of that set. A backup that has not been restored in a test within [6 months] is not counted as a recovery capability.

7.6 Invoking a plan

A plan is invoked on the authority of the service owner or, where the service owner cannot be reached within [15 minutes], of the continuity manager. The decision, the time and the reason are recorded.

1. DeclareThe service owner declares invocation and tells the continuity manager, who opens a recovery log and calls the crisis team within [15 minutes].
2. MobiliseThe continuity manager contacts the recovery team using the call list. If a person does not answer in [10 minutes], the deputy is called.
3. RecoverTechnical teams carry out the recovery steps in order, recording each with its time. The information security lead confirms that security controls are in place before service is returned to users.
4. CommunicateThe customer representative sends updates at the intervals in the plan, at least every [60 minutes] for Tier 1 events. Where a cyber incident is involved, reporting duties are decided under the Service Incident Management Procedure.
5. Stand downWhen the service is stable and the objectives are met, the service owner declares recovery complete. Fail back is planned, tested and carried out as a change.
6. ReviewA review is held within [5 business days] and updates the plan, the strategy and the risk register.

7.7 Testing and exercising

Plans are tested to find weaknesses before an event does. Tests are planned a year ahead, approved by the process owner, and conducted so that live service is not put at unacceptable risk.

• Each test has a written objective, scope, date, observers and pass criteria, and the results are recorded in the test report.
• Failures and gaps are raised as actions with owners and dates, tracked to closure, and reported to the process owner.
• A plan that fails a test is retested within [3 months]. A plan that has not been tested within its period is reported to top management.
• Plans are updated within [10 business days] of any change to the service, the people named, the suppliers, or the findings of a test or event.

7.8 Supplier involvement

A plan that depends on a supplier names the supplier's recovery commitments. The supplier manager obtains evidence of the supplier's own continuity arrangements at contract signature and each [12 months], and asks suppliers of Tier 1 components to join the annual exercise. Findings go to the supplier review under the Supplier Management Procedure.

7.9 Process flow

1. Service owner and customer representative agree availability, RTO, RPO and hours for the service.
2. Continuity manager assesses risks and impact, assigns a tier and agrees the strategy and resources.
3. Technical teams design and operate the service to meet the strategy; availability monitoring starts at go-live.
4. Continuity manager writes the plan, names the team and obtains approval from the service owner.
5. Availability manager measures and reports availability monthly and passes patterns to problem management.
6. Continuity manager runs the test programme and tracks gaps to closure.
7. In a disruption, the service owner invokes the plan, the team recovers the service and communicates, and the plan is stood down on recovery.
8. Review after events and tests updates plans, strategy and risk register.

8. Interfaces with Other Processes

9. Key Performance Indicators

10. Records and Evidence

Annexure A: Service continuity plan

Annexure B: Continuity test report

Annexure C: Recovery call list

Annexure: Document history

11. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

12. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

13. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 20000-1:2018 references

Related documents

• BCP and DR Procedure
• Information Security Aspects of Business Continuity Policy
• Backup Management and Retention Procedure
• Capacity and Demand Management Procedure
• Service Incident Management Procedure
• Service Level Management Procedure
• Change Management Procedure
• Supplier Management Procedure