The short answer
An incident plan must make clear who coordinates, who determines technical actions and who communicates. Reachable contacts and rehearsed decision-making are at least as important as the document itself.
Capture responsibilities
In case of an incident, technical and business questions come to the table at the same time. Who's assessing the impact? Who can temporarily stop an application? Who maintains contact with suppliers? Capture who takes these roles and who replaces in absence.
Keep information accessible
A plan that's only on an unreachable system doesn't help much. Determine how contact details and basic procedures remain available in case of failure. Limit access to sensitive details to the people they need and keep the information up to date.
Practice a scenario at the table
For example, discuss an unreachable application or an assumed account. Let participants explain what they would do, what information is missing and who they call. The goal is to find bottlenecks before there is real time pressure.
Connecting incidents to recovery and learning
Technical response, business continuity and communication must be linked. After an exercise or incident, discuss what adjustments are needed. Any reporting obligations will be assessed by the competent advisors for your situation. JViT helps organise the IT and security side of that preparation.
Discuss this with your team
- Who coordinates and who decides?
- Any replacements available?
- Is the plan available in case of system failure?
- When was the decision-making practice?
