The server is back. The customer still cannot pay.
Imagine the end of a disaster-recovery rehearsal. The backup has restored successfully. The application is running. Monitoring shows green. The technical team records a pass.
Then someone tries the thing the service exists to do: complete a payment. The customer can open the page, but the transaction will not go through. An employee trying to investigate cannot sign in to the recovered system.
The technical results were real. So is the unfinished business. What did “passed” actually mean?
A green dashboard is only the beginning
Recovery happens in stages. First, the infrastructure runs. Then the data is available. The application starts. Its connections to other systems work. Finally, a customer or employee can complete an essential task.
Each stage is worth testing. Each answers a different question.
An application health check may show that software responds while its payment connection remains unavailable. A successful administrator login may say little about a frontline employee’s access. A restored database may contain records that are missing, duplicated or too old for the work at hand.
Choose the business service before choosing the test steps. “Restore the database” is a technical task. “Enable staff to receive and fulfil orders using accurate records” is an outcome the business can recognise. The exercise needs to follow that outcome all the way to the person relying on it.
Decide what a pass would look like
Before the rehearsal, business owners and technical teams should agree how much disruption and data loss the service can tolerate.
The Recovery Time Objective (RTO) is how long the organisation has agreed the service can remain unavailable. The Recovery Point Objective (RPO) is how much recent data it has agreed it could lose during recovery. These are decisions for the particular organisation, workload and risk; there is no single target that suits every service.
Define the clock, too. When does it start? What must work before it stops? If the server restarts at 10:00 but customers cannot complete a transaction until 10:40, the report should not quietly use 10:00 as the moment the business service returned.
The same care applies to data. Identify the most recent valid records available after restoration and check whether transactions were lost, repeated or left incomplete. A service can return quickly and still need work before people can trust what it shows.
Try the journey a user would take
Pick a realistic disruption and a few essential tasks. For an order service, have a test customer place an order. Can an employee see it? Does stock change correctly? Does the payment record match? Does the confirmation arrive?
Now follow what those steps depend on. Can users authenticate? Do network routes, DNS, firewalls and security controls work in the recovery environment? Are cloud services, connectivity providers and other external partners ready to play their part?
The people behind the plan need a rehearsal as well. Who declares that recovery is needed? Who authorises the move to the alternate environment? Who contacts a supplier, updates employees and decides the service is safe to use? If the plan relies on a manual workaround, can staff carry it out and reconcile the work afterward?
Not every exercise can safely reproduce every production condition. A simulation or a test that excludes a supplier can still teach the team something valuable. State those limits plainly. They define what the result proves.
Give the business evidence it can use
A useful test report should answer four questions:
- What did we set out to prove? Name the service, disruption scenario, essential customer and employee tasks, success criteria and any exclusions.
- What happened? Compare the agreed RTO and RPO with the actual time until essential work resumed and the most recent valid data. Include the data-integrity checks and user results.
- What helped or hindered recovery? Record the identity, network, security, application and external-provider dependencies, along with decisions, escalations, communications, failures and manual workarounds.
- What happens next? Assign each corrective action an owner and deadline. Where a material step failed, plan a retest after the fix.
Timestamps, test transactions and confirmation from business users give those answers substance. “Passed with limitations” may be the right conclusion. It tells a decision-maker more than an unqualified pass when a critical connection was outside the exercise.
Know which provider is responsible for which step
When colocation is part of a recovery design, the facility is one part of a longer service chain. The customer, connectivity providers, cloud or application suppliers and facility operator may each have different responsibilities. Agree who supplies what, who joins a test and who responds when a dependency fails.
Onix operates a data-centre facility in Accra, Ghana. Onix is a carrier-neutral colocation provider offering colocation and related infrastructure services, with access to multiple networks and internet exchanges. Organisations considering those options should bring their service map and recovery objectives to the discussion. The map helps everyone ask precise questions about infrastructure, connections and responsibility boundaries. Using a facility alone does not prove that a customer’s applications or business processes will recover.
Ghana’s Cyber Security Authority has called for closer collaboration across the digital finance ecosystem during National Cyber Security Awareness Month 2026. For regulated financial institutions, the Bank of Ghana’s Cyber and Information Security Directive 2026 addresses recovery objectives and documented continuity, disaster-recovery and failover testing. Regulated organisations remain responsible for confirming their obligations with the Bank of Ghana and their professional advisers. This article is general operational guidance, not legal or regulatory advice.
At the end of the next exercise, ask the person who owns the business service to complete an essential task. Check the time. Check the data. Record what did not work.
That is a result worth calling a pass.
