Business Continuity and Disaster Recovery Policy

Purpose

This Policy makes sure that Tidewell IT keeps its critical services running through a disruption, and restores them in time when they stop. Our customers depend on us for their daily work, so continuity is part of the service.

Scope

This Policy covers the services we deliver, the internal systems that support them, the two data centres we use, the Utrecht office, and the people and suppliers needed to run them.

Policy statements

Objectives

1. For internal systems the recovery targets are a loss of at most 24 hours of data and at most 8 hours to restore.
2. Customer services follow the targets in the customer's agreement.

Critical activities

1. We identify the activities that must continue, rank them by the harm of an outage, and record them in the Continuity register.
2. Each activity has a maximum tolerable outage that the Management Board has approved.

Plans and roles

1. Every critical activity has a continuity plan with an owner, a recovery procedure, and a list of contacts.
2. Each plan names the people who take over when the usual owner is absent.
3. Plans are short enough to follow under pressure, and they are checked for accuracy after every change to the activity they cover.

Data centre resilience

1. Production workloads run so that the loss of one data centre does not stop the critical services. Power, cooling, and network uplinks are redundant.
2. A failover between the two data centres is rehearsed as part of the yearly plan test.

Backups

1. Backups run daily, are encrypted, are copied to the other data centre, and are kept for 35 days.
2. A restore is tested every quarter on three systems, and the result is recorded.

Testing

1. Each continuity plan is tested at least once a year, and the result and the lessons are recorded.
2. Defects found in a test become Tasks with an owner and a due date.

Communication during disruption

1. The Incident Coordinator informs affected customers, staff, and the Management Board with the status and the next update time.
2. Contact lists are kept outside the systems that may be down.

ICT readiness

1. We keep spare capacity, spare hardware, and tested restore tooling so that recovery does not depend on one person or one system.
2. Recovery runbooks are written for each critical system, and a second engineer is trained on each one.

Security during disruption

1. Security controls stay in force during a disruption. A workaround that lowers protection needs the approval of the ISMS Manager and ends when normal operation returns.

Roles and responsibilities

The Management Board owns this Policy and provides the resources for continuity. The Incident Coordinator leads the response in a disruption. The Service Desk Lead runs the backups and restore tests. The Change Manager keeps recovery tooling current. The ISMS Manager checks that plans are tested.

Exceptions

An exception needs a written request to the ISMS Manager that states the reason, the risk, and an end date. The Management Board approves any exception to a recovery target.

Compliance and enforcement

Plans that are not tested in time, and backups that are not verified, are raised as Findings. Breaches of this Policy lead to disciplinary measures under the HR process.

Related documents

• Backup and Restore Procedure
• Incident Response Policy
• Incident Handling Procedure
• Information Security Policy
• Physical and Environmental Security Policy

Review

The Management Board reviews this Policy at least once a year and after a significant change, and approves each revised version.