BCP and DR Procedure

1. Purpose

This procedure sets out how the Organisation keeps its critical services running, or restores them within agreed times, when an event disrupts people, premises, technology, suppliers or data, and how information security is maintained while normal controls are degraded.

It carries out the Information Security Aspects of Business Continuity Policy. It combines the business continuity plan (keeping the business working), the disaster recovery plan (restoring technology) and the business resumption plan (returning to normal operations) in one set of steps.

2. Scope

The procedure applies to all business units, sites, systems and people that deliver the Organisation's services, and to suppliers whose failure would disrupt them.

• In scope: loss of premises (fire, flood, access denial), loss of people (illness, strike, transport failure), loss of technology (hardware, software, network, power, cloud provider outage), cyber attack (ransomware, data destruction), loss of a critical supplier, and loss of data.
• In scope: staff at all locations, including remote workers, and contractors engaged on critical activities.
• In scope: the information security controls that must be kept or replaced during a disruption.
• Out of scope: routine incidents that the Incident Management Procedure resolves within the normal service targets and do not threaten a critical activity.

3. Terms and Definitions

4. Roles and Responsibilities

5. Business Continuity Strategy

The strategy is to protect people first, then to restore customer-facing and legally required activities in the order set by the BIA, using the least costly arrangement that meets each recovery objective.

Top management approves the strategy [annually] and when the BIA changes the picture. Funding decisions for standby, alternate sites and services are recorded in management review minutes.

6. Information Security Continuity

6.1 Implementing information security continuity

Security must hold when conditions are not normal. Disruption is a high-risk period because staff work in unfamiliar ways and emergency changes are made quickly.

• Each recovery plan lists the security controls that must continue (access control, logging, malware protection, encryption, physical protection) and the compensating controls if a control cannot run.
• Emergency access to recovery systems uses the break-glass arrangements in the User Access Management Procedure; every use is logged and reviewed.
• Recovery environments carry the same classification and protection as production, including patching and monitoring, within [48 hours] of becoming live.
• Emergency changes follow a short form of the Change Management Policy and Procedure and are ratified after the event.
• Data restored from backup is scanned before use, and personal data is protected at the recovery site.
• Staff working at an alternate site or at home follow the Mobile Device and Teleworking Policy.

6.2 Strategy for information security continuity

Information Security reviews the strategy after each BIA update and each exercise. Where a control cannot be kept, the risk is recorded and accepted by the risk owner for the period of the disruption only.

7. Disaster Recovery Plan

The disaster recovery plan restores technology in an order that follows the BIA. It is maintained by IT Operations, tested under the exercise programme and held in a form that is available without the systems it describes.

• The plan holds a current network diagram, system list with dependencies, access to the recovery environments, supplier contacts and copies of the runbooks.
• Runbooks for each service give steps, owners, expected durations, validation checks and rollback.
• Copies of the plan and runbooks are held offline and in a separate location, so that they can be read during a total outage.
• Recovery is validated by the system owner before users are reconnected.

Data restoration steps follow the Backup Management and Retention Procedure; the capacity needed at the recovery site is planned with the Capacity Management and Planning Procedure.

8. Business Resumption Plan

The business resumption plan covers the move back from recovery mode to normal working. It is prepared by each department head with IT Operations and approved by the Crisis Management Team before the return begins.

1. Declare readinessThe IT Recovery Team Lead confirms that the primary environment is safe, stable and tested for a minimum of [24 hours] before the return.
2. Plan the returnDepartment heads agree the order and timing of the move back, the data to be synchronised, and the people involved.
3. ReconcileWork done during recovery (manual records, transactions at the alternate site) is entered into the primary systems and reconciled by the process owner.
4. Switch backServices are moved in the reverse order of recovery during a controlled window, with a rollback plan.
5. VerifyUsers and owners confirm the services work; data is checked for completeness and integrity.
6. Close temporary arrangementsEmergency accounts are disabled, credentials rotated, temporary kit returned, and recovery-site data deleted or secured.

9. Crisis Management Programme

A small team with the authority to commit resources takes the decisions needed in a crisis. It is activated when an event is severe enough to threaten life, a critical activity or the Organisation's reputation.

• The Crisis Management Team consists of the CISO (chair), a top management representative, the heads of IT, HR, Administration, Legal and Compliance, and the Communications lead, each with a named alternate.
• A meeting place and a virtual bridge are named in advance, with an alternative if the first is unavailable.
• The team keeps a decision log recording the time, decision, reason and decision maker.
• Roles during the crisis are listed in the team sections that follow and in the contact list (Annexure B).

