When should a disaster recovery plan actually be activated?

Activate when a critical system is down beyond the tolerance you agreed for it, when you have lost confidence in the integrity of your systems, or when an event will visibly affect customers. The trigger should be written and the decision should belong to one named person, because the delay is almost always in deciding, not in doing.

The reason this deserves its own answer is that the failure mode is so consistent. Almost nobody suffers from activating too readily. What happens instead is an hour or two of hopeful diagnosis, someone rebooting something, a quiet assumption it will come good, and a plan invoked at nine when it should have been invoked at seven. Those two hours come straight off the end of the recovery, and they are also the hours in which ransomware finishes what it started.

So write triggers that do not require a judgement call in the moment. A time-based one: this system has been down longer than its agreed tolerance, therefore we activate, no debate. A trust-based one: if there is credible evidence of compromise, activate immediately, because in a cyber incident the systems you would use to assess the situation are the systems you cannot trust. And an impact-based one: if customers will notice before we can fix it, activate, because the communications half of the plan matters as much as the technical half.

The other half of the answer is naming who decides, with a deputy, both reachable out of hours. A plan with an unfilled authority line stalls exactly where speed is worth most. And agree in advance what your provider may do without waiting for you, since containment is measured in minutes and ours runs 24/7. If your current plan does not answer who declares, that is the cheapest gap you will fix this year: call 1800 456 567.