# Incident Response Runbook — Apache-3 Inc.

**Document version:** 1.0
**Effective date:** 2026-05-20
**Next review:** 2026-11-20

This runbook documents Apache-3's process for detecting, responding to, and recovering from security incidents. It aligns with NIST SP 800-61 Rev. 3 (Computer Security Incident Handling Guide).

## Definitions

**Event** — any observable occurrence in a system (login, file access, log entry).

**Incident** — an event (or set of events) that violates Apache-3's security policies, threatens Customer Data, or threatens Apache-3 operations.

**Breach** — an incident confirmed to involve unauthorized access to, or disclosure of, Customer Data or confidential information.

## Reporting

All Apache-3 personnel must report suspected incidents immediately to:

- **Primary**: s@apache-3.com
- **Backup**: apache3corp@gmail.com
- **Phone (severe incidents)**: +1 (720) 707-9461

Reports should include (where known):
- Time of discovery
- System(s) involved
- Nature of the suspected incident
- Any immediate actions taken

## Severity classification

**P0 — Critical**
- Confirmed breach of Customer Data
- Production system unavailable affecting all customers
- Active intrusion in progress
- Response: paged immediately. CEO + technical lead engaged within 15 minutes.

**P1 — High**
- Suspected breach (investigation needed)
- Partial customer impact
- Compromised credentials with unknown blast radius
- Response: engaged within 1 hour. Daily updates.

**P2 — Medium**
- Single-system compromise without customer impact
- Lost / stolen workstation (encrypted)
- Phishing attempt against personnel (no compromise)
- Response: engaged within 8 business hours.

**P3 — Low**
- Policy violation without security impact
- Failed phishing test
- Routine vulnerability finding
- Response: triaged in next business cycle.

## Response phases

### 1. Identification

- Confirm the incident is real (not a false positive)
- Determine severity
- Open an incident record (date, time, summary, severity)
- Assign an Incident Commander (default: CEO for P0/P1)

### 2. Containment

- For active intrusions: isolate affected systems (revoke credentials, rotate keys, pull network)
- For compromised credentials: rotate immediately, audit access logs for the compromised account
- For lost devices: trigger remote wipe, force-revoke all sessions
- Preserve evidence before remediation (logs, snapshots)

### 3. Eradication

- Identify root cause (technical and process)
- Remove the threat (malware, unauthorized access, vulnerability)
- Apply patches or configuration changes to prevent recurrence

### 4. Recovery

- Restore affected systems from clean state
- Verify integrity of restored systems
- Monitor for recurrence for at least 48 hours
- Resume normal operations

### 5. Post-incident review

Within 30 days of resolution:

- Written post-mortem
- Root cause analysis
- What worked / what didn't
- Action items to prevent recurrence
- Distribute to affected stakeholders

## Customer notification

For confirmed breaches affecting Customer Data:

- **Within 72 hours of confirmation**: written notification to the Customer's designated contact (per the engaged Data Processing Agreement)
- **Notification includes**: nature of breach, scope of affected data, immediate mitigations, remediation plan, contact for further questions
- **Final report within 30 days**: full post-mortem provided to the Customer

## Regulatory notification

If the incident involves data subject to specific regulations:

- **HIPAA-covered data**: notify per 45 CFR § 164.404 (covered entity) or § 164.410 (business associate) — within 60 days
- **GLBA-covered data**: notify per applicable regulations
- **State data-breach laws**: notify per the laws of each affected jurisdiction
- **Federal contract CUI**: notify the Contracting Officer per the contract's CUI clause within the required timeframe (typically 72 hours for CDI under DFARS 252.204-7012)

Apache-3 will engage legal counsel for regulatory notifications.

## Common scenarios

### Compromised AWS / Supabase / Stripe credential

1. Rotate the credential immediately
2. Review the platform audit log for unauthorized actions in the 30 days preceding the suspected compromise
3. Identify any data accessed; classify per data sensitivity
4. Determine if the compromise constitutes a breach requiring notification
5. Apply MFA + key rotation policy updates

### Lost or stolen workstation

1. Trigger remote wipe (find-my for macOS, Microsoft 365 for Windows)
2. Revoke all sessions across the user's accounts
3. Reset their passwords on all systems
4. Inventory what was likely on the device (mostly transient working state — disk encryption prevents data access)
5. File a police report for the stolen device
6. Document for insurance claim

### Phishing email reaching personnel

1. If the recipient clicked: treat as P1 — immediate credential rotation + session revocation + access log review
2. If the recipient reported without clicking: treat as P3 — track via phishing-simulation metrics
3. Either way: report the phishing email to the affected SaaS vendor's abuse address

### Vendor-side breach affecting Apache-3

1. Determine what data was exposed
2. Determine if any of that data is Customer Data
3. If Customer Data is implicated, follow the breach-notification protocol above
4. Reassess the vendor's continued use under the vendor management policy

## Contact list

| Role | Person | Contact |
|---|---|---|
| Incident Commander (P0/P1) | Snake Blocker, CEO | s@apache-3.com / +1 (720) 707-9461 |
| Technical Lead | Naveen Dhillon, Senior Engineer | s@apache-3.com |
| Legal counsel | (Engaged per incident) | TBD per engagement |
| Insurance broker | (On file at workspace-admin) | Contact per current policy |

## Review

This runbook is reviewed at least annually and after any incident classified P0 or P1.

---

*Apache-3 Inc. — UEI JQMHLJNNJYN1 — CAGE 8DFR5*