Security

Incident Response Plan

Our formal, documented process for identifying, containing, eradicating, and recovering from security incidents — aligned with NIST SP 800-61 Rev.2, SOC 2 CC7, and ISO 27001 Annex A.5.24–A.5.28.

Last updated: February 23, 2026  |  Version 1.0

Table of Contents

1. Purpose & Scope 2. Incident Definitions 3. Roles & Responsibilities 4. Severity Classification 5. Response Phases 6. Communication Plan 7. Escalation Matrix 8. Post-Incident Review 9. Plan Testing & Updates 10. Regulatory Notifications

1. Purpose & Scope

This Incident Response Plan (IRP) establishes a structured approach for FindTheBreach to prepare for, detect, contain, eradicate, and recover from information security incidents affecting our platform, customer data, or operational infrastructure.

Scope: This plan covers all security incidents involving:

  • FindTheBreach platform infrastructure (API, database, scanners, web servers)
  • Customer data (scan results, vulnerability findings, account information)
  • Third-party integrations (webhooks, API keys, SSO providers)
  • Employee credentials, workstations, and development environments
  • Physical security of data center and hosting infrastructure

Compliance Alignment: NIST SP 800-61 Rev.2, SOC 2 CC7 (System Operations), ISO 27001 A.5.24–A.5.28, GDPR Article 33/34, HIPAA §164.308(a)(6), DORA Article 17.

2. Incident Definitions

Security Event: Any observable occurrence in a system or network that may affect the confidentiality, integrity, or availability of information.

Security Incident: A security event that has been confirmed as a violation or imminent threat of violation of security policies, acceptable use policies, or standard security practices.

Data Breach: A security incident in which sensitive, protected, or confidential data is accessed, disclosed, or acquired by an unauthorized party.

Examples of incidents include: unauthorized access to systems or data, malware infection, denial of service attacks, data exfiltration, compromised credentials, vulnerability exploitation, social engineering attacks, insider threats, and physical security breaches.

3. Roles & Responsibilities

🔴 Incident Commander (IC)

Overall authority during an incident. Makes containment/eradication decisions. Coordinates cross-functional response. Reports to executive leadership. Designated: CTO or senior engineering lead.

🟡 Security Response Team (SRT)

Performs technical investigation, evidence collection, containment actions, and forensic analysis. Implements remediation. Designated: Security engineers and DevOps team.

🔵 Communications Lead

Manages internal and external communications, customer notifications, regulatory filings, and status page updates. Designated: Head of Customer Success or CEO.

🟢 Legal Advisor

Advises on regulatory notification requirements (GDPR 72hr, HIPAA 60-day, state breach laws). Reviews customer communications. Engages outside counsel as needed.

4. Severity Classification

Severity Definition Response Time Example
P1 — Critical Active data breach, complete service outage, or active exploitation 15 minutes Customer data exfiltration, RCE exploit in production
P2 — High Confirmed unauthorized access, significant vulnerability exploited, partial outage 1 hour Unauthorized admin access, SQL injection confirmed
P3 — Medium Suspicious activity, potential compromise, vulnerability discovered 4 hours Unusual login patterns, failed brute-force attempts
P4 — Low Minor policy violation, informational security event 24 hours Phishing attempt reported, minor misconfiguration

5. Response Phases

Phase 1: Preparation

  • Maintain this IRP with annual reviews and updates after significant incidents
  • Conduct tabletop exercises quarterly and full simulations annually
  • Maintain incident response tooling: forensic images, network capture, log aggregation
  • Ensure all team members have incident response training and access to this plan
  • Maintain relationships with external forensic firms and law enforcement contacts

Phase 2: Detection & Analysis

  • Monitor infrastructure logs, application logs, and security alerts 24/7
  • Validate alerts: confirm the incident is real, determine scope and impact
  • Classify severity using the matrix above
  • Begin evidence preservation: capture logs, memory dumps, network traffic as appropriate
  • Document: who reported, when, what systems affected, initial indicators of compromise (IoCs)

Phase 3: Containment

  • Short-term containment: Isolate affected systems, block malicious IPs, revoke compromised credentials, enable WAF rules
  • Long-term containment: Apply temporary patches, redirect traffic, enable enhanced monitoring
  • Preserve forensic evidence before containment actions that may alter data
  • For data breaches: immediately revoke all potentially compromised API keys, JWT tokens, and sessions

