Incident response planning requires constant testing

The primary step towards a robust incident response plan is to get testing. It’s crucial not to wait until you’re faced with an issue to test all elements of the plan, especially around critical systems and processes.

Involve relevant stakeholders across the business as though a serious incident is occurring to test the process, technologies and people.

Tabletop exercises can be a great way to include all the elements as the team will understand why drills matter whilst undergoing a practical simulation of what it feels like when under pressure during an incident.

An incident response plan should be robust and cover business priorities; not all systems are equally important and knowing which the focus is to secure and restore ahead of other systems is essential.

The plan should cover the full estate with an additional spotlight on interlinking systems, and be aware that sometimes the systems that you rely on as part of the plan could be down too!

Although it may seem overkill, a top tip is to ensure everyone who might be part of an incident should have a printed copy of the incident response plan at home and at work.

Ownership of the incident response plan should fall to a single owner plus a back-up deputy; their role is to run the plan and liaise with other stakeholders to prevent confusion and potential time wasting.

The owner also needs to track progress and ultimately note pitfalls to improve the plan for future incidents.

Taking time after the incident to review what work and what didn’t is hugely important and must be rigorous; there’s no point having a plan that doesn't evolve to ever-changing incidents.

Jack Chapman is vice president of threat intelligence at Egress.