# Data Breach Response Plan

**SnapSell AI**
**Data Controller:** Nova AI Ventures
**Effective Date:** January 2025
**Last Updated:** January 2025
**Classification:** Internal Use

---

## 1. Introduction

This Data Breach Response Plan establishes procedures for detecting, responding to, and reporting personal data breaches in compliance with GDPR Articles 33 and 34.

**Key Requirements:**
- **72 hours** - Notify supervisory authority (PUODO) if breach poses risk
- **Without undue delay** - Notify affected individuals if high risk
- **Documentation** - Record all breaches regardless of notification

---

## 2. Definitions

| Term | Definition |
|------|------------|
| **Personal Data Breach** | Security incident leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data |
| **Confidentiality Breach** | Unauthorized or accidental disclosure of or access to data |
| **Integrity Breach** | Unauthorized or accidental alteration of data |
| **Availability Breach** | Accidental or unauthorized loss of access to or destruction of data |

---

## 3. Breach Response Team

### 3.1 Core Team Roles

| Role | Responsibilities | Contact |
|------|------------------|---------|
| **Incident Commander** | Overall coordination, decisions | [Name/Contact] |
| **DPO/Privacy Lead** | Regulatory notification, rights | privacy@snap-sell.app |
| **Technical Lead** | Investigation, containment | [Name/Contact] |
| **Communications Lead** | User notifications, PR | [Name/Contact] |
| **Legal Counsel** | Legal advice, liability | [External counsel] |

### 3.2 Escalation Contacts

| Escalation Level | Contact | When to Escalate |
|------------------|---------|------------------|
| Level 1 | Technical Lead | All potential incidents |
| Level 2 | Incident Commander | Confirmed breach |
| Level 3 | Executive Management | High-risk breach |
| External | Legal Counsel | Any breach notification |

---

## 4. Breach Response Phases

### Phase Overview

```
Detection → Assessment → Containment → Investigation → Notification → Recovery → Review
    │           │            │             │              │            │         │
   <1hr       <4hrs        <8hrs        <24hrs         <72hrs       <7days    <30days
```

---

## 5. Phase 1: Detection (< 1 hour)

### 5.1 Detection Sources

| Source | Examples |
|--------|----------|
| **Automated Alerts** | Intrusion detection, anomaly monitoring |
| **Employee Report** | Staff notices suspicious activity |
| **User Report** | Customer reports unauthorized access |
| **Subprocessor** | Google, Stripe notifies of incident |
| **External** | Security researcher, law enforcement |

### 5.2 Initial Triage

**Immediate Questions:**
1. What data may be affected?
2. How many individuals may be affected?
3. Is the incident ongoing?
4. Who discovered it and when?

### 5.3 Incident Logging

Create breach log entry immediately:

```
BREACH LOG ENTRY
================
Log ID: BR-[YYYY]-[NNN]
Detected: [Date/Time]
Detected By: [Name/System]
Initial Description: [Brief description]
Potential Scope: [Data types, # affected]
Initial Severity: [Low/Medium/High/Critical]
```

---

## 6. Phase 2: Assessment (< 4 hours)

### 6.1 Severity Classification

| Severity | Criteria | Response |
|----------|----------|----------|
| **CRITICAL** | Large-scale data breach, sensitive data, ongoing | All hands, immediate escalation |
| **HIGH** | Significant data exposure, many users affected | Full team activation |
| **MEDIUM** | Limited data exposure, contained | Core team response |
| **LOW** | Minor incident, no actual data exposure | Investigation and documentation |

### 6.2 Risk Assessment Matrix

**Likelihood of harm:**
- High: Data accessible to malicious actors
- Medium: Data potentially accessible
- Low: Theoretical exposure only

**Severity of harm:**
- High: Financial data, authentication credentials
- Medium: Personal identifiers, communications
- Low: Non-sensitive operational data

### 6.3 Assessment Checklist

- [ ] What types of personal data are affected?
- [ ] How many data subjects are affected?
- [ ] What is the nature of the breach (confidentiality/integrity/availability)?
- [ ] Is the breach contained or ongoing?
- [ ] Who has had unauthorized access?
- [ ] What is the likelihood of harm to individuals?
- [ ] What is the severity of potential harm?

### 6.4 Data Categories Impact

| Data Category | Risk Level | Notification Trigger |
|---------------|------------|----------------------|
| Payment data | HIGH | Yes - financial harm |
| Authentication credentials | HIGH | Yes - account compromise |
| Email + Name | MEDIUM | Likely - identity risk |
| Photos only | LOW | Case-by-case |
| Usage data only | LOW | Unlikely |

---

## 7. Phase 3: Containment (< 8 hours)

### 7.1 Immediate Containment Actions

