E055
April 2013

NRS BCMS Methodologies and Procedures
Note: This document is only valid on the day it was printed
Version history
Version Status
0.1 Draft
1.0 Final
Author
Sam Burns
Distribution list
Copy Name
1.
2.
3.
1 Audrey Robertson
2 John Simmons
3 Project Team members
Reason for issue
First Draft
Revised by C2
Position/Organisation
Project Executive
Project Assurance
Date
04/05/2011
11/04/13
Method of issue
Electronic
Electronic
Electronic
E055
Location: 2 of 36 Last saved date: 2013-04-11
Version 1.0

NRS
BCMS Methodologies and Procedures E055
Document control ......................................................................................................................................2
Version ......................................................................................................................................................2
Copy 2
1 Introduction .......................................................................................................................... 1
1.1
The NRS BCMS..............................................................................................................................1
2 Business Impact Analysis ................................................................................................... 2
2.1
Products and Services ....................................................................................................................2
2.2
Activities ..........................................................................................................................................2
2.3
Impact Analysis for Each Activity ....................................................................................................2
2.4
Assigned Analysis...........................................................................................................................8
2.5
BIA Output ......................................................................................................................................8
3 Risk Appetite ........................................................................................................................ 9
4 Risk Assessment................................................................................................................ 10
4.1
Step 1 – The BIA identifies the critical activities and the supporting resources .......................... 10
4.2
Step 2 – Supporting resources are assessed ............................................................................. 11
4.3
Step 3 - Risk Treatments are Identified ....................................................................................... 11
4.4
Step 4 - Risk Treatments are Assessed ...................................................................................... 12
4.5
Risk Assessment Example .......................................................................................................... 12
5 Document and Record Control .......................................................................................... 13
5.1
Document Structure ..................................................................................................................... 13
5.2
Version Control ............................................................................................................................ 13
5.3
Version Number ........................................................................................................................... 13
5.4
Version History ............................................................................................................................ 13
5.5
Change Summary ........................................................................................................................ 13
5.6
Review and Authorisation ............................................................................................................ 13
5.7
Storage of Documents ................................................................................................................. 14
5.8
Previous Versions ........................................................................................................................ 14
6 Operational Planning and Control..................................................................................... 15
7 Plan Exercises .................................................................................................................... 16
7.1
Exercise Types ............................................................................................................................ 16
7.2
Set Up and Scheduling ................................................................................................................ 16
7.3
Exercise Output ........................................................................................................................... 18
7.4
Invoking an Exercise ................................................................................................................... 19
8 Training, Awareness and Communication ....................................................................... 20
8.1
BCMS Competencies .................................................................................................................. 20
8.2
Training Modules ......................................................................................................................... 24
8.3
Awareness Effectiveness ............................................................................................................ 24
8.4
Communications .......................................................................................................................... 24
9 Performance Evaluation .................................................................................................... 25
10 Audit and Review ............................................................................................................... 28
10.1
Internal Audit programme ............................................................................................................ 28
10.2
Internal Audit approach ............................................................................................................... 29
10.3
Create Audit ................................................................................................................................. 29
Location: 3 of 36 Last saved date: 2013-04-11
Version 1.0

The main aims of the Business Continuity Management System (BCMS) are to establish, implement, operate, monitor, review, maintain and improve business continuity capability for the organisation.
This document details the methodologies and procedures that support the BCMS. All information resulting from the application of the BCMS and subsequent outputs are deemed to be confidential
NRS information.
Methodologies and Procedures Page 1 of 36 April 2013

The Business Impact Analysis (BIA) methodology determines the impact of any disruption to activities that support key products and services. The process is conducted via our C2 application BIA tool, where BIAs are associated with BC plans.
Key products and services are identified and all activities supporting them listed.
All activities supporting products and services are then identified.
For all identified activities the impacts of business interruption is then established. The analysis can be assigned to an appropriate individual - the contact receives an email from the application with a link to the BIA which will allow them complete the analysis (reminders are sent out as the date the analysis is due approaches).
2.3.1 Step 1 – Impact Analysis
The ‘Impact Analysis’ icon opens a web page where the analysis can be completed (this is also the page that a contact who has been assigned analysis will be taken to). Initially only two tabs are available; Step 1 - Impact Analysis, and Step 2 – BAU.
Methodologies and Procedures Page 2 of 36 April 2013

