Signal/docs/compliance/incident-response.md

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.