Phase 4: Eradication

  • Identify and remove root cause: patch vulnerabilities, remove malware, close attack vectors
  • Harden affected systems: update configurations, rotate all potentially compromised secrets
  • Scan for persistence mechanisms: backdoors, unauthorized accounts, scheduled tasks
  • Verify eradication through re-scanning with FindTheBreach platform and manual review

Phase 5: Recovery

  • Restore systems from verified clean backups or rebuild from infrastructure-as-code
  • Gradually return systems to production with enhanced monitoring
  • Monitor for signs of re-compromise for a minimum of 30 days post-recovery
  • Confirm normal operations and update status page

Phase 6: Lessons Learned

  • Conduct post-incident review within 5 business days of resolution
  • Document: timeline, root cause, impact, response effectiveness, improvements needed
  • Update this IRP, runbooks, and detection rules based on findings
  • Share anonymized lessons with the team (and customers if applicable)

6. Communication Plan

Internal Communication

  • P1/P2: Immediate notification to all SRT members via secure channel (Signal/encrypted Slack). Incident Commander establishes dedicated war room.
  • P3/P4: Notification to SRT lead via standard channels. Status updates during business hours.
  • All incident communications must use the dedicated incident channel — never personal email or public Slack.

Customer Communication

  • Data breach affecting customer data: Notify affected customers within 48 hours of confirmation. Include: what happened, what data was affected, what we're doing, what they should do.
  • Service disruption: Update status page within 15 minutes of detection. Post updates every 30 minutes during active incidents.
  • Enterprise customers with BAAs or DPAs receive direct communication from their account manager.

7. Escalation Matrix

Timeframe P1 P2 P3/P4
+0 min SRT + IC activated SRT lead notified SRT member assigned
+30 min CEO/CTO briefed IC engaged Investigation begins
+1 hour Legal advisor engaged, status page updated CEO briefed —
+4 hours External forensics if needed Status page updated Resolution or escalation
+24 hours Board notified if data breach confirmed Post-containment review Close or escalate

8. Post-Incident Review

A blameless post-incident review (PIR) is conducted within 5 business days of incident resolution. The review must address:

  • Timeline: Complete chronology from detection to resolution
  • Root Cause Analysis: Using the "5 Whys" or fishbone methodology
  • Impact Assessment: Systems affected, data exposed, customers impacted, financial impact
  • Response Effectiveness: What worked well, what didn't, response time vs SLA
  • Action Items: Specific improvements with owners and deadlines
  • Detection Gap Analysis: Could we have detected this earlier? What monitoring should be added?

PIR reports are stored for a minimum of 3 years and made available to auditors upon request (SOC 2, ISO 27001).

9. Plan Testing & Updates

  • Tabletop Exercises: Quarterly scenario-based discussions with the SRT to walk through hypothetical incidents
  • Full Simulation: Annual full-scale incident simulation including communication and escalation procedures
  • Plan Review: This IRP is reviewed and updated at least annually, after every P1/P2 incident, and after significant infrastructure changes
  • Contact Verification: Quarterly verification that all escalation contacts are current and reachable

10. Regulatory Notification Requirements

Regulation Notification Deadline Notify
GDPR (EU) 72 hours Supervisory authority + affected data subjects (if high risk)
DORA (EU Financial) 4 hours (initial), 72 hours (detailed) Competent authority
HIPAA (US Healthcare) 60 days (individual), 60 days (HHS) Affected individuals + HHS Secretary + media (if >500 individuals)
US State Laws 30–90 days (varies by state) State AG + affected residents (requirements vary)
NIS2 (EU) 24 hours (early warning), 72 hours (detailed) CSIRT or competent authority
PIPEDA (Canada) As soon as feasible OPC + affected individuals (if real risk of significant harm)

📋 Incident Communication Runbooks

Detailed step-by-step response procedures for specific incident types including data breaches, unauthorized access, DDoS attacks, credential compromise, and third-party vendor incidents.

View Runbooks

Report a Security Incident

If you discover a security vulnerability or incident affecting FindTheBreach, contact us immediately:

security@findthebreach.com Responsible Disclosure Program