# Signal Incident Response Procedure

**Version:** 1.0
**Date:** June 7, 2026
**Owner:** STTIL Solutions LLC / Kisa Fenn, Managing Member
**Classification:** Internal — do not publish

---

## Purpose

This document defines the steps STTIL Solutions will take if a security incident affects Signal or the data of Signal customers. An "incident" includes any unauthorized access, data breach, ransomware event, accidental deletion, or disclosure of customer data.

---

## Incident Classification

| Severity | Description | Examples |
|---|---|---|
| P1 — Critical | Active breach or confirmed data exposure | Unauthorized access to Supabase; database dump exfiltrated |
| P2 — High | Suspected breach or significant service disruption | Unusual API activity; Railway service crash with data loss risk |
| P3 — Medium | Potential vulnerability or policy violation | Misconfigured CORS; unexpected admin access |
| P4 — Low | Minor issues with no data exposure | Failed login attempts; expired SSL (auto-renewing) |

---

## Response Timeline

| Step | P1 | P2 | P3/P4 |
|---|---|---|---|
| Detect and classify | Immediate | Within 1 hour | Within 24 hours |
| Contain | Immediately | Within 2 hours | Within 72 hours |
| Notify affected customers | Within 72 hours | Within 72 hours | As appropriate |
| Root cause analysis | Within 24 hours | Within 72 hours | Within 1 week |
| Remediation complete | Within 48 hours | Within 1 week | Within 2 weeks |

---

## Step 1: Detect and Classify

Detection sources:
- Railway logs and alerts
- Supabase dashboard alerts
- Vercel deployment alerts
- Clerk auth anomaly alerts
- Customer report
- Routine audit log review

Upon detection, Kisa Fenn assesses severity and begins the response log.

---

## Step 2: Contain

**P1 (Critical):**
1. Immediately revoke all active API keys and rotate secrets (Railway env vars, Supabase service key, Clerk API key)
2. Take Signal offline if breach is active (Railway: pause service)
3. Preserve logs — do not delete or overwrite
4. Do not communicate publicly until scope is understood

**P2 (High):**
1. Revoke and rotate suspected compromised credentials
2. Isolate affected service if possible
3. Begin forensic log review

**P3/P4:**
1. Patch or reconfigure the identified vulnerability
2. Document the fix

---

## Step 3: Assess Scope

Determine:
- What data was accessed or exposed?
- Which customers (organizations) are affected?
- What is the time range of the exposure?
- Was any patient data (even de-identified hashed IDs) involved?

Signal's data architecture minimizes exposure: patient_id is hashed (SHA-256) before storage. Even in a worst-case database exposure, the hashes cannot be reversed to reveal patient identities without the supplier's local crosswalk. Audit logs are structured with the same hashing protocol and cannot be used to reconstruct patient identity independently.

---

## Step 4: Notify Affected Customers

**Timeline:** Within 72 hours of confirming that customer data was affected.

**Notification must include:**
1. Date and time the incident was detected
2. Description of the incident (what happened)
3. Data affected (which tables, which organizations, what fields)
4. Steps STTIL has taken to contain and remediate
5. Steps the customer should take (if any)
6. Contact for follow-up questions

**Notification method:** Email to the primary contact for each affected organization. For P1 incidents, also attempt phone contact.

**Breach notification under HIPAA:** If any incident involves data that may constitute PHI under HIPAA, STTIL will comply with HIPAA breach notification requirements, including notification to HHS within 60 days of discovery for breaches affecting 500 or more individuals. Given Signal's de-identification architecture, PHI breach is unlikely but is addressed here for completeness. The 72-hour customer notification timeline above is more stringent than the 60-day HIPAA threshold and is the operative timeline for Signal operations.

---

## Step 5: Root Cause Analysis and Remediation

Document:
- Root cause (technical failure, human error, external attack)
- How it was detected
- Timeline of the incident
- Containment actions taken
- Remediation actions taken
- Preventive measures implemented

Store the incident report in `signal/docs/compliance/incidents/YYYY-MM-DD-incident-report.md`.

---

## Step 6: Post-Incident Review

Within one week of remediation:
- Review whether current monitoring would have caught this sooner
- Update runbooks, monitoring, or access controls as needed
- Evaluate whether additional audit log coverage is needed
- Assess whether WORM enforcement gaps contributed to the incident

---

## Key Contacts and Credentials

| System | Access | Rotation after incident |
|---|---|---|
| Railway | railway.app — sttilsolutionsllc@proton.me | Rotate SIGNAL_API_KEY, SUPABASE_SERVICE_KEY, CLERK_JWKS_URL |
| Supabase | supabase.com — Kisa's account | Rotate service_key (JWT) immediately |
| Vercel | vercel.com | Rotate VITE_API_URL if endpoint changed |
| Clerk | clerk.com — eternal-goblin-1 | Rotate API keys |

After a P1 incident, rotate ALL secrets listed above regardless of which service was directly involved.

---

## Escalation

Kisa Fenn is the sole incident commander for all Signal incidents. If Kisa is unavailable and the incident is P1, the default action is to take Signal offline (Railway: pause service) until Kisa can respond.

**Legal contact:** Nixon Law Group — contact for any incident that may involve regulatory notification obligations or breach of a customer BAA.

---

## Audit Log Posture

Per the HIPAA Security Rule (as updated in the 2026 Final Rule, 45 CFR §164.312(b)), audit logs must meet a WORM standard and be retained for a minimum of 6 years. Signal's `audit_logger.py` writes to the Supabase `audit_events` table with hashed identifiers and structured JSON. The WORM enforcement gap (preventing DELETE on the audit_events table) is tracked in the compliance checklist and must be resolved before any live PHI enters the system. Until then, the audit log is append-only by policy and reviewed quarterly.
