KDS – Neo – Disaster Recovery Plan (DRP)

Classification

Information owner: Jean-Philippe Boucharlat

Public Restricted Confidential Secret
Classification level:
X
Following section to be completed for « Restricted », « Confidential » or « Secret » levels:
Recipient(s) list (name and/or entity)
(optional for “Restricted” level, PCI-DSS auditors
mandatory for “Confidential” and ISO 27001 auditors
“Secret” levels) (names of recipients Customers and prospects under NDA
are mandatory for « Secret » level)

Revision

Version Date Name Role Revisions

7.0 2015-06-22 Slimen Benrabah CSO Update for Executive Support
8.0 2015-09-08 Slimen Benrabah CSO Added RPO and RTO
9.0 2015-10-21 Slimen Benrabah CSO Fix erroneous RPO/RTO
Jean-Philippe Chief Security Move of secondary site to secondary
10.0 2016-02-15
Boucharlat Officer datacenter
Jean-Philippe Chief Security
11.0 2017-02-28 Annual review – Classification
Boucharlat Officer
Béatrice Joucreau Security Officer Removed confusing Tier 3 certifications for
12.0 2020-02-19 datacenters. Use of a new document
template.
TABLE OF CONTENTS
1 PURPOSE ...................................................................................................................................................... 3

2 DISASTER RECOVERY PLAN ....................................................................................................................... 3

2.1 DESCRIPTION ..................................................................................................................................................................................... 3

2.2 OBJECTIVES ........................................................................................................................................................................................ 4

3 TEST RESTRICTIONS/SCOPE ...................................................................................................................... 5

4 TEST PROCEDURE ....................................................................................................................................... 6

4.1 ORGANIZATION ................................................................................................................................................................................ 6

4.2 TIMELINE ............................................................................................................................................................................................ 6

4.3 SUGGESTED TEST PLAN..................................................................................................................................................................... 7

KDS – Neo – Disaster Recovery Plan (DRP) – Restricted – 2/7

1 PURPOSE
This document describes the principles of the disaster recovery plan and documents the test procedure
proposed to a specific client to simulate a disaster of KDS main production site.

2 DISASTER RECOVERY PLAN

2.1 DESCRIPTION
KDS primary site is hosted in a datacenter at Courbevoie near Paris, France. Without being certified by the
Uptime Institute, this primary site complies with requirements that would place it between Tier III and Tier
IV.

The secondary site is located in a datacenter at Marcoussis, France. The secondary site will be called “DR
site” in this document.

The DR site only supports all customers who are entitle for an Executive Support service. This means that in
case of a major outage at the primary site, only KDS customers with an Executive Support contracts are able
to use the DR site. The data of other customers are not lost, but these customers won’t be able to access
the DR site.

When activated, the DR site acts as a replacement of the primary site: in this case, the primary site is totally
disabled. In particular:

• It is not possible to have some customers using the DR site, while other customers still using the
primary site;
• It is not possible to have some features available on the DR site while other features are still
available on the primary site.

Figure 1 shows the overall architecture of KDS primary and DR sites.

KDS – Neo – Disaster Recovery Plan (DRP) – Restricted – 3/7

 Figure 1: KDS Disaster Recovery Site overall architecture

2.2 OBJECTIVES
Both RPO (Recovery Point Objective) and RTO (Recovery Time Objective) are important elements of our
recovery plan so that our clients are the least possible impacted in case of a disaster.

• Our RPO is 10 minutes

• Our RTO is 48 hours

KDS – Neo – Disaster Recovery Plan (DRP) – Restricted – 4/7

3 TEST RESTRICTIONS/SCOPE
KDS is able to open DR site for any client for test purposes only. Because of the primary-DR sites
architecture explained above, the following restrictions apply:

• KDS will open the DR site for a specific client, but it will be reachable with a different URL;
• Everything done in the DR site during the test period will be definitely lost.

During the tests, the primary site will continue to run normally.

Consequently, KDS strongly recommends to avoid the use of DR site by regular users

KDS test and validate the DR plan every 12 months internally.

As the DR site and the primary site will run in parallel with production data during the tests, some features
will be disabled to keep them from interfering with external systems or with each other. Namely,

• E-mails: the DR site won’t send any e-mail;

• Asynchronous events (jobs): usual events that are handled by batch jobs are disabled. Nevertheless,
export of expense reports data can be provided on request.

The duration test will not exceed two days.

Services that are not due to be recovered within one day according KDS Recovery Plan won’t be included in
this test (e.g. Data loading, Profile synchronization, maps, reporting …).

KDS – Neo – Disaster Recovery Plan (DRP) – Restricted – 5/7

4 TEST PROCEDURE

4.1 ORGANIZATION
The DR site tests will be managed by a team consisting of, at least:

• KDS Project Owner, who will act as the coordinator for this test;
• KDS Security Officer;
• Client Project Owner.

This team will agree on a date/time for starting the test.

4.2 TIMELINE
See figure 2.

KDS and client agree on a date and time for starting the test (t=0). This
moment cannot be earlier than 7 days before the effective start of the test.

t=0 Start. This corresponds to the moment where the primary experiences “virtually”
a major outage.

t+4 hours KDS opens the DR site with data copied from the primary site. KDS guarantees
that the data is not older than t-10 minutes.

Between t+4 hours Client tests the DR site.

and t+48 hours
Exports on request

t+48 hours KDS closes the DR site. All the data modified on the DR site is definitely lost.

Before t+5 days Debriefing

KDS – Neo – Disaster Recovery Plan (DRP) – Restricted – 6/7

 Figure 2: Test timeline

4.3 SUGGESTED TEST PLAN

URL for test: https://dr-w.mykds.com/client-instance

Here are a few tests that can be performed. This list is a suggestion.

• Check that the URL for DR site resolves to an IP address that is different from the primary site. Check
that these IP addresses are located at different geographic places
• Create an expense report on the primary site a few minutes before the start of the test (<t-10
minutes). Verify that this expense report is available on the DR site. This validates that data has been
correctly copied from primary site to DR site
• Create an expense report on the primary site a few minutes after the start of the test. Verify that this
expense report is not present on the DR site. This validates that primary site and DR site are
independent
• Perform the steps defined as “critical” as part of the KDS-client integration. This validates that the
client can use the DR site for its daily operations, namely: ...(to be defined by KDS Project Owner)
KDS – Neo – Disaster Recovery Plan (DRP) – Restricted – 7/7