Disaster Recovery Policy

Confidentiality Statement
Copyright © 2020, Valuefy Solutions Pvt. Ltd. All rights reserved. This product or document may not,
in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic
medium or machine readable form, by any means electronic, mechanical, photographic, optic
recording or otherwise without prior consent, in writing, of the copyright owner. Statutory declaration
under section 52A of the Copyright Act 1957.

Document Control

Document Name Disaster Recovery Policy

Document Reference Number VFY/ISMS/DisasterRecovery
Classification Restricted
Version Number V1.0
Date 20-06-2020
Reviewed by Ketan Patil
Approved by Amit Kaushik

Revision History
Date Version Description Created by
20-06-2020 V1.0 First Release Aditya Barve

Distribution
• Internal

Documentation status
This is a controlled document. This document may be printed; however, any printed copies of the
document are not controlled. The electronic version maintained in the file server is the controlled
copy.

VFY/ISMS/DisasterRecovery Internal Page 1

 Related documents
S.No. Document Reference Number Document Name Version
1. Hardware Software Request Form -
2. VFY/ISMS/PR-MANUAL Information Security Management V1.0
System Manual

Abbreviations, Acronyms & Definitions

CISO Chief Information Security Officer
IT Information Technology
ISMS Information Security Management System
OS Operating System
PC Personnel Computer
USB Universal Serial Bus

Disaster Recovery Plan Policy

1. Overview
Since disasters happens rarely, management often ignores the disaster recovery planning process. It
is important to realize that having a contingency plan in the event of a disaster gives Valuefy Solutions
Pvt. Ltd. a competitive advantage. This policy requires management to financially support and
diligently attend to disaster contingency planning efforts. Disasters are not limited to adverse
weather conditions. Any event that could likely cause an extended delay of service should be
considered. The Disaster Recovery Plan is often part of the Business Continuity Plan.

2. Purpose
This policy defines the requirement for a baseline disaster recovery plan to be developed and
implemented by Valuefy Solutions Pvt. Ltd. that will describe the process to recover IT Systems,
Applications and Data from any type of disaster that causes a major outage.

3. Scope
This policy is directed to the IT Management Staff who is accountable to ensure the plan is developed,
tested and kept up to date. This policy is solely to state the requirement to have a disaster recovery
plan, it does not provide requirement around what goes into the plan or sub-plans.

4. Policy
4.1 Contingency Plans
The following contingency plans must be created:
• Computer Emergency Response Plan: Who is to be contacted, when, and how? What
immediate actions must be taken in the event of certain occurrences?

VFY/ISMS/PR-A.14 Internal Page 2

 • Succession Plan: Describe the flow of responsibility when normal staff is unavailable to
perform their duties.
• Data Study: Detail the data stored on the systems, its criticality, and its confidentiality.
• Criticality of Service List: List all the services provided and their order of importance.
• It also explains the order of recovery in both short-term and long-term timeframes.
• Data Backup and Restoration Plan: Detail which data is backed up, themed to which it is
saved, where that media is stored, and how often the backup is done. It should also
describe how that data could be recovered.
• Equipment Replacement Plan: Describe what equipment is required to begin to provide
services, list the order in which it is necessary, and note where to purchase the equipment.
• Mass Media Management: Who is in charge of giving information to the mass media?
• Also provide some guidelines on what data is appropriate to be provided.
After creating the plans, it is important to practice them to the extent possible. Management should
set aside time to test implementation of the disaster recovery plan. Tabletop exercises should be
conducted annually. During these tests, issues that may cause the plan to fail can be discovered and
corrected in an environment that has few consequences.

The plan, at a minimum, should be reviewed an updated on an annual basis.

5 Disaster recover y
Disaster recovery is the ability to recover data in case the production system is damaged, destroyed
or becomes unavailable for an undeterminable period of time. A comprehensive disaster recovery
solution that can restore data quickly and completely is required to meet low RPO and RTO
thresholds.
Recommendations

1. Take a daily AMI backup of the production servers in a different region. In case of a instance
level failure we can launch the servers from the AMI image from that region. The frequency
of the backup of the AMI images will be every day.
2. We can have a separate DR setup as live production in a different region, if the live
production region goes down for any reason, we can bring up the resources in the DR
region.

The below illustrates the recovery possibilities when a production server crashes.

The Devops team will try to analyze the issue persisting on the current server, while simultaneously
bug fixing to bring up the production server.
Meanwhile below steps would be the recovery procedure
➢ Launch the new server from the latest backup. (ETA - Max 1 Hour)
➢ Attach the Production server NIC and Public IP to the new VM. (ETA 15 Minutes)
➢ Check and confirm the application status.
➢ Enable the Server backup to this VM. (ETA 10 minutes)
➢ Monitoring will be configured. (ETA 15 - 20 Minutes)

VFY/ISMS/PR-A.14 Internal Page 3

RPO: Recovery Point Objective
The Recovery Point Objective is the threshold of how much data you can afford to lose since the last
backup. Defining your company’s RPO typically begins with examining how frequently backup takes
place. Since backup can be intrusive to systems it is not typically performed more frequently than
every several hours. This means that your backup RPO is probably measured in hours of data loss.
The recovery point objective is 1 hour.

RTO: Recovery Time Objective

The Recovery Time Objective is the threshold for how quickly you need to have an application’s
information restored. The recovery time objective is 4 hour(s).

6 Policy Compliance
6.1 Compliance Measurement
The Info sec team will verify compliance to this policy through various methods, including but not
limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits,
and feedback to the policy owner.
6.2 Exceptions
Any exception to the policy must be approved by the Infosec Team in advance.
6.3 Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and
including termination of employment.

7 Rel ated Stand ard s , Poli ci es and Pro ces ses

None.

---------End of Document---------

VFY/ISMS/PR-A.14 Internal Page 4