Business continuity plan (BCP) and disaster recovery plan (DRP): what to include and what NIS2 requires
Business continuity and disaster recovery plans: how they differ, what to include, how to test them and what NIS2, the Polish KSC Act and GDPR require in 2026.
ZeroLayer Team 16 min read
A business continuity plan (BCP) sets out how an organisation keeps its most important services running when something stops working. A disaster recovery plan (DRP) sets out how to restore IT systems and data to their state before the event. The Polish National Cybersecurity System Act (ustawa o krajowym systemie cyberbezpieczeństwa, KSC) requires both documents from essential and important entities: Art. 8(1)(2)(f) lists implementing, documenting, testing and maintaining business continuity plans, contingency plans and recovery plans. Below: definitions, document structure, testing and the legal bases as they stand in 2026.
How a BCP differs from a DRP
A BCP sets out how to keep delivering a service when a system, a building, people or a supplier is missing. A DRP sets out how to rebuild the IT infrastructure and data, and is largely a technical document.
| Feature | Business continuity plan (BCP) | Disaster recovery plan (DRP) |
|---|---|---|
| Subject | The organisation's processes and services | IT systems, network, data |
| Main question | How do we keep the service running during a disruption? | How do we restore systems after an event? |
| Owner | Management and process owners | IT department or IT service provider |
| Typical content | Workarounds (e.g. manual work), roles, crisis communication | Restore order, backups, technical procedures, alternate site |
| Measures | MTPD, minimum acceptable service level | RTO, RPO for systems |
| Equivalent in the KSC Act | Business continuity plans and contingency plans | Recovery plans |
The KSC Act describes the recovery plan as a plan that makes it possible to restore the information system “after an event that caused losses exceeding the entity's capacity to rebuild using its own resources” (Art. 8(1)(2)(f)). So the DRP must also work when the administrator's routine procedures are not enough.
Both plans belong to a single whole. ISO standards call it a business continuity management system (BCMS). The requirements for such a system are set out in ISO 22301:2019, while ISO/IEC 27031:2025 describes ICT readiness for business continuity, which is the area a DRP covers in practice. Both standards are voluntary. Neither the KSC Act nor NIS2 requires certification against them.
Terms you need to know: BIA, RTO, RPO, MTPD
Every business continuity plan rests on an impact analysis and a few time measures. We give the definitions of MTPD, RTO and RPO in our own words, based on the ISO 22300:2025 vocabulary:
- BIA (business impact analysis). The process of assessing what will happen when a given service or activity is interrupted: what financial, legal, reputational and operational losses arise after an hour, a day, a week. The other three values follow from the BIA.
- MTPD (maximum tolerable period of disruption), sometimes MTD. The time after which the impact of not delivering a product, service or activity becomes unacceptable.
- RTO (recovery time objective). The time within which an activity must be resumed at a specified minimum level. The RTO must be shorter than the MTPD.
- RPO (recovery point objective). The point to which information and data must be restored for the activity to operate after it resumes. In practice: how much data from the last few hours you can afford to lose.
Example (fictitious): in its BIA, a medical practice determines that it can last at most two working days without its booking system (MTPD), during which it will register patients on paper lists. It therefore sets the system's RTO at one working day and the RPO at four hours. It follows that a once-a-day backup is not enough.
Commission Implementing Regulation (EU) 2024/2690 also requires a BIA to be carried out and the continuity requirements for systems to be set on that basis (point 4.1.3 of the Annex).
What NIS2, the KSC Act and the GDPR require
NIS2: Art. 21(2)(c)
The NIS2 Directive lists in Art. 21(2) the minimum elements of risk management measures. Point (c) reads: “business continuity, such as backup management and disaster recovery, and crisis management”. This one provision covers the BCP, the backups that are part of the DRP, and crisis management.
The KSC Act: Art. 8(1)(2)(f) and Art. 10
The Polish Act (as amended by the act of 23 January 2026, Journal of Laws (Dz.U.) 2026 item 252) transposes this requirement into the information security management system. Art. 8(1)(2)(f) covers:
- implementing, documenting, testing and maintaining business continuity plans that enable continuous and uninterrupted provision of the service and ensure the confidentiality, integrity, availability and authenticity of information,
- contingency plans,
- recovery plans that make it possible to restore the information system after an event that exceeds the entity's capacity to rebuild using its own resources.
The document alone is not enough, because the Act also refers to testing and maintenance. Art. 10(3)(3) classifies “business continuity management system documentation” as normative documentation. Art. 10(4), in turn, requires operational documentation, that is, records showing that the activities set out in the normative documentation were actually carried out. A restore test report is exactly such a record. We describe where these documents sit in the overall system in our article on the ISMS and information security policy (in Polish).
An important entity that is a public entity, such as many local government units, does not apply Art. 8(1) but the requirements of Annex No. 4 to the Act (Art. 8(3)). Part I of that annex requires, among other things, backups that are logically and physically separated (point 10), testing the completeness of backups and the ability to restore data from them (point 11), and preparing and testing a procedure for failures or incidents (point 12).
In the event of a critical incident, the minister responsible for computerisation may also issue a protective order requiring these plans to be reviewed for a given vulnerability (Art. 67g(10)(2)).
The head of the entity is responsible for fulfilling the obligations under Art. 8 (Art. 8c), even if they have entrusted them to another person. If you do not yet know whether your organisation is an essential or important entity, start with our article NIS2 and the KSC Act: who it applies to.
Digital service providers: Regulation 2024/2690
Providers of DNS services, cloud computing services, data centre services, managed services and several other categories apply Regulation 2024/2690 directly (Art. 8b(1) of the KSC Act). Point 4 of its Annex lists the elements of business continuity, backup management and crisis management. For other organisations it is a good skeleton for the document, and we use it below.
GDPR: Art. 32(1)(b) and (c)
If your systems contain personal data, the GDPR also requires business continuity. Art. 32(1)(b) refers to the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services. Point (c) concerns the ability to restore the availability of and access to personal data in a timely manner in the event of a physical or technical incident. Point (d) adds regular testing of the effectiveness of measures. Our guide GDPR audit step by step describes how to check this.
For the financial sector, DORA sets separate requirements: Art. 11 of Regulation 2022/2554 requires an ICT business continuity policy, tested plans and a business impact analysis. We discuss them in our article DORA: the regulation and its requirements.
- Art. 8(1)(2)(f)
- provision of the KSC Act on business continuity plans, contingency plans and recovery plans
- Dz.U. 2026 item 252
- 3 April 2027
- deadline for implementing the Chapter 3 obligations for entities covered by the Act from its entry into force
- Art. 33(1) of the act of 23 January 2026
- 2 years
- minimum retention period for security documentation after it is withdrawn from use
- Art. 10(7) of the KSC Act
- 300%
- of salary: the maximum fine for the head of an entity for failing to fulfil the obligations under Art. 8; first fines from 3 April 2028
- Art. 73a(1)(2) and (4) of the KSC Act, Art. 35 of the act of 23 January 2026
How to write a business continuity plan step by step
The steps assume the organisation already has a preliminary risk analysis; we describe how to prepare one in our article on the risk matrix and risk register.
Step 1: define the scope and the services covered by the plan
Start with the services the organisation provides externally (in the KSC Act, the “service” of an essential or important entity), then add the internal processes without which those services stop: payroll, accounting, email, network access. Write down the boundaries: locations, systems, suppliers. Check: every service has a named owner.
Step 2: carry out a business impact analysis
The goal is an MTPD, RTO and RPO for each service. Ask the owner what will happen after 4 hours, 1 day, 3 days and a week of downtime. Assess the financial and legal impact (e.g. statutory deadlines), the impact on customers and on people's safety. List the dependencies: systems, data, people with unique knowledge, suppliers. The RTO and RPO values are approved by management, because this is a decision about what risk the organisation accepts. Check: the RTO of each service is shorter than its MTPD, and the RTO of the systems it depends on is not longer than the service's RTO.
Step 3: choose continuity and recovery strategies
For services, choose a fallback mode: manual work, another location, remote work, redirecting to a partner. For systems, choose a recovery method: backup with restore to new hardware, a standby environment, replication. Compare the backup frequency with the RPO. Under point 4.2.2 of Regulation 2024/2690, the backup plan covers, among other things, storing backups outside the system's network and away from the primary location, access control and retention periods. Check: a strategy exists for each service, and management has accepted its cost.
Step 4: write the plan using a fixed structure
We describe the structure in the next section. Write briefly and operationally: who, what, in what order, from which phone, so that a deputy who did not write the plan can understand it. Check: the plan is available outside the systems that may stop working (a paper version or an offline copy).
Step 5: test the plan
We describe the types of tests below. The first test can be simple, as long as it is documented.
Step 6: set a review cycle
Set a fixed review date (e.g. once a year) and the events that force an earlier review: a serious incident, a system change, a change of supplier, a reorganisation. Point 4.1.4 of Regulation 2024/2690 frames it the same way. Check: the document has a version number and a change history, which Art. 10(6)(3) of the KSC Act also requires.
What to include in the plan: document structure
Many people look for a ready-made business continuity plan template. A template helps as a table of contents. The content must follow from the BIA of the specific organisation. The structure below is based on the elements in points 4.1.2 and 4.3.2 of the Annex to Regulation 2024/2690, supplemented with practical elements.
| Chapter | What it contains | Source of the requirement |
|---|---|---|
| 1. Purpose, scope and audience | Services and locations covered by the plan, version, date of approval, who approved it | Reg. 2024/2690, point 4.1.2(a) |
| 2. Roles and responsibilities | Crisis team, incident lead, deputies, authority for financial decisions | point 4.1.2(b), point 4.3.2(a) |
| 3. Activation and deactivation conditions | Thresholds for invoking the plan (e.g. downtime longer than half the RTO), who declares and who stands it down | point 4.1.2(d) |
| 4. BIA results | List of services with MTPD, RTO, RPO and dependencies | point 4.1.3 |
| 5. Restore order | Priorities of services and systems, technical dependencies | point 4.1.2(e) |
| 6. Continuity and recovery procedures | Fallback modes for services, technical DRP procedures for systems, recovery objectives | point 4.1.2(f) |
| 7. Backups and resources | What, how often, where, who has access, how to restore; spare hardware, links, people | point 4.1.2(g), point 4.2 |
| 8. Crisis communication | Internal and external channels, prepared messages, a backup channel for when email is down | point 4.1.2(c), point 4.3.2(b) |
| 9. Contacts | Team, suppliers (contract numbers, emergency lines), authorities, insurer | point 4.1.2(c) |
| 10. Return to normal operations | Completion criteria, transfer of data from fallback mode, post-incident review | point 4.1.2(h) |
| 11. Tests and reviews | Test schedule, lessons from the last test, version history | point 4.1.4 |
Activation thresholds. Write down a measurable condition and the person who has the authority to declare activation without convening the board.
Crisis communication. Plan a channel that does not depend on the organisation's infrastructure: a phone list on paper, a messenger group on private devices, a backup email account. Reporting obligations towards the CSIRT are a separate process, which the plan should only point to, with a reference to the incident handling procedure.
Supplier contacts. In addition to the helpline number, record the contract number, support level and contractual response time. We write about supplier-side risk in our article on supply chain attacks (in Polish).
Return to normal operations. Data entered in manual mode must be transferred to the system, and after a cyberattack you need to make sure the restored environment is clean.
Ransomware as the baseline scenario
If you test only one scenario, choose ransomware. It tests almost the whole plan at once: many systems unavailable at the same time, possible loss of backups reachable from the network, the need to communicate without corporate email, and the decision on the point from which to restore data. We describe how such an attack unfolds and why backups are often a target in our article ransomware: how the attack works (in Polish).
How to test a business continuity plan
The plan is tested at three levels, from the cheapest to the most demanding.
| Type of test | What it involves | What it checks | Frequency (suggested) |
|---|---|---|---|
| Desk review | Owners read the plan and check that contacts, systems and procedures are up to date | Whether the document describes the organisation's current state | Quarterly or after every change |
| Tabletop exercise | The crisis team walks through a scenario around a table, e.g. “on Monday at 7:00 the servers are encrypted” | Roles, decisions, communication, activation thresholds | At least once a year |
| Restore test | Restoring a selected system from backup in a test environment, with timing | Whether the backup is complete and whether the RTO and RPO are achievable | Regularly, for every critical system |
The frequencies in the table are our suggestion. The regulations do not set intervals; they refer to testing (Art. 8(1)(2)(f) of the KSC Act) and to regular tests (point 4.2.6 of the Annex to Regulation 2024/2690, Art. 32(1)(d) GDPR). Choose the intervals based on the results of the BIA and the risk analysis.
The restore test has the greatest evidential value. Point 4.2.6 of Regulation 2024/2690 requires regular testing of backup recovery, documenting the results and taking corrective action. The test report should include: the date, the system, the backup source, the measured restore time, the point in time to which data was restored, problems and corrective actions. If the measured time is eight hours and the plan says two, you need to change either the strategy or the RTO.
The most common mistakes in continuity plans
A backup nobody has ever restored. Making a backup does not prove that a system can be restored from it. The backup may be incomplete, corrupted or dependent on a key or configuration that was lost along with the server. Annex No. 4 to the KSC Act explicitly requires testing the completeness of backups and the ability to restore data (point I.11).
An RTO set by IT without talking to the business. The plan then describes what IT can do today, and the organisation's needs remain unexamined. The RTO and RPO follow from the BIA and should be approved by management.
Backups on the same network as the production system. If an attacker has access to the network, they also have access to the backups. Regulation 2024/2690 (point 4.2.2(c)) and Annex No. 4 to the KSC Act (point I.10) require backups to be separated.
No evidence. Without test reports it is hard to show that the plan was tested, and the Act requires this. Business continuity plans are among the documents examined in the cybersecurity audit (in Polish) required by the KSC Act.
How to check your readiness in SelfAudyt
SelfAudyt is a self-assessment tool for compliance with the KSC Act, NIS2, the GDPR and ISO/IEC 27001:2022. It is not an external audit or a certificate. In the business continuity area it asks, among other things, whether in the last 6 months the organisation has restored a system from backup and checked how long it took. A gap goes into the risk register and the remediation plan with a deadline and a responsible person. The document templates include a business continuity plan template, and documents created from templates that are older than 6 months are added to a list for refreshing. The quick 8-question test gives an indicative picture, and before an audit or inspection the inspection preparation module is useful.
FAQ
Is a business continuity plan mandatory?
For essential and important entities, yes. Art. 8(1)(2)(f) of the KSC Act requires implementing, documenting, testing and maintaining business continuity plans, contingency plans and recovery plans. Important entities that are public entities instead apply Annex No. 4, which requires, among other things, testing the procedure for failures or incidents and testing the restoration of data from backups.
How does a BCP differ from a DRP?
A BCP describes how to keep the organisation's services and processes running during a disruption, including fallback modes and crisis communication. A DRP describes how to restore IT systems and data. The DRP is usually part of wider business continuity management, and in the KSC Act it corresponds to the recovery plan.
How often should a business continuity plan be tested?
The regulations do not set a specific frequency. The KSC Act requires the plans to be tested, and Regulation 2024/2690 refers to tests at planned intervals and after major incidents or significant changes. A sensible minimum is an annual tabletop exercise and regular, timed restore tests of critical systems from backup.
Is it enough to download a business continuity plan template?
A template organises the structure, but it does not replace the business impact analysis. The RTO and RPO values, the restore order, the contacts and the fallback procedures must follow from the situation of the specific organisation.
Disclaimer
This article is for information purposes only and reflects the law as at 24 October 2026. It is not legal advice. The scope of a specific organisation's obligations depends on its status under the KSC Act, its sector and any sector-specific regulations. A self-assessment in SelfAudyt does not replace a security audit, a legal opinion or certification. We give the definitions from ISO standards in our own words, based on publicly available ISO information, not on the full text of the standards.
Sources
- Act of 23 January 2026 amending the National Cybersecurity System Act and certain other acts (ustawa o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw, Dz.U. 2026 item 252) — Journal of Laws of the Republic of Poland, 2 March 2026 (Art. 8(1)(2)(f), Art. 8(3), Art. 8b, Art. 8c, Art. 10, Art. 67g, Art. 73a, Annex No. 4; Art. 33 and 35 of the amending act)
- Dz.U. 2026 item 252 in the Internet System of Legal Acts (ISAP) — Sejm of the Republic of Poland
- Directive (EU) 2022/2555 of the European Parliament and of the Council (NIS2), Art. 21 — EUR-Lex
- Commission Implementing Regulation (EU) 2024/2690, Annex point 4 — EUR-Lex
- Regulation (EU) 2016/679 (GDPR), Art. 32 — EUR-Lex
- Regulation (EU) 2022/2554 (DORA), Art. 11 — EUR-Lex
- ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements — ISO
- ISO 22300:2025 Security and resilience — Vocabulary — ISO
- ISO/IEC 27031:2025 Cybersecurity — Information and communication technology readiness for business continuity — ISO
Read next
Compliance
GDPR audit step by step: what to check before an auditor or a UODO inspection
GDPR audit step by step: 12 areas with legal provisions, evidence and a remediation plan, plus what Polish law says about how a UODO inspection works.
15 min read
Compliance
Record of processing activities (RoPA): how to build and maintain it in 2026
Record of processing activities step by step: Art. 30 GDPR elements, controller vs processor records, under-250 exemption, a sample entry and typical errors.
15 min read
Compliance
5×5 risk matrix and risk register: how to assess information security risk
A 5×5 risk matrix for information security: likelihood and impact scales, acceptance thresholds, a sample risk register and KSC, NIS2 and GDPR requirements.
16 min read