Detecting, Assessing, and Reporting a Security Incident - The Complete Process

When the emergency strikes

Monday morning, 7:42 AM. The system administrator opens his dashboard and sees 143 failed login attempts on the Exchange server during the past night. Three of them were successful. From an IP address in Southeast Asia. At the same time, an employee from accounting reports that a strange email was sent from her own mailbox to all colleagues, without her having done it.

Is this a security incident? Yes. Is it a critical incident? That depends on what happens in the next 30 minutes. And this is precisely where the wheat is separated from the chaff: Companies with a clear incident response plan act in a structured and swift manner now. Companies without such a process improvise, lose time, and make mistakes that amplify the damage.

This article describes the complete process, from detection through assessment and containment to post-incident review. It is written so that you can use it as a basis for your own incident response process.

Phase 1: Detection - the three channels

Security incidents are detected through three fundamentally different channels. Each of these channels has its own strengths and weaknesses, and a robust process needs all three.

Channel 1: Technical monitoring

This is the channel most people think of first. SIEM systems, intrusion detection systems, endpoint detection and response solutions, firewall logs, antivirus alerts. These systems automatically generate alarms when predefined thresholds are exceeded or known attack patterns are detected.

The strength of technical monitoring lies in speed and objectivity. When ransomware begins encrypting files, an EDR system detects it within seconds. The weakness: It only detects what it has been configured to detect. New attack techniques, social engineering attacks, or slow, inconspicuous data exfiltration often remain below the radar.

Typical technical indicators of an incident:

For a mid-market company with 50 to 200 employees, monitoring does not need to be at the level of a SOC at a large enterprise. But a few basics are indispensable: centralized log collection, alerting on obvious anomalies, and someone who actually reads and assesses the alerts. If alarms are generated but nobody looks at them, you might as well turn off the monitoring.

Channel 2: Employee reports

This channel is chronically underestimated. Yet employees are often the first to notice that something is wrong. The colleague who received a suspicious email. The sales representative who notices their CRM access no longer works. The trainee who observes a USB stick in the server room that nobody recognizes.

For this channel to work, you need three things:

First, a clear reporting path. Every employee must know whom to contact when they notice something. This can be a central email address (security@company.com), a phone number, or a simple form on the intranet. The path must be low-threshold and must not create fear of consequences.

Second, a culture where reports are welcome. If someone clicked a phishing link and does not dare report it because they fear reprimand, you have a problem. The incident does not become less serious because it is concealed - it becomes worse. A blame-free culture for security incidents is not a luxury but an operational necessity.

Third, regular awareness training. Employees can only report what they recognize as unusual. Someone who has never learned what a phishing email looks like will not identify it as one. Short, regular training sessions as part of a security awareness program, ideally quarterly, keep attention high.

Channel 3: External tips

Sometimes you learn about a security incident in your company from third parties: A business partner reports receiving suspicious emails from your domain. The BSI informs you about a vulnerability that may have been exploited at your company. A security researcher contacts you because they found your data in a darknet forum. Or your managed security provider raises an alarm.

For this channel, you need a published contact address for security reports (a security.txt on the website per RFC 9116 is a good start) and an internal process that takes such reports seriously and routes them to the right place.

Phase 2: Initial assessment - determining severity

When a potential incident has been detected, the most critical phase begins: the initial assessment. Within a maximum of 30 minutes, an initial evaluation must be available that determines further action.

The severity scale from 1 to 10

A severity scale helps assess incidents consistently and trigger the appropriate response. Here is a proven model with four tiers:

Criteria for the initial assessment

To determine the severity, answer the following questions in the initial assessment:

Which systems are affected? A single workstation PC is to be assessed differently than the domain controller or the ERP system. The more business-critical the system, the higher the severity.

Are personal data affected? If yes, this triggers additional reporting obligations under DSGVO (GDPR). Customer data, employee data, health data, and financial data have different sensitivity levels.