Each activity is scored against defined drivers over time. The time when the loss of the activity would impact on the drivers is entered and a rationale for the decision recorded.
Any activity where the impact becomes unacceptable e.g. Higher than a 3 on any of the categories, then it is deemed to be a critical activity and a further 8 tabs become available to complete the analysis, as per the example below.
Methodologies and Procedures Page 3 of 36 April 2013

2.3.2 Step 2 – BAU
The second tab is used to record the time within which the activity has to return to Business As
Usual (BAU) and the rationale behind this.
2.3.3 Steps 3 and 4 – Dependencies
The BIA process identifies interdependencies of critical activities. Activity owners are questioned in respect of dependencies, e.g. who/what are they (their recovery time objectives are captured if this information is known). The output informs the business continuity plan.
Internal dependencies, e.g. teams or departments the critical activity is reliant on, and the nature of the dependency are captured. More information, via additional questions, which can be pre-defined within the application, related to the dependency can also be recorded at this stage.
Details of external dependencies that the critical activity is reliant and the nature of the dependency are captured. More information, via additional questions, which can be pre-defined within the application, related to the dependency can also be recorded at this stage.
Methodologies and Procedures Page 4 of 36 April 2013

2.3.4 Step 5 - Resource Requirements
Resource requirements over time are captured via tab 5. Required quantity of each resource over the timeline is entered by selecting the edit button associated with the resource. Resources not listed can be added by selecting ‘Additional/Specific Resources’
Methodologies and Procedures Page 5 of 36 April 2013

2.3.5 Step 6 - Systems/Applications over Time
IT systems and applications required by the critical activity (over time) are captured via tab 6. The relevant systems/applications are selected from a pre-populated list. The time within which the system/application needs to be back up and running by is also recorded.
2.3.6 Step 7 – Vital Records
Tab 7 is used to capture any vital records required by the critical activity. For vital records that are backed up, information relating to any resilience measures is also entered at this stage.
2.3.7 Step 8 – Recovery Strategy
The strategy for recovering the critical activity, within its Recovery Time Objective (RTO) and the level of operation required, is defined using tab 8.
Methodologies and Procedures Page 6 of 36 April 2013

2.3.8 Step 9 – Recovery Tasks
A list of tasks required to recover the critical activity and the time by which they need to be completed are entered via tab 9.
2.3.9 Step 10 – Additional Questions
System administrators can create additional, specific questions. These additional questions can be viewed and answered using tab 10.
The information has now been saved within the application.
Methodologies and Procedures Page 7 of 36 April 2013

If the user has been assigned the analysis to complete they submit the analysis by clicking on
‘Submit Assignment’. This notifies the person requesting the BIA analysis that it has been completed.
The BIA report is compiled and maintaine d in the application and can be viewed via the ‘Preview’ icon. The report aggregates resources, such as Employee’s and PCs etc, required by all critical activities and lists all required systems/applications. These resource and systems/applications are listed over time.
The report includes an overview of the key products and services and descriptions of all activities.
The impact analysis data, RTO, MTPD (and rationales), and internal/external dependencies is included for all critical activities.
The report is held under document control including review, signoff and distribution within the C2 application BIA tool.
Methodologies and Procedures Page 8 of 36 April 2013

Acceptable level of risk acceptance / risk appetite is stated within policy to be:
Any activity or supporting resource deemed to be critical:
Shall be recoverable to the level of functionality required to recover and continue its operations, preventing the demise of the business.
This good practice approach to risk appetite (Institute for Risk Management: IRM), is based on the premise of that:

The setting of our risk appetite is measurable i.e. critical activities are measured via the BIA process against the criteria set out in policy.

The acceptability of risk should have a time (temporal) consideration; i.e. BIAs are reviewed annually.

