Incident Response Playbook: What to Do When You've Been Breached

Introduction: It Is Not If, but When

Every organization will face a security incident. This is not pessimism — it is the statistical reality of operating in a connected world. The IBM Cost of a Data Breach Report consistently places the average cost of a breach in the EU at approximately €4.5 million, a figure that accounts for detection, containment, notification, lost business, and long-term reputational damage. For organizations subject to GDPR and NIS2, regulatory fines can push that number significantly higher.

Yet despite these well-documented risks, most organizations remain unprepared. They lack documented response procedures. Their teams have never rehearsed a breach scenario. Their logging infrastructure has gaps that will blind them at the worst possible moment. When the alert finally fires — or worse, when a journalist calls asking for comment — the result is chaos, improvisation, and a cascade of avoidable mistakes.

The difference between a contained incident and a catastrophic breach is almost never about the sophistication of the attacker. It is about the speed and quality of the response. Organizations with a tested incident response plan identify and contain breaches an average of 54 days faster than those without one. At the scale of modern breach costs, every day of delay translates directly into financial and operational damage.

You do not rise to the level of your expectations during a crisis. You fall to the level of your preparation.

This guide walks through the six phases of incident response, grounded in the NIST Computer Security Incident Handling Guide (SP 800-61) and adapted for the European regulatory landscape. Whether you are building your first IR plan or pressure-testing an existing one, the framework below provides a concrete, actionable foundation.

Phase 1: Preparation (Before the Breach)

Preparation is the phase that determines everything that follows. An incident response plan written during an active breach is not a plan — it is panic with formatting. The time to build your response capability is now, while your systems are quiet and your team can think clearly.

Build Your Incident Response Team

An effective IR team is not composed entirely of technical staff. It is a cross-functional group with clearly defined roles and a documented chain of command. At minimum, your team should include:

• IR Lead / Incident Commander — Owns the response, makes decisions on containment and escalation, coordinates all activities. This person must have the authority to take systems offline without waiting for committee approval.
• Forensics Analyst — Collects and preserves evidence, analyzes compromised systems, determines root cause and scope. Must understand chain of custody requirements.
• Legal Counsel — Advises on regulatory notification obligations (GDPR, NIS2), manages privilege considerations, coordinates with law enforcement. Should be involved from the first hour, not the first week.
• Communications Lead — Manages internal and external messaging, drafts customer notifications, handles media inquiries. Prevents the accidental disclosures that turn manageable incidents into front-page stories.
• Management Sponsor — A senior executive with decision-making authority over budgets, business operations, and strategic trade-offs. Their role is to remove organizational obstacles in real time.

Create Documented Playbooks

Generic incident response plans are better than nothing, but specific playbooks for common scenarios are far more effective under pressure. Develop step-by-step procedures for at least these four scenarios:

• Ransomware — Isolation procedures, backup verification, decryption assessment, negotiation policy (or explicit policy against negotiation), law enforcement notification
• Data exfiltration — Scope determination, data classification review, regulatory notification triggers, customer impact assessment
• DDoS attack — Upstream provider coordination, traffic scrubbing activation, service degradation procedures, customer communication
• Insider threat — HR coordination, access revocation, legal hold procedures, evidence preservation with employment law considerations

Ensure Logging and Visibility

You cannot investigate what you cannot see. Before an incident occurs, verify that your logging infrastructure covers the areas that matter most during an investigation:

• SIEM deployment with log aggregation from critical systems, network devices, and authentication services
• Endpoint detection and response (EDR) on all workstations and servers, with sufficient retention to support forensic timelines
• Network flow data and DNS query logs — often the first indicators of command-and-control communication or data exfiltration
• Cloud audit logs (AWS CloudTrail, Azure Activity Log, GCP Audit Logs) with tamper-proof storage

Maintain Contact Lists and Retainers

During an active incident, you do not want to be searching for phone numbers. Maintain a current, offline-accessible contact list that includes your legal counsel, cyber insurance provider and claims contact, local law enforcement cyber unit, external IR firm (ideally on retainer), data protection authority (Austrian DSB), and your NIS2 reporting CSIRT.

Practice with Tabletop Exercises