Is the attack still active? An ongoing attack requires immediate containment. An already completed incident discovered after the fact allows more careful analysis.

What type of attack is it? Ransomware requires different immediate measures than data exfiltration. A DDoS attack has different priorities than a compromised email account.

How broad is the attack? Does it affect a single system, a network segment, or the entire enterprise? The answer to this question determines the resource allocation for containment.

Escalation criteria

Escalation is based on the severity level. Define in advance who is notified at which severity level:

An important point: The initial assessment is exactly that - an initial estimate. It can and will change during the investigation. An incident initially classified as severity 3 may turn out to be severity 8 when further compromised systems are discovered during analysis. Therefore, reassessment is an integral part of the process.

Phase 3: Containment - limiting the damage

Once the initial assessment is complete, containment begins. The goal: Prevent the incident from spreading further. At the same time, you must not prematurely destroy evidence that may be important for later analysis and possible criminal prosecution.

Immediate containment (short-term containment)

The first measures aim to stop the immediate spread:

Isolate affected systems. Unplug network cables, disable Wi-Fi, reconfigure VLANs. Important: Do not shut down systems while forensic capture is still pending. Valuable clues are often found in working memory that are lost when the system is powered off.

Lock compromised accounts. Reset passwords, terminate sessions, invalidate tokens. If an admin account is affected, all systems that account had access to must be checked.

Segment network areas. When the extent of the spread is unclear, it may be sensible to temporarily isolate entire network segments. This is a drastic step with impacts on business operations, but often unavoidable at severity 8 or higher.

Block external communication. If a command-and-control channel has been identified: block the corresponding domains and IP addresses on the firewall. This cuts off the attacker's control over the compromised systems.

Extended containment (long-term containment)

After the immediate measures, follow measures that enable controlled continued work while the investigation is ongoing:

Set up temporary workarounds. If the ERP system has been isolated, employees need a way to continue their work. Manual processes, offline systems, or alternative access paths can bridge the gap.

Perform forensic capture. Before systems are cleaned: pull images, secure logs, create RAM dumps. These data form the basis for root cause analysis and possibly for legal proceedings.

Intensify monitoring. During the containment phase, heightened vigilance is necessary. Attackers frequently attempt to regain access to the network through alternative paths when their primary access is blocked.

Phase 4: Eradication - eliminating the cause

Containment stops the spread but does not eliminate the cause. In this phase, the attack is completely removed from the environment.

Remove malware. On all affected systems, malicious software, backdoors, and persistence mechanisms must be identified and removed. This sounds simple but is often not. Professional attackers install multiple backdoors and persistence mechanisms to return after cleanup.

Close vulnerabilities. The attacker's entry point must be identified and closed. Was it an unpatched vulnerability? A weak password? A misconfiguration? If you do not fix the cause, the next attack will come through the same path.

Rotate credentials. All passwords and credentials that were potentially compromised must be changed. In a severe incident, particularly when Active Directory is compromised, this can mean that all passwords in the company must be reset. An enormous effort, but unavoidable when the domain controller is compromised.

Rebuild systems. In severe compromises, it is often safer and faster to restore affected systems from clean backups or completely rebuild them, rather than trying to clean them. You can never be absolutely certain that after cleanup, no hidden mechanism remains.

Phase 5: Recovery - returning to normal operations

Recovery is the transition from crisis mode back to normal operations. This transition must be controlled and monitored, not rushed.

Bring systems back online step by step. Do not start everything simultaneously. Begin with the most critical systems and expand gradually. Monitor each system intensively after startup for signs of re-compromise.

Verify functionality. Before a system is used productively again, verify that it functions correctly. Is all data present? Are configurations correct? Do interfaces to other systems work?

Maintain elevated monitoring. For at least two to four weeks after recovery, monitoring should remain at an elevated level. Attackers who have been expelled from a network frequently attempt to return through alternative paths.

Work through the backlog. During the incident, tasks have likely accumulated: emails that were not processed, orders that had to be captured manually, reports that could not be generated. Plan time and resources for working through these.

