A successful technical test is valuable only when the claim made from it matches what was demonstrated. In 2019 we restored a database and I described the recovery test as successful. The database result was genuine. The insurance service depended on more than that component, however, and my statement did not preserve the distinction. Management heard that the work could resume. What we had actually shown was that one important part of the system had returned under the conditions of the exercise.
Colleagues then attempted 240 invented representative tasks. One hundred and ninety-two completed; forty-eight could not retrieve attachments held in a separate document store. The records referred to material the restored component did not itself contain. We had not demonstrated the complete path the colleague needed. This was a rehearsal, not evidence that customer information had been lost in production. Its value was that it exposed the gap before we relied on the stronger claim in a real interruption.
I had approved the earlier statement, so the correction began with withdrawing that service-readiness description. It would have been easy to call the missing documents a small extension to an otherwise successful test. That would still have understated their significance to the tasks that could not be completed. The relevant question was not how large the omitted component looked in a technology inventory. It was whether the colleague could perform the work that our restoration account was meant to support.
A real result with an unjustified meaning
There is a difference between a false result and a result given too much meaning. We did not need to deny that the database had been restored. We needed to name that outcome accurately and avoid letting it stand for a larger service. This distinction matters because teams can become defensive when a valid technical achievement is dismissed as worthless. The achievement was useful; it was not sufficient. A precise account can recognise both without making the conversation about protecting a project label.
Operating colleagues helped define the complete tasks, while qualified technology owners examined the supporting dependencies. The broader exercise included the document store, identity, permissions and network conditions needed to reach the material. That did not create a universal recovery checklist for every insurance service. It described the scope our particular tasks required. Another application may depend on different components or authorised work, so the method begins with the service and follows its conditions rather than borrowing a list because it looks comprehensive.
We funded ₹1.4 crore of change and retained ₹18 lakh annual exercise and support expense separately. The recurring amount mattered because the service would continue to change. A recovery arrangement demonstrated once could become incomplete as documents, access requirements or integrations evolved. Treating the response as a one-time repair would have recreated the same confidence problem later. The expense was part of maintaining evidence, not a saving derived from having avoided a hypothetical incident whose cost we had never measured.
Follow the task into its dependencies
The business task provides a useful way to organise the discussion because it connects technical states with something a colleague can attempt. Can the person reach the authorised record, obtain the supporting material and complete the intended action under the exercise conditions? The answer should be observed, not inferred from a collection of successful component messages. At the same time, the task needs to be representative enough to justify its place in the test. A convenient demonstration can be too simple to reveal the dependencies that matter.
Our exercise used invented material. That allowed colleagues to examine the workflow without turning the rehearsal into a disclosure of policyholder records. It did not establish that the sample represented every case the insurer might encounter. We needed to preserve that limit rather than report the exercise as proof of universal recoverability. The appropriate insurance professionals also retained the meaning of their decisions. A system that can retrieve a document does not thereby establish that a claim is payable or a contract has a particular effect.
The technical team needed to own the recovery arrangements, but operations needed to say whether the work was usable. Neither perspective could replace the other. A technical owner could explain which dependency was restored and under what condition. A service colleague could show that a task still failed at a point not reflected in the component account. The CIO's responsibility was to connect those observations and resource the response, rather than choose the more reassuring perspective when the two did not yet agree.
Report the unfinished work without changing the denominator
Retesting the same 240 tasks produced 231 passes and nine still requiring an assisted route while repair continued. The same task set made the stated result understandable, but it did not prove every cause of improvement or every future service condition. The nine remained visible. Assistance could allow work to proceed differently, yet it was not the same as the tested path passing. Removing those tasks from the denominator would have changed the question in order to recover a perfect completion figure.
An assisted route also needs an operating account. Who provides it, what can it support and what work remains to be repaired? Without that explanation, the word assisted can become a polite way to leave the problem with a colleague. We retained continuing support expense and unfinished scope rather than present the remaining cases as inconsequential. The purpose was to give management a practical basis for deciding how the service could be used, with the limitation and its cost still attached.
For a board, the central enquiry is what a readiness statement actually demonstrates. Directors need not inspect every recovery command. They can ask which business tasks were exercised, which dependencies were excluded, how unresolved work is handled and whether the result is being represented beyond its scope. A component can be restored quickly while a critical task remains unavailable. The board's decision should be informed by the task that matters to the enterprise, not only the easiest technical success to summarise.
The experience changed the language I use with management. I want to say what returned, what colleagues could do and what still needed another route. Those statements may be less elegant than a single successful-recovery label, but they are more useful. The database result was not the problem; the extra meaning I gave it was. By following the work into its dependencies and retaining the nine unfinished tasks, we produced a more credible account of readiness and a clearer responsibility for the evidence still needed.