That the acceptance of risk does not have anything to do with relaxing controls
(risk treatments) i.e. the controls in place via BCP strategies.
We are willing to tolerate a finite amount of downtime so long as does not result in breaching our
High to Critical tolerances as described in the “Assessment guidance for BC drivers” within policy.
Acceptable
Personal
Safety
Reputational Statutory and Legal Financial (direct) Customer Service
Minimal
Low
Medium
High
No impact on personal safety
Cause minimal distress to 0-1 individuals
No impact on statutory or legal requirements
Financial loss of up to
£10k
Likely to reduce an individuals perception of that service
Inconvenience or discomfort to an individual
Little chance of any repercussions for NRS and low level specialist press coverage
Unable to meet statutory/legal requirements resulting in escalation to senior management
Financial loss of £10k -
£100K
Likely to the reduce the perception of the service by many people
Risk to an individuals personal safety
Short term interest; press coverage/ parliamentary scrutiny of
NRS
Unable to meet statutory/legal requirements resulting in questions in parliament
Financial loss of
£100k-£500k
Likely to result in lack of confidence over
NRS generally
Risk to a group of individuals safety
Long term persistent press coverage/ parliamentary scrutiny of
NRS
Unable to meet statutory/legal requirements resulting in court action
Financial loss of greater than £500k
Likely to result in a lack of confidence over wider government service
Methodologies and Procedures Page 9 of 36 April 2013

This model is derived from standard risk assessment methodology. Its intention is to link the work carried out via Business Impact Analysis to the measurement, prioritisation and action plans required to manage the risk of critical activity and supporting resource failure. The model has been successfully utilised for a wide spectrum of risk analysis across the Organisation for horizon scanning and risk management decision making.
The risk assessment methodology is carried out in 4 steps:
1. The BIA identifies the critical activities and the supporting resources.
2. Supporting resources are assessed in respect of threats to and vulnerabilities of.

Impacts are understood in that they are defined in the BIA output
3. Risk treatments are identified
4. Risk treatments are assessed against risk acceptance criteria and implemented
The BIA identifies the critical activities, RTO and MTPD* for the critical activities and supporting resources.
*The Maximum Tolerable Period of Disruption (MTPD) is the time frame in which a critical activity can operate at the level of continuity before the activity needs to commence its return to normal operations.
For each critical activity the supporting resources are assessed against the threats to and vulnerabilities of risk. For example;
Critical Activity Team (Location) RTO
Resources Example
IT
Telephony
People
Buildings and Buildings
Infrastructure
Internal Suppliers
Third party suppliers
IT applications / systems required to maintain operation of the critical activity
Telephony / systems required to maintain operation of the critical activity
People required to maintain operation of the critical activity
Buildings and Buildings Infrastructure required to maintain operation of the critical activity
Internal Suppliers required to maintain operation of the critical activity
Third party suppliers / outsourced partners systems requiered to maintain operation of the critical activity
Methodologies and Procedures Page 10 of 36 April
2013

Supporting resources are assessed in respect of impact to, threats to and vulnerabilities of.
Critical Activity Team
(Location)
RTO IT Tele People Building /
Infr
Internal
Suppliers
Third party suppliers
Data is gathered from various sources on the specific status of resources e.g. Buildings resilience data, IT systems resilience data, third party suppliers resilience data etc.
Overall Impact of the loss of the critical activity under risk assessment is available within the BIA.
The impact of the loss of the specific resource being assessed should be determined in respect of its relationship to the critical activity i.e.
Impact level 1 = Manageable impact to the Critical Activity
NB* where impact level is scored 1, threat and vulnerability are not considerations and should be scored 1 also.
Impact level 2 = Disruptive to Critical Activity i.e. material effect to the process.
Impact level 3 = Critical Activity unable to function without this Supporting Resource i.e. Critical
Activity stops within RTO and will not resume until Supporting Resource is recovered/reinstated.
See Appendix 1 for a worked example.
Risk Levels are calculated Impact x Threat x Vulnerability. Qualitative explanations to all scores are to be included in the assessment tables.
High = 18 to 27 Impact, threat and vulnerability to IT, Telephony, People, Buildings and Building infrastructure, Internal Dependencies, Third Party Suppliers and Outsourced Partners supporting the critical activity is high.
Medium = 10 – 12 Impact, threat and vulnerability to IT, Telephony, People, Buildings and Building infrastructure, Internal Dependencies, Third Party Suppliers and Outsourced Partners supporting the critical activity is medium.
Low = up to 9 Impact, threat and vulnerability to IT, Telephony, People, Buildings and Building infrastructure, Internal Dependencies, Third Party Suppliers and Outsourced Partners supporting the critical activity is low.
Qualitative explanations to all scores are to be included in the assessment tables.
Treatments:
Risk reduction/control
Design and implement a consistent set of actions which will:-
 Reduce the likelihood of the risk materialising (prior to the event) and/or
 Reduce the impact of the risk should it materialise (during or after the event)
 Shorten the period of disruption