| Action | When |
|--------|------|
| Isolate affected systems | Ongoing breach |
| Revoke compromised credentials | Credential leak |
| Block malicious access | Unauthorized access detected |
| Preserve evidence | All cases |
| Activate backup systems | Service disruption |

### 7.2 Containment Checklist

- [ ] Identify all affected systems
- [ ] Isolate compromised systems from network
- [ ] Preserve logs and forensic evidence
- [ ] Change compromised credentials
- [ ] Block unauthorized access paths
- [ ] Verify containment effectiveness
- [ ] Document all actions taken

### 7.3 Evidence Preservation

**Preserve:**
- System logs
- Access logs
- Network traffic captures
- Affected database snapshots
- Communication records

**Do NOT:**
- Delete logs
- Modify affected systems
- Reboot without capturing memory
- Contact suspected attackers

---

## 8. Phase 4: Investigation (< 24 hours)

### 8.1 Investigation Objectives

1. **Root cause** - How did the breach occur?
2. **Timeline** - When did it start and end?
3. **Scope** - What data was actually accessed?
4. **Attribution** - Who was responsible?
5. **Impact** - What harm may result?

### 8.2 Investigation Steps

1. Review access logs for suspicious activity
2. Analyze network traffic
3. Interview relevant personnel
4. Examine affected systems
5. Determine full scope of data exposure
6. Identify vulnerability exploited
7. Document findings

### 8.3 Investigation Log

```
INVESTIGATION LOG
=================
Breach ID: BR-[YYYY]-[NNN]
Lead Investigator: [Name]

Timeline of Events:
[Date/Time] - [Event description]
[Date/Time] - [Event description]

Findings:
- Root Cause: [Description]
- Data Affected: [Types and volume]
- Individuals Affected: [Number]
- Attack Vector: [How access was gained]

Evidence Collected:
- [Log file name/location]
- [Screenshot/capture]
```

---

## 9. Phase 5: Notification (< 72 hours)

### 9.1 Notification Decision Tree

```
                    Is there a breach?
                          │
                         YES
                          │
            Does it involve personal data?
                          │
                         YES
                          │
        Is there a risk to individuals' rights?
                    │            │
                   YES           NO
                    │            │
              Notify PUODO    Document only
              within 72hrs    (no notification)
                    │
        Is there HIGH risk to individuals?
                    │            │
                   YES           NO
                    │            │
            Notify affected    PUODO only
             individuals
```

### 9.2 Supervisory Authority Notification

**Authority:** PUODO (Polish Data Protection Office)
**Deadline:** 72 hours from awareness
**Method:** Online form at uodo.gov.pl

**Required Information (Article 33(3)):**
1. Nature of breach (categories, approximate numbers)
2. DPO/contact point details
3. Likely consequences of breach
4. Measures taken/proposed to address breach

### 9.3 PUODO Notification Template

```
DATA BREACH NOTIFICATION TO SUPERVISORY AUTHORITY
=================================================

1. CONTROLLER IDENTIFICATION
   Organization: Nova AI Ventures (SnapSell AI)
   Registration: Poland
   Contact: privacy@snap-sell.app

2. BREACH DESCRIPTION
   Date of breach: [Date]
   Date of discovery: [Date]
   Nature: [Confidentiality/Integrity/Availability]
   Description: [Brief description]

3. DATA AND SUBJECTS AFFECTED
   Categories of data: [List]
   Approximate number of records: [Number]
   Categories of data subjects: [List]
   Approximate number of individuals: [Number]

4. CONSEQUENCES
   Likely consequences: [Description of potential harms]

5. MEASURES TAKEN
   Containment: [Actions taken]
   Mitigation: [Actions to reduce harm]
   Prevention: [Actions to prevent recurrence]

6. CONTACT
   DPO/Contact: privacy@snap-sell.app
```

### 9.4 Individual Notification

**Required when:** High risk to rights and freedoms

**Method:** Direct communication (email preferred)

**Content (Article 34(2)):**
- Clear description of breach
- DPO/contact details
- Likely consequences
- Measures taken
- Advice for protection

### 9.5 Individual Notification Template

```
Subject: Important Security Notice from SnapSell AI

Dear [User Name],

We are writing to inform you of a data security incident that may have
affected your SnapSell AI account.

WHAT HAPPENED
[Clear, plain-language description of the incident]

WHAT DATA WAS AFFECTED
[List of data types: e.g., email address, name, photos]

WHEN DID THIS HAPPEN
[Date range of the incident]

WHAT WE ARE DOING
- [Containment action]
- [Investigation status]
- [Remediation steps]

WHAT YOU CAN DO
- [Specific protective action, e.g., change password]
- [Monitor for suspicious activity]
- [Report concerns to support]

We sincerely apologize for this incident and any concern it may cause.

For questions, contact us at: privacy@snap-sell.app

Sincerely,
The SnapSell AI Team
```