10. Redundancy

10.1 Availability of information processing facilities

Facilities are designed with enough redundancy to meet the RTOs. The Capacity Management and Planning Procedure checks that standby capacity is sized for the load it must carry. Redundancy is tested by switching over, not assumed from design.

11. Teams and Their Responsibilities

11.1 Administration team

• Keeps staff safe: assembles people at the muster point, accounts for everyone and liaises with emergency services.
• Assesses the damage to premises and decides whether the building may be used.
• Opens and prepares alternate sites, arranges transport, accommodation, food and supplies for the teams.
• Secures the premises, restricts entry to authorised people and protects documents and equipment.
• Arranges salvage, insurance notifications and repair, and keeps a log of costs.
• Maintains vendor contacts for emergency services, utilities and security guards.

11.2 Human resources team

• Maintains the staff contact list and the call tree, tests it [every 6 months], and uses it to contact all staff.
• Looks after welfare, including family contact, counselling and leave arrangements.
• Tracks who is available and who is unable to work, and rosters cover for critical roles.
• Handles employment and payroll questions arising from the event.
• Coordinates internal communication to staff with the Communications lead.

11.3 Emergency response team

• Trained first aiders and fire wardens who act in the first minutes of an event.
• Evacuate the premises, check each floor and report the headcount to the Administration team.
• Raise the alarm and call emergency services without delay.
• Do not re-enter the building until the all-clear is given.
• Record the event timeline and pass it to the Crisis Management Team.

11.4 IT recovery team

• Assesses the technical state of systems, networks and data within [2 hours] of notification and reports to the Crisis Management Team.
• Carries out the disaster recovery plan in the agreed order, using the runbooks.
• Restores data from backup to the agreed point and checks integrity.
• Re-establishes network, remote access and communication tools.
• Works with the Information Security Manager on containment, forensics and clean restore points.
• Documents every action and keeps system owners informed of progress.
• Prepares for the return to normal under the business resumption plan.

11.5 Communications team

• Prepares holding statements and updates for customers, regulators, partners, media and staff, using templates approved in advance by Legal and Compliance.
• Is the only channel for external statements; other staff refer enquiries to the team.
• Notifies customers according to contract and the regulator as described in the plan steps.
• Records what was said, to whom and when.

12. Business Continuity Plan

Each disruption differs, so the steps below set the sequence of decisions and the evidence required, not the details of each recovery. The details are in the department continuity plans and the disaster recovery runbooks.

12.1 Step 1: Incident detection and escalation

1. DetectAny employee who sees or suspects a disruption that may affect a critical activity reports at once to the service desk or the on-call contact.
2. LogThe service desk opens a record with time, place, what is affected and who reported it, within [15 minutes].
3. EscalateIf the event may meet Level 2 or above, the on-call manager informs the CISO within [30 minutes] of detection.
4. RecordThe business continuity coordinator opens the invocation log (Annexure C).

12.2 Step 2: Initial assessment

1. AssembleThe CISO and the IT Recovery Team Lead form the assessment group within [1 hour] of escalation.
2. AssessThey establish the cause if known, systems and services affected, people at risk, data exposure, likely duration and the activities and customers affected.
3. RateThey rate the event against the crisis levels and advise on whether the plan should be invoked.
4. ReportA short written summary goes to the Crisis Management Team within [2 hours] of detection.

12.3 Step 3: Plan invocation decision

1. DecideThe CISO, with top management, decides whether to invoke the plan, the level, and the teams to activate. A decision is made within [30 minutes] of the assessment.
2. ActivateThe call tree is used to alert the teams, who are told what happened, what to do and where to meet.
3. RecordThe decision, time and decision maker are logged.
4. Stand down optionIf the event is contained within its RTO, the decision not to invoke is also logged with the reason.

12.4 Step 4: Execution and monitoring

1. RecoverThe IT Recovery Team carries out the disaster recovery plan and each department carries out its continuity plan, working to the recovery order.
2. BriefThe Crisis Management Team meets every [2 hours], or as it decides, to review progress against RTOs, resources and risks.
3. ProtectThe Information Security Manager makes sure security controls hold and that emergency changes are recorded.
4. CommunicateThe Communications lead issues updates to staff [every 4 hours] and to customers as agreed.
5. TrackThe business continuity coordinator keeps the timeline, decisions and actions in the log.

12.5 Step 5: Regulatory and customer notification