A plan that has never been tested is a plan that will fail. Conduct tabletop exercises at least twice a year, walking your IR team through realistic scenarios and identifying gaps in your procedures, communication, and decision-making. These exercises consistently reveal assumptions that do not survive contact with a simulated crisis — better to discover those now than during a real one.

Phase 2: Detection and Analysis

Detection is where theory meets reality. A breach can surface through any number of channels, and your ability to recognize and correctly assess the situation in the first minutes and hours will shape the entire response.

How Breaches Are Identified

In practice, organizations discover breaches through a mix of internal and external signals:

• Automated alerts — SIEM correlation rules, EDR detections, intrusion detection/prevention system alerts
• Anomaly detection — Unusual network traffic patterns, unexpected system behavior, abnormal authentication activity (off-hours logins, impossible travel, privilege escalation)
• User reports — Employees noticing unusual behavior on their systems, unexpected password reset emails, unfamiliar applications
• External notification — A security researcher, law enforcement agency, or business partner informing you that your data has appeared where it should not be. In the EU, a significant percentage of breaches are first detected by external parties.

Initial Triage: Severity Classification

Not every alert warrants the same response. Classify incidents immediately using a severity framework so that resources are allocated appropriately:

Evidence Collection

Begin collecting evidence immediately upon detection. The first hours are critical — volatile data disappears quickly, and early evidence is often the most valuable for determining scope and attribution:

• System logs — Authentication logs, application logs, system event logs from affected and adjacent systems
• Memory dumps — Capture volatile memory from compromised systems before any reboot. RAM contains running processes, network connections, decryption keys, and malware that may exist only in memory.
• Network captures — Packet captures from network segments where suspicious activity was observed, firewall logs, proxy logs, DNS query logs
• Disk images — Forensic bit-for-bit images of affected systems, created using write-blockers to ensure admissibility

Document everything with timestamps. Maintain an incident log from the moment detection occurs. Record every action taken, every decision made, and every person involved. This log serves multiple purposes: it supports the forensic investigation, satisfies regulatory documentation requirements, and provides the raw material for your post-incident review.

Determine Scope

Before you can contain an incident, you must understand its boundaries. Work to answer these questions as quickly as possible: What systems have been accessed or compromised? What data was stored on those systems, and what is its classification? How many users, customers, or partners are potentially affected? How did the attacker gain initial access, and do they still have access? Is there evidence of lateral movement to other systems or network segments?

Phase 3: Containment

Containment is about stopping the bleeding without destroying the evidence. This is where the tension between operational urgency and forensic integrity is most acute, and where undisciplined responses cause the most avoidable damage.

Short-Term Containment

The immediate goal is to prevent the attacker from causing further damage while preserving your ability to investigate. Short-term containment actions include:

• Network isolation — Segment or disconnect affected systems from the network. Do not simply unplug the power — this destroys volatile evidence. Isolate at the network layer instead.
• Account suspension — Disable compromised accounts, revoke active sessions, and block known attacker IP addresses and domains
• Firewall rule deployment — Block known indicators of compromise (IOCs) at the perimeter and internal segmentation points
• DNS sinkholing — Redirect command-and-control domains to internal sinkholes to cut off attacker communication while monitoring for additional compromised hosts

Long-Term Containment

Short-term containment buys time. Long-term containment ensures you understand the root cause before rebuilding. Premature recovery — rebuilding systems before understanding how the attacker got in — frequently results in recompromise, sometimes within hours.

During long-term containment, focus on identifying the initial attack vector, mapping all persistence mechanisms the attacker has established, verifying the integrity of systems that were not initially flagged as compromised, and building a comprehensive timeline of attacker activity from initial access to detection.

Chain of Custody

If there is any possibility that the incident will involve law enforcement, regulatory investigation, or litigation, evidence must be handled with chain of custody discipline. This means documenting who collected each piece of evidence, when, how, and where it has been stored. Use cryptographic hashes to verify evidence integrity. Store evidence on dedicated, access-controlled media. This is not bureaucratic overhead — it is what makes evidence admissible.

Phase 4: Eradication and Recovery

Once you have contained the incident and understand the root cause, you can begin removing the attacker's presence and restoring normal operations. This phase must be methodical — rushing recovery is how organizations get breached a second time.

