Two milestones measured from the same beginning
In a 2022 rehearsal, our systems reached a technical restoration milestone six hours after the exercise began. The agreed business flow completed at hour twenty-nine. Those were two elapsed times from the same starting point, not six hours followed by another twenty-nine. The distinction sounds elementary, but an imprecise account could misstate both the duration and the operating meaning of the exercise. I asked that the report retain the two milestones and explain what each one established.
The exercise was planned. It was not a live cyberattack or an actual factory outage. Its conditions were chosen, its participants knew it was happening and its result applied to the work it exercised. That does not make it unimportant. A rehearsal can expose dependencies before an incident forces the enterprise to confront them under greater pressure. Its value depends on preserving the scope of that evidence rather than promoting a test result into a universal assurance.
Technical restoration was a genuine achievement. The people who completed it had done necessary work. The problem would have been to let that milestone stand for the completion of something broader. The enterprise still needed authorised users, connected records and the relevant process steps to work together. A screen becoming available did not establish that a purchasing or operating transaction could reach its intended conclusion under the conditions of the rehearsal.
I did not want the discussion to become a competition between IT and operations over whose clock was correct. Both clocks described useful events. The executive task was to connect them to the question being asked. If directors wanted to understand when a business activity could resume, a technical restoration time alone was incomplete. If a technical team wanted to assess one restoration step, the broader business elapsed time could obscure the progress within that step.
The operating owner belongs inside the rehearsal
The intended business flow needed an owner who could say what completion meant. That owner could identify the records, permissions and decisions necessary for the activity, rather than rely on IT to infer them from system availability. Shalini Neqvashi retained operating responsibility while I coordinated the technology work. This was a partnership around a shared exercise, not a transfer of production authority to the CIO.
The process also needed a clear treatment of unresolved steps. An exercise can reach a point where one component is available while another condition remains uncertain. That uncertainty should remain in the record. Quietly using a workaround without explaining its limits may allow the demonstration to finish while hiding the dependency the rehearsal was meant to reveal. A useful result includes the path taken and the conditions on which completion depended.
This does not mean every rehearsal must simulate every possible event. An exercise with an intelligible scope can teach more than an elaborate performance whose assumptions nobody can explain. The chosen flow should connect to a material business question. The participants should know which conditions are being tested, which are being assumed and which remain outside the exercise. Management can then judge what further evidence is needed.
The same discipline applies to the data used. A technically available record may still need reconciliation before it supports an authorised business action. I would want the relevant owner to explain what must be checked before acting on it. This is not an invitation for directors to prescribe database procedures. It is a request that a recovery claim include the business conditions needed to make restored capability usable.
There are practical reasons to involve the people who normally perform the work. They can notice a missing handoff, an unavailable approval or a sequence that seems obvious to a designer but is not available in the actual operating arrangement. Their participation also makes the account less dependent on a small group of technical specialists narrating success. The exercise becomes a way to examine a working process rather than simply observe a system returning.
An approved programme is not a new recovery result
We funded a ₹71 lakh programme to address the dependencies the rehearsal exposed. That was an authorised response to evidence, not a demonstrated reduction in recovery time. A later claim about improvement would need another assessment with its own conditions. The programme might change several parts of the process, but its budget could not tell us how those parts would perform together in a future exercise.
I wanted the board account to preserve this sequence. First came the observed six-hour technical milestone and twenty-nine-hour business completion. Then came the decision to fund work. The account should not jump from an approved response to a completed resilience outcome. That jump is attractive because it turns an uncomfortable finding into a resolved story, but it removes the evidence management still needs to produce.
Nor should the difference between the milestones be treated automatically as twenty-three hours of avoidable waste. The exercise established elapsed times and unresolved dependencies. It did not establish that every intervening activity could disappear, or that a particular technology purchase would remove the whole interval. The work needed to be examined on its own terms, with operating priorities and resource choices made by the responsible leaders.
A useful recovery discussion therefore asks several connected questions. What business activity is being considered? What event begins the measurement? Which conditions define completion? What does the rehearsal actually demonstrate, and what remains assumed? These questions help directors understand the evidence without requiring them to become the incident team. They also help management explain why a seemingly modest dependency can matter more than a dramatic restoration milestone.
I would retain the limits even after a later exercise produced a better result. A changed test population, a different flow or additional preparation could affect comparability. Improvement should be described within the conditions observed. The enterprise may reasonably become more confident while still recognising that a real disruption introduces circumstances the rehearsal did not reproduce. Confidence and precision can coexist.
The lasting lesson for me is that recovery is a claim about useful work, not merely about visible equipment or available screens. Technology restoration belongs in that account, but it should not be asked to prove more than it has demonstrated. Our twenty-nine-hour result was less reassuring than a six-hour headline and more valuable for the decisions we needed to make. It showed where the enterprise still had work to do, and gave the programme that followed a question it would eventually have to answer with evidence.