Business continuity: prove the recovery path

A recovery plan becomes credible when the team can show how a critical service will return, in what order, and with which resources. A backup is one input to that plan; it does not establish the whole recovery capability.

For a CTO, the practical question is whether recovery still works when normal operating assumptions fail. Can another engineer execute the procedure? Can the team obtain credentials without the production identity service? Can business users complete a transaction after infrastructure has been restored?

Treat continuity as an engineered capability: define acceptable outcomes, identify dependencies, build recovery procedures, exercise them, and retain evidence of what happened. The deliverable is a demonstrated recovery route, with its limitations understood and its weaknesses assigned for correction.

Establish the obligation and the operational boundary

NIS2, Article 21 includes business continuity, such as backup management and disaster recovery, and crisis management among cybersecurity risk-management measures. It also addresses policies and procedures for assessing the effectiveness of those measures. Article 20 covers management approval and oversight.

NIS2 is a directive implemented through national law. Applicability depends on sector, size, service, and inclusion rules; applicable national and sector requirements determine specific obligations. Do not treat a generic continuity template as a complete legal assessment.

Operationally, distinguish four connected activities:

• Business continuity: keeping important business functions operating, potentially at reduced capacity.
• Backup management: maintaining protected, recoverable copies of data and necessary configuration.
• Disaster recovery: restoring technical systems and validating the service they support.
• Crisis management: coordinating decisions, resources, communications, and escalation.

A service may continue through manual work while its systems remain unavailable. Conversely, servers may be running while the business function remains unusable. Define both technical and business acceptance criteria.

Begin with one critical service and a stated scenario boundary. Recovery from accidental deletion is different from recovery after administrative credentials have been compromised. Record which situations the plan covers, which need separate procedures, and who accepts any remaining gap.

Work backward from the business service

A business impact analysis, or BIA, establishes what disruption means before engineering selects a recovery design. Interview the service owner and the people who actually perform the work. Ask what happens after an hour, a working day, and a longer interruption: missed transactions, unsafe operations, contractual failures, customer harm, or an accumulating backlog.

Document the minimum acceptable operating level. A customer portal might need order submission and order-status access before reporting features return. A production operation may need scheduling and safety information before administrative functions.

Three measures guide the design:

These are related but different. RTO should leave room within tolerable disruption for business validation and operational recovery. RPO describes acceptable data loss; it is not another downtime target.

Agree the clock explicitly. If one team measures RTO from incident declaration while another measures from service interruption, reported results will be misleading. Record detection and activation time separately even when the agreed recovery metric starts later.

Business owners approve the required outcome; engineering demonstrates whether the design can meet it. Where cost, staffing, or supplier limitations make a target unrealistic, present the options: invest in faster recovery, introduce reduced operations, change the target with accountable approval, or accept the risk. Do not silently replace a business requirement with what the current backup system happens to achieve.

Map the dependencies that can prevent recovery

For a customer portal, restoring the database may still leave the service unusable if identity, DNS, or deployment credentials are unavailable. Build a dependency map from the business transaction outward, rather than from the server inventory inward.

Include applications and databases, but also networks, identity providers, certificate services, secrets, encryption keys, deployment artifacts, monitoring, external integrations, people, and supplier support. Record where each dependency is operated, who can recover it, and what must exist before recovery starts.

Look particularly for circular dependencies. The password vault may require the identity platform, while restoring that platform requires credentials stored in the vault. The recovery guide may sit in the collaboration service that is itself unavailable. Resolve these loops through controlled emergency access and independently accessible instructions; test both rather than assuming they work.

Recovery order is a dependency graph, not necessarily a universal sequence of network, database, and application. Some tasks can run in parallel. Others have gates, such as confirming a clean administrative environment before exposing restored workloads to it.

For suppliers, distinguish promises from operational arrangements. Establish support contacts, escalation routes, customer-side responsibilities, export options, recovery commitments, and how you will receive updates during disruption. A supplier's recovery objective does not automatically establish your end-to-end service objective. Model what happens if it is unavailable longer than expected.

Design backups around recovery, not job completion