Financing / Transfer
Financing / Transfer reduces the impact or the likelihood of the risk on the business by sharing the consequences of the risk materialising with another party. This may be through contractual transfer
(penalties to the resource provider) or some kind of financing / insurance arrangement.
Methodologies and Procedures Page 11 of 36 April
2013

Risk treatments are assessed against risk acceptance criteria and implemented.
In line with the level of risk acceptance for NRS the appropriate risk treatments for each of the critical activity’s resources are implemented.
The level of risk acceptance for NRS = any activity or supporting resource deemed to be critical:
Shall be recoverable to the level of functionally required to recover and continue its operations, preventing the demise of the business.
Critical Activity Team
(Location)
RTO IT Tele People Building /
Infr
Internal
Suppliers
Third party suppliers
Critical Activity:
Supporting Resource:
Description:
Impact level
Threat:
Vulnerability:
Score Threat level
Score Vulnerability Level
I x T x V =
Treatment :
Cost to Implement:
Responsibility: Target Completion Date:
Methodologies and Procedures Page 12 of 36 April
2013

This section describes how BCMS documents are structured, reviewed, updated and approved and explains how version control is implemented and maintained. All NRS BCMS documents are maintained in the C2 application, and are reviewed and signed off at least annually.
All new and revised documents must follow the current and accepted format and layout for BCMS documents. The minimum requirements for this are: document title, author, reviewer, authoriser, date of last revision and version number.
Version control allows users of a document to quickly and easily see which is the latest version, when it was updated and a summary of the most recent changes. The version number is displayed on the front page of documents, with version history, change summary and distribution on page 2.
All of these fields update automatically on check in to the C2 application.
A simple version numbering system is used to help identify different iterations of a document. This system uses two numbers separated by a period (.) mark (e.g. 1.4) The first number refers to the number of times the document has been authorised (signed-off). The second number refers to the number of amendments since the last authorised version.
It should be noted that this is not a decimal system and should ten or fourteen revisions of a document be made without sign-off, the version number would change to 1.10 or 1.14, respectively.
For all documents a ‘Version History’ section is required. This area allows authors and users to track the version of the document.
The version history should include:

Version numbers

The status of the respective version (e.g. Draft, Review, Sign-off)

Author

Reason for Issue (e.g. Initial draft, Annual Review etc)

Date of Issue
This section tracks the changes that have been made to the document since the previous version.
This can help authors, reviewers and users quickly ascertain which changes have been made and where.
As such, the Change Summary should include information identifying where the change has occurred (section or page number) and a brief description of what the amendment entailed (addition, amendment and removal).
When a document is created, the author will identify appropriate individuals for review and authorisation of the document. These individuals can be amended whenever the document is updated, ensuring they remain appropriate.
Review
Documents are sent out for review via the C2 application, by clicking on the ‘Request
Review/Signo ff’ button. Reviewers are then sent a link in an email from the application. Clicking on this link allows them to ‘View’, ‘Accept’ or ‘Reject’ the document.
Individuals identified to review a document tend to be subject matter experts or those with a specific interest in the document. They will judge the accuracy of the content, ensure it satisfies the intended purpose and any process, action or objective detailed within the document is achievable.
13

