If Commission Implementing Regulation (EU) 2024/2690 applies to your organisation, regularly testing backup recovery and documenting the results are explicit requirements. Other NIS2 entities must implement effective backup management, business continuity and disaster-recovery measures. For them, a documented restore test is one of the strongest ways to demonstrate that those measures actually work.
For a WordPress site that is awkward. The obvious way to test a restore is to restore over the live site, which nobody wants to do. A staging copy resolves it: restore the backup into a separate environment, confirm the site actually comes back, and write down what you found.
NIS2 WordPress Recovery Backup Testing Technical Guide
Key takeaway
A backup file alone is not proof that a WordPress site can be recovered. A meaningful recovery test restores a real retained backup, verifies the recovered website and documents whether the recovery objectives were achieved.
The rest of this article covers who NIS2 applies to, where the testing duty comes from, and what a defensible restore test looks like.
Does NIS2 apply to you?
Most WordPress site owners are outside scope. It is worth being precise, because a good deal of marketing implies otherwise.
NIS2 (Directive (EU) 2022/2555) generally covers entities in the sectors listed in Annexes I and II that qualify as medium-sized enterprises or exceed the medium-enterprise thresholds. The calculation follows the enterprise-size definitions in Commission Recommendation 2003/361/EC, and can consider employee numbers, annual turnover, annual balance-sheet total and, in some circumstances, figures from partner or linked enterprises.
Do not use turnover alone
NIS2 scope cannot reliably be determined from annual turnover alone. Employee numbers, balance-sheet totals, linked enterprises, sector classification, special designations and national implementation may all affect the assessment.
As a practical starting point, organisations with at least 50 employees should examine their position carefully. Smaller organisations may still fall within scope because of financial thresholds, corporate-group relationships, special designations or size-independent exceptions. That is a rule of thumb for deciding whether to look properly. It is not a complete legal test.
The classification into essential and important entities also depends on sector and size, and the treatment of medium-sized and large organisations differs. What follows is a simplified overview: the binding detail is in your member state’s national implementation, which varies.
- Sector. Eighteen sectors, including energy, transport, health, banking, water, public administration, digital infrastructure and ICT service management.
- Size-independent exceptions. Some entities are in scope regardless of size, including DNS service providers, TLD name registries and trust service providers.
Where agencies and hosts actually land
The category that most often catches web professionals is ICT service management, which covers managed service providers and managed security service providers. It targets managed services rather than generic software-as-a-service.
A managed WordPress host, or an agency that actively manages client applications or infrastructure, may qualify as a managed service provider if it also meets the applicable size or special-scope criteria. A small design or development agency will commonly remain outside direct scope, but size calculations, corporate-group relationships, national implementation and the actual services supplied must still be checked.
How NIS2 can reach smaller suppliers indirectly
Article 21(2)(d) requires in-scope entities to manage supply chain security, including the security of their direct suppliers. This is how NIS2 reaches small suppliers. You may be well below the thresholds and still be asked to evidence your backup and recovery practice, because your client is in scope and you are one of their suppliers. In practice it arrives through:
- customer contracts;
- supplier questionnaires;
- procurement requirements;
- cyber-insurance conditions;
- supply-chain risk management.
If that is why you are reading this, the rest of the article is the part you need.
The legal basis for backup and recovery testing
Legal distinction
- Regulation (EU) 2024/2690 contains explicit recovery-testing and documentation requirements for the entities it covers.
- Other NIS2 entities still have backup, business-continuity, disaster-recovery and effectiveness obligations.
- The exact national implementation and your organisational scope must be checked.
Article 21(2)(c) of NIS2 lists, among the risk-management measures entities must take:
business continuity, such as backup management and disaster recovery, and crisis management
That is the general obligation. It says backup management, not backups. Article 21(1) also requires the measures to be appropriate and proportionate, and Article 21(2)(f) requires policies to assess whether they are effective. An untested recovery process is difficult to argue as effective.
Where the explicit testing duty comes from
For a defined set of digital entities, the Commission has set out technical requirements in detail. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 applies to DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, online search engines and social networking platforms, and trust service providers.
Two obligations from its Annex are the ones most often missed:
The relevant entities shall carry out regular testing of the recovery of backup copies and redundancies.
The relevant entities shall perform regular integrity checks on the backup copies.
For those entities, restore testing is explicit rather than inferred.
If your organisation is not in that list, the implementing regulation does not bind you directly, and you should not assume the same detailed clause applies to you word for word. Article 21 still applies. The regulation remains the clearest published statement of what the Commission considers adequate for comparable services, which makes it a sensible reference point when deciding how to evidence your own measures.
Why WordPress makes this awkward
Where recovery testing is explicitly required, or used to demonstrate the effectiveness of backup and disaster-recovery measures, the objective is to show that a real backup can actually be restored. Restoring into the live site to prove it risks the very thing you are protecting. If the backup is bad, you have replaced a working site with a broken one. So the test that would produce the evidence is the test nobody wants to run.
The substitutes people reach for are weaker than they look:
- Checking the backup file exists. Proves storage, not recoverability. A truncated database dump looks perfectly normal on disk.
- Checking the archive opens. Archive readability is not the same as a successful application restore. A readable ZIP tells you nothing about whether WordPress will boot from it.
- Restoring once, at setup, some years ago. “Regular” is doing a lot of work in that sentence.
- Restoring a backup created moments earlier for the test. This tests the tool, not your retention. Use a real retained backup, ideally one from your offsite copies.
What is missing is somewhere safe to restore into.
What a defensible restore test looks like
A restore test that provides useful and defensible evidence for supplier questionnaires, internal reviews and recovery audits has five parts.
- Restore into an isolated environment. Not production. A staging copy on the same server, or a local environment, both work. The point is that a failed restore does not overwrite the production website.
- Restore a real backup, not a fresh copy. Take an actual backup from your actual retention, including one from storage that is geographically separate from the live site if you keep offsite copies.
- Verify the site works, not just that files landed. A restore that produces a white screen has still failed. Work through the checklist below.
- Record the outcome, including what did not work.
- Repeat at intervals you can justify. Base the interval on risk assessment, business impact analysis, recovery objectives, rate of change and contractual requirements, and document why you chose it.
A same-server staging restore can still consume disk space, database capacity, CPU and memory. If the backup may contain malware, or if the test scenario includes compromise or loss of the production host, restore it on separate infrastructure instead.
No universal NIS2 testing interval
NIS2 does not prescribe one universal monthly or quarterly restore-test schedule. Select and document an interval based on risk, business impact, recovery objectives, rate of change and contractual requirements. Repeat relevant tests after significant changes or incidents.
Many organisations choose quarterly testing as an operational starting point, but that is a risk-management decision rather than a fixed NIS2 requirement. Test again after significant infrastructure changes, migrations, major application upgrades or incidents that affect the recovery process.
Verifying the restored site
Work through the restored site as a user would. The following covers the areas that most often break in a restore:
- front-end loading;
- wp-admin access;
- media files;
- internal links;
- critical pages;
- contact forms;
- user roles and permissions;
- plugin and theme activation;
- WP-Cron or scheduled tasks;
- WooCommerce products, orders and a safe test checkout where applicable;
- search;
- multilingual functionality where applicable;
- important integrations and webhooks;
- safe email behaviour;
- absence of production-side effects.
Prevent real-world side effects
Disable or safely redirect outgoing email, payments, customer notifications, webhooks and other external actions before testing them in a staging or recovery environment. Do this before running the test, not after.
Recovery objectives: targets versus measurements
Two pairs of numbers matter, and they are easy to confuse. Two are decisions you make in advance; two are results you measure during the test.
RTO
The maximum acceptable target recovery duration.
Actual recovery time
The duration measured during the restore test.
RPO
The maximum acceptable amount of data loss, expressed as time.
Actual backup age
The age of the data restored during the test.
Record both the target and the measurement in each pair. The test result shows whether the recovery objective was achieved. Comparing the RPO target with the age and completeness of the restored backup provides practical evidence of whether the selected recovery point would meet the objective. Backup age is useful evidence, but the backup must also be complete and application-consistent.
Restore-test documentation fields
These are the fields that make a restore-test record useful and defensible evidence for supplier questionnaires, internal reviews and recovery audits.
| Field | Purpose |
|---|---|
| Test date | When the test was performed |
| Backup ID or filename | Which backup was tested |
| Backup creation date | When the backup was created |
| Backup location | Where the tested backup was stored |
| Test environment | Same server, local computer, separate server or other |
| Scope tested | Which website functions were verified |
| Target RTO | Maximum acceptable recovery duration |
| Actual recovery time | Duration measured during the test |
| Target RPO | Maximum acceptable data-loss period |
| Actual backup age | Age of the restored data |
| Result | Pass, partial pass or fail |
| Evidence | Screenshots, logs, reports or checklist |
| Corrective action | Required remediation |
| Owner and due date | Person responsible and completion deadline |
A worked entry might read: 2026-07-14, backup wpstg_20260713_nightly.wpstg created 2026-07-13, stored in offsite object storage, restored to a protected staging site, scope covered front end, admin, media and checkout, target RTO 4 hours against an actual recovery time of 11 minutes, target RPO 24 hours against an actual backup age of 19 hours, result pass, evidence screenshots and restore log.
Corrective actions
A test is not finished when the restore completes. Document failures, degraded functionality, missing files, incorrect configuration, unmet recovery objectives and manual intervention required during the restore. Assign each corrective action to an owner, set a due date and repeat the affected test after remediation.
A failed test is still useful
A failed or partially successful restore test can still provide valuable evidence. Document what failed, assign corrective actions, repeat the affected test and retain the updated result. A file of nothing but passes invites the question of whether anything was really tested.
Three levels of WordPress recovery testing with WP STAGING
The three levels answer different recovery questions. The correct level depends on the scenario you need to validate, and organisations do not necessarily need to run all three at the same frequency. Match the tests to the identified risks and recovery objectives.
Level 1
Functional restore test
- restore a real retained backup;
- verify files and the database;
- test important WordPress functionality;
- avoid overwriting production.
You can restore into a staging environment from a retained backup.
Limitation: when staging is hosted on the same infrastructure, this does not test complete loss of the server or hosting account.
Level 2
Off-server restore test
- restore a downloaded
.wpstgbackup on another computer; - verify off-server recoverability;
- inspect the recovered site in a controlled local environment;
- avoid depending on the active production WordPress installation during the restore;
- automate the same local restore repeatedly with WP Staging CLI.
WP Staging Desktop is free and restores a downloaded backup locally. WP Staging CLI covers the same ground non-interactively, as a repeatable Docker-based local restore you can script and run on a schedule.
Limitation: a local restore does not automatically prove that the complete production hosting environment can be rebuilt.
Level 3
Fresh-server recovery test
- restore onto new or separate infrastructure;
- test a more complete disaster-recovery scenario;
- identify undocumented server, PHP, database and configuration dependencies.
WP Staging Restore covers recovery onto separate infrastructure.
Limitation: the test environment must still represent the intended recovery scenario closely enough to produce meaningful evidence.
The general workflow is documented under back up and restore WordPress, and you can configure scheduled backups so the retained copies a test draws on are created consistently.
What each test level does and does not prove
Same-server and off-server tests answer different questions. Neither replaces the other, and routine testing does not have to happen on fresh infrastructure.
Same-server staging test
- functional recovery;
- database and file validation;
- WordPress application checks;
- frequent operational testing.
- recovery after total host loss;
- availability after hosting-account compromise;
- independence from the same storage or network;
- access when production credentials are unavailable.
Off-server or fresh-server test
- infrastructure-loss scenarios;
- host-independent recovery;
- access and credential testing;
- validating external backup availability;
- identifying undocumented environment dependencies.
Note that where a backup was downloaded from the production server, that download still depended on the server being reachable. Keeping an offsite copy you can retrieve independently is what closes the gap.
Backup storage and separation
WP Staging Pro can store backups with remote providers such as Google Drive, Amazon S3, Dropbox and SFTP. Properly configured, these services can support an off-network and off-site backup strategy. The organisation must still consider storage location, access separation, retention, encryption, credentials and whether the backup would remain available after compromise of the production environment.
Selecting a remote storage provider does not by itself demonstrate adequate geographic or security separation. The questions that decide it are:
- whether the storage uses separate credentials from the production site;
- whether access is restricted to the people who need it;
- whether retention is protected against alteration;
- whether copies are protected from deletion or ransomware, including by an attacker who has taken the production host;
- whether the backup remains available when the production hosting account is inaccessible;
- whether the geographic location is appropriate for your data and your obligations.
The available destinations and their configuration are covered in the backup and restore documentation.
What a defensible WordPress recovery test should show
- A real retained backup was selected.
- The backup was restored into an appropriate test environment.
- Important WordPress functions were verified.
- RTO, RPO and actual results were documented.
- Failures were assigned, corrected and retested.
Test your WordPress recovery process
Use WP STAGING to restore a real backup into a protected staging environment, or restore it off-server with WP Staging Desktop. For fresh-server recovery testing, use WP Staging Restore.
Document the result, compare the measured recovery time and recovered data age with your recovery objectives, and correct any failures before a real incident occurs.
What WP STAGING does not do
It does not make you NIS2 compliant, and a successful restore does not by itself demonstrate compliance. It does not cover management-body governance and accountability under Article 20, incident reporting under Article 23, supply-chain assessment, access control, cryptography, training or the remainder of Article 21.
What it gives you is a safe place to run the restore test and something concrete to record. It supports a narrow part of the broader NIS2 cybersecurity risk-management framework. Treat anyone selling you the whole directive in a plugin with appropriate scepticism.
Frequently asked
Do I need to test every backup?
No. Regular testing of the recovery of backup copies is an explicit requirement for the entities covered by Commission Implementing Regulation (EU) 2024/2690, and even there the duty is regular testing of recovery, not testing of every copy. Other NIS2 entities should select and document a risk-based testing approach instead: choose an interval you can justify from your risk assessment, test a real backup from your retention, and document the result.
Is a staging site enough of an isolated environment?
For testing that a backup restores and the site functions, yes, provided the staging copy is properly separated from production. If your recovery plan depends on rebuilding on different infrastructure, test that too, because a same-server staging restore does not exercise it. Restoring a downloaded backup locally is the cheapest way to cover the off-server case, and a fresh-server restore covers the rest.
We are a small agency. Do we need any of this?
Often not as a matter of direct statutory scope. But if a client of yours is in scope, expect the question to arrive through their supply chain obligations. A restore-test log is considerably cheaper than losing the account.
Does a managed host’s backup cover us?
It may cover backup creation and storage, depending on what the hosting service includes. It does not automatically provide evidence that a complete application recovery has been tested, control over the testing schedule or proof that your recovery objectives can be met. Ask your host what they can produce in writing, and what their own recovery objectives are.
How long should a restore take?
That is your decision to make and then verify, not a number anyone can hand you. Set a recovery time objective from what the business can tolerate, then measure the actual recovery time in a test and see whether the two agree.
Sources
- Directive (EU) 2022/2555 (NIS2)
- Commission Implementing Regulation (EU) 2024/2690
- Commission Recommendation 2003/361/EC concerning the definition of micro, small and medium-sized enterprises
- ENISA, Technical implementation guidance on cybersecurity risk-management measures
This article is general information, not legal advice. NIS2 is implemented through national law, and the detail varies between member states. Whether NIS2 applies to your organisation, and what it requires of you, depends on your sector, your size calculation, your corporate group and the national implementation that applies to you. Evaluate the applicable national implementation and obtain qualified legal or compliance advice where necessary.