You are currently viewing Incident Response – Process Matters
PICERL - Common incident response process / framework

Incident Response – Process Matters

In the last month, there has been news about a range of cybersecurity breaches. The Register reported over 620 million hacked accounts being available from breaches on popular apps like MyFitnessPal and ShareThis. At the same time ransomware continues to disrupt healthcare, government and private companies. It seems a redundant truth to say breaches are inevitable. This means incident response is a critical business process for every organisation. Incident Response really does matter.

Incident Response - PICERL
PICERL – Common incident response process / framework

When it comes to building an Incident Response process, you need to decide on a framework. This can be anything you want. The key is pick one you understand and covers the important stages. PICERL (shown left) is one of the more common frameworks used to build an incident response process. In this, the flow runs Preparation, Identification, Containment, Eradication, Recover and then Lessons Learned. Future blog posts will look at each stage of PICERL in a bit more detail.

If you are starting off, all that matters is that you have a process.

Incident Response Process Matters

Key areas to consider are the fundamental areas of incident response – the things you do before the incident, how you respond to the incident and what you do after the incident. It may seem strange but all three areas are equally important so make sure you don’t just focus on the bit in the middle. The more effort you, or your response team, put into the first and last stages, the better and faster the middle bit will happen.

Once you have built a framework (or adopted an existing one) you can start to flesh out the details. Avoid perfection here and don’t think that once a document is written, it has to be set in stone. You can’t predict every incident in advance and trying to do so is the path to madness. Start with some likely events and document how you want your incident response team to respond. Then, over time build new ones. When you have incidents, update and modify your process documents.

When you adopt new technology, or change business processes, update and change your documents. When you get new staff into the incident response team, have them read & review the documents to see if they have any suggestions for improvements. It doesn’t matter how you do it, just need to keep the documents living and current.

Avoid the trap of thinking you need a finalised version for Audit or Compliance (you might do, but that is a different problem), and focus on having a version which works, can be used by your responders and relates to your current business.


As always, if you want specialised training for your IR team, we can provide tailored courses on or off-site for your staff, as well as table-top scenarios and red team exercises to ensure practical experience. Alternatively, you can look to send your staff on public training such as SANS SEC504 and SANS FOR508.

If you want to find out more, as always, get in touch.

Halkyn Security

Halkyn Security Consultants.