When reviewers accept the document, the person(s) with signoff authorisation receive a similar email with link which allows them to ‘View’, ‘Accept’ or ‘Reject’ the document.
Authorisation
When authorisers accept the document it moves to full version (e.g. 2.0) and is emailed to the, predetermined, distribution list.
DMS Documents
All Documents are stored securely within the C2 DMS application.
On creation of DMS Documents users should utilise the document template stored in the system. If this instruction is followed the system will automatically populate the following areas on the document:

Author – The individual uploading the document - Under Review (Front page)

Date – the date the plan is uploaded (Front page)

Version – one standard increment more than the previous version (Front page)

Plan Owner – The individual that created the plan within the system - Under Review (Front page)

Authorised by – from the sign-off distribution list within the system (Front page)

Version History – all fields automatically updated by system (Page 2)

Distribution list – from the application distribution list and assume electronic distribution method
(Page 2)
Recovery Plans
When creating or updating Recovery Plans, authors should follow the process outlined in the
Document Structure section of this methodology. Some fields are auto-populated by the system.
Recovery Plans utilise a document template that will automatically populate the following areas on the document:

Author – The individual uploading the document - Under Review (Front page)

Date – the date the plan is uploaded (Front page)

Version – one standard increment more than the previous version (Front page)

Plan Owner – The individual that created the plan within the system - Under Review (Front page)

Authorised by – from the sign-off distribution list within the system (Front page)

Version History – all fields automatically updated by system (Page 2)

Distribution list – from the application distribution list and assume electronic distribution method
(Page 2)
All other fields should be updated manually by the author, as required.
Other Documents
The C2 application does not provide document control for items stored within the ‘Associated
Documents’ function. As such, this part of the application should not be the only repository for these documents.
Regular document review/revision and normal business change will result in numerous iterations of documentation. However, rapid business change or an unexpected incident may require regression to an earlier version. Therefore, five previous versions of documents are available to standard users, although all previous versions are held in the application.
14

NRS’s plans and control the operation of the BCMS requirements, including;
 A detailed methodology and documented process for conducting business impact analysis (ref: section 3 of this document)
 A detailed methodology and documented process for conducting risk assessments in respect of critical activities identified in the business impact analysis process (ref: section 5 of this document)
 A definition of and methodology for selecting appropriate business continuity recovery strategies (ref: section 14 of this document)
15

It is important that business continuity plans are exercised and updated regularly to ensure that they are up to date and effective. NRS BC exercises are setup and scheduled, at least annually, via the C2 application.
 These exercises shall ensure that all members of the recovery teams and other relevant
Employee’s. Employee’s are aware of the plans and their roles and responsibilities
 Elements of business continuity/emergency response plans can be exercised independently in such a way that the service and activities are not disrupted
 An exercise schedule for business continuity plan(s) shall indicate how and when each plan will be tested
 Exercise types will be defined and will range from simple call tree drills to full scale work area recovery exercises
 The results of the exercises will be documented along with any corrective and or preventative action plans based on the output of the exercise
Business Continuity Plans shall be regularly updated to ensure that they are still relevant and include changes in the business activities and underlying activity resources. Typically an update is required following an exercise; however a major business change may trigger a review and update of a plan.
There is an exercise page associated with each plan. An exercise is created by clicking on the ‘New
Pla n Exercise’ button, and the type of exercise can then be selected. The calendar icon allows the date of the exercise to be set.
16

A summary of exercise details and people being invited to participate in exercise (including details of their role in the ex ercise) are entered in ‘Exercise Summary’ page.
Objectives of the exercise are then added. The title and description of the exercise objective are entered (several objectives can be added in this way).
Participants can be informed that they are to take part in an exercise by clicking on the Email icon.
This will email all participants a document detailing the date, the exercise summary and objectives.
17

The document created is a draft Exercise report and is used as a template to create the final report.
This document is version controlled and can be reviewed and signed off in the same way as plans.
Observations on the exercise objectives are added.
The New Observation button allows entry of details of observations.
Observations are entered and the status indicated i.e. whether the objective has met or requires minor or significant improvements. Recommendations to correct the observation are recorded .
Actions for the recommendation(s) are added (multiple actions can be added for recommendations).
18

