Recovery is incomplete until the working service has been exercised

Four hours was a useful result. The technical team had restored the application, and authorised colleagues could sign in and see the records. I did not want to diminish that work. I wanted to prevent the result from acquiring a meaning the exercise had not established. The telephone path and other working dependencies had not been tested together with the application. A service colleague might therefore have had a functioning screen without the complete route needed to carry out the intended coordination. Restoring the component was real progress;calling it service recovery would have required more evidence.

Keep the restored component's achievement specific

Our 2025 exercise concerned a commercial-vehicle roadside-assistance coordination enterprise. Its working service depended on people, telephony, application records and contact with independent partners. Those dependencies did not all belong to one technology supplier. That made it possible for individual assurance reports to look satisfactory without demonstrating the complete functional journey. Each owner could describe the part tested accurately while the enterprise still lacked an answer about how the parts worked together after restoration. The CIO's responsibility included making that missing question visible.

The infrastructure lead preferred to close the technical exercise and rely on the telephony supplier's routine assurance for its part. There was a reasonable efficiency argument. Repeating tests already performed by a competent supplier can consume time without adding useful evidence. But we had not established that the separate results answered the joined service question. Operations wanted to understand whether a controlled call could reach the appropriate intake process and support contact with the partner through the restored environment. That was a different test from confirming that the application's sign-in page responded.

I supported a₹62 lakh recovery programme with the relevant owners. We agreed a defined intake-to-partner-contact workflow and the evidence required to assess it. The exercise used controlled calls and arrangements. It did not simulate a live emergency through public channels or instruct anyone to perform an actual roadside intervention. Qualified operating and technical colleagues retained responsibility for the service conditions. This boundary mattered because a realistic business context should make an exercise useful without creating an uncontrolled event or inviting an unsupported safety claim.

Agree the minimum working service together

A minimum working service is not simply the smallest collection of servers that can be restarted. It is an account of the work the enterprise needs to perform and the dependencies required to perform it under the agreed conditions. Technology can help make that account precise, but operations must explain the task and its limitations. Other professional owners may need to assess records, access, contracts or fallback arrangements. The useful outcome is a shared understanding of what the exercise will and will not demonstrate before anyone reports a recovery time.

That discussion can expose uncomfortable gaps. A supplier may have completed its contractual component test while the enterprise still needs work between components. An operating team may have a fallback description that has not been rehearsed under the expected conditions. A technically restored environment may contain a record that requires validation before it supports the next action. I do not treat every such gap as evidence that earlier work was worthless. I treat it as evidence that the assurance needs a more careful boundary and a funded plan for the remaining dependency.

The joined review examined twenty-eight controlled calls. Twenty-two completed the defined workflow and six required manual fallback. We retained the six in the report and examined the conditions around them. The exercise did not establish that every future interruption could be handled in the same way. It did not demonstrate a live response time, prove the safety of an intervention or create a universal recovery-time commitment for the enterprise. The evidence was useful because its scope was clear enough for management to decide what further preparation was needed.

The earlier four-hour application figure also remained in the account. We did not replace it with a single blended number that implied every dependency had returned at that moment. Different stages answered different questions. A restored technical component, a completed test workflow and an approved fallback arrangement should each be described on their own terms. That can make an executive paper longer, but it prevents the headline from concealing the stage at which the actual service still depends on an unresolved condition or a different way of working.

Report the fallback without inventing a universal recovery time

Manual fallback should not be used as a phrase that makes an incomplete test disappear. It requires a supported account of the people, records, authority and conditions involved. Nor should it automatically be treated as failure merely because it differs from the normal application path. The relevant question is whether the fallback is understood, appropriate and adequately prepared for the defined situation. In our report, the six calls remained distinct from the twenty-two completing the principal workflow. That distinction allowed the next review to examine what had actually happened rather than argue about a broad pass label.

The programme required time from colleagues whose individual systems already had favourable reports. Coordinating that work was part of the cost. I wanted the enterprise to recognise it rather than assume that a supplier's technical responsibility automatically included every business dependency around its service. A clear contract and a capable supplier are valuable. The company still needs to understand how their work connects with its own operation. The joined exercise was a way to examine that connection, not a claim that management could outsource the final meaning of service readiness to a collection of separate certificates.

For directors, the question is whether recovery assurance is expressed in terms the enterprise can use. Which important work was exercised? What assumptions did the test make? Which dependencies and exceptions remain? Who owns the next decision, and what resources are required? Those questions support oversight without asking the board to run a technical recovery. They also help distinguish a useful component result from an overextended assurance claim. A board should be able to recognise progress while still asking whether the service on which customers rely has been examined sufficiently.

I would agree the minimum working service before funding the next recovery programme. That would help technical and operating owners plan their tests around a common question from the beginning. It would also make the final report easier to interpret, because the scope would not need to be reconstructed after a favourable technical result had already become the headline. Four hours remains an achievement worth recording. Its value is clearer when we say precisely what returned in that time, and what the enterprise still had to exercise before relying on the working service.