Skip to main content

Incident Response Plan

Last updated: April 2026

1. Purpose

This plan establishes procedures for identifying, responding to, and recovering from security incidents affecting FeatureSignals and its customers.

2. Definitions

TermDefinition
Security IncidentAny event that compromises the confidentiality, integrity, or availability of FeatureSignals systems or customer data
Data BreachUnauthorized access to or disclosure of customer personal data
Severity 1 (Critical)Data breach, complete service outage, active exploitation
Severity 2 (High)Partial service degradation, suspected breach, vulnerable system
Severity 3 (Medium)Minor vulnerability, policy violation, anomalous activity
Severity 4 (Low)Informational, proactive detection, no immediate impact

3. Incident Response Team

RoleResponsibility
Incident CommanderOverall coordination, stakeholder communication
Technical LeadInvestigation, containment, remediation
Communications LeadCustomer notification, public statements
Legal/ComplianceRegulatory notification, legal obligations
Executive SponsorEscalation, resource allocation

4. Response Phases

Phase 1: Detection and Identification (0–15 minutes)

  1. Alert received via monitoring, audit log analysis, or report
  2. On-call engineer performs initial triage
  3. Severity level assigned
  4. Incident Commander notified for Sev 1/2

Detection sources:

  • Automated monitoring and alerting
  • Audit log anomaly detection (failed login spikes, unauthorized access attempts)
  • Rate limiting triggers
  • Customer reports
  • Vulnerability scan findings

Phase 2: Containment (15 minutes – 1 hour for Sev 1)

Immediate containment:

  • Revoke compromised credentials (API keys, tokens)
  • Enable IP allowlist restrictions
  • Isolate affected systems
  • Preserve evidence (logs, snapshots)

Short-term containment:

  • Deploy targeted patches
  • Increase monitoring
  • Restrict access to affected areas

Phase 3: Eradication (1–24 hours for Sev 1)

  1. Identify root cause
  2. Remove threat vectors
  3. Patch vulnerabilities
  4. Verify all indicators of compromise addressed

Phase 4: Recovery (24–72 hours for Sev 1)

  1. Restore from clean backups if needed
  2. Gradual service restoration with increased monitoring
  3. Verify system integrity
  4. Confirm no persistent threat

Phase 5: Post-Incident Review (within 5 business days)

  1. Timeline reconstruction
  2. Root cause analysis
  3. Lessons learned documentation
  4. Control improvements identified
  5. Post-mortem report published internally

5. Communication Protocol

Internal Communication

SeverityNotification TimelineAudience
Sev 1ImmediateFull incident team, executive team
Sev 2Within 30 minutesIncident team, engineering leadership
Sev 3Within 4 hoursEngineering team
Sev 4Next business dayRelevant team members

Customer Notification

EventTimelineMethod
Data breach confirmedWithin 72 hours (GDPR)Email + dashboard banner
Service disruptionWithin 1 hourStatus page
Vulnerability disclosureAfter patch deployedSecurity advisory email

Regulatory Notification

RegulationRequirement
GDPRNotify supervisory authority within 72 hours of breach awareness
CCPANotify affected California residents "in the most expedient time possible"
HIPAA (if applicable)Notify HHS within 60 days; affected individuals without unreasonable delay

6. Evidence Preservation

During any incident:

  • Do not modify or delete audit logs
  • Export relevant logs immediately: GET /v1/organizations/{orgID}/audit/export
  • Take database snapshots before any remediation changes
  • Document all actions taken with timestamps

7. Testing

This plan is tested annually via tabletop exercises and periodic red team engagements.

ExerciseFrequencyParticipants
Tabletop exerciseSemi-annualFull incident team
Red team assessmentAnnualExternal security firm
Backup restore testQuarterlyEngineering team
Communication drillAnnualFull incident team + exec