Eradicate Attacker Access

• Remove all backdoors and persistence mechanisms — This includes web shells, scheduled tasks, modified startup scripts, rogue SSH keys, unauthorized local accounts, and any implants identified during forensic analysis
• Patch the exploited vulnerability — Identify and remediate the vulnerability or misconfiguration that enabled initial access. If the vector was phishing, this means addressing both the technical controls (email filtering, endpoint protection) and the human factors (awareness training, reporting procedures)
• Reset all potentially compromised credentials — This is not limited to accounts known to be compromised. If the attacker had access to a domain controller, Active Directory credential store, or password database, assume all credentials in that scope are compromised. Force a password reset for all affected users and service accounts, and rotate all API keys, certificates, and tokens that may have been exposed.

Rebuild from Known-Good State

For systems that were directly compromised, rebuilding from known-good backups is almost always preferable to attempting to clean them in place. Verify backup integrity before restoration — sophisticated attackers sometimes compromise backup systems as well. Where possible, rebuild using fresh images and restore only data (not executables or configurations) from backups.

Staged Recovery with Monitoring

Do not bring all systems back online simultaneously. Implement a staged recovery process: restore critical services first, monitor them closely for any signs of recompromise, and then gradually bring secondary systems online. Deploy enhanced monitoring on all recovered systems for a minimum of 30 days. The attacker knows you have discovered them — if they retained any access you missed, they may act quickly.

Phase 5: Notification and Compliance

For organizations operating in the EU, regulatory notification is not optional. Missing a deadline does not just result in fines — it undermines trust with regulators and can escalate enforcement from cooperative to adversarial.

GDPR Notification (Regulation (EU) 2016/679)

If the breach involves personal data, GDPR Article 33 requires notification to the competent supervisory authority without undue delay and no later than 72 hours after becoming aware of the breach. In Austria, the supervisory authority is the Datenschutzbehörde (DSB).

The notification must include the nature of the breach, categories and approximate number of individuals affected, the likely consequences, and the measures taken or proposed to address the breach. If the breach is likely to result in a high risk to the rights and freedoms of affected individuals, Article 34 requires direct notification to those individuals as well.

NIS2 Notification (Directive (EU) 2022/2555)

For organizations subject to NIS2, the notification timeline is even more aggressive:

Law Enforcement Coordination

In Austria, cybercrime incidents should be reported to the Bundeskriminalamt (BK), specifically the Cybercrime Competence Center (C4). Law enforcement involvement is particularly important for ransomware incidents, cases involving organized criminal groups, incidents with cross-border elements, and situations where stolen data may appear on dark web markets. Coordinate with your legal counsel before engaging law enforcement to ensure that your communication is appropriately structured and that privilege considerations are addressed.

Cyber Insurance

If you carry cyber insurance, notify your insurer as early as possible — most policies require notification within a specific window (often 24 to 72 hours) or risk coverage denial. Your insurer may have a panel of pre-approved IR firms, legal counsel, and communications specialists. Using panel providers can streamline the claims process and is sometimes required by policy terms.

Phase 6: Post-Incident Review

The post-incident review is where an incident becomes an investment in future resilience. Skip this phase, and you are likely to repeat the same mistakes. Execute it well, and every incident — no matter how painful — leaves your organization materially stronger.

Lessons Learned Meeting

Conduct a structured debrief within two weeks of incident closure, while details are still fresh. This meeting should include all members of the IR team and relevant stakeholders. The goal is to understand what happened, why it happened, what worked well, what did not, and what specific changes will prevent recurrence. This must be a blameless review. If people fear punishment for honest reporting, they will conceal mistakes, and your organization will lose the most valuable insights.

Update Playbooks and Procedures

Every incident reveals gaps in your existing documentation. Update your IR playbooks, runbooks, and contact lists based on what you learned. If a specific scenario was not covered by your existing playbooks, create one. If communication broke down at a specific point, redesign that workflow. These updates should be completed within 30 days of the lessons learned meeting.

Implement Technical Improvements

Translate investigation findings into concrete technical improvements: new detection rules in your SIEM, additional logging coverage, tighter network segmentation, improved access controls, or enhanced monitoring in the areas where visibility was lacking during the incident. Track these improvements as formal projects with owners and deadlines.

Management Briefing

Provide senior management and the board with a clear, non-technical summary of the incident: what happened, what the impact was, how it was handled, and what investments are needed to reduce future risk. Under NIS2, management bodies have a direct responsibility for cybersecurity governance — keeping them informed is not just good practice, it is a compliance requirement.

Common Mistakes During Incidents

Having responded to incidents across organizations of varying sizes and maturity levels, we consistently observe the same avoidable mistakes. Recognizing them in advance is the first step toward not repeating them.

• Panicking and shutting everything down — The reflexive urge to "pull the plug" on all systems destroys volatile evidence, disrupts business operations unnecessarily, and often does not stop an attacker who has already established multiple persistence mechanisms. Targeted, surgical containment is almost always more effective than a full shutdown.
• Not preserving evidence — Reimaging systems, clearing logs, or restarting servers before forensic collection eliminates the data needed to understand scope, satisfy regulators, and support law enforcement. You cannot investigate what you have destroyed.
• Communicating too early or too late — Issuing a public statement before you understand the scope often leads to corrections and retractions that erode trust. Waiting too long triggers regulatory penalties and media speculation that fills the vacuum with worst-case assumptions. Work with legal counsel and communications professionals to find the right timing.
• Trying to handle everything internally — Even organizations with mature security teams benefit from external expertise during significant incidents. External IR firms bring specialized tools, broader threat intelligence, and the objectivity that comes from not being emotionally invested in the compromised environment. Engaging external support is not an admission of failure — it is a professional response.
• Not involving legal counsel immediately — Legal counsel should be among the first people notified, not an afterthought. Early legal involvement protects privilege, ensures regulatory notification timelines are met, guides law enforcement engagement, and reduces the risk of statements or actions that create unnecessary liability.

The cost of a breach is largely determined not by the attacker's skill, but by the defender's preparation. Organizations with tested IR plans, external partnerships, and practiced teams consistently experience lower costs, shorter containment times, and less lasting damage.

How A.KHAT Can Help

A.KHAT provides incident response services to organizations across Austria and the EU. Our team brings offensive security expertise to defensive challenges — we understand how attackers operate because we simulate real-world attacks as part of our penetration testing practice.

Our incident response capabilities include:

• 24/7 Incident Response — When a breach occurs, time is the most critical variable. Our team is available around the clock to provide immediate remote triage and, where necessary, on-site response across Austria and the EU.
• Digital Forensic Analysis — Full-spectrum forensic investigation including memory analysis, disk forensics, network traffic analysis, malware reverse engineering, and timeline reconstruction. All evidence handling follows chain of custody best practices suitable for regulatory and legal proceedings.
• IR Readiness Assessment — We evaluate your current incident response capabilities, identify gaps, and help you build and test the plans, procedures, and team structures you need before an incident occurs.
• Tabletop Exercises — Realistic, scenario-based exercises that test your IR team's decision-making, communication, and technical response under simulated pressure. We tailor scenarios to your industry, threat landscape, and regulatory environment.
• Regulatory Compliance Support — Guidance on GDPR and NIS2 notification requirements, documentation preparation, and coordination with Austrian supervisory authorities and law enforcement.

Conclusion

A security breach is a high-pressure, high-stakes event that compresses weeks of decision-making into hours. The organizations that navigate it successfully are not the ones with the largest security budgets or the most sophisticated tools. They are the ones that prepared: that built their teams, documented their procedures, practiced their responses, and established the relationships and retainers they would need before the crisis arrived.

The six phases outlined in this guide — preparation, detection, containment, eradication, notification, and review — are not theoretical. They are the framework used by mature security organizations worldwide, adapted here for the European regulatory context that Austrian businesses operate within. Each phase builds on the one before it, and each is diminished when the preceding phases were neglected.

If your organization does not yet have a tested incident response plan, start building one today. If you have one but have never exercised it, schedule a tabletop exercise. If you lack the internal expertise to handle a significant incident, establish a relationship with an external IR provider now — not during the breach.

The question is not whether your organization will face a security incident. The question is whether you will be ready when it happens.