CyberSec Update #40: Business Continuity, RTO & RPO | KWKR

CyberSec Update: Business Continuity – Build the Ark Before the Flood (Series Finale)

Noah began building the ark while the sky was still clear. Had he waited for the first drops of rain, no amount of timber would have saved him. The entire wisdom of this story can be summed up in a single word: beforehand.

In the previous parts of this series, we built a contractual “border wall” in the form of a cybersecurity clause, assessed risk using categories A–D, and established a common language for incidents through project parameters and an incident matrix. Today, we move to the layer that often determines whether an organisation survives a cybersecurity incident: business continuity.

How should RTO and RPO be defined in a practical and sensible way? How should BCP and DRP plans be prepared? And where does proportionality end and a hard requirement begin?

Why Include Business Continuity in a Cybersecurity Clause?

Sooner or later, an incident will occur. The key question is how quickly the organisation can return to normal operations.

For this reason, contractors should provide business continuity measures appropriate to the operational importance of every system covered by the clause, including:

• a Business Continuity Plan (BCP);
• a Disaster Recovery Plan (DRP);
• data and system backups.

This contractual requirement reflects the statutory obligation to maintain business continuity and recovery plans imposed on essential and important entities under the KSC framework and the NIS2 Directive.

RTO and RPO: Two Numbers That Must Be Agreed Upon

RTO (Recovery Time Objective) and RPO (Recovery Point Objective) form the foundation of every discussion on business continuity and operational resilience.

In practice, a simple mechanism works well:

• for each operationally critical system, the contractor proposes RTO and RPO values, which are then approved by the contracting authority in accordance with the minimum requirements set out in the project parameters;
• where no individual arrangements have been made, the default maximum values specified in the project parameters apply;
• these values form part of the project’s “variable layer” rather than the core cybersecurity clause itself.

Where Does Proportionality End and a Hard Requirement Begin?

This is the key issue addressed in today’s article. Not every system requires the same level of security controls. However, when operationally critical systems are concerned, proportionality has its limits.

• operationally critical systems should be covered by comprehensive BCP and DRP arrangements that are tested regularly; disaster recovery tests should be conducted at least once a year, with results documented and made available upon request;
• other operationally significant systems should have a proportionate continuity framework reflecting the contractor’s risk category, level of access and the system’s impact on contract performance;
• the scope of obligations should be determined by the actual impact on operations rather than solely by the fact that a system is covered by the clause.

In other words, the closer a system is to the “heart” of an organisation’s operations, the less room there is for discretion.

What Is an Operationally Critical System?

This category should be defined precisely, as it determines the level of cybersecurity and business continuity requirements.

An operationally critical system is a system whose unavailability, failure, or loss of data confidentiality, integrity or availability could result in:

• significant disruption of business operations;
• risks to the safety of people, property or infrastructure;
• interruption of business continuity;
• substantial operational or financial losses.

Such a system may be designated by the contracting authority in the project parameters or identified on the basis of a Business Impact Analysis (BIA), risk assessment or procurement documentation.

Business Continuity Over Time: Delivery, Maintenance and Warranty

Business continuity obligations do not end once a project has been accepted. However, they should be allocated reasonably over time.

• full business continuity obligations apply throughout the contract performance period and the maintenance phase;
• during the warranty and defect liability periods, these obligations should apply proportionately to the contractor’s responsibility for the relevant environment; where the contractor is not responsible for maintenance, obligations related to BCP, DRP and RTO/RPO should be limited accordingly;
• certain obligations, such as secure data deletion or support during regulatory inspections, may continue even after the contract has ended.

Contract Exit Is Also Part of Business Continuity

Some of the greatest risks to business continuity arise at the end of a business relationship, particularly when changing service providers.

For operationally significant systems, organisations should therefore consider implementing a phase-out or exit plan covering:

• the secure transfer of systems, documentation and know-how to a successor provider;
• maintaining service continuity during migration;
• where justified, allowing the contracting authority to assume temporary operational control through a step-in mechanism.

Quite literally, this is the final plank of the ark.

KSC, NIS2 and GDPR: A Common Business Continuity Framework

Tested business continuity plans, backup procedures and crisis management measures are all elements of risk management required from essential and important entities.

From a personal data protection perspective, these requirements also align with Article 32 of the GDPR, which identifies the ability to restore the availability of personal data in a timely manner following an incident as one of the key security measures.

What’s Next? A Final Word on the Series

Noah’s ark reminds us that business continuity is not a reaction to disaster; it is preparation for it.

RTOs, RPOs, BCPs, DRPs and disaster recovery testing are effective only when they are implemented in advance, especially in the case of operationally critical systems.

With this article, we conclude our mini-series on the cybersecurity clause. Together, we have explored:

• the clause as a contractual border between an organisation and its contractor;
• risk categories A–D as a method of calibrating requirements;
• project parameters and the incident matrix as a shared language for incident management;
• business continuity as the guarantee of returning to operations after an incident.

The conclusion remains unchanged: a well-designed cybersecurity clause is not a list of prohibitions. It is a carefully structured risk management architecture, stringent where security is at stake and proportionate where the nature of the risk allows it.

Thank you for following the entire CyberSec Update series. More topics and new challenges lie ahead, all viewed through the same cybersecurity lens.