A successful backup job shows that a process completed. It does not prove that the right data was captured, that keys remain available, or that the application can use the restored state.

Create a backup specification for each critical system:

• Included datasets, configuration, artifacts, and explicit exclusions.
• Backup method, schedule, expected recovery-point age, and retention.
• Storage locations and dependencies on accounts, regions, or facilities.
• Administrative access, encryption, key recovery, and deletion controls.
• Monitoring responsibilities, failure escalation, and restoration instructions.
• Restore-test scope, acceptance criteria, and retained results.

The commonly used 3-2-1 approach, sometimes extended with an offline or immutable copy and verification, is a practical design heuristic, not a universal NIS2 formula. Evaluate whether copies have genuinely different failure modes. Several copies managed through one compromised administrator account may provide little protection against deliberate deletion.

Offline and immutable copies are also different. Offline storage is disconnected; immutable storage restricts modification or deletion under defined controls. Examine who can alter retention, destroy keys, close the account, or change access policies. Avoid treating the label alone as proof of protection.

Match the mechanism to the data

For a transactional database, snapshot frequency alone may not meet the RPO. Log capture, application-consistent backups, and point-in-time recovery may be necessary. Validate whether transactions spread across several systems can be recovered to a coherent state.

Replication can reduce interruption, but it may also replicate corruption or malicious changes. It does not replace retained recovery points. Similarly, a SaaS availability commitment may not cover recovery from customer deletion or account compromise; check the actual recovery and export arrangements.

Include encryption keys and configuration needed to interpret the restored data. Protect recovery material separately where appropriate, with controlled access and a tested retrieval route. Encryption and key management should cover recovery as well as normal operation.

Retention must account for delayed discovery: the newest copy may already contain the problem. Selecting an older clean point can increase data loss beyond the RPO. Document that tradeoff and the reconciliation work needed, rather than calling any completed restore a success.

Write runbooks that another engineer can execute

A useful recovery runbook identifies prerequisites, actions, expected outputs, failure branches, and acceptance checks. It should be specific enough for an authorized substitute to follow without reconstructing the architecture under pressure.

Start with activation conditions and safety boundaries. Who authorizes recovery? Where will it run? Which networks must remain isolated? What production changes are prohibited during the exercise? If malicious activity is suspected, preserve relevant evidence and coordinate containment before reconnecting recovered systems.

Each step should contain:

Reference controlled procedures for environment-specific commands. Keep secrets out of the runbook itself, but explain how authorized responders retrieve them during an outage.

Measure setup, transfer, restoration, configuration, validation, and handover separately. A fast data restore can still miss the RTO because infrastructure provisioning or business checks take longer than expected.

For cyber recovery, rebuilding from trusted artifacts may be safer than restoring entire machines. Validate privileged accounts, rotate exposed credentials as appropriate, and check for persistence before release. These decisions should be explicit branches in the procedure.

Finish with service-level checks: authentication, a representative transaction, integration behavior, monitoring, and reconciliation. The technical lead records completion; the business owner accepts the agreed operating level. Include a controlled return from temporary arrangements, with responsibility for resolving queued work and duplicate records.

Keep the business operating while recovery proceeds

Alternative operations need their own capacity and safety limits. “Use a spreadsheet” is not a plan unless someone has established access, fields, authorization, storage protection, and later reconciliation.

For a disrupted order service, a temporary process might accept a limited class of orders through an approved channel, issue unique references, and defer payment processing. Record who authorizes orders, how duplicates are prevented, how customer information is protected, and when the workaround must stop.

Assess whether reduced operations actually buy enough time. Manual processing may sustain a small volume but collapse under the normal workload. Test representative demand and identify priority customers or transactions using agreed business criteria.

Also plan for people and workplaces. Recovery can fail because the only qualified operator is unavailable, the alternate site lacks connectivity, or responders cannot work safely through an extended incident. Assign substitutes, handover requirements, and staffing arrangements rather than relying on individual endurance.

Give the crisis team clear decision rights

Separate incident coordination from hands-on recovery so the technical lead is not simultaneously restoring systems, approving expenditure, and answering every stakeholder.