Details of the significance, costs, the action itself, the action owner and the date that the action should be completed by are all entered. An action owner is chosen from the contact list.
Objectives, recommendations and actions are all added automatically into the exercise report after it has been checked out, to enter free text fields, and checked back in.
Clicking on the ‘Invoke Exercise’ button allows the creation of an incident for an exercise. This incident is not real and only relates to the exercise. This is useful for scenario exercises, where the application can be used as it would be in a real incident or in call tree response tests.
19

Training, competency and awareness are managed via the NRS C2 application. Contacts can be assigned roles e.g. BC Manager, BC Steering Group member, BC Plan Leader etc. In addition NRS ensure that Employee’s are made aware of their inclusion within Business Continuity Plans and that there may be a requirement for them to work under alternative working arrangements.
Training modules have been designed for each role and are maintained in the C2 application. The modules are issued via the application to Employee’s email accounts. Where appropriate, results are included in personnel’s BCM training records, which are also held, securely, in the C2 application.
To fully embed and operate an effective Business Continuity Management System the correct personnel must be identified and empowered. Senior Management and their authorised representatives will appoint or select individuals who have appropriate knowledge and experience, or are strategically placed within the business to fulfil Business Continuity roles.
In order to deliver a Business Continuity Management capability effectively it is essential that roles, responsibilities and procedures have been identified and that the people involved have the necessary competence.
In this section, competence has been defined as having the appropriate knowledge and skills to perform the relevant tasks within the NRS BCMS.
The outcomes of the successful implementation of training to meet these competencies will result in:
 Higher general awareness of the need for BCM
 Awareness of BCM risks to the organisation and of business priorities
 Improved effectiveness in conducting specific BCM tasks
 More effective responses to actual business continuity incidents
Skills & Knowledge Requirements for BCM Roles
The Business Continuity community within NRS focuses on the impact of any potential disruption to
NRS and plans to mitigate any potential risks.
A virtual Business Continuity team supports the Business Continuity Manager and Business
Continuity Team. Individuals in the virtual Business Continuity team do not have full-time business continuity responsibilities, but take key roles in the Business Continuity organisational structure.
Furthermore, these employees have significant knowledge and experience at their level within the organisation or of their business areas.
This section provides detail on the following key roles within BCM, the responsibilities associated with them, and the competencies requirement to fulfil the role.
 Executive Sponsor
 BC Steering Group members
 BC Manager
 BC Recovery Team members
 BC Plan Owners
 Employee’s
20

Role Description Responsibilities Required Competence Training Needs
Executive Sponsor The Exec Business Continuity Sponsor provides senior management support to the Business Continuity Steering Group within NRS. They are also responsible for agreeing business continuity objectives for the year and the performance of the respective Steering
Group members’ BCMS and represent
NRS on the NRS BCM steering committee.

Provide strategic guidance to the
BC steering group.

Ensure that NRS are aligned with NRS Group BCM Policy, procedure & governance

Have knowledge of business critical activities and strategy and
NRS Business Continuity policy for
BC.

Be able to provide overall direction to Business Continuity
Management.

Be able to make decisions in respect of overall BCMS objectives
/ programme.
BC Management: Guidance Policy
BC Steering Group
Members
The BC Forum members are representatives for each of the business areas within NRS
The BC Steering Group meets every 2 months to ensure regular interaction between departments, share experiences and review situations / issues in order to make effective decisions for Business
Continuity arrangements.
 Maintenance of continuity arrangements during changes in business structures, objectives, processes and people

Have knowledge of business critical activities and strategy.

Have knowledge of NRS ’s
Business Continuity guidance policy.

Have knowledge of NRS ’s
Business continuity management system

BC Management: Policy

BC programme
BC Manager The role of the Business Continuity
Manager is to assist and support all levels of NRS in understanding and carrying out their Business Continuity related responsibilities. The BCM is responsible for the day to day management of the BCMS including overall management responsibility for the analysis of BC impact and risk.

Overall management responsibility for adherence to the
Business Continuity Management
Policy and BCMS requirements

Overall management responsibility for BC Strategy and
Continuity options

Overall management responsibility for BC Planning

Overall management responsibility for BC Quality, testing, maintenance and

To have knowledge of business critical activities and strategy and
NRS Business Continuity Policy for BC.

