control
backup and recovery
Copies of your data and systems that you can bring back, in a time you chose. NIS2 names backups and disaster recovery. DORA spells out policy, testing and a separate place to restore.
- what it protects
- a way back to working systems and data after a failure, a deletion or ransomware
- who owns it
- head of IT, with the business owners
- start with
- the systems the business cannot stop, then one restore test
what it is
Backup and recovery means keeping copies of your data and systems, and being able to bring them back within a time you chose. A backup that has never been restored is a guess. The proof is a restore.
NIS2 lists backup management and disaster recovery among the minimum measures. DORA goes further for financial entities: a written policy with scope and frequency, periodic tests, and restoration on systems kept apart from the source. GDPR asks you to restore access to personal data in good time after an incident.
Start from the business question. Which systems matter most, how long can each be down, and how much data can you lose? Those answers set how often you copy and how fast you must restore. Then keep at least one copy where ransomware and a stolen administrator login cannot reach it, and test a restore on a schedule.
basis NIS2 Art. 21(2)(c); DORA Art. 12(1), 12(2); GDPR Art. 32(1)(c). The restore goals and the schedule are practice.
how copies travel away from what they protect
- 1live systemthe data and the systems people use today
- 2first copyclose by, quick to restore from
- 3second copyin another place, under other accounts
- 4locked copycannot be changed or deleted by normal administrators
what each extra copy survives
- a failed diskthe first copy is enough
- a deleted folderolder versions bring it back
- ransomwarethe second and locked copies sit out of its reach
- a stolen administrator loginonly the locked copy stays safe
basis working practice. No legal text sets this.
an example
Picture a company of a few hundred people with a nightly backup job that has reported success for years.
The job copies the main servers and nothing else. The cloud tools are missing, the same administrator account runs production and the backups, and nobody has restored anything. When ransomware arrives through that account, the copies are encrypted along with the live data.
The business agreed how long each system may be down and how much data it can lose. The asset list is checked against the backup scope, one copy sits where normal administrator accounts cannot reach it, and one real system is restored to a clean place every year with the time written down.
An illustration. It is not a real case.
what it has to do for each rule
| rule | where | what the text asks | what the control has to do |
|---|---|---|---|
| NIS2 | NIS2 Art. 21(2)(c) | Business continuity, such as backup management and disaster recovery, and crisis management. | Decide what is copied, how often and how long a restore may take, then restore one real system to show it works. |
| DORA | DORA Art. 12(1) | Written backup policies and procedures: the scope of the data, the minimum frequency based on criticality or confidentiality, and restoration and recovery procedures. | Write the policy with a scope and a frequency for each system, and a restore procedure that someone other than its author can follow. |
| DORA | DORA Art. 12(2) and 12(3) | Backup systems that can be activated without harming security or data, periodic testing, and restoration on systems physically and logically separate from the source. | Test restores on a schedule. Keep a restore environment that does not share accounts or storage with production. |
| GDPR | GDPR Art. 32(1)(c) | The ability to restore availability and access to personal data in a timely manner after a physical or technical incident. | Include the systems that hold personal data in the restore tests and write down how long the restore took. |
basis NIS2 Art. 21(2)(c); DORA Art. 12(1), 12(2), 12(3); GDPR Art. 32(1)(c). What the control has to do is practice.
what to look for when you choose
- Does it cover every system you listed, including cloud services and software-as-a-service tools, or only the servers in your own rooms?
- Can one copy be kept where your normal administrator accounts cannot change or delete it, and can you show that?
- Are the copies encrypted, and who holds the keys? If the keys sit only in the system you are restoring, the copy is no use.
- Does it show you a restore test result, not only a report that the job ran?
- How long does a full restore of your largest system take, measured on your own data and your own network?
- Can you restore to a clean environment, or only on top of the system that failed?
- Does it keep older versions long enough to go back before the point where files were damaged or encrypted?
- Who is told when a job fails, and who checks that someone read the alert?
basis working practice. No legal text sets this.
three levels, from first step to strong
Each level adds something visible. Stop where the risk you accepted allows.
- start
Agree restore goals for your most important systems, copy them and restore one to a clean environment with a clock running.
- solid
Cover every system on the asset list, keep one copy out of reach of administrator accounts and run restore tests on a schedule.
- strong
Restore a full critical system from the locked copy, rehearse it with the people who would do it in a real incident and fix every gap you find.
basis working practice. No legal text sets this.
where it goes wrong
backups never restored
The job reports success for years and nobody has tried the other direction. A restore test is the only proof the copy works.
one login deletes everything
If the account that runs production also reaches the backups, one stolen password reaches both. Keep one copy out of that account's reach.
the missing systems
Cloud services and software-as-a-service tools often fall outside the backup job because nobody on the IT team set them up. Check the asset list against the backup scope.
restore goals nobody agreed
How long a system may be down and how much data you can lose is a business decision. If IT guesses, the first real incident sets the numbers.
basis working practice. No legal text sets this.
the proof it leaves
| what you can show | who owns it | refresh |
|---|---|---|
| backup policy: scope, frequency, retention | head of IT | yearly |
| restore test record: date, system, time taken, what was missing | head of IT | at least yearly |
| list of systems with their agreed restore goals | head of IT, with the business owners | yearly |
| backup job logs and the record of failures that were followed up | head of IT | quarterly |
basis DORA Art. 12(1) and 12(2) for the policy and the periodic tests. The rhythms are your choice.
check it yourself
- Directive (EU) 2022/2555 (NIS2) (EUR-Lex)
- Regulation (EU) 2022/2554 (DORA) (EUR-Lex)
- Regulation (EU) 2016/679 (GDPR) (EUR-Lex)
your next step
Pick one system and restore it to a clean environment this month, with a clock running.