Incident Response Plan

Definition of terms

Before defining how to respond, it is important to use consistent terms. In IT security, three terms are often used in related but different ways:

1. Event — A neutral occurrence that happens frequently (e.g. a file created, a folder deleted, an email opened). By itself, an event is usually not a sign of a breach, but in combination with other events it may indicate a threat.
2. Alert — A notification triggered by one or more events. An alert may or may not represent a real threat; it requires assessment by people or systems.
3. Incident — A group of related alerts that have been assessed (by staff or automation) as indicating a real or likely security breach. Each single alert might not be critical on its own, but together they point to a possible compromise.

Incident response is the set of actions an organisation takes when it believes that IT systems or data may have been compromised. For example, security staff act when they see signs of unauthorised users, malware, or failures in security controls. The goals are to stop the attack as quickly as possible, restore systems, notify customers or regulators where required by law, and learn how to reduce the risk of similar incidents in the future.

In SecBoard you record and track such incidents in the Incident Register. The terms and classifications used there are aligned with the concepts described in this guide.

How incident response works

Response usually starts when the security team receives an alert from monitoring systems (for example a SIEM or other security tools). Team members must confirm that the situation meets the organisation’s definition of an incident, then isolate affected systems and remove the threat. If the incident is serious or long-running, the organisation may need to restore from backup, handle ransom demands, or notify customers and authorities.

For this reason, incident response often involves not only the security team but also privacy officers, legal counsel, and business decision-makers. In SecBoard, the Incident Register allows you to assign responsibility, record the current state, and keep a history of measures taken, so that both technical and non-technical stakeholders can follow the status of each case.

Types of security incidents

Attackers may try to gain access to company data or disrupt operations in several ways. Below are some of the most common types that you may classify and register in SecBoard:

In the SecBoard Incident Register you can assign an incident type and classification to each case so that statistics and reports remain consistent across the organisation.

What is an incident response plan?

During an incident, the team must work together in a structured way to contain the threat and meet regulatory and internal requirements. Under stress, people are more likely to make mistakes, so many organisations define a formal incident response plan. The plan sets out roles and responsibilities and the steps needed to handle, document, and report each incident correctly.

Why the plan matters

A serious incident can damage not only operations but also the organisation’s reputation and may have legal consequences. How quickly and consistently the team responds, and how management communicates with stakeholders, affects the overall impact. Organisations that hide breaches or downplay threats may breach the law. Such mistakes are more likely when there is no plan and people must decide under pressure. A clear plan helps everyone know what to do at each stage and, after recovery, allows the organisation to demonstrate that it took the incident seriously and took appropriate steps.

Incident response steps (lifecycle)

Many organisations follow a six-step model (e.g. SANS/NIST-style). The Incident Register in SecBoard supports documenting each phase so that you have a clear audit trail:

You can record the current state and measures taken for each incident in the SecBoard Incident Register so that the lifecycle is visible to all authorised users.

Incident response team

A dedicated team (often called CSIRT, CIRT or CERT) is responsible for executing the incident response plan. It usually includes both technical and non-technical roles:

• Incident manager (e.g. IT or security director) — Coordinates all phases and keeps internal stakeholders informed.
• Security analysts — Investigate the incident, document findings, and collect evidence.
• Threat researchers — Gather external intelligence to add context to the investigation.
• Management representative (e.g. CISO or IT lead) — Provides direction and liaises with other leaders.
• HR — Supports response when the threat involves insiders.
• Legal — Advises on liability and ensures evidence is collected in a way that supports possible legal or regulatory proceedings.
• Communications — Coordinates accurate external messaging to media, customers, and other stakeholders.

This team may be part of a broader security operations centre (SOC). In SecBoard, the Incident Register allows you to record the responsible person and reported-by fields so that roles are clear for each incident.

Automation and SOAR

Many organisations receive far more alerts than the response team can handle manually. Automation and Security Orchestration, Automation and Response (SOAR) tools help by:

• Correlating data from multiple sources to identify real incidents that need human action.
• Running predefined playbooks to contain and eradicate known types of threats.
• Building timelines and case files for investigation and reporting.
• Enriching alerts with external context for analysts.

If your organisation uses such tools, the incidents they generate or escalate can be recorded and tracked in the SecBoard Incident Register so that there is a single place for status, classification, and reporting.

Implementing a response plan

Building an incident response capability can feel demanding, but it significantly reduces the risk of being unprepared when a serious incident occurs. Practical steps you can take (and document in SecBoard) include:

• Identify and prioritise assets — Document critical data and systems, where they are, and their business importance.
• Assess risks — Understand the organisation’s main vulnerabilities and how an attacker might exploit them.
• Define procedures — Decide what counts as an incident; define steps for detection, containment, eradication, and recovery; and set rules for documentation and evidence preservation.
• Form the response team — Assign the roles above and ensure someone at executive level supports the team and its needs.
• Communication plan — Define when and how to notify management, the whole organisation, customers, and regulators or media.
• Training and testing — Train staff to recognise threats (e.g. phishing) and to report suspected incidents. Test the plan periodically and update it based on lessons learned.

Frequently asked questions