### 9.6 Notification Exemptions

Individual notification may not be required if:
- Data was encrypted (and key not compromised)
- Subsequent measures eliminate risk
- Disproportionate effort (use public communication instead)

---

## 10. Phase 6: Recovery (< 7 days)

### 10.1 Recovery Actions

| Action | Owner | Timeline |
|--------|-------|----------|
| Patch vulnerability | Technical Lead | Immediate |
| Restore from backup (if needed) | Technical Lead | As needed |
| Reset affected credentials | Technical Lead | Immediate |
| Enhance monitoring | Technical Lead | 24 hours |
| User support response | Support Team | Ongoing |
| Communication updates | Communications | As needed |

### 10.2 Recovery Checklist

- [ ] Vulnerability patched/fixed
- [ ] Systems restored to normal operation
- [ ] Enhanced monitoring in place
- [ ] Affected users supported
- [ ] Follow-up communications sent
- [ ] PUODO updated (if required)

---

## 11. Phase 7: Post-Incident Review (< 30 days)

### 11.1 Lessons Learned Meeting

**Participants:** All breach response team members

**Agenda:**
1. Incident timeline review
2. Response effectiveness
3. Communication review
4. Root cause analysis
5. Control improvements
6. Process improvements

### 11.2 Post-Incident Report

```
POST-INCIDENT REPORT
====================
Breach ID: BR-[YYYY]-[NNN]
Date: [Date]

EXECUTIVE SUMMARY
[Brief overview of incident and response]

TIMELINE
[Chronological events from detection to closure]

ROOT CAUSE ANALYSIS
[Technical and procedural factors]

IMPACT ASSESSMENT
- Data subjects affected: [Number]
- Data types exposed: [List]
- Business impact: [Description]
- Regulatory notifications: [Yes/No, details]

RESPONSE EVALUATION
- What worked well: [List]
- What could improve: [List]

REMEDIATION ACTIONS
| Action | Owner | Deadline | Status |
|--------|-------|----------|--------|
| [Action] | [Name] | [Date] | [Status] |

PREVENTION MEASURES
[Changes to prevent similar incidents]
```

### 11.3 Documentation Updates

After each incident, review and update:
- [ ] This response plan
- [ ] Security policies
- [ ] Training materials
- [ ] Detection mechanisms
- [ ] Vendor agreements

---

## 12. Breach Register

All breaches must be logged regardless of notification requirement:

| Field | Required |
|-------|----------|
| Breach ID | Yes |
| Date discovered | Yes |
| Date occurred | Yes |
| Description | Yes |
| Data categories | Yes |
| Number affected | Yes |
| Consequences | Yes |
| Measures taken | Yes |
| PUODO notified | Yes/No |
| Individuals notified | Yes/No |
| Documentation location | Yes |

**Retention:** Breach records kept for 5 years

---

## 13. Training and Testing

### 13.1 Training Requirements

| Audience | Training | Frequency |
|----------|----------|-----------|
| All employees | Breach awareness | Annual |
| Response team | Response procedures | Bi-annual |
| Technical staff | Forensics basics | Annual |

### 13.2 Testing Schedule

| Test Type | Frequency | Last Test | Next Test |
|-----------|-----------|-----------|-----------|
| Tabletop exercise | Annual | [Date] | [Date] |
| Notification drill | Annual | [Date] | [Date] |
| Technical recovery | Annual | [Date] | [Date] |

---

## 14. Subprocessor Breach Handling

### 14.1 Subprocessor Obligations

Per DPA requirements, subprocessors must:
- Notify us within 24 hours of discovering a breach
- Provide all information needed for our notification
- Cooperate with investigation

### 14.2 Subprocessor Contact

| Subprocessor | Security Contact | Notification SLA |
|--------------|------------------|------------------|
| Google Cloud | Via support console | 24 hours |
| Stripe | security@stripe.com | 24 hours |
| Firebase | Via support console | 24 hours |

---

## 15. Contact Information

### Internal

| Role | Email | Phone |
|------|-------|-------|
| DPO/Privacy Lead | privacy@snap-sell.app | [Phone] |
| Technical Lead | [Email] | [Phone] |
| Incident Commander | [Email] | [Phone] |

### External

| Contact | Details |
|---------|---------|
| **PUODO** | ul. Stawki 2, 00-193 Warsaw; https://uodo.gov.pl |
| **Legal Counsel** | [Firm name and contact] |
| **Cyber Insurance** | [If applicable] |
| **Law Enforcement** | Local police (if criminal) |

---

## 16. Document Control

| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | January 2025 | Nova AI Ventures | Initial plan |

---

*This Data Breach Response Plan fulfills GDPR Articles 33 and 34 requirements.*