Time estimates for recovery

The duration of recovery depends heavily on severity:

For a ransomware attack that encrypted the entire network, a complete recovery in under two weeks is ambitious. Many mid-market companies need four to six weeks until all systems are fully functional again.

Phase 6: Lessons learned - learning from the incident

This phase is the most valuable and is nevertheless most often skipped. After the stress of crisis management, everyone wants to return to day-to-day business. That is exactly the mistake.

The lessons-learned workshop

Within two weeks of completing recovery, a structured workshop should take place. Participants: everyone who was involved in the incident, from IT to management to communications.

The central question is not who was to blame. Blame prevents honest analysis. The questions are instead:

What happened? Create a complete timeline of the incident. When was it detected? When was it escalated? What measures were taken in what order?

What worked well? Which processes functioned as planned? Where was the response fast and effective? These insights are just as important as the weaknesses, because they show you what to maintain and strengthen.

What did not work? Where were there delays? Where was information missing? Which processes failed or did not exist? Where was the incident worse than necessary because the response was too slow or wrong?

What do we change? For each identified weakness: concrete measures with a responsible person and deadline. No vague statements of intent but measurable improvements. If monitoring was too slow, a new alerting system comes with a deadline and budget. If communication was chaotic, the communication plan is revised and tested in the next exercise.

Incident documentation

Every incident is documented. This documentation serves multiple purposes: It is evidence for supervisory authorities, the basis for insurance claims, learning material for the organization, and input for improving the incident response process. Tools like ISMS Lite generate the BSI initial report directly from the captured incident data, so you do not have to start from scratch within the 24-hour deadline.

A complete incident documentation contains:

• Timestamps of detection, reporting, and all significant measures
• Type and severity of the incident (including any reassessments)
• Affected systems, data, and business processes
• Containment and eradication measures taken
• Root cause analysis
• Impact on business operations (downtime, financial damage)
• Results of the lessons-learned workshop
• Defined improvement measures with responsible persons and deadlines

The NIS2/GDPR reporting obligation check

Running parallel to the operational phases is a critical assessment: Must this incident be reported? And if so, to whom and by when?

Reporting obligation under NIS2

If your company falls under NIS2, the following deadlines apply for significant security incidents:

A significant security incident under NIS2 exists when it:

• causes or may cause serious operational disruptions,
• results in financial losses for the entity, or
• impairs other persons or entities through significant material or immaterial damage.

In practice: A ransomware attack that interrupts business operations is virtually always reportable. An isolated malware finding on a single workstation PC without spread is typically not. When in doubt, report rather than not - the BSI does not view omissions favorably.

Reporting obligation under GDPR

If personal data is affected, the GDPR reporting obligation also comes into play:

The GDPR notification to the supervisory authority is only waived if the breach is unlikely to result in a risk to the rights and freedoms of natural persons. For encrypted data that was exfiltrated, customer databases that were copied, or health data that was exposed, a risk is virtually always present.

Dual reporting obligation

Note: NIS2 and GDPR do not exclude each other. A ransomware attack that simultaneously disrupts business operations (NIS2-relevant) and affects customer data (GDPR-relevant) triggers both reporting obligations. You then report to both the BSI and the data protection supervisory authority, with different deadlines and content.

The reporting obligation decision tree

For quick decision-making under time pressure, a simple decision tree helps:

Question 1: Does your company fall under NIS2? If yes: Is the incident significant (operational disruption, financial damage, harm to third parties)? Then report to the BSI within 24 hours.

Question 2: Are personal data affected? If yes: Is there a risk to the rights and freedoms of those affected? Then report to the supervisory authority within 72 hours. In case of high risk, additionally notify those affected.

Question 3: Neither applies? Then no external reporting obligation, but internal documentation is still mandatory.

The interplay of phases in practice

The six phases sound sequential on paper; in reality they overlap. While you are still dealing with containment, the initial report to the BSI is already in progress. While eradication is ongoing, recovery on non-critical systems is already beginning. This is normal and correct.