Assign primary and substitute roles for crisis coordination, technical recovery, business operations, executive decisions, communications, and legal or compliance assessment. Record activation thresholds, contact methods, decision authority, and escalation conditions. Practical pre-authorizations can cover emergency support purchases, alternate infrastructure, and suspension of unsafe services, within limits approved by management.

Prepare communication templates for employees, customers, suppliers, and authorities. Each should distinguish known facts from estimates, describe affected services, give current instructions, and identify the next update time. Test an alternate channel when corporate email and chat are unavailable. Ensure responders can access contact information securely outside normal systems.

Reporting assessment must run alongside recovery. For significant incidents within scope, NIS2, Article 23 establishes a 24-hour early warning, a 72-hour incident notification, and generally a final report within one month of notification. Check applicable national and sector rules, thresholds, recipients, and procedures. Not every outage is automatically reportable.

Assign someone to track awareness time and reporting decisions; do not wait for full restoration before assessing obligations. Where personal data is involved, assess the separate GDPR breach-notification requirements according to the organization's role and the risk to individuals.

Exercise different claims with different tests

Choose the exercise type according to what you need to prove:

Set frequency as a practical, risk-based decision informed by applicable requirements, service criticality, change rate, and previous findings. Do not assume a universal quarterly or annual interval satisfies every obligation. Trigger additional tests after material architecture, supplier, access, or staffing changes.

Before testing, approve the scenario, objectives, safety controls, participants, stop conditions, and success criteria. Prefer isolated environments where feasible. Prevent test messages, payments, or customer notifications from escaping into live operations.

Use realistic constraints: an absent specialist, unavailable identity services, an older clean backup, or delayed supplier support. Avoid silently providing credentials and infrastructure that would not exist during the incident.

Capture the scenario, participants, start and end times, step timings, actual results, and deviations. Record assistance and shortcuts. If the test omitted DNS changes, production-volume data, or external integrations, say so. A bounded result is more useful than an overstated pass.

Worked example: proving a customer portal recovery route

Consider an illustrative portal supporting order submission. The following targets and timings are assumptions, not industry benchmarks or product promises.

The business agrees a four-hour RTO and a 15-minute RPO. Recovery means customers can authenticate, submit an order, and see its status; reporting can return later. The scenario assumes production infrastructure and ordinary administrator credentials are unavailable, but a separately controlled backup copy remains accessible.

The team budgets the route as follows:

This leaves only 20 minutes against the four-hour target. Because several tasks share one recovery engineer, the team does not assume they can run concurrently.

During the exercise, obtaining deployment credentials takes an additional 55 minutes: the documented access route depends on the unavailable identity provider. The service passes its functional checks after 275 minutes and misses the RTO. Its latest recoverable transaction is 12 minutes before interruption, meeting the assumed RPO for this scenario.

The result is not a general pass. The access owner establishes a controlled independent retrieval route, the runbook is updated, and a substitute engineer retests it. The next integrated exercise must verify the complete elapsed time again. The business owner also reviews whether the remaining timing margin is sufficient for less favorable conditions.

Retain evidence and close the weaknesses

Keep a coherent evidence set: the approved BIA, service boundary and dependencies, backup specification, recovery runbooks, crisis roles and contacts, alternate-operation procedures, and exercise records. Preserve versions so reviewers can see which plan was actually tested.

For every material weakness, record the affected service, observed result, business consequence, owner, due date, remediation, and verification method. Completing a task is not the same as proving the fix. Retest the affected step and, where dependencies changed, the wider recovery route. Escalate overdue actions and target gaps to the accountable decision-maker.

In Secani, model the critical service and its supporting systems and providers, connect exercise evidence to the requirements or controls it supports, and turn gaps into owned tasks. Keep reviewer comments and human approvals attached to the decisions. The documented workflow supports that evidence context; technical recovery still needs to be executed and validated by the responsible team.

Start with one critical service. Agree what recovery means, walk its dependency route with a substitute operator, and schedule a bounded restoration exercise. Use the measured result to update the plan, not merely to mark the exercise complete.