---
title: "Incident Response: How to Build a Plan That Works"
description: "A practical guide to incident response — what it involves, how to build an incident response plan, the phases of handling security incidents, regulatory requirements under NIS2, DORA, and ISO 27001, and how to communicate incidents to customers and regulators."
canonical: https://www.orbiqhq.com/glossary/incident-response
html: https://www.orbiqhq.com/glossary/incident-response
publisher: Orbiq GmbH
language: en
---
# Incident Response: How to Build a Plan That Works

A practical guide to incident response — what it involves, how to build an incident response plan, the phases of handling security incidents, regulatory requirements under NIS2, DORA, and ISO 27001, and how to communicate incidents to customers and regulators.


Incident response is the structured process an organisation uses to detect, contain, investigate, and recover from security incidents. Every organisation that handles data will eventually face an incident — whether a phishing compromise, a misconfigured cloud service, a ransomware attack, or an insider threat.

For B2B SaaS companies, incident response capability is both an operational necessity and a compliance requirement. Enterprise buyers expect documented incident response procedures in vendor assessments. Regulatory frameworks — GDPR, NIS2, DORA, ISO 27001 — mandate specific incident handling and notification processes. The difference between a managed incident and a crisis often comes down to preparation.

This guide covers how to build an incident response programme, the phases of handling incidents, regulatory notification requirements, and how to communicate incidents to customers.

---

## Incident Response Fundamentals

### What Constitutes a Security Incident

A security incident is any event that compromises or threatens the confidentiality, integrity, or availability of information systems or data. Examples include:

| Category | Examples |
|---|---|
| **Data breaches** | Unauthorised access to personal data, exfiltration of customer records |
| **Malware and ransomware** | Encryption of systems, cryptomining, backdoor installation |
| **Account compromise** | Stolen credentials, session hijacking, privilege escalation |
| **Denial of service** | Volumetric DDoS, application-layer attacks, resource exhaustion |
| **Insider threats** | Malicious data theft, accidental data exposure, policy violations |
| **Supply chain compromise** | Compromised third-party software, vulnerable dependencies |
| **Cloud misconfiguration** | Exposed storage buckets, overly permissive IAM, unencrypted data |

### Incident vs Event vs Vulnerability

| Term | Definition | Example |
|---|---|---|
| **Security event** | An observable occurrence in a system or network | Failed login attempt |
| **Security incident** | An event that compromises security or violates policy | Successful brute force leading to data access |
| **Vulnerability** | A weakness that could be exploited | Unpatched software, weak password policy |

Not every event is an incident, and not every vulnerability leads to one. Effective triage distinguishes between noise and genuine incidents that require response.

---

## The Incident Response Lifecycle

### NIST Framework (SP 800-61)

The NIST Computer Security Incident Handling Guide defines four phases:

**Phase 1: Preparation**

Preparation happens before incidents occur:

- Establish an Incident Response Team (IRT) with defined roles
- Document incident response procedures for common scenario types
- Deploy detection and monitoring tools (SIEM, EDR, network monitoring)
- Create communication templates for internal and external notifications
- Establish relationships with external parties (legal counsel, forensics providers, law enforcement, CERTs)
- Conduct tabletop exercises and simulations
- Ensure logging is comprehensive and tamper-resistant

**Phase 2: Detection and Analysis**

Identifying that an incident has occurred and understanding its scope:

- Monitor security alerts from SIEM, IDS/IPS, EDR, and cloud security tools
- Analyse anomalies in logs, network traffic, and user behaviour
- Correlate events across multiple data sources
- Determine incident severity and classify according to your taxonomy
- Document initial findings and timeline
- Notify relevant stakeholders according to escalation procedures

**Phase 3: Containment, Eradication, and Recovery**

Stopping the incident, removing the threat, and restoring operations:

- **Short-term containment**: Isolate affected systems to prevent spread (network segmentation, account suspension, firewall rules)
- **Evidence preservation**: Capture forensic images, preserve logs, maintain chain of custody
- **Long-term containment**: Apply temporary fixes to allow continued operations while preparing full remediation
- **Eradication**: Remove malware, close attack vectors, patch vulnerabilities, reset compromised credentials
- **Recovery**: Restore systems from clean backups, verify integrity, monitor for re-infection
- **Validation**: Confirm the threat is eliminated and systems are operating normally

