We have a corporate incident response retainer. Is that enough?

It is a good start for the IT side of an incident. Ask the provider what they would do with a compromised PLC, and whether they have been on a plant floor. The answer tells you whether you need an OT plan alongside it.

How often should we exercise?

At least once a year, and after any significant change to the plant or the plan. The Australian and Indian regimes both expect exercises for the entities they cover.

Incident response for OT: why the IT playbook fails on the plant floor

Five things that are different

Safety comes before containment. The first question is not what the attacker has, it is whether the process is in a safe state and who is confirming that.
Isolation is not free. Pulling a controller off the network can drop a plant into manual or into a trip. Containment has to be planned with the people who run the process, in advance.
Evidence lives in strange places. Controller logic, HMI project files, historian trends and engineering workstation caches are evidence. Most of it is volatile and none of it is covered by the corporate forensics kit.
Vendors are inside the incident. The integrator who built the system and the OEM who supports it hold the knowledge and often the remote access. They need to be in the plan, with a phone number that works at 2 am.
Recovery means the process, not the server. A restored image is only the start; the plant has to be brought back in a known-good state, with the logic verified, before anyone trusts it.

The clocks

Regulators have put a stopwatch on this. In Australia, a responsible entity under the SOCI Act must report a cyber incident with a significant impact on the availability of a critical infrastructure asset within 12 hours of becoming aware of it, and an incident with a relevant impact within 72 hours. In India, the CERT-In Directions require cyber incidents to be reported within six hours of noticing them, and the CEA power sector regulations require the same six hours to CSIRT-Power and CERT-In, with 24 hours for an incident concluded as sabotage of a critical system.

Those clocks start when you become aware, which is often before you understand. The plan has to name who decides that a report is due, who sends it, and what goes in it when the facts are still thin.

What a ready organisation has

An OT-specific incident response plan: roles that include operations, engineering and vendors; severity levels defined by process consequence; safe-state and containment options pre-agreed per system.
Playbooks for the likely scenarios: ransomware reaching the engineering network, a vendor account misused, a controller behaving unexpectedly, loss of the historian.
Evidence procedures for OT: how to capture controller logic, HMI and workstation images and network traffic without stopping the plant.
Relationships in place before the day: the OEM, the integrator, an incident response partner, the regulator's contact point.
Exercises. A tabletop every year at least, with a control-system scenario, and the findings fed back into the plan.