Count the hours to restart, not the attacks blocked
Cyber reports to Indian boards still lead with blocked attacks and patch percentages. For a manufacturer the measure that matters is how long it would take to make and ship medicine again from a clean start, and most companies have never timed it.
For several years the cyber-security slide I took to our board looked much like everyone else's. It showed the phishing emails stopped, the attacks blocked at the perimeter, the share of laptops patched within thirty days and the completion rate for awareness training. The numbers were large and moving in the right direction. Directors nodded, asked one question about phishing and moved on. In February 2025, when ransomware encrypted our corporate servers, none of those numbers told anyone what they needed to know, which was how long it would be before we could ship again.
I have come to think the usual cyber report is designed to reassure, and that for a manufacturer it measures the wrong end of the problem. Prevention matters, and my team spends most of its security budget on it. But the board's real question is not whether an attacker will get in, because sooner or later one will. It is what the company can still do when that happens, and how quickly it can recover the rest.
The dashboard that reassures
Counts of blocked attacks are the easiest number to produce and the hardest to interpret. A rising count may reflect more attacks, better detection or a change in how a tool classifies events, and it says nothing about the attacks that were not blocked. Patch percentages have a different weakness in a pharmaceutical plant. The office estate can be patched monthly. The control systems and execution servers on the plant floor cannot, because each change to a validated system needs an impact assessment and sometimes requalification, and some equipment runs operating systems its vendor stopped supporting years ago. A patch figure that blends the two flatters the office and hides the plant.
In our case the plants were protected by architecture rather than by patching. Since 2017 at Kurkumbh, and from the first design at Dahej in 2019, the plant control and execution networks have sat in separate zones, with traffic to corporate IT limited to defined connections through an intermediate zone. When the attackers came in through a contractor's remote-access account and encrypted our corporate servers, they did not reach those zones. Every batch in progress finished normally. That outcome had never appeared on any dashboard I showed the board, because segmentation produces no events to count.
A plant is not restored when its servers are
The plants kept running, but they could not ship. Dahej's execution system took its material master data and dispatch instructions from ERP, which was encrypted. It was the last month of the financial year and ₹160 crore of shipments were due. Our chief operating officer asked, reasonably, for ERP to be restored from the latest backups within three days.
The difficulty was that a server restored is not a business restored. The investigators found that the attackers had been inside our network for nineteen days before encrypting anything, longer than our oldest online backup. Restoring those backups would have restored the attackers' foothold along with our data. We rebuilt the identity servers from nothing, restored applications from offline copies only after checking them, and brought systems back in an order that let quality confirm the integrity of each one before the plants relied on it. ERP returned in eleven days, and about ₹63 crore of shipments moved into the next quarter.
Those eleven days taught me what a recovery plan has to contain. It needs a map of dependencies: which plant functions stop when ERP stops, which laboratory systems need the directory to authenticate their users, which customer obligations fall due in the first week. It needs offline backups that an attacker holding administrator rights cannot delete. It needs a decision taken in advance, by people with authority, on whether the company will ever pay a ransom, so that nobody debates it at two in the morning; our board had settled that in 2023. And it needs rehearsal, because the first restore of anything is always slower than anyone expects.
Regulation adds its own clock. In India, CERT-In's directions require many kinds of cyber incident to be reported within six hours of being noticed, and a listed company must also consider what it owes the stock exchanges and its customers. We met those obligations because the steps were written into our runbook, with named owners and draft wording prepared in advance. A plant manager in the middle of a recovery should not be the person discovering them, and neither should a company secretary at midnight.
What I now report to the Risk Management Committee
The SEBI Listing Regulations give the Risk Management Committee of a large listed company a remit that includes cyber security, and ours now sees different numbers from me. The first is the time to restore each critical system from clean backups, measured in our latest drill rather than estimated: ERP, the execution systems at each plant, the laboratory platforms and the identity servers that everything else depends on. In the November 2025 drill ERP came back in 58 hours. The second is the number of days each plant can dispatch on manual procedures that quality has approved, and what volume it can manage that way. The third is every remote-access session granted to vendors and contractors, each approved and recorded, with any exception named.
The fourth is the one I find hardest to show and most important: the risks that have waited longest on the register without funding. The contractor-access weakness that let the attackers in had sat on our register for fourteen months, scheduled for the following year's budget. I had accepted that schedule. I should have taken it to the committee as a choice for directors, with its cost beside it.
None of this makes the familiar measures useless. We still count phishing and patch the office estate on time. But I would urge any board that oversees a manufacturer to put one question to management at its next meeting: if every server in the corporate network were encrypted tonight, how many hours would pass before the plants could ship again, and when did you last prove it? If the answer is an estimate, the company does not yet know.