**Phase 4: Post-Incident Activity**

Learning from the incident to improve future response:

- Conduct a post-incident review (blameless post-mortem)
- Document the complete incident timeline
- Identify root causes and contributing factors
- Determine what worked well and what needs improvement
- Update incident response procedures based on lessons learned
- Track remediation actions to completion
- Share relevant findings (anonymised if needed) with industry peers

---

## Building an Incident Response Plan

### Incident Classification

Define clear severity levels with objective criteria:

| Severity | Criteria | Response Time | Examples |
|---|---|---|---|
| **Critical (P1)** | Active data breach, system-wide outage, ransomware | Immediate (< 1 hour) | Customer data exfiltrated, production encrypted |
| **High (P2)** | Significant compromise, partial service impact | < 4 hours | Account takeover, malware on server, targeted phishing success |
| **Medium (P3)** | Contained compromise, limited impact | < 24 hours | Single workstation malware, policy violation, suspicious activity |
| **Low (P4)** | Minor event, no confirmed compromise | < 72 hours | Phishing email reported (no click), port scan detected |

### Incident Response Team Roles

| Role | Responsibility |
|---|---|
| **Incident Commander** | Overall coordination, decision-making, escalation |
| **Technical Lead** | Technical investigation, containment, and remediation |
| **Communications Lead** | Internal and external communications, media handling |
| **Legal Counsel** | Regulatory notification requirements, evidence preservation, liability |
| **Executive Sponsor** | Business decisions, resource allocation, stakeholder management |
| **Forensics Analyst** | Evidence collection, malware analysis, root cause determination |
| **Operations** | System restoration, backup management, service continuity |

### Communication Plan

**Internal communication:**
- Escalation matrix with contact details (phone, not just email)
- War room or incident channel setup procedures
- Status update cadence (every 2-4 hours during active incidents)
- Need-to-know classification for sensitive incident details

**External communication:**
- Regulatory notification templates (GDPR 72-hour, NIS2 24-hour, DORA 4-hour)
- Customer notification templates (affected vs potentially affected)
- Media holding statement and spokesperson designation
- Law enforcement engagement criteria and procedures

---

## Regulatory Incident Reporting Requirements

### GDPR (Articles 33-34)

| Requirement | Detail |
|---|---|
| **Who reports** | Data controller to supervisory authority |
| **Deadline** | Within 72 hours of becoming aware |
| **Threshold** | Breaches likely to result in risk to individuals' rights |
| **Individual notification** | Required if high risk to individuals (Article 34) |
| **Processor obligation** | Notify controller without undue delay |

### NIS2 (Article 23)

| Requirement | Detail |
|---|---|
| **Early warning** | Within 24 hours of becoming aware of a significant incident |
| **Incident notification** | Within 72 hours with initial assessment |
| **Intermediate reports** | Upon request from CSIRT or competent authority |
| **Final report** | Within one month of incident notification |
| **Threshold** | Significant operational disruption or financial loss |

### DORA (Articles 17-19)

| Requirement | Detail |
|---|---|
| **Initial notification** | Within 4 hours of classification (or 24 hours of detection) |
| **Intermediate report** | Within 72 hours of classification |
| **Final report** | Within one month of last intermediate report |
| **Classification criteria** | Affected clients, duration, geographical spread, data losses |
| **Voluntary reporting** | Significant cyber threats may be reported voluntarily |

### ISO 27001

| Control | Requirement |
|---|---|
| **A.5.24** | Establish incident management planning and preparation |
| **A.5.25** | Assess and decide on security events |
| **A.5.26** | Respond according to documented procedures |
| **A.5.27** | Learn from incidents to improve security |
| **A.5.28** | Collect and preserve evidence properly |
| **A.6.8** | Provide a mechanism for reporting security events |

---

## Incident Response for B2B SaaS Companies

### SaaS-Specific Considerations