1. Assess obligationsLegal and Compliance decides within [2 hours] of invocation whether the event is a reportable incident or a personal data breach, and which customers have contract notification terms.
2. Report cyber incidentsWhere the disruption is a cyber incident covered by the CERT-In Directions of 28 April 2022, it is reported within 6 hours of noticing it [confirm the current requirement].
3. Report personal data breachesWhere personal data is affected, notification to the Data Protection Board of India and to affected data principals follows the Digital Personal Data Protection Act, 2023 and its Rules [confirm the current requirement], and the Data Protection Act Compliance Procedure.
4. Notify othersCustomers, insurers, law enforcement and other regulators are told as required by contract or law in each jurisdiction where the Organisation operates, such as under the EU General Data Protection Regulation.
5. LogEach notification records who sent it, to whom, the time, and the content.

12.6 Step 6: Return to normal

1. DecideThe CISO declares the end of the invocation when critical services are running at the normal level and the primary environment is confirmed safe.
2. ResumeThe business resumption plan is followed to move back.
3. Stand downTeams are stood down, and temporary arrangements, emergency accounts and credentials are closed or rotated.
4. InformStaff, customers and regulators receive a closing message.

12.7 Step 7: Post-incident review

1. MeetA review is held within [72 hours] of the stand-down, with all teams that took part.
2. ExamineThe group compares actual recovery times and data loss with the RTO and RPO, and what worked and what did not.
3. ReportThe business continuity coordinator issues the review report (Annexure D) within [10 working days].
4. ActActions have an owner and due date, are tracked, and the plan, BIA and runbooks are changed where necessary within [30 days].
5. LearnLessons are shared in awareness sessions, and the event is recorded in the risk register where it exposed new risks.

13. Business Impact Analysis Procedure

The BIA identifies what matters most, how soon it must be restored and what it depends on. It is the basis of all recovery objectives.

1. PlanThe business continuity coordinator issues the BIA calendar and the form (Annexure A) to department heads [each year], or at a major change.
2. List activitiesEach department head lists the activities, products and services the department delivers, and who relies on them.
3. Assess impact over timeFor each activity, the head scores the impact of disruption at [4 hours, 1 day, 3 days, 1 week] across operational, financial, legal and contractual, customer, reputational and safety effects, using the scale below.
4. Set objectivesThe MTPD, RTO, RPO and minimum service level are set, with the RTO always shorter than the MTPD.
5. Identify dependenciesPeople, premises, applications, data, suppliers, utilities and other activities needed are listed, along with single points of failure.
6. ReviewThe Information Security Manager and the IT Recovery Team Lead challenge the results and confirm technology feasibility.
7. ApproveTop management approves the consolidated BIA, which feeds the strategy, the DR plan, the backup tiers and the risk assessment.
8. MaintainThe BIA is reviewed [annually], and after a significant change or invocation.

14. BCP and DR Exercise and Maintenance Programme

A plan that has not been exercised is not trusted. The business continuity coordinator publishes an annual programme approved by top management.

1. PlanSet the objectives, scenario, scope, safety limits, observers and success criteria; notify those who could be affected.
2. RunCarry out the exercise, with an observer who records times, decisions and problems.
3. ReviewHold a debrief within [5 working days] and produce the exercise report (Annexure E).
4. ImproveLog actions with owners; update the plan within [30 days]; retest where the exercise failed.

Maintenance: the coordinator reviews the plan [every 12 months], and after any invocation, major organisational or technology change, change of supplier or site, or a failed exercise. Contact lists are checked [quarterly]. Every version is approved, dated and distributed, and old copies are withdrawn. Staff with continuity roles are trained when they join and [annually] after that.

15. Roles and Responsibilities Matrix

16. Measures

17. Reporting and Management Review

The CISO reports to the Information Security Steering Committee [quarterly] and to top management in the management review.

• BIA changes and the recovery objectives now in force.
• Exercises done and planned, results against objectives and findings.
• Any invocation or near miss, with its post-incident review and actions.
• Redundancy gaps, supplier continuity risks and their treatment.
• Resources and decisions needed from top management.

18. Records and Evidence

Annexure A: Business impact analysis form

Annexure B: Emergency contact and call tree

Annexure C: Invocation and decision log

Annexure D: Post-incident review report

Annexure E: Exercise report

19. 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.

20. 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.

21. 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 27001:2022 references

Related documents

• Information Security Aspects of Business Continuity Policy
• Backup Management and Retention Procedure
• Incident Management Procedure
• Physical and Environmental Security Procedure
• Supplier Relationship Management Procedure
• Capacity Management and Planning Procedure
• Risk Management Policy
• Information Security Incident Management Policy