Incident Response Plan
Effective Date: February 2026
1. Purpose and Scope
This Incident Response Plan ("IRP") establishes the framework, roles, and procedures that Rymeda, Inc. ("Rymeda") follows to detect, contain, eradicate, recover from, and report security and privacy incidents affecting the Rymeda platform, its users, and the Protected Health Information ("PHI") processed on behalf of healthcare providers (Covered Entities).
This plan applies to all Rymeda workforce members (employees, contractors, and temporary staff), all systems and infrastructure operated by Rymeda (including AWS cloud resources, databases, APIs, and client applications), all data processed through the platform (including PHI, personal data, and operational data), and all subprocessors listed on our Subprocessor List.
This IRP is maintained in alignment with the HIPAA Security Rule (45 CFR §164.308(a)(6) — Security Incident Procedures), the NIST Cybersecurity Framework (CSF) Respond function, NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide), and the incident response requirements of our Business Associate Agreement, Data Processing Agreement, and Breach Notification Policy.
2. Incident Classification
All incidents are classified by severity to determine response urgency, escalation path, resource allocation, and notification requirements. Classification is determined at initial triage and may be escalated or de-escalated as the investigation progresses.
| Severity | Description | Examples | Response Time |
|---|---|---|---|
| Sev 1 — Critical | Confirmed PHI breach, complete platform outage, active intrusion, ransomware | Unauthorized PHI exfiltration, database compromise, encryption key exposure, full denial of service | 15 minutes |
| Sev 2 — High | Suspected PHI exposure, major feature degradation, privilege escalation, account compromise | Unauthorized access to clinical data, role-based access control bypass, major API outage, compromised provider credentials | 1 hour |
| Sev 3 — Medium | Minor data exposure, partial service degradation, policy violation, suspicious activity | Accidental disclosure to wrong provider within same org, single-service degradation, unusual login patterns, failed penetration attempts | 4 hours |
| Sev 4 — Low | Policy violation, misconfiguration, near-miss, non-sensitive data exposure | Employee policy violation, non-PHI misconfiguration, phishing attempt (unsuccessful), community guideline violation | 1 business day |
Incidents involving PHI or ePHI are automatically classified as Sev 1 (confirmed breach) or Sev 2 (suspected exposure) and trigger the four-factor risk assessment process described in the Breach Notification Policy. Trust and safety incidents (content violations, account abuse) are tracked through the platform's moderation system and may be classified as Sev 3 or Sev 4 unless they involve PHI, unauthorized access, or platform compromise.
3. Incident Response Team
The Incident Response Team ("IRT") is activated upon detection of a Sev 1 or Sev 2 incident. For Sev 3 and Sev 4 incidents, the on-call engineer and relevant team lead handle the response, escalating to the full IRT if the severity changes.
| Role | Responsibilities | Activated |
|---|---|---|
| IR Lead | Commands the incident response. Makes containment and escalation decisions. Coordinates all IRT activities. Owns the incident timeline and status updates. | Sev 1–2 |
| Privacy Officer | Conducts the four-factor risk assessment for PHI breaches. Determines notification obligations under HIPAA, CCPA, CMIA, and state laws. Coordinates with Covered Entities. Manages regulatory reporting. | Sev 1–2 involving PHI |
| Legal Counsel | Advises on legal obligations, privilege, regulatory notification deadlines, law enforcement coordination, and liability exposure. Reviews all external communications. | Sev 1–2 |
| Engineering Lead | Directs technical containment, forensic investigation, root cause analysis, and system recovery. Manages infrastructure changes and patches. Leads the technical post-mortem. | Sev 1–3 |
| Communications Lead | Drafts and coordinates all internal and external communications, including customer notifications, status page updates, media statements, and regulatory filings. | Sev 1–2 |
| Executive Sponsor | Provides executive authority for major decisions (e.g., full platform shutdown, public disclosure, law enforcement engagement). Approves resource allocation. Final approval on external communications. | Sev 1 |
4. Detection
Rymeda employs multiple layers of detection to identify security and privacy incidents as early as possible:
4.1 Automated Monitoring
- Infrastructure monitoring: AWS CloudWatch, VPC Flow Logs, GuardDuty, CloudTrail for API activity, S3 access logging, and WAF event monitoring.
- Application monitoring: Centralized logging of all API requests, authentication events (Cognito), authorization failures, and error rates.
- Anomaly detection: Automated alerting for unusual access patterns, failed login spikes, privilege escalation attempts, and out-of-hours PHI access.
- Trust & safety system: AI-powered content moderation with automated analysis of reported content, confidence-based auto-moderation for severe violations (violence, self-harm, illegal content, hate speech), and trust scoring for user accounts.
4.2 Audit Log Alerts
The platform's immutable audit trail system captures all data access events, including user ID, clinical role, timestamp, IP address, entity type, entity ID, and action performed. Audit logs support real-time querying by entity, user, date range, and action type, with export capabilities for compliance and forensic investigation. Alerts are triggered for anomalous access patterns, including bulk data access, access outside assigned patient scope (for scoped roles), and access by suspended or locked accounts.
4.3 User Reports
Workforce members and platform users can report suspected incidents through: direct email to security@rymeda.com, the platform's moderation reporting system (for content and user violations), or anonymous reporting channels. All reports are triaged within the response times specified in Section 2. The moderation queue tracks reports with status (pending, reviewing, escalated, resolved), priority, and assigned reviewer.
4.4 Third-Party and Subprocessor Notifications
Subprocessors are contractually required to notify Rymeda of security incidents within seventy-two (72) hours (per our DPA). AWS, Stripe, OpenAI, Google, and other subprocessors provide incident notifications through their respective notification channels. Notifications from subprocessors are triaged and classified using the same severity framework.
5. Containment
The goal of containment is to limit the scope and impact of the incident while preserving evidence for investigation. Containment actions are authorized by the IR Lead (Sev 2–4) or Executive Sponsor (Sev 1).
5.1 Short-Term Containment
- Credential revocation: Immediately revoke compromised access credentials, API keys, and JWT tokens. Force session invalidation for affected users through the platform's session management system (invalidate specific sessions or all sessions for a user, with audit trail).
- Account actions: Lock compromised accounts using the trust & safety account lock system (with reason code and audit logging). Suspend accounts where unauthorized access is confirmed.
- Network isolation: Isolate affected systems at the network level using AWS Security Groups, NACLs, or VPC isolation. Block malicious IP addresses at the WAF level.
- Service isolation: If a specific service or API is compromised, isolate it from the production environment while other services continue operating.
- Increased monitoring: Elevate monitoring levels on affected and adjacent systems. Enable enhanced logging where applicable.
5.2 Long-Term Containment
- Apply emergency patches or configuration changes to close the attack vector.
- Rotate encryption keys (per-tenant AWS KMS keys) if key compromise is suspected.
- Rebuild affected systems from known-good configurations if integrity is in question.
- Implement additional access restrictions (e.g., IP allowlisting, MFA enforcement, rate limiting) pending full remediation.
6. Eradication
Eradication eliminates the root cause of the incident from the environment:
- Root cause analysis: Conduct thorough forensic investigation using audit logs, system logs, AWS CloudTrail, VPC Flow Logs, and application-level telemetry to identify the vulnerability, misconfiguration, or process failure that enabled the incident.
- Vulnerability remediation: Patch the specific vulnerability or close the misconfiguration. Update infrastructure-as-code configurations. Apply changes through the standard deployment pipeline with expedited review.
- Malware removal: If malware is identified, perform forensic imaging of affected systems, remove all malicious artifacts, and rebuild systems from known-good state. Verify integrity using checksums and behavioral analysis.
- Unauthorized access removal: Remove all unauthorized accounts, backdoors, persistence mechanisms, and lateral movement paths. Verify that no residual unauthorized access remains.
- Access review: Conduct an emergency access review for all staff with access to affected systems using the platform's access review system (which tracks reviewer, staff member, review period, current access, and recommended changes). Verify all access levels are appropriate.
7. Recovery
Recovery restores affected systems and services to full operational status:
7.1 System Restoration
- Restore systems from verified, clean backups. RPO (Recovery Point Objective): one (1) hour. RTO (Recovery Time Objective): four (4) hours.
- Verify data integrity before returning systems to production.
- Validate that eradication was successful — confirm no residual compromise.
- Restore tenant data isolation boundaries and verify tenant-level data isolation.
7.2 Graduated Return to Production
- Return services to production in a controlled, phased manner — starting with non-PHI services, then PHI-handling services.
- Maintain elevated monitoring for a minimum of seventy-two (72) hours after recovery.
- Unlock affected user accounts after verifying credential integrity (through the trust & safety system with documented unlock reason and audit trail).
- Restore normal access levels after access review completion.
7.3 Verification
- Run automated security scans against recovered systems.
- Verify all security controls are functioning (encryption, RBAC, audit logging, PHI redaction pipeline).
- Confirm service availability meets SLA commitments (99.9% monthly uptime per our SLA).
- Validate that all subprocessor integrations are operating normally.
8. Post-Incident Review
A post-incident review (blameless post-mortem) is conducted after every Sev 1 and Sev 2 incident, and for Sev 3 incidents at the IR Lead's discretion.
8.1 Timeline
- Sev 1: Post-incident review meeting within five (5) business days of incident resolution. Written report within ten (10) business days.
- Sev 2: Post-incident review within five (5) business days. Written report within ten (10) business days.
- Sev 3: Written summary within ten (10) business days (meeting at IR Lead discretion).
8.2 Report Contents
The post-incident report includes:
- Incident timeline from detection to resolution.
- Root cause analysis.
- Impact assessment (affected systems, data, users, Covered Entities).
- Containment and eradication actions taken.
- Notification actions taken (internal, customer, regulatory).
- Lessons learned — what went well, what could be improved.
- Action items with owners and deadlines for process improvements.
8.3 Customer Communication
Post-incident reports are provided to affected customers (Covered Entities) within ten (10) business days of incident resolution, as specified in our Service Level Agreement. Customer-facing reports include root cause analysis, impact assessment, and remediation actions, but exclude internal operational details protected by attorney-client privilege or work product doctrine.
9. HIPAA Breach Integration
When an incident involves PHI or ePHI, the incident response process integrates with the Breach Notification Policy:
- Immediate classification: Any incident involving confirmed or suspected unauthorized access to PHI is classified as Sev 1 (confirmed breach) or Sev 2 (suspected exposure).
- Four-factor risk assessment: The Privacy Officer initiates the four-factor risk assessment per 45 CFR §164.402(2) within twenty-four (24) hours of PHI incident confirmation. The assessment must be completed within five (5) business days.
- Breach determination: Based on the risk assessment, the Privacy Officer determines whether the incident constitutes a reportable breach under HIPAA.
- Notification triggers: If a breach is confirmed, the notification timelines in the Breach Notification Policy are activated from the date of discovery (not the date of breach determination).
- Covered Entity notification: Rymeda notifies the affected Covered Entity within thirty (30) days of discovery, per the BAA.
- Documentation: All PHI-related incidents are documented in the breach log with a minimum six (6) year retention period per 45 CFR §164.530(j).
10. California Dual-Track Notification
For incidents affecting California residents, Rymeda must comply with both federal HIPAA notification requirements and California state requirements, which may have shorter timelines:
| Requirement | Legal Basis | Deadline |
|---|---|---|
| CDPH reporting (healthcare facilities) | Cal. HSC §1280.15 | 15 business days |
| Consumer notification | Cal. Civ. Code §1798.82 (SB 446) | 30 days |
| AG notification (500+ CA residents) | Cal. Civ. Code §1798.82 | 30 days |
| BA → Covered Entity notification | 45 CFR §164.410 / BAA | 30 days |
| Individual notification (federal) | 45 CFR §164.404 | 60 days |
The Privacy Officer and Legal Counsel maintain a notification checklist for each incident to ensure all deadlines are tracked. California's SB 446 thirty (30) day deadline is the most aggressive consumer notification requirement and drives the operational timeline for incidents affecting California residents. See the Breach Notification Policy for full notification procedures and content requirements.
11. Communication Templates
Rymeda maintains pre-approved communication templates for each audience and severity level. All external communications are reviewed by Legal Counsel before distribution.
11.1 Internal Communications
IRT activation notifications, escalation communications, status updates (every two (2) hours for Sev 1, every four (4) hours for Sev 2), all-hands briefings for Sev 1 incidents, and post-incident summaries.
11.2 Customer / Covered Entity Communications
Initial incident acknowledgment (within response time for severity level), ongoing status updates, formal breach notification (per Breach Notification Policy), and post-incident report.
11.3 Regulatory Communications
HHS breach report submissions, California Attorney General notifications, CDPH reports (HSC §1280.15), and annual breach log submissions.
11.4 Media Communications
Public statements (Sev 1 incidents with broad impact), media inquiries (directed to Communications Lead), and prominent media notifications for breaches affecting 500+ individuals in a single state (per 45 CFR §164.406).
12. Law Enforcement Coordination
Rymeda cooperates with law enforcement in the investigation of security incidents, subject to legal review:
- Decision authority: The decision to involve law enforcement is made by Legal Counsel and the Executive Sponsor. For Sev 1 incidents involving active intrusion, ransomware, or confirmed criminal activity, law enforcement is contacted as part of the standard response.
- Evidence preservation: Rymeda preserves all forensic evidence in accordance with Section 14, including maintaining chain of custody documentation suitable for legal proceedings.
- Notification delay: If law enforcement requests a delay in breach notification, Rymeda complies in accordance with 45 CFR §164.412 (written request for specified period; oral request for up to thirty (30) days). See the Breach Notification Policy Section 11.
- FBI and IC3: For cyber incidents involving significant financial loss or infrastructure compromise, Rymeda may file reports with the FBI Internet Crime Complaint Center (IC3).
13. Insurance Notification
Rymeda maintains cyber liability insurance to cover costs associated with security incidents, including breach notification, forensic investigation, legal fees, regulatory fines, and credit monitoring services.
- Sev 1 and Sev 2: The cyber insurance carrier must be notified within twenty-four (24) hours of incident confirmation. Legal Counsel coordinates the notification.
- Sev 3: Notification to the carrier at Legal Counsel's discretion, depending on potential exposure.
- Carrier resources: The insurance carrier may provide access to pre-approved forensic investigators, breach response counsel, notification vendors, and credit monitoring services. These resources are coordinated through Legal Counsel.
14. Evidence Preservation
Evidence preservation is critical for forensic investigation, regulatory compliance, and potential legal proceedings:
- Forensic imaging: Create forensic images of affected systems before any containment or remediation actions that may alter system state. Store images in a secure, access-controlled location separate from production systems.
- Log preservation: Export and preserve all relevant audit logs, system logs, network logs, and application logs. Platform audit logs are immutable and append-only by design. Audit log exports are themselves logged (recording the exporter, filters applied, and entry count).
- Chain of custody: Maintain documented chain of custody for all evidence, including who collected it, when, how it was stored, and who has accessed it. Evidence is stored with write-protection and integrity verification (checksums).
- Retention: Incident evidence is retained for a minimum of six (6) years from the date of collection, consistent with HIPAA record retention requirements (45 CFR §164.530(j)). Evidence related to ongoing legal proceedings is retained indefinitely under legal hold.
- Trust & safety evidence: All trust and safety actions (account locks, suspensions, bans, moderation decisions) are preserved in dedicated audit logs with actor ID, actor email, action, resource type, resource ID, before/after state, reason, IP address, severity, and timestamp.
15. Tabletop Exercises and Testing
Rymeda conducts regular testing of this Incident Response Plan to ensure readiness:
15.1 Quarterly Tabletop Exercises
The IRT conducts quarterly tabletop exercises simulating different incident scenarios, including PHI breach, ransomware, insider threat, and subprocessor compromise. Exercises test communication protocols, decision-making processes, escalation paths, and notification procedures. Findings are documented and corrective actions tracked.
15.2 Annual Full Simulation
An annual full-scale incident simulation is conducted, involving all IRT members and relevant support functions. The simulation tests end-to-end response capabilities, including detection, containment, eradication, recovery, and notification. External parties (e.g., forensic investigators, legal counsel) participate where feasible.
15.3 Technical Testing
Annual penetration testing, regular vulnerability scanning (critical vulnerabilities patched within 24 hours, high within 7 days, medium within 30 days, low within 90 days per our Security commitments), and periodic red team exercises. Findings from technical testing are integrated into the incident response plan and security infrastructure.
15.4 Compliance Training Integration
Incident response training is integrated with the platform's compliance training system. Training requirements are defined by role and frequency (annual for all workforce, quarterly for IRT members). Training completions are tracked with attestation, scores, and expiration dates. The workforce compliance training system records staff attestation to incident response policies through the policy attestation mechanism (policy version, staff ID, attestation date, IP address).
16. Plan Maintenance
This IRP is reviewed and updated:
- At least annually as part of the overall security program review.
- After every Sev 1 or Sev 2 incident, incorporating lessons learned from the post-incident review.
- When there are material changes to applicable laws or regulations (e.g., HIPAA, CCPA/CPRA, California breach notification laws).
- When there are significant changes to Rymeda's infrastructure, services, or subprocessor relationships.
- After tabletop exercises or simulations identify gaps or improvement opportunities.
Changes to this IRP are approved by the IR Lead, Privacy Officer, and Executive Sponsor. All IRT members are notified of changes and required to acknowledge the updated plan.
17. Contact Information
To report a security incident or for questions about this plan:
- Security Team (24/7): security@rymeda.com
- Privacy Officer: legal@rymeda.com
- Legal Department: legal@rymeda.com
- Compliance Office: legal@rymeda.com
This plan should be read in conjunction with the Breach Notification Policy, Business Associate Agreement, Data Processing Agreement, Security page, Service Level Agreement, and Privacy Policy.