What really happens when your systems have to restart
We restore your essential systems in an environment kept separate from production, measure how long it takes before they’re usable again, and document what blocks recovery — within a scope we define with you.
Your backups show green. Has anyone proved you can restart?
A backup console and its logs show that copies exist. They don’t prove your systems will come back. Only a restore followed by a verified restart shows that — and that’s what CERVOX Jour Zéro does.
- Network: connections and firewalls.
- Identity: directory and access.
- Databases restored and consistent.
- Applications started.
- Business check: the system is usable.
What the test tells you
- What can actually be restored.Which copies are usable, and which are incomplete or out of reach.
- Under what conditions.The access, people, licences and providers you need to get back up.
- How long it takes, and how much data you’d lose.The time measured until a system is usable, confirmed by a simple business check (opening a file, issuing an invoice), and the gap between the last usable copy and the simulated incident.
- What gets in the way.Dependencies, restart order, missing access: what works, what blocks, what remains uncertain.
- What to do first.Recommendations, each linked to a gap the test observed.
How the test works, in four stages
- Scope: essential systems, dependencies, copies to use and recovery objectives; test plan approved in writing.
- Restore: the systems in scope are restored in an environment kept separate from production.
- Measure: time until each system is usable, estimated data loss, comparison with your objectives.
- Report: gaps ranked by impact, priority actions and the report.
The nine steps in detail
| Step | What we do | What we ask you |
|---|---|---|
| 1. Essential systems | List the systems you can’t work without | Which activities stop if this system goes down? |
| 2. Dependencies | Map network, identity, directory, databases, applications, licences, providers | What has to run first? Who holds the access? |
| 3. Backups involved | Identify the copies to use, where they are, how they’re protected, how often they run | Where are the copies? Which are off-site and protected? |
| 4. Separate restore | Restore outside production | Is the test plan approved in writing? |
| 5. Restart time | Time the restart until the system is usable | Which action proves the system is usable? |
| 6. Data lost | Estimate the gap with the last usable copy | What data loss would be unacceptable? |
| 7. Comparison with objectives | Compare the measurements with your objectives | Are these objectives still right? |
| 8. Gaps and uncertainties | Sort what works, what blocks and what remains uncertain | Which constraints do you already know about? |
| 9. Report | Hand over the results and the action plan | Who needs which level of detail? |
What you receive
- A one-page summary for leadership.
- A dated, signed technical report.
- The tested and untested scope, stated explicitly.
- The results actually measured: restart time and data lost, per system.
- The gaps, ranked by their impact on your operations.
- Prioritised recommendations, each linked to an observed gap.
- The conditions and limits of the test: backup versions, environment, assumptions.
- A record of the deletion of the temporary environment, where the method calls for it.
Who does what
| Topic | You | CERVOX |
|---|---|---|
| Priority activities | Decide which are essential | Asks the questions, structures the answers |
| Acceptable downtime and data loss | Set and approve your objectives in writing | Explains, offers options, shows the consequences |
| Actual capability | Authorise the scope and provide access | Measures it through a test in a separate environment |
| Gaps | Review and decide | Documents them, with evidence and likely causes |
| Fixes | Choose who fixes | Recommends; carries out fixes only if you choose so |
| Residual risk | Formally accept it, or decide to reduce it | Makes it visible |
How we operate
- A defined scope, in writing, before the test.
- A test plan approved in writing; nothing is done on your production.
- Named, temporary access, limited to the agreed scope, which you create and remove.
- Remote delivery when the environment and access allow it; where and how the restore happens is agreed during scoping, depending on your environment.
- People available on your side to validate the business checks.
Two formats
Essential
Microsoft 365 or Google Workspace, plus up to three essential systems.
Complete
All your essential systems and their restart order.
The exact scope is always defined with you.
After the test
Priority actions
Each recommendation states the observed gap, the risk, the success criterion and how it will be checked. You choose who fixes it: your team, your provider or CERVOX. If an objective can’t be met, you choose between investing, organising differently, planning a fallback mode, or accepting the risk in writing.
A retest
No objective is declared met until it has been tested again.
Periodic tests
Your systems change, and a result is only valid as of its test date. How often to retest depends on your changes and your risks. Between tests, Copilot PRA can help spot the gaps that could block recovery.
Copilot PRALimits of the test
The test covers the tested scope, and only that. Its results are valid as of the test date. It is not a penetration test, not a certification and not a guarantee of recovery.
FAQ
Do you need our passwords?
We need named, temporary access, limited to the agreed scope, which you create and remove. We never ask for credentials through the website form.
Where is our data during the test?
In the restore environment agreed during scoping, kept separate from production; its location depends on your environment. Where the method calls for it, the deletion of the temporary environment is recorded in a written deletion record.
What if the test fails?
You learn what would have blocked recovery before an incident does. The report documents it and sets out the priority actions. Nothing is fixed without your decision.
How long does a test take?
It depends on the number of systems and their dependencies. The duration is stated in the written proposal, after scoping.
Can our IT provider take part?
Yes, and it often helps: they know your environment and can carry out the fixes you assign to them.
Can we test only Microsoft 365 or Google Workspace?
Yes, these are part of the Essential format.
Ready to find out what restarts?
Tell us what you want to cover and why now. We’ll get back to you to define the test scope.