To have knowledge of NRS ’s
Business Continuity Management
System.

To have knowledge of BS25999 internal audit and self assessment procedures.

To have knowledge of NRS ’s
BCMS software management tool
 BC Management: Policy, programme
 BIA, recovery requirements and risk assessment training.
 Strategy and continuity options training.

Quality, testing, maintenance and auditing training.
21

Role
BC
Analyst/Specialist
Recovery Team
Description Responsibilities auditing.
Required Competence
C2.

Academic and NRS specific knowledge of BIA, including recovery requirements assessment and risk assessment approaches.

Academic and NRS specific knowledge of Emergency, crisis management and continuity plans.

Academic and NRS specific knowledge of quality, testing, maintenance and auditing.

To have knowledge of strategic options for business continuity.
Training Needs
BC Coordinators are departmental / functional leads with a wide and in depth knowledge of the departmental responsibilities, processes and dependencies.
The role of the recovery team members is to assist the plan leader with the

To provide day to day management of business continuity plan content/detail /call tree maintenance.

To have knowledge business continuity planning.

To have experience of management and understanding of business priorities.

To have knowledge of key products and services and their critical activities.

To have knowledge of business imperatives in line with strategic objectives.

To have knowledge and experience of team management dynamics.

To have knowledge and experience of BC plan management system.

To have knowledge and experience of functional and critical activities.

Organisational skills.

C2 Training.

Business Continuity plan training.

Assist the plan leader with the

Incident Management.

Incident Management.
22

.
Role
Members
Plan
Owner/Recovery
Team Leader
Employees
Description management of the recovery. Recovery team members are selected on the basis of their normal day to day roles
Responsibilities management of the recovery
Required Competence

To have specific BC Plan
Knowledge
Training Needs
 Specific BC plan training

Make operational BC decisions related to their own operational plan.

Invoke War room / Command centres.

Facilitate recovery site invocation

Make operational BC decisions related to their own operational plan.

Invoke War room / Command centres.

Facilitate recovery site invocation

The role of general Employee’s is be aware of their inclusion within Business
Continuity Plan and that they may be a requirement for them to work under alternative working arrangements

BC Awareness


Plan owner.
Recovery Team

To have awareness of the requirement for BC planning and the potential for alternative working arrangements
 Awareness of BC appropriate to their
BC needs
23

Training modules have been designed for each role and are maintained in the C2 application. These training and awareness modules are issued via the application to Employee’s email accounts.
Where appropriate, results are included in personnel’s BCM training records, which are also held, securely, in the C2 application.
Roles have been created within the application and can be assigned to Employees
Improving and maintaining awareness of business continuity management among employees adds value to the BCMS. Raising awareness helps to:
 Create knowledge of NRS ’s response and recovery strategies
 Improve understanding of emergency response and crisis management processes
 Communicate BCM policy and objectives
While employees with a role in the BCMS must be knowledgeable of business continuity plans and processes, it is equally important that all Employees are aware of the elements applicable to them.
Implementation
NRS utilises various mechanisms to deliver business continuity training and awareness, including:
 Delivery of training modules via the C2 application
 Plan exercises
 Call tree review and update
 Email updates
Evaluation of Effectiveness
Bespoke training and awareness modules have been designed and are used to evaluate the effectiveness of the BCM awareness delivery.
During a BC incident internal communications to staff and other interested parties will be facilitated by the central internal communications function via recovery team communications coordinators.
The C2 BCMS application incident management tools facilitate communications via SMS or voice to staff call trees and recovery teams. There is also the capability to utilise bulletin boards and the company email system. Recovery team use of these tools is practiced in BC exercises. BC awareness for staff and role specific training is also issued and managed by the C2 BCMS application (issued in line with the BC programme for the year).
Staff call trees are reviewed, updated and tested twice annually.
All external communications will be in accorda nce with NRS’s communications procedures/response. All media communications will be conducted by the Press Office.
BC awareness for staff and role specific training is also issued and managed by the C2 BCMS application.
24

