You are currently viewing Incident Response Phases – Identification
PICERL - Common incident response process / framework

Incident Response Phases – Identification

In a previous post we discussed the importance of having an Incident Response (IR) process and our preference is one that runs Preparation, Identification, Containment, Eradication, Recovery and Lessons Learned (PICERL). This time we are looking at the second phase: Identification.

Incident Response - P Identification CERL
PICERL – Common incident response process / framework

During this phase of IR, we start what most people recognise as Incident Response. As a result, the pressure will start to mount. However, responders must still understand and follow process.


Something has happened. Possibly something bad. Right now, no one really knows for sure. Incident responders need to act quickly, yet accurately, to assess the situation. By this we mean they need to IDENTIFY what has happened. You want them to understand it well enough to decide if this event really is an “incident”, or if this is something that can be addressed in other ways.

Although this sounds simple, it rarely is. The “fog of war” makes decisions difficult. There is never enough information. Also, you will feel there is never enough time. Resisting this is important. To do this, you need a good identification process/workflow. As an example of how important this is, the UK Government guidance on IR has THREE steps dedicated to incident identification.

Remember to prepare

Identification is the second step of the IR cycle. This means you should have prepared before you get here. Your preparation should include guides on classifying & prioritising incidents. Also, you probably want some playbooks on how to respond, but that’s the next step.

What does this all mean

In summary, “identification” here means being able to validate an event is an incident; putting it in a category to help responders & management reporting; prioritise it to protect resources; importantly, be able to determine if any regulator/government agency needs to be involved. In other words, it is easy.

Except it isn’t. However, if you plan & practice it becomes easier. Above all else, give your responders the authority & trust to make decisions here. Remember, until they assess it is an incident, you simply have an event. In other words, “something happened” and you dont know anything else for sure.

The Event

First, we need to look at the event. In IT lots of things happen all the time. For example, your firewall is almost constantly being probed. In addition, your mailboxes are bombarded with spam/phishing. Meanwhile, your staff are visiting websites and people are ringing up trying to bluff their way to speaking with the boss.

This is constant. There is no way you can treat every event as an incident. Apart from anything else, this would bankrupt you in days. So, clearly, we can see there needs to be a way to tell the difference between an “event” and an incident. This is why identification matters.


When looking at the event, consider the source. Some are more trusted than others. However, dont automatically dismiss sources, just weight your confidence appropriately. For example, if a random phone call says “you’ve been hacked”, you might want to worry less than if a Specialist Police Officer turns up and tells you the same thing. In your planning phase, you can document this. Alternatively, Responders should be trained to assess this on the fly.

Remember to consider possible internal and external sources. Additionally, be open to reporting. Above all else, you want people to report incidents early when you can respond, not after a breach.

Internal Examples
  • SIEM/Monitoring
  • Firewall
  • User reports
  • Pentest/Red Teams
  • Internal Threat Hunts
External Examples
  • Customer reporting
  • Client/supplier/3rd party notification
  • Law Enforcement report
  • News Reporter telling you
  • Attacker notification

Clearly it is better to detect the incident internally. If a national news crew turn up at your office, things are probably already out of control. In short, you want to detect the incident rather than be notified.

However, if you are notified, good IR will still see you through the problem.

Congratualtions, its an INCIDENT!

So, you’ve confirmed the event is bad. Responders have declared an incident and your response process is gearing up. Meanwhile, staff, customers and clients are going about their business as normal. You need to decide how much disruption this incident is going to cause.

However, although this is important, it isn’t set in stone. During the response, you may learn new things which change your view. You might discover it’s all a mistake. Alternatively, you might discover what you thought was minor is a full breach. Whatever the outcome, never hesitate to reassess the incident.

Incident identification should lead to three bits of knowledge.


First, you want to categorise the incident. That is to say, describe it in a manner you can use to track against other incidents. This can be as simple or complex as you want. Some organisations have a basic model along the lines of:

  • Malware
  • Phishing
  • Intrusion
  • etc

While others go for lots of detail:

  • Trojan – Windows
  • Worm – Windows
  • RCE – Windows
  • Trojan – Linux
  • etc

You need to pick whatever works best for your organisation. You can, if you want, build a huge model with a detailed taxonomy and ENISA has good guidance on this. But you may find this is overkill. All you really need is something Responders can use and provides some management information.


It won’t always be an issue, but most incidents impact your normal activities. You need to establish how important this incident is compared with everything else that is going on. Also, you may need to divert resources from other parts of the business. You may need to shut down profit-generating functions to prevent further damage. Clearly you can’t treat every incident as if it was the end of the world. However, you cant treat all of them as if they dont matter either.

Consequently, you need some way to prioritise. Again, this should be part of your planning documentation. You can go for a simple 1 – 5 scale or you can do detailed assessments of potential costs and impact. Whatever you pick, it has to work and be useable by a responder under stress. As a result, simpler is probably better.


Last part of identification is deciding what “level” this problem sits at. Escalation can be a responder deciding if they can deal with it or if they need help from a broader team. Also, it can be an entire organisation deciding if they need to bring a 3rd party in. Incidents frequently happen at weekends/holidays. Incident responders are almost always under pressure and isolated. As a result, clearly defined escalation criteria are essential. Minimise the guesswork needed. Provide a framework that supports your responder.

Examples of escalations include:

  • Individual responder requiring support from network and sysadmins
  • Response team calling in 3rd party support
  • Identifying a breach and requiring legal/PR support
  • Discovering criminal employee activity which needs Law Enforcement asssitance

As you can see, it varies wildly. Therefore make sure you plan this well.

Identification is…

To summarise, identification is how you tell the difference between an event and an incident. Good practices here will save you money, and stress, in the long term by minimising the disruption and cost of an incident. In addition, it reinforces the need to have strong preparation. The IR cycle works best when all the steps are carried out.

Halkyn Security

Halkyn Security Consultants.