Services
Overview Cybersecurity solutions Penetration testing SOC Digital forensics & incident response Audit & Advisory GRC Security awareness & training Social engineering IT staffing & placement
Partners
Use cases
Overview Infrastructure & network Unified secure network Industrial infrastructure Wi-Fi network Zero Trust access (ZTNA) Cloud & identity Microsoft 365 / Azure migration Privileged access (PAM) Active Directory Corporate email Detection & response Detection capability (SOC) Responding to a compromise Vulnerability management Compliance & resilience Preparing for ISO 27001 ICT Minimum Standard DORA regulation Business continuity (BCP/DRP) Human factor Reducing human risk
Clients
Company
About Certifications Careers CSR commitments
Contact
FRENDE
Continuity & recovery

Ensuring business continuity

After a major incident only one question counts: how long before you are operational again, and with which data? Answering it takes objectives owned by the business and a capability that has actually been tested — not a binder updated once a year.

The challenge

Objectives you own, and the proof that they hold

Continuity rests on two simple figures. The RPO defines the tolerable data loss: how far back can you go? The RTO defines the acceptable delay before service resumes. Both are business decisions, not technical settings — which is why they are set with the departments concerned, on the basis of an impact analysis.

The classic mistake is to publish ambitious objectives that the infrastructure cannot meet: backups too far apart, restorations never timed, dependencies forgotten. On the day of the incident, the gap is paid in full.

We make the capability credible: rank the activities, set reachable objectives, align the backup and recovery architecture, then verify through restoration tests and a crisis exercise that the whole thing works — teams included.

What is at stake
  • RTO and RPO published but never verified
  • Backups untested, or reachable from the compromised domain
  • Critical dependencies (suppliers, cloud) not taken into account
  • No crisis organisation identified or trained
  • Recovery documentation out of date, or stored on the system to be restored
Diagram

The two windows that determine your recovery

RPO and RTO windows around a disaster RPO tolerable data loss RTO acceptable time to restore service DISASTER Lastclean backupServicerestored beforeafter
The RPO measures the acceptable data loss before the disaster; the RTO, the delay before service resumes after it. The whole capability is built around those two values.
Our approach

How we proceed

From the business towards the technology: decide what must come back first, then build the corresponding means.

01

Business impact analysis (BIA)

Identification of the essential activities, of the outage they can tolerate and of their dependencies — applications, data, suppliers and key people.

02

RTO / RPO objectives

Setting the objectives per activity with the business, weighing ambition against cost. This is the step where the trade-off is made explicitly rather than inherited implicitly.

03

BCP and DRP plans

Formalising degraded-mode operation (BCP) and the technical recovery procedures (DRP): restart order, prerequisites, roles and fallback means of communication.

04

Technical alignment

Bringing backups and architecture into line with the objectives: frequency, immutability, isolation of the copies from the domain, and timed restorations.

05

Exercises and upkeep

A crisis exercise (table top) and real restoration tests, then an update of the capability. A plan is alive: it is reassessed at every significant change to the information system.

Services involved

Several disciplines, a single point of contact

Continuity mixes governance, architecture and lessons from real incidents — we bring all three.

Audit & Advisory GRC Forensics & incident response Cybersecurity solutions Security awareness & training
Deliverables
  • Business impact analysis (BIA)
  • RTO and RPO objectives approved by the business
  • Continuity (BCP) and recovery (DRP) plans
  • Recommendations on backups and architecture
  • Exercise report and restoration test results
Frequently asked questions

Frequently asked questions

The BCP organises how the business keeps going during the incident, including in degraded mode — often with workarounds. The DRP describes the technical restoration of the systems. Both are needed: one protects the business, the other restores the IT.

A restoration test at least annually for critical systems, plus a crisis exercise. Many organisations discover on that occasion that a backup will not restore, or that the procedure was stored on the very server to be restored.

Rarely as they stand. Against ransomware, what counts is that a copy is isolated from the domain, immutable and restorable within the target time. We check those three properties rather than the mere existence of a backup.

Yes, all of those frameworks require a proven continuity capability. The work done here feeds those programmes directly, and the other way round: if you are already running one, we build on what exists.

How long would it take you to come back?

An impact analysis and a restoration test give a factual answer — often different from the expected one.

Contact us