Legal

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.

SeverityDescriptionExamplesResponse Time
Sev 1 — CriticalConfirmed PHI breach, complete platform outage, active intrusion, ransomwareUnauthorized PHI exfiltration, database compromise, encryption key exposure, full denial of service15 minutes
Sev 2 — HighSuspected PHI exposure, major feature degradation, privilege escalation, account compromiseUnauthorized access to clinical data, role-based access control bypass, major API outage, compromised provider credentials1 hour
Sev 3 — MediumMinor data exposure, partial service degradation, policy violation, suspicious activityAccidental disclosure to wrong provider within same org, single-service degradation, unusual login patterns, failed penetration attempts4 hours
Sev 4 — LowPolicy violation, misconfiguration, near-miss, non-sensitive data exposureEmployee policy violation, non-PHI misconfiguration, phishing attempt (unsuccessful), community guideline violation1 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.

RoleResponsibilitiesActivated
IR LeadCommands the incident response. Makes containment and escalation decisions. Coordinates all IRT activities. Owns the incident timeline and status updates.Sev 1–2
Privacy OfficerConducts 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 CounselAdvises on legal obligations, privilege, regulatory notification deadlines, law enforcement coordination, and liability exposure. Reviews all external communications.Sev 1–2
Engineering LeadDirects technical containment, forensic investigation, root cause analysis, and system recovery. Manages infrastructure changes and patches. Leads the technical post-mortem.Sev 1–3
Communications LeadDrafts and coordinates all internal and external communications, including customer notifications, status page updates, media statements, and regulatory filings.Sev 1–2
Executive SponsorProvides 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:

RequirementLegal BasisDeadline
CDPH reporting (healthcare facilities)Cal. HSC §1280.1515 business days
Consumer notificationCal. Civ. Code §1798.82 (SB 446)30 days
AG notification (500+ CA residents)Cal. Civ. Code §1798.8230 days
BA → Covered Entity notification45 CFR §164.410 / BAA30 days
Individual notification (federal)45 CFR §164.40460 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:

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.