A recovered database can leave the service without its context

The first sign of recovery is often visible and reassuring. A login works, an application opens and familiar records appear. After an interruption, those signs matter. They can also make it easy to stop asking questions too soon. A service may depend on supporting material that is less visible than the main record, or on a relationship between records that a basic technical check does not examine. Recovery needs to be defined around the work that must resume, not only the software that must start.

Our exercise at Fervali Hearing Services covered seven datasets. The application opened and the core checks completed, but two datasets had missing attachment references. Service owners could not use that result as the complete recovery they expected. The finding did not mean every aspect of the exercise had failed. It meant the success claim needed to remain open until the missing context was addressed and the relevant checks were repeated.

The technical team initially proposed closing the infrastructure portion and handling the references as ordinary support work. That would have recognised work already completed, and I understood the wish to avoid describing a useful technical result as a total failure. I disagreed with closing the overall recovery objective. We recorded the completed technical elements while retaining the service-level exception. That choice required more coordination and delayed the final sign-off, but it preserved the meaning of the exercise.

## Define the usable result before the exercise

A recovery objective should name the service activity it is intended to support. Otherwise, the test can become a collection of convenient checks whose relationship to actual use is assumed rather than demonstrated. Technical colleagues know how the infrastructure behaves. Service owners know which records and supporting material they require for particular tasks. Both kinds of knowledge are needed, and neither should be treated as a substitute for the other.

In our case, attachment references were part of that usable context. Their absence could not be answered by repeating that the database had restored. We funded ₹49 lakh of corrective work and changed the exercise so that service owners participated in defining and examining the result. The amount describes the work we approved; it does not by itself establish value or resilience. The evidence came from the corrected behaviour and the repeat exercise, with the scope recorded alongside it.

It is useful to distinguish a missing component from a disagreement about the objective. If the original objective never included a required element, the organisation needs to improve how it defines the test. If the element was included but absent, the response concerns execution and correction. In practice both questions may arise. A careful review avoids turning every finding into a debate about who can claim that their own part was technically complete.

Service participation also has a cost. Colleagues must spend time defining expected results, examining restored material and explaining discrepancies. That time competes with current service work. It should be planned as part of the exercise rather than requested at the last moment as a favour. A business that wants a credible account of recoverability must resource the people who can recognise an incomplete result, not only the people who operate the recovery tools.

The exercise should protect sensitive records while still providing meaningful evidence. The appropriate design depends on the data, the service and the company's obligations, with qualified advice where necessary. I would not prescribe one test environment or dataset for every business. The governance point is that the choice must be deliberate and explainable. An easy-to-run exercise that omits the dependencies central to the stated objective may produce a reassuring result without answering the question directors intended to ask.

There is a similar issue with exceptions. A test report needs a clear way to distinguish a known limitation, a newly discovered fault and work outside the agreed scope. Otherwise, every uncomfortable finding can be relabelled as something the test was never meant to cover. The categories should help management explain the result honestly, not provide a route to remove inconvenient facts from the account after they appear.

## Report the test that actually happened

After the corrective work, all seven datasets passed the agreed checks at the tested point. I regard that as a useful and specific outcome. It showed that the identified problem had been addressed in the repeat exercise. It did not prove that every future recovery would work, that every possible dataset had been examined or that later changes could not introduce another dependency. Those limits are part of a truthful result, not reasons to discount it.

The board account should therefore identify the objective, the scope, the exception and the evidence from the repeat. It should also explain what remains outside the conclusion. Directors can then assess whether the exercise supports the service commitment management is making and whether another area needs attention. They do not need to inspect every technical log, but they do need enough context to avoid mistaking a narrow test for a comprehensive assurance.

A repeat exercise should not become a ritual whose only purpose is to reproduce the previous green result. Systems change, suppliers change and service processes evolve. The test should be reconsidered when those changes alter what must be recovered or how its usability will be judged. That does not mean discarding every established check. It means maintaining a relationship between the exercise and the service, rather than allowing the test procedure to become an end in itself.

I also resist the idea that an honest exception necessarily damages confidence. Confidence should depend on whether the organisation can detect, explain and address a problem at the appropriate level. A report that records a missing attachment reference and shows a credible correction can be more useful than one that never looks beyond application startup. The quality of the question determines how much the answer can tell us.

For a CIO, the practical discipline is to keep technical accomplishment and service usability connected without erasing their differences. The infrastructure team deserves recognition for restoring what it restored. The service owner deserves an account that does not declare their work recoverable before the needed context is present. Holding both statements together leads to a more accurate decision. In our case, the application opening was a necessary milestone; the completed recovery claim required the attachments and the repeat evidence as well.