Incident Management & Response Policy

Purpose

This policy establishes procedures for detecting, responding to, and recovering from security incidents affecting the Close-Rate platform. The goal is to minimize damage, reduce recovery time, communicate transparently with affected parties, and prevent recurrence.

Incident Classification

The Incident Lead gives each incident one of four severity levels:

• Severity 1 (Critical): Confirmed data breach, unauthorized access to customer data, complete service outage, compromised credentials.

• Severity 2 (High): Partial service degradation affecting customers, suspected unauthorized access, failed authentication systems.

• Severity 3 (Medium): Single-customer impact, integration failures, non-critical service degradation.

• Severity 4 (Low): Minor issues, cosmetic bugs, non-impacting anomalies.

Incident Response Team

• Incident Lead: Ben Paulson (Co-Founder and CTO) — responsible for technical investigation, containment, and remediation, and assigns the severity level

• Customer Communication: Brian Balboni (Co-Founder and CEO) — responsible for communication with customers when an incident may affect them or their data

Contact: client-services@close-rate.com for all incident reports.

Response Procedures

1. Detection & Triage

• Incidents may be detected via application logs (AWS CloudWatch), customer reports, automated alerts, or third-party notifications

• The person who identifies the incident records initial details: what happened, when, what systems are affected

• The Incident Lead assigns a severity level and brings in the CEO when an incident may affect customers or their data

2. Containment

• Isolate affected systems to prevent further damage

• Revoke compromised credentials immediately (API keys, OAuth tokens, access keys)

• If customer data is at risk, disable affected features or endpoints

• Preserve logs and evidence for investigation

3. Investigation

• Determine root cause and full scope of the incident

• Identify which customers, data, and systems were affected

• Review our application logs in AWS CloudWatch (kept for 90 days). We do not keep a log of who viewed which customer record

• Document timeline of events

4. Remediation

• Apply fixes to resolve the root cause

• Release fixes through our deploy workflow, which requires our automated checks to pass on the exact commit

• Verify the fix in production

• Restore any affected services to normal operation

5. Recovery & Verification

• Confirm all systems are operating normally

• Monitor for any recurrence over 24-48 hours

• Restore database records from backups if necessary (seven days of point-in-time recovery). Transcript files in S3 are not versioned, so a deleted file cannot be restored from S3

Communication

• When an incident affects a customer's data, we tell that customer

• Our notice says what happened, what data was affected, what we are doing about it, and what the customer should do

• If legally required (e.g., under GDPR breach notification), relevant authorities are notified within 72 hours

Post-Incident Review

After an incident that affects customers, we write down:

• What happened, from detection to resolution

• What we found about its cause and contributing factors

• What we changed to prevent it from happening again

• The follow-up work that is still open