What NIS2 Article 21(2)(c) business continuity and crisis management requires
If your entity provides services covered by NIS2, Article 21(2)(c) asks you to show that you can keep those services running and recover from disruption. In practice, that means four connected parts: continuity and disaster recovery plans, backup and redundancy management, a crisis management process, and a duty to test and update all three. Implementing Regulation (EU) 2024/2690 sets the detail for these parts in its Annex, section 4, and the detail is what a national authority will check. Start by confirming which of your systems fall under the regulation and whether your entity is a provider type it covers directly. The continuity and disaster recovery plan must rest on your risk assessment. It should name roles, contacts, activation conditions, the order in which systems return, recovery objectives, the resources needed, and how you move from temporary measures back to normal operation. Before you write it, carry out a business impact analysis and derive the continuity requirements for your network and information systems from that analysis. Ask whether the analysis reflects what the business actually depends on, not only what IT hosts. The hardest part is proving it works. Plans are often written and never exercised, backups run daily but nobody has restored from them, and crisis roles are assigned on paper without anyone knowing who calls the regulator or who approves a shutdown. Your plans, backup restores and crisis exercises must be tested, reviewed and updated at planned intervals and after significant incidents or significant changes. Keep dated records of each test, its results and the fixes that followed. No certificate exists for NIS2. Your national competent authority judges the evidence through inspections, audits, scans and information requests, and a partner can help you prepare that evidence but cannot issue a finding of compliance.
Which systems, teams and suppliers fall under continuity scope
Continuity scope is set before any plan is written. Article 21(2)(c) work starts by deciding which services and systems the entity cannot lose, which data must be recoverable, who owns recovery, and which providers sit in the recovery path. Each card below is a decision that changes the size and cost of the program.
Essential services and their systems
Start from the services the entity delivers and trace each one back to the network and information systems it depends on, including identity, networking, DNS and monitoring. The Implementing Regulation expects the business impact analysis to derive continuity requirements for these systems, so the scope list should come from that analysis, not from the asset inventory alone. Ask which services would breach a legal or service obligation if they stopped for a defined period.
Data stores that need backup
Inventory every database, file share, object store, configuration repository and backup catalog that a recovery depends on. Record where each store lives, who owns it and how often it changes, because these facts determine backup frequency and retention. Confirm that backup scope includes the catalog and key material needed to restore, not only application data.
Teams that own recovery steps
Name the owner of each recovery step, from declaring an incident to restoring service and resuming normal operations. Continuity plans must set roles and contacts, so gaps in ownership show up as gaps in the plan. Include business owners who approve recovery order and accept temporary measures, not only infrastructure staff.
Cloud and data center dependencies
Map which recovery paths run through cloud regions, colocation facilities or hosting providers, and which of those providers is the only source of a backup copy. Implementing Regulation 2024/2690 applies its requirements to cloud computing, data center and managed service providers, so entities that rely on such providers need to know what those providers are obliged to do and what the entity still must verify. Ask for each provider's recovery commitments in writing.
Managed providers and supporting utilities
Identify managed service providers that operate monitoring, backup or security tooling for the entity, and confirm which of their functions would stop during an outage. The Implementing Regulation also addresses supporting utilities such as power, cooling and connectivity under its point 13.1, so check which utilities the essential services need and whether the entity has evidence of their continuity. Document how an outage at one provider would affect each service.
Dependencies on open-source tooling
List the self-hosted platforms that run backup, restore, verification and alerting, such as Bareos, restic, Grafana and Prometheus, and record which systems each one protects. A backup tool that fails silently can leave a service without recoverable data, so monitoring the tool itself belongs in scope. Confirm version ownership, upgrade responsibility and where each component runs, because these platforms are often overlooked when recovery paths are drawn.
How an assessor tests continuity, backup and crisis processes
An assessor starts by reading the business continuity and disaster recovery plan and checking that it traces back to the risk assessment, as point 4.1.2 of the Annex to Implementing Regulation (EU) 2024/2690 requires. The reviewer looks for named roles, contact lists, activation conditions, the order in which systems return, recovery objectives, the resources needed, and steps for moving from temporary measures back to normal operations. Interviews with the people named in the plan test whether they know their role and can reach the contacts listed.
- Document review: Compare the plan against the current risk assessment and the system inventory to confirm that every critical system has a recovery entry.
- Interviews: Ask the named owners to describe their activation trigger and first three actions without reading the plan.
- Evidence requested: Approved plan version, change history, contact list with dates of last verification, and recovery order documentation.
- Common finding: Plans written from a template, with recovery objectives that no one has validated and contacts who have left the organization.
- Common finding: No record that the plan was reviewed after the last significant change or incident, as point 4.1.4 expects.
Check that the plan names an owner, carries a review date and shows what changed since the last test.
Point 4.1.3 of the Annex asks the entity to carry out a business impact analysis and derive continuity requirements for its network and information systems from it. An assessor checks that the analysis covers the processes the entity depends on, identifies which systems support them, and links each system to a tolerable downtime and data loss level. The reviewer then follows one or two systems from the analysis into the recovery plan and into the backup configuration to confirm the chain holds.
- Traceability: Pick a critical service and confirm that its dependencies, recovery requirements and backup schedule all match.
- Dependency mapping: Check that upstream identity, network, DNS and third-party services appear, not only the application itself.
- Evidence requested: Signed analysis, method description, dependency diagrams, and the sign-off record from management.
- Common finding: Analysis produced once and never refreshed after new systems or cloud migrations were added.
- Common finding: Recovery time targets set in the analysis that the technical team says cannot be met, with no decision recorded.
Confirm that the analysis was approved by the people accountable for the services it covers.
For backup and redundancy, an assessor moves from policy to operation. The reviewer asks for backup job records, retention settings and the results of integrity checks, then asks for a live restore of a sample system into a test environment. Point 4.1.4 expects continuity and recovery arrangements to be tested at planned intervals, and a backup that has never been restored is treated as unproven. Redundancy claims, such as a standby site or secondary data copy, need the same kind of observation.
- Restore observation: Ask the entity to restore a chosen file set or system and time the process against the recovery objective.
- Integrity verification: Review verification logs, and where tools such as Bareos or restic are used, check that verify and read-data checks run on a schedule.
- Evidence requested: Job logs, catalog or repository listings, restore test records, retention policy and off-site or isolated copy details.
- Common finding: Restores never performed, or performed once without a written result.
- Common finding: Backups that exist but are not covered by the continuity plan, or copies held in the same account as the primary data.
Test a restore yourself if the entity allows it, and record the time taken and any errors.
Point 4.3.2 asks for a crisis management process that defines roles during a crisis, the communication with competent authorities including incident reports and their timelines, and the measures that keep systems secure while the crisis is running. An assessor tests this through a walkthrough or tabletop exercise, then checks whether the roles and reporting steps match what the plan states. Point 4.3.4 requires the crisis plan to be tested and updated after significant incidents or changes, so the reviewer also reads the record of past exercises and any real events.
- Walkthrough: Ask the crisis lead to describe who decides, who communicates and who contacts the authority, and compare the answers with the written process.
- Exercise records: Review scenario, participants, timings, gaps found and corrective actions with owners and dates.
- Evidence requested: Crisis roles and deputies, communication templates, reporting timeline checklist, exercise reports and post-incident reviews.
- Common finding: Reporting timelines in the crisis plan that do not match the incident reporting process.
- Common finding: Exercises run with no follow-up, so the same gaps appear in the next test.
Check that the crisis roles are filled by people who are on call and that the security measures during a crisis are written down, not assumed.
How to build the continuity program step by step
This sequence turns the risk assessment into a tested continuity capability, so each plan rests on documented business priorities and each recovery step has an owner, a target and evidence behind it. Work proceeds from analysis to plan, technical redundancy, crisis handling and ongoing testing.
Derive the business impact analysis from the risk assessment
Start from the risk assessment already required under the Article 21 risk management process. Identify the business processes that depend on network and information systems, the services they support, and the effect of losing each one over time. Record the dependencies on systems, data, suppliers and facilities. The output is a business impact analysis that names the systems whose disruption matters most and gives continuity requirements for each. Check that every requirement traces back to a risk and an owner who has signed off on it.
Set recovery objectives and the order of recovery
Using the business impact analysis, set recovery objectives for each critical system and agree the order in which systems come back after a disruption. Ordering usually follows dependencies, such as identity and network services before the applications that rely on them. Ask business owners to confirm the tolerable downtime and data loss for their processes, and ask technology owners to confirm they can meet those targets. The output is an approved recovery sequence with objectives attached, which becomes the reference for backup design and drills.
Write the business continuity and disaster recovery plan
Draft the plan from the risk assessment and the recovery sequence. Define roles and deputies, contact lists with out-of-hours numbers, the conditions that activate the plan and who has authority to activate it, the recovery steps for each critical system, the required resources such as people, facilities, licenses and spare hardware, and how services move from temporary measures back to normal operation. The output is a versioned plan that a responsible manager has approved, with contact details stored where they remain reachable during an outage.
Implement backup and redundancy for critical systems
Put in place the backup and redundancy designs that the recovery objectives require. Configure scheduled backups, retention, offsite or isolated copies, and a catalog that lets operators locate and restore specific files or versions. Add redundancy for critical components where the objectives demand it. Monitor backup jobs and alert on failures, and verify that copies are structurally sound and readable. Evidence includes job configurations, backup reports, verification results and restore logs tied to the recovery objectives.
Write the crisis management process and authority communication
Define how the organization runs a crisis: who leads, who decides on escalation, how decisions are logged, and how security stays intact while systems run in temporary or degraded modes. Specify how the crisis team communicates with the competent authority, including the incident reports the process must produce and the timelines that apply to them under the incident reporting obligations. Include communication with customers and staff. The output is a crisis management procedure, a decision log template, and a contact matrix that someone has checked against current authority requirements.
Test the plans and run exercises
Run structured tests of the continuity plan, disaster recovery procedures and crisis process at planned intervals. Start with tabletop exercises that walk through a scenario, then move to restore tests and failover tests for critical systems. Record what was tested, who took part, the time each step actually took, and each gap found. The output is a test report with actions assigned to owners and deadlines set by the organization's own policy, as the supplied facts give no fixed interval.
Review and update after incidents and changes
Update the business impact analysis, recovery objectives, plan, backup designs and crisis process when test results, real incidents or significant system or organizational changes reveal gaps. Keep a change record that links each revision to its trigger. Confirm that the management body reviews the updated program. The output is a current, approved version of each document and a revision history that shows the program is maintained, which is the evidence a competent authority will ask to see.
Why restores and failovers must be tested, not assumed
A continuity plan that has never been exercised is a hypothesis. Implementing Regulation (EU) 2024/2690 requires the business continuity and disaster recovery plan, the crisis management process and the related backup and redundancy arrangements to be tested, reviewed and updated at planned intervals, and again after significant incidents or significant changes. The regulation does not fix a test frequency in the Annex, so the entity must set one, justify it from its risk assessment and business impact analysis, and be able to show supervisors the schedule and the results.
Different exercise types prove different things, and an entity should not treat one as a substitute for another. A restore test shows that selected data can be recovered from backup within the recovery objectives the plan states, which is the only way to confirm that backups are usable. A failover test shows that a redundant system or site takes over in the order the plan sets, with the resources it names. A tabletop exercise tests roles, contacts, activation conditions and decision-making without touching production. A crisis simulation tests the crisis process end to end, including communication with competent authorities and the incident reporting timelines. Checking backup integrity separately, for example by reading pack files back with restic check --read-data-subset, adds evidence that stored data has not been altered.
Results should change the documents and the risk picture. Each test should record what was measured, what failed, who decided the fix and when it was retested. Findings flow back into the business continuity plan, the business impact analysis and the risk assessment, and a material gap should trigger a review outside the planned cycle. Ask your implementation partner and auditor to confirm which test records, timestamps and sign-offs your supervisor is likely to request, because the evidence format is set by your own environment and national transposition law.
Evidence that passes a NIS2 continuity review
A continuity review under Article 21(2)(c) asks whether the plans exist, whether they rest on a business impact analysis, and whether they have been tested and kept current. Each card below names one artifact an assessor will ask for and the routine that keeps it accurate between reviews. Together they show a chain from risk assessment to tested recovery.
Approved continuity and DR plan
The business continuity and disaster recovery plan must rest on the risk assessment and name roles, contacts, activation conditions, recovery order, recovery objectives, required resources and how services resume from temporary measures. Check that management has approved the version in force and that each recovery objective traces to a risk. Keep the plan under version control, with an owner and a review date tied to the test schedule and to significant changes.
Business impact analysis and derived requirements
The business impact analysis shows which network and information systems support essential functions and how long each can be down before harm occurs. The continuity requirements for each system should follow directly from it, so an assessor can read the chain from impact to recovery target. Confirm the analysis names its data sources, its approvers and the dates it was last reviewed, and that it is refreshed when systems or services change.
Backup policy and job records
The backup policy sets what is protected, how often, where copies are stored and how long they are kept. Job schedules and run logs from the backup server prove that the policy is followed in practice. Bareos keeps a SQL catalog of backed-up files and records of its jobs, which can supply these records if retention is configured to cover the audit period. Ask for failed-job reports and how each failure was resolved.
Restore test records
A backup that has never been restored is not evidence of recovery. Keep dated restore test records showing the system tested, the backup used, who ran the test, the time to restore and the outcome, including failures and the fixes that followed. For data integrity, restic check with --read-data or --read-data-subset reads pack files back to confirm stored data is unmodified, and its output can be kept with the test record.
Redundancy architecture diagrams
Architecture diagrams show where primary and secondary systems, backup repositories and recovery sites sit, and which failures each design survives. Assessors compare these diagrams with the recovery objectives in the plan and with the results of restore tests. Keep diagrams dated and tied to change records, and confirm that the diagram matches the deployed environment, not the design from the original project.
Crisis management process and authority communication
The crisis management process defines who decides in a crisis, who speaks to competent authorities and how incident reports and their timelines are met. Keep the contact tree, escalation paths and deputies current, and record when each contact was last verified. Grafana Alerting can route alerts from monitoring data to the people named in this process, and the alert rule configuration is itself evidence that detection links to escalation.
Exercise reports and change-driven revisions
The plan must be tested, reviewed and updated at planned intervals and after significant incidents or significant changes. Exercise reports should state the scenario, the participants, the gaps found, the corrective actions with owners and the date each was closed. Keep a revision log that links each plan update to the test, incident or change that caused it, so the review shows a working feedback loop rather than an annual rewrite.
What meeting Article 21(2)(c) costs in money and effort
This table breaks down the cost and effort components of meeting Article 21(2)(c), showing who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to build a scope and to ask suppliers and assessors for line-item quotes, since no fixed figures are supplied for these components.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives it |
|---|---|---|---|
| Backup and redundancy infrastructure | Cloud provider, data center operator or hardware vendor, plus the internal team that operates it | Mostly one-time setup, then recurring storage, compute and replication | Data volume, number of sites, retention periods and whether copies must sit off-site or in separate accounts |
| Licenses or the zero-license route | Software vendor for commercial backup suites, or no license fee for self-hosted open source such as Bareos or restic | Recurring for commercial licenses, usually none for open-source licenses | Number of protected hosts, support tier and whether vendor support is required by your continuity plan |
| Engineering time for recovery design | Internal platform engineers, or an implementation partner under a written scope | One-time, with periodic revision | Number of critical services, dependencies between systems and recovery objectives set by the business |
| Restore testing engineering | Internal operations staff or a partner running restore exercises | Recurring at planned intervals and after major changes | Size of restore sets, number of systems tested per cycle and whether tests cover full environments |
| Business impact analysis and exercises | Business owners, process leads and risk staff, with facilitation by internal or external staff | Recurring, usually annual or after significant change | Number of business processes in scope, number of departments and how often plans change |
| Evidence upkeep | Internal compliance or security staff, sometimes supported by a partner | Recurring | Frequency of test records, number of plans and how much evidence is produced automatically by monitoring and backup logs |
| External exercise facilitation or review | Independent facilitators or consultants, billed per agreed scope | Recurring per exercise cycle | Complexity of crisis scenarios, whether cross-team or multi-site exercises are included and the depth of the written report |
| Auditor or assessor time | Independent auditor, assessor or certification body, not the implementation partner | Recurring with each assessment cycle | Scope of systems sampled, number of sites visited and how well evidence is organized before fieldwork |
Who owns continuity, who can outsource it, and what the auditor checks
The entity keeps ownership of its continuity program. Article 20 places approval and oversight of the Article 21 measures with the management body, and the entity remains liable for its own infringements whoever helps build the systems. Decisions about what is critical, how much downtime and data loss the business can accept, and when a crisis is declared cannot be delegated to a consultant or a vendor.
- Management approval: The management body approves the continuity and disaster recovery plan, the crisis management process and the recovery objectives that flow from them.
- Business impact decisions: Business leaders confirm which services and systems are critical, the impact of their loss and the continuity requirements derived from the business impact analysis.
- Risk owners: Named owners accept residual risk, decide on redundancy investment and sign off recovery priorities for each system.
- Crisis leadership: Internal staff hold the crisis roles, make containment and recovery decisions, and speak to the competent authority and affected customers during an event.
- Plan maintenance: Internal owners schedule tests, review the plans after significant changes or incidents and record the outcomes.
Before engaging any partner, confirm that named internal people hold each of these roles and have the authority to act on them.
An implementation partner can do much of the technical and documentary work. DeployOpen, for example, plans, implements, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, and prepares systems and evidence for assessments. A partner does not issue reports or certificates, and it does not take over the entity's accountability for continuity.
- Backup and redundancy build: The partner can configure backup jobs, retention, offsite copies and redundant components for the in-scope systems, such as Bareos for scheduled backup and restore jobs.
- Plan drafts: The partner can prepare draft continuity and disaster recovery plans, runbooks and crisis procedures for the entity to review, change and approve.
- Restore and failover tests: The partner can run restore and failover exercises, record results and fix the gaps they expose.
- Evidence preparation: The partner can collect job logs, verification results, test reports, alert configurations and version records in a form the entity can present.
- Monitoring setup: The partner can deploy monitoring and alerting, for example with Prometheus and Grafana Alerting, so that backup failures and capacity problems reach people quickly.
Before signing, ask for a written scope that names each deliverable, the systems covered and who approves the drafts.
Independent reviewers test and judge the evidence. Depending on the framework and the country, this is an independent auditor, assessor or certification body for voluntary assurance, or a national competent authority that inspects, audits, scans and requests information under its NIS2 transposition law. NIS2 creates no certificate of compliance, so no one can certify continuity as compliant under the Directive alone.
- Plan review: The reviewer checks that the continuity and disaster recovery plan rests on the risk assessment and sets roles, activation conditions, recovery order and recovery objectives.
- Business impact analysis: The reviewer tests whether continuity requirements for systems are traceable to the analysis and approved by management.
- Test results: The reviewer examines restore and failover tests, their dates, scope and outcomes, and whether findings led to plan updates.
- Crisis records: The reviewer checks crisis roles, communication paths with authorities and the timelines for incident reports.
- Backup integrity: The reviewer may ask for evidence that stored data can be read back, such as integrity checks, and for proof that retention meets the entity's own requirements.
Ask your auditor or authority which evidence format and test cadence it expects before preparing the package.
Where continuity programs usually fall short
Most continuity programs exist on paper but fail when tested against the Article 21(2)(c) expectations for plans, impact analysis, backups and crisis handling. The gaps below cluster around links that break between documents, people and suppliers, so each card pairs a gap with the action that closes it.
Business impact analysis not tied to risk
The business impact analysis often sits in a separate workbook that nobody reconciles with the risk assessment. Under Implementing Regulation 2024/2690, continuity requirements for network and information systems should be derived from the impact analysis, and the continuity plan should rest on the risk assessment. Check that each critical system in the impact analysis maps to a risk entry, and that the recovery targets trace back to a documented scenario.
Backups never restored
Many programs prove that backup jobs succeed but never prove that data comes back usable. A job report shows that files were written, not that a database, configuration or application can be rebuilt from them. Schedule restore tests against realistic scenarios, and record the time taken and the data lost. Tools such as restic can verify stored pack data with read-data checks, which supports integrity testing, though a full restore exercise is still required.
No defined recovery order
Plans often list systems but not the sequence in which they must return. Identity services, DNS, network routing and the database layer usually have to come back before the applications that depend on them, and an unordered list leads to hours lost to dependency discovery during an outage. Document the recovery order, the dependencies behind each step, and the point at which a temporary workaround is replaced by full service.
Crisis roles without named deputies
A crisis plan that names one incident commander, one communications lead and one technical lead has a single point of failure built in. Absences, overnight incidents and holiday periods all remove the named person. The crisis management process should define roles during a crisis and the contact path for each, so confirm that every role has a deputy, that contact details are current, and that deputies have run at least one exercise.
No communication path to authorities
Crisis plans frequently omit how the organization will reach its competent authority, which matters when an incident is significant and reporting clocks start. Point 4.3.2 of the implementing regulation expects the crisis process to cover communication with competent authorities, including incident reports and timelines. Write the reporting path into the crisis plan, name the people authorized to file, and rehearse it against the reporting timelines under Article 23.
Plans not updated after change
Continuity plans age quickly when infrastructure, cloud accounts, suppliers or organizational structures change. The implementing regulation requires plans to be tested, reviewed and updated at planned intervals and after significant incidents or significant changes. Tie plan review to change management, so that a new system or migration triggers an update to the impact analysis, recovery order and contact list, and monitor backup and recovery dashboards so that gaps appear before a test does.
Supplier recovery dependencies left out
Plans frequently assume that hosting providers, managed service providers and software vendors will recover on their own schedule. If a critical service depends on a supplier's platform, the recovery time of that supplier becomes the organization's recovery time. Record each supplier that supports a critical system, the recovery commitments in its contract, and the fallback if that commitment fails. Confirm these terms with suppliers before relying on them in the plan.
Questions buyers ask about continuity and crisis management
How much effort does NIS2 business continuity work take?
The effort depends mainly on how many critical services the entity runs, how interdependent they are, and how much continuity documentation already exists. Article 21(2)(c) work breaks into a business impact analysis, a business continuity and disaster recovery plan, backup and redundancy design, a crisis management process, and tests that show the plans work. Each of these needs input from operations, IT and management, and each must be repeated after significant incidents or significant changes. Ask any consultant to break their scope into these components so you can see where the time goes.
Can we handle NIS2 continuity planning in-house?
Yes, many organizations do the planning in-house, but the decisions belong to management and cannot be delegated. The implementing regulation expects the plans to rest on the risk assessment and the business impact analysis, which means business owners must state how long each service can be down and how much data loss is tolerable. Internal teams often handle the documentation and backup engineering well, while external help is useful for an independent review of the plans, facilitated exercises, or hardening the recovery environment. Confirm internally who will sign off each plan before deciding what to outsource.
How long does it take to get continuity evidence ready?
No single duration applies, because the timeline is driven by the number of in-scope systems, the state of current backups and recovery documentation, and how quickly business owners can agree on priorities. The longest steps are usually the business impact analysis and the first full recovery test, since both depend on other teams. Evidence also accumulates over time: a supervisor will expect records of tests, reviews and post-incident updates, not only a plan. Ask a prospective partner to show how the schedule depends on your system inventory and on the availability of your staff.
What do management and operations need to commit to?
Management must approve the continuity priorities, accept the recovery objectives, and fund the resources the plans require, because these are risk decisions under the Article 20 governance duties. Operations teams must provide the system inventory, dependency maps, backup and restore procedures, and time to run recovery exercises. Several roles also need named backups, since crisis management requires defined roles and contacts even when key people are unavailable. Put these commitments in the project plan with names and dates before work starts.
Does backup software alone meet the continuity requirement?
No. Backup tooling covers the backup management and recovery mechanics, but Article 21(2)(c) also requires a business impact analysis, a plan with roles, activation conditions, recovery order and objectives, crisis communication, and tested, reviewed plans. Tools such as Bareos, which schedules backup, restore and verify jobs and keeps a catalog of backed-up files, and restic, whose check command with --read-data or --read-data-subset reads pack files back to confirm the stored data is unmodified, produce evidence for specific parts of the requirement. Monitoring with Prometheus and Grafana Alerting can show whether backup jobs are running. Confirm with each vendor exactly which features they support before you map them to the plan.
How is a DeployOpen partner scope written and priced?
DeployOpen works under fixed-scope engagements, where scope, deliverables and timelines are agreed in writing before work starts. A written scope for continuity work should list the systems and sites covered, the plans to be produced or reviewed, the backup and recovery components to be built or configured, the exercises to be run, and the evidence delivered to your team. DeployOpen does not publish a price list, so a quote follows from that written scope. Ask for the assumptions behind the quote, what you must provide, and which items are one-time versus recurring, such as retainers for testing and upgrades. DeployOpen prepares systems and evidence, and only an independent auditor or assessor reports on compliance.
Which parts of continuity work can be outsourced?
Technical implementation, such as deploying and hardening backup infrastructure, configuring redundancy, building monitoring, and writing recovery runbooks, can be outsourced to an implementation partner. Facilitated exercises and independent review of plans can also be bought in. The decisions on recovery objectives, risk acceptance, and crisis leadership cannot be outsourced, and the organization remains accountable for them to its competent authority. Clarify in the contract which deliverables transfer ownership and which remain your responsibility.
How DeployOpen works on this
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, then prepares the continuity plans, recovery configuration and test records that Article 21(2)(c) expects you to hold. We do not decide your recovery objectives or issue any attestation; your management body owns those decisions and an independent assessor reviews the evidence.
How we scope
- Agree in writing which systems, sites and services fall under the continuity and crisis management scope.
- Confirm with you which business impact analysis and risk assessment outputs the continuity requirements will be derived from.
- Document who owns the decisions on recovery objectives, roles and crisis communication before any build work starts.
How we build
- Configure Bareos backup jobs, retention and catalog settings for the in-scope systems in your environment.
- Set up restic repositories with scheduled check runs, including read-data checks that confirm stored backup data is unmodified.
- Build Prometheus metrics and Grafana alert rules that flag backup failures and outages so teams can activate the plan.
How we hand over
- Deliver continuity and disaster recovery plan drafts covering roles, contacts, activation conditions and recovery order.
- Record restore test results, verification logs and alert history in a form your assessor can sample and trace.
- Hand over runbooks and a test schedule so your own staff can review, update and rerun the plans after significant changes.
How we support
- Support ongoing operation, upgrades and backup maintenance under a retainer, if you choose one.
- Run restore and crisis exercises on request, with findings documented for management and your competent authority.
- Confirm with your legal and compliance team how crisis communication timelines align with your Article 23 reporting duties.