The NRS BCMS performance evaluation is set to the core principles of its BCMS as set out in policy.
It is designed to effectively measure against the core objectives set out within the policy i.e. to
Analyse, Plan, Exercise and to Communicate. To assist with this an MI reporting function has been deployed to allow for the setting of performance metrics and KPIs (set annually) that are set around the completion of BCMS core tasks i.e. BIA, Planning, Exercising and Communicating.
1. Analyse : Understand the impacts of business interruption and the resources required to maintain an acceptable level of business operations during periods of interruption.

Measurement is obtained via the carrying out of the review BIAs on an annual basis via the methodology within the BCMS
25

2. Plan: Plan for the resumption of critical activities (over time) on a prioritised basis that support
NRS key products and services

Measurement is obtained via the formulation of business continuity plans and the annual reviewing of plans in line with the BCMS.
3. Exercise: Exercise business continuity arrangements to validate the effectiveness of our strategies for the recovery of critical activities

Measurement is obtained via the exercising of business continuity plans annually in line with the BCMS.
4. Communicate: Communicate business continuity awareness to staff

Measurement is obtained via the conducting of notification exercises, publishing of awareness and training modules line with the BCMS.
26

5. Review the performance of the BCMS arrangements in order to provide the basis for continual improvement

Measurement is obtained via the online MI reporting function within the C2 application and conducting of the annual management review.
Corrective actions are logged against performance in the system and transferred to the overall
Corrective action register.
27

Scope and Frequency :
The scope of the internal audit will be in line with the scope of NRS BCMS and carried out annually.
Competency and Responsibility:
Those conducting the audits shall be certified in the practice of BCM (MBCI) and with the practice of internal audit within e.g. BS25999 or ISO22301.
The responsibility for audit will reside with the NRS Business Continuity Manager who will act on behalf of, and report findings to, the BC Steering Group.
Methodology:
The NRS BCMS Internal auditing and self assessments are performed by a combination of two elements
STAGE 1: Review and report of the current status of the arrangements of the NRS BCMS. The auditor accesses the C2 application and views the working arrangements of the management system and responds to audit questions set out in the audit criteria. The schematic below shows the areas of investigation.
BIAs
Policy
Methodologies and procedures
BCMS
Programme
Plans
Audit
Corrective
Actions
Management
Review
Exercises
Communication
Exercises
Training and
Awareness
STAGE 2: Verification and report of the findings of stage 1 via analysis online questioning of 100% of those with roles in the management system and scoring of at least 70% of the responses against an expectation criteria.
STAGE 3: 10% of the responders are then interviewed face to face to validate the scoring and stage one audit findings. And the reports are updated.
28

The auditors are either external qualified auditors or nominated NRS business and group representatives, who to demonstrate impartiality will only audit elements of the BCMS that have no direct bearing on their day jobs or places of work.
Audits are targeted exclusively at those with roles and responsibilities with the NRS BCMS e.g. BC
Sponsors, Steering Group Members, Plan Owners, Recovery Team Members etc. It should be noted that both the Stage 1 and 2 audits are created in the same way. However, the Stage 1 audit questions are directed at the Auditor /s only.
The following paragraphs describe the process.
This allows for the formulation of audit questions. Audit questions are open questions in nature and require the responder to explain via a qualitative answer and provide evidence to support their response.
The responder can be given help text advice to guide them appropriately or contextualise the question.
29

The auditor then describes the expectation criteria for expected responses in terms of what type of response would meet the criteria of the audit and what type of response would exceed the criteria.
Audits are targeted exclusively at those with roles and responsibilities within the BCMS e.g. BC
Sponsors, Steering Group Members, Plan Owners, Recovery Team Members etc.
The audits questions are sent to the responders via email where they provider their answers online and provide their supporting evidence.
30

The auditor now scores all responses to the audit against the expectation criteria based on the answers given and the evidence provided:
31

The responder is individually scored with the responses from all responders aggregated across all of the questions expectation criteria is aggregated across all responders. In this way the auditor can see both the individual scoring and collective scoring across specific areas of the audits focus i.e. specific questions. The auditor can now select individuals for sampling.
32

Corrective and preventive actions can be raised at the individual question level of the audit for tracking and continual Improvement and a full audit report is sent to the steering group for approval.
33