Incident Response: What It Is, How to Build a Plan, and What B2B Companies Must Know

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 — Data breach notification requirements under GDPR
• Information Security Policy — The policy framework governing incident response procedures
• Compliance Automation — Automating incident response evidence and reporting
• Penetration Testing — Proactive testing that prevents incidents

---

This guide is maintained by the Orbiq team. Last updated: March 2026.