What is decisive is that despite this parallelism, no phase is skipped. In particular, the initial assessment and lessons learned are readily shortened or omitted under time pressure. With the initial assessment, this leads to wrong prioritization and resource waste. With lessons learned, it leads to the same mistake recurring three months later.

A complete example walkthrough

Monday, 7:42 AM: The described situation with the failed login attempts and the compromised mailbox.

7:42 - Detection. The administrator recognizes the anomaly in the dashboard and simultaneously receives the employee's report. Two channels simultaneously - this increases urgency.

7:55 - Initial assessment. Log analysis shows: Three successful logins with valid credentials from abroad. The mailbox was used to send phishing emails to internal and external contacts. Severity: 5, with a tendency upward since it is still unclear whether further accounts are affected. IT management and ISB are informed.

8:10 - Containment. The compromised account is locked, sessions are terminated, the password is reset. The IP address is blocked on the firewall. All employees receive a warning not to open attachments from the suspicious email.

8:30 - Extended analysis. Check of all accounts for unusual login patterns. Two additional accounts show successful logins from the same IP address. Reassessment to severity 7. Executive management is informed. Reporting obligation check begins.

9:00 - Eradication. All three compromised accounts are secured. MFA is enforced for all accounts (previously optional). The entry point was a password spray attack on accounts without MFA.

9:30 - Reporting obligation check. GDPR: The compromised mailboxes contained customer data (email addresses, names, order information). Notification to the supervisory authority is being prepared. NIS2: If the company falls under NIS2, the initial report to the BSI is being prepared.

Tuesday to Friday - Recovery and monitoring. Elevated monitoring on all systems. Analysis of whether further actions took place through the compromised accounts (data access, forwarding rules, delegated permissions).

Two weeks later - Lessons learned. Workshop with IT team, ISB, and executive management. Result: MFA becomes mandatory for all accounts (no longer optional). The password policy is tightened. Automatic alerting for logins from unusual geo-locations is set up. The awareness training on password security is moved up.

The three most common mistakes in incident handling

Mistake 1: Cleaning up too quickly. The reflex to immediately delete everything and rebuild systems is understandable but dangerous. If you destroy evidence before you understand the cause, you do not know whether the attacker has other access paths. And you cannot present a well-founded root cause analysis to the supervisory authority.

Mistake 2: Neglecting communication. While IT works in crisis mode, employees do not know what is happening, executive management has no information for customers and partners, and press inquiries go unanswered. A communication plan is just as important as the technical response plan.

Mistake 3: Stopping after recovery. The incident is resolved, all systems are running again, normal operations return, and everyone is relieved. This is exactly when the phase that has the greatest long-term value begins: the post-incident review. Companies that consistently implement their lessons learned get better with every incident. Companies that skip this phase make the same mistakes over and over again.

What you can do now

If you are reading this article and do not yet have an incident response process, you do not need to implement everything at once. Start with three things:

Define reporting paths. Where does an employee turn who notices something suspicious? Who decides on escalation? Who reports to the BSI and the supervisory authority? Write this on one page and communicate it.

Create the severity scale. Take the table from this article, adapt it to your company, and ensure your IT team knows and can apply it.

Test the process once. Run through a scenario, preferably as a tabletop exercise with the IT team. Friday evening, ransomware, Exchange is encrypted. What do we do? Who calls whom? Where is the number of the external service provider? This simple exercise uncovers more gaps than any document.

Further reading

• Reporting a GDPR data breach: When, how, and to whom
• Creating an incident response plan: Template and practical example
• NIS2 reporting deadlines overview: 24h, 72h, 1 month - what is due when
• Planning and conducting a tabletop exercise: How to test your emergency plan
• NIS2 initial report to the BSI: Content, deadlines, and template

A structured incident response process does not protect against incidents. But it determines whether a security incident becomes a controllable disruption or an existentially threatening crisis.