This runbook establishes the procedures EMStool LLC will follow to detect, contain, investigate, eradicate, recover from, and learn from security incidents affecting Cadence and related systems.
1. Purpose and Scope
This runbook applies to all systems operated by EMStool LLC including Cadence customer tenants, the emstool.com web properties, and supporting infrastructure. A security incident is any event that compromises or threatens the confidentiality, integrity, or availability of Cadence systems or the PHI and PII they contain.
2. Severity Classification
| Severity | Definition | Response Time | Notification |
| Critical | Active breach of PHI; ransomware; full system compromise | Immediate (within 1 hour) | All customers + HHS within 60 days |
| High | Attempted breach; privilege escalation; data exfiltration suspected | Within 4 hours | Affected customers within 72 hours |
| Medium | Unauthorized access attempt; service degradation; malware detected | Within 24 hours | Internal log + assess notification need |
| Low | Policy violation; suspicious activity; failed auth spike | Within 72 hours | Internal documentation |
3. Incident Response Phases
Phase 1: Identification
- Monitor audit logs, server alerts, and customer reports
- Confirm the event is a genuine security incident (not a false positive)
- Document initial indicators: timestamp, affected systems, observed behavior
- Assign incident severity level (Critical/High/Medium/Low)
- Create incident record: date, time, reporter, initial description
Phase 2: Containment
- Short-term: Isolate affected systems; revoke compromised credentials; block attacking IPs at Cloudflare
- Long-term: Rebuild compromised containers with clean images; restore from last verified clean backup
- Preserve evidence (logs, database snapshots) before making changes
- Do not power off systems without capturing forensic evidence first
Phase 3: Eradication
- Identify and eliminate root cause (patching, config change, credential reset)
- Scan all related systems for indicators of compromise (IOCs)
- Verify no backdoors or persistence mechanisms remain
- Rotate all potentially exposed credentials (DB passwords, API keys, session secrets)
Phase 4: Recovery
- Restore services from verified clean state
- Monitor systems closely for 72 hours post-recovery
- Gradually restore access — verify each restoration step
- Confirm all systems return to normal operational metrics
Phase 5: Post-Incident Review
- Conduct post-mortem within 5 business days of resolution
- Document: root cause, timeline, actions taken, impact assessment
- Identify gaps and create remediation action items
- Update this runbook and related policies as needed
4. Communication Plan
| Audience | Trigger | Timeline | Channel |
| Internal team | Any incident | Immediately | Direct communication |
| Affected customers | High or Critical incident | Within 72 hours | Email to account admins |
| HHS (HIPAA breach) | PHI breach >500 individuals | Within 60 days | HHS breach portal |
| Affected individuals | PHI breach confirmed | Without unreasonable delay, no later than 60 days | Written notice per HIPAA |
5. Key Contacts and Resources
- Security Officer: Jacob Russell — [email protected]
- Infrastructure: Cadence runs on Vincent (192.168.0.11), managed via Cloudflare SWAG
- Backup verification: Check Backblaze B2 bucket for latest encrypted .sql.gpg backup
- Cloudflare: Account admin at dash.cloudflare.com to block IPs or disable tunnel
- HHS Breach Portal: ocrportal.hhs.gov
6. Evidence Preservation Checklist
- Export and archive Apache/PHP access and error logs
- Export Cadence audit_log table from MariaDB
- Capture active_sessions table state
- Screenshot Cloudflare access logs
- Document timeline of events with timestamps
Security Officer Signature
Jacob Russell — Security Officer, EMStool LLC
Date Reviewed
June 29, 2026