**Multi-tenant impact**: An incident in a multi-tenant platform can affect all customers simultaneously. Your plan must address tenant isolation, cross-tenant impact assessment, and per-customer notification.

**Shared responsibility**: Cloud infrastructure incidents may involve your cloud provider (AWS, Azure, GCP). Clarify responsibilities and escalation paths with providers in advance.

**Data processor obligations**: As a data processor under GDPR, you must notify your customers (controllers) without undue delay so they can meet their own 72-hour notification deadline to supervisory authorities.

**API and integration security**: Incidents involving APIs or integrations may affect downstream systems. Identify dependencies and notification obligations for connected services.

**Continuous deployment**: Rapid release cycles can introduce vulnerabilities. Your incident response plan should cover incidents arising from deployments (rollback procedures, feature flag kill switches).

### Customer Communication During Incidents

Best practices for B2B incident communication:

1. **Notify promptly** — Direct communication to affected customers, not just a status page update
2. **Be factual** — State what you know, what you do not know, and what you are investigating
3. **Avoid speculation** — Do not guess about attribution, scope, or impact before investigation confirms it
4. **Provide actionable guidance** — Tell customers what they need to do (rotate credentials, review access logs, notify their own users)
5. **Give regular updates** — Set expectations for update frequency and honour them
6. **Publish a post-incident report** — Timeline, root cause, remediation actions, and improvements planned

---

## Testing Your Incident Response

### Tabletop Exercises

Scenario-based discussions where the IRT walks through hypothetical incidents:

- No actual systems are affected
- Focus on decision-making, communication, and procedure validation
- Typical duration: 2-4 hours
- Recommended frequency: quarterly
- Include scenarios relevant to your technology and threat landscape

### Functional Exercises

Hands-on exercises that test specific technical capabilities:

- Restore from backup within recovery time objectives
- Isolate a compromised system from the network
- Conduct forensic analysis of a simulated compromise
- Execute communication procedures (internal and external)
- Recommended frequency: twice annually

### Full-Scale Simulations

End-to-end exercises that test the complete incident response process:

- Simulated attack with real (but controlled) technical activity
- Tests detection capabilities — can your team identify the incident?
- Includes executive communication and external notification procedures
- Recommended frequency: annually
- Consider engaging a red team to increase realism

---

## Common Incident Response Mistakes

### No Plan Until the First Incident

Building incident response procedures during an active incident leads to chaos. The time to plan is before the incident — not during. Even a basic documented plan dramatically improves response effectiveness.

### Insufficient Logging

You cannot investigate what you did not log. Ensure comprehensive logging across applications, infrastructure, authentication systems, and network boundaries. Retain logs for at least 12 months (many regulations require longer).

### Destroying Evidence

Well-meaning IT staff who immediately reimage compromised systems destroy forensic evidence needed for investigation and regulatory reporting. Train staff on evidence preservation before remediation.

### Communication Failures

Internal communication breakdowns during incidents cause duplicate effort, conflicting actions, and missed notifications. External communication failures — delayed, inconsistent, or misleading customer notifications — destroy trust faster than the incident itself.

### Skipping Post-Incident Reviews

Every incident, even minor ones, offers learning opportunities. Organisations that skip post-incident reviews repeat the same mistakes. Make post-incident reviews mandatory and blameless.

---

## How Orbiq Supports Incident Response

- **Trust Center:** Publish your incident response posture, post-incident reports, and remediation status for customer transparency
- **Continuous Monitoring:** Track incident response controls across ISO 27001, NIS2, and DORA requirements
- **Evidence Management:** Centralize incident records, post-mortem documentation, and exercise reports mapped to compliance frameworks
- **AI-Powered Questionnaires:** Auto-respond to incident response questions in security questionnaires from your documented procedures

---

## Further Reading

- [GDPR Compliance](/glossary/gdpr-compliance) — Data breach notification requirements under GDPR
- [Information Security Policy](/glossary/information-security-policy) — The policy framework governing incident response procedures
- [Compliance Automation](/glossary/compliance-automation) — Automating incident response evidence and reporting
- [Penetration Testing](/glossary/penetration-testing) — Proactive testing that prevents incidents

---