Information Security Policy

1. Purpose & Scope

This Information Security Policy (“Policy”) establishes the security standards, controls, and responsibilities governing all information systems, infrastructure, and data processed by Rymeda, Inc. (“Rymeda,” “we,” “us”). This Policy implements a defense-in-depth security architecture across nine interconnected layers to protect healthcare data at every stage of its lifecycle.

This Policy implements the requirements of the HIPAA Security Rule (45 CFR Part 164, Subpart C); NIST Cybersecurity Framework (CSF) 2.0; NIST Special Publications 800-53, 800-63B, and 800-88; SOC 2 Type II trust service criteria; and applicable federal and state security regulations.

This Policy applies to all Rymeda information systems, cloud infrastructure, application code, data stores, network components, and third-party integrations. It covers all workforce members, contractors, authorized users, and subprocessors who access, process, or transmit Rymeda data.

2. Security Roles & Responsibilities

3. Risk Management Framework

Rymeda’s information security risk management program is aligned with the NIST Cybersecurity Framework (CSF) 2.0 and implements the five core functions:

Risk assessments are conducted annually and whenever significant changes are made to the platform architecture, infrastructure, or subprocessor relationships. The risk register is maintained by the Compliance team and reviewed quarterly by the CISO.

4. Access Control

Rymeda implements role-based access control (RBAC) and capability-based access control enforced at every layer of the application. Access is governed by the principle of least privilege and the HIPAA minimum necessary standard (45 CFR §164.502(b)).

4.1 Authentication Gateway

All user authentication is managed through AWS Cognito with the following configuration:

• Protocol: OAuth 2.0 Authorization Code flow with Proof Key for Code Exchange (PKCE) — no client secrets stored on client devices
• Token Format: RS256-signed JSON Web Tokens (JWT) verified against Cognito JWKS public keys
• Token Verification: Signature validation, issuer verification, expiration check, audience (client_id) validation, and token type (token_use) claim validation
• Separate App Clients: Dedicated Cognito app clients for User, Provider, and Admin applications with independent configuration
• JWKS Caching: Public key set cached for 1 hour with a maximum of 16 cached keys to balance performance and security

4.2 Clinical Role-Based Access Control

Clinical data access is governed by a nine-role permission matrix enforced at the API layer. For the complete access control matrix, see our Clinical Data Governance Policy.

4.3 Multi-Tenant Isolation

• Every data record includes an org_id field validated on every database query
• User sessions are bound to a specific organization at authentication time via Cognito custom attributes (custom:orgId)
• API endpoints validate resource ownership before returning data — cross-tenant queries are architecturally impossible
• Per-tenant AWS KMS encryption keys ensure cryptographic isolation

4.4 Session Management

• Token Expiration: Access tokens expire after 24 hours. Support impersonation sessions have configurable timeouts of 5–120 minutes (default 30)
• Session Invalidation: Sessions are invalidated on logout, password change, account suspension, or GDPR deletion
• Concurrent Session Control: Multiple sessions are tracked with device identification and monitored for anomalous patterns
• Impersonation Controls: Support impersonation sessions are time-limited, fully audited, and automatically expire at the configured timeout

5. Authentication Standards

Authentication standards are aligned with NIST Special Publication 800-63B (Digital Identity Guidelines — Authentication and Lifecycle Management).

5.1 Password Policy

5.2 Multi-Factor Authentication (MFA)

• Clinical Access: MFA is required for all roles with clinical chart access (physician, NP, PA, RN, therapist) per HIPAA §164.312(d)
• Administrative Access: MFA is required for all admin roles (Super Admin, Compliance Admin, AI Admin, Support, Staff Admin)
• Supported Methods: TOTP authenticator apps (preferred), SMS-based verification codes
• Enforcement: Managed through AWS Cognito MFA configuration at the user pool level

5.3 Provider Identity Verification

Healthcare providers undergo additional identity verification beyond standard authentication. NPI numbers are validated against the CMS NPPES Registry through the verification state machine (unverified → pending → npi_validated → verified). Providers in unverified or suspended status are denied clinical data access regardless of assigned role. Credential types tracked include: medical license, professional insurance, DEA registration, specialty certification, and board certification.

6. Encryption

Rymeda implements encryption at rest and in transit for all data, with enhanced encryption standards for Protected Health Information (PHI).

6.1 Key Management

• Key Service: AWS Key Management Service (KMS) with hardware-backed key storage (FIPS 140-2 Level 2 validated)
• Per-Tenant Keys: Each organization receives a dedicated KMS customer-managed key (CMK) for S3 encryption, ensuring cryptographic tenant isolation
• Key Rotation: Automatic annual key rotation enabled for all KMS keys. Previous key versions are retained for decryption of existing data
• Key Deletion: KMS key deletion requires a 7-day waiting period (minimum per AWS policy), allowing cancellation if initiated in error. Key deletion implements cryptographic erasure per NIST SP 800-88

7. Network Security

Network security controls protect the Rymeda platform at the infrastructure, transport, and application layers.

7.1 Infrastructure Isolation

• VPC Isolation: All backend services run within an isolated AWS Virtual Private Cloud (VPC) with private subnets for databases and internal services
• Security Groups: Restrictive security group rules allow only required inbound/outbound traffic. Database ports are accessible only from application subnets
• WAF Protection: AWS Web Application Firewall (WAF) protects API endpoints against common web exploits (SQL injection, XSS, request forgery)
• DDoS Mitigation: AWS Shield Standard provides automatic protection against volumetric DDoS attacks. Rate limiting at the application layer provides additional defense

7.2 API Rate Limiting

Rate limiting is enforced at the application layer to prevent abuse, credential stuffing, and denial-of-service attacks:

7.3 Content Security Policy

The website enforces a strict Content Security Policy (CSP) and additional security headers:

• CSP: default-src 'self'; scripts restricted to self and Plausible Analytics; frame-ancestors 'none' prevents clickjacking
• X-Frame-Options: DENY — prevents embedding in iframes
• X-Content-Type-Options: nosniff — prevents MIME type sniffing
• Referrer-Policy: strict-origin-when-cross-origin — limits referrer leakage
• Permissions-Policy: camera=(), microphone=(), geolocation=() — disables sensitive browser APIs on the marketing site

7.4 CORS Policy

Cross-Origin Resource Sharing (CORS) is restricted to authorized application domains (app.rymeda.com, *.app.rymeda.com, clients.rymeda.com, admin.rymeda.com). Credentials are enabled for authenticated cookie-based sessions. Custom headers X-Request-ID and X-Response-Time are exposed for request tracing and performance monitoring.

8. Application Security

Security is integrated into the software development lifecycle (SDLC) from design through deployment.

8.1 Secure Development Lifecycle

• Security by Design: Security requirements are defined during the design phase for all features that process PHI or ePHI
• Code Review: All code changes undergo peer review with security-focused review for changes to authentication, authorization, encryption, or data access layers
• Input Validation: All API inputs are validated through Pydantic v2 schemas with strict type enforcement, required field validation, and enum constraints before processing
• PHI Protection: Audit logs never contain PHI content — only entity type and ID references are logged. This rule is enforced by the audit service architecture

8.2 Security Testing

8.3 Dependency Management

Third-party dependencies are pinned to specific versions in requirements files and package manifests. Security-critical libraries include: cryptography (cryptographic primitives), bcrypt (password hashing), PyJWT and python-jose (token handling), fastapi (API framework), pydantic (input validation), and slowapi (rate limiting). Dependencies are updated promptly when security advisories are published, following the vulnerability management SLAs in Section 12.

9. Data Classification

All data processed by Rymeda is classified into four tiers that determine encryption standards, access controls, retention requirements, and handling procedures. For the full classification matrix mapped to platform data models, see our Clinical Data Governance Policy.

10. Cloud Security (AWS)

Rymeda’s cloud infrastructure is hosted on Amazon Web Services (AWS) and follows AWS Well-Architected Framework security best practices.

10.1 AWS Service Configuration

10.2 S3 Security Policies

• Public access is blocked at the bucket level (Block Public Access enabled)
• Bucket policies enforce SSE-KMS encryption for all PutObject operations
• Presigned URLs are generated with 1-hour expiration for both uploads and downloads
• S3 lifecycle policies automatically delete temporary processing artifacts within 24 hours
• Object versioning is enabled for critical buckets to prevent accidental data loss
• S3 access logging is enabled for audit trail compliance

11. Monitoring & Detection

Rymeda maintains comprehensive monitoring and detection capabilities to identify security threats, unauthorized access, and anomalous behavior in real time.

11.1 Centralized Audit Logging

The centralized audit service captures the following fields for every auditable event: user ID, organization ID, entity type, entity ID, action, role, clinical role, IP address, timestamp (ISO 8601 UTC), and non-PHI metadata. The audit service supports single-entry logging, batch logging (up to 10,000 entries), full-text query with pagination, entity-based trail queries, and compliance exports with date/type filtering.

11.2 Automatic Audit Middleware

The audit middleware automatically captures access events for sensitive endpoints without requiring explicit logging calls in application code:

• Clinical chart access and all chart sub-resources (notes, problems, medications, labs)
• Patient data access
• Voice note access and processing
• Document downloads
• Secure messaging (patient messages, staff notes, system alerts)
• Care messaging and staff channel communications

Middleware events are prefixed with auto_ to distinguish from direct application logging. The middleware runs after successful responses (HTTP 200–299) and never disrupts the request on audit failure.

11.3 Security Event Detection

• Brute Force Detection: 5+ authentication failures within 15 minutes triggers a security alert and potential account lock
• Anomaly Detection: Unusual access patterns (time, location, volume) are flagged for review
• Trust Scoring: User trust scores (base 100) are decremented on policy violations (−20 per enforcement action, −5 per report), triggering escalation at thresholds
• AI Content Moderation: Automated content analysis with three confidence tiers (85% auto-action, 60% review queue, 40% manual review)
• Admin Action Logging: All administrative actions are separately logged with admin identity, action type, target, timestamp, IP address, and result

11.4 Log Retention

• Audit Logs: Minimum 6 years (HIPAA §164.530(j))
• Security Events: Minimum 6 years
• CloudWatch Logs: Streamed to long-term encrypted S3 archival storage
• Immutability: All audit records are append-only — they cannot be modified, overwritten, or deleted by any user including administrators
• Audit Log Access: Restricted to org_admin and owner clinical roles; access is itself audited (meta-auditing)

12. Vulnerability Management

Rymeda maintains a vulnerability management program to identify, assess, and remediate security vulnerabilities across all platform components.

12.1 Patch SLAs

12.2 Vulnerability Disclosure

Rymeda welcomes responsible vulnerability disclosure from security researchers. For our disclosure process and safe harbor provisions, see our Vulnerability Disclosure Policy. Security vulnerabilities may be reported to security@rymeda.com.

13. Third-Party Security

All third-party services that process Rymeda data are subject to security assessment, contractual controls, and ongoing monitoring. For the complete list of subprocessors, see our Subprocessor List.

13.1 Vendor Risk Assessment

• Pre-Engagement: Security questionnaire, SOC 2 report review, and data flow analysis before onboarding any new subprocessor
• PHI Processing: Subprocessors that process PHI must maintain a HIPAA Business Associate Agreement (BAA) and demonstrate compliance with the HIPAA Security Rule
• AI Subprocessors: AI/ML services must operate under Zero Data Retention (ZDR) agreements or equivalent contractual prohibitions against using customer data for model training
• Payment Processing: Payment subprocessors must maintain PCI DSS Level 1 certification

13.2 Contractual Controls

• Data Processing Agreements (DPA) with all subprocessors per GDPR Article 28
• Business Associate Agreements (BAA) with all subprocessors that access PHI
• Contractual data deletion obligations upon service termination
• Breach notification requirements (72-hour maximum)
• Right to audit and security assessment

13.3 Ongoing Monitoring

• Annual Review: Formal security review of all subprocessors at minimum once per year, including SOC 2 report refresh and BAA compliance verification
• Change Notification: 30-day advance notification to customers before adding or replacing subprocessors that process PHI
• Incident Tracking: Subprocessor security incidents are tracked and assessed for impact on Rymeda data

14. Business Continuity & Disaster Recovery

Rymeda maintains business continuity and disaster recovery (BC/DR) capabilities to ensure the availability and recoverability of healthcare data and platform services per HIPAA §164.308(a)(7).

14.1 Backup Strategy

• Database: MongoDB Atlas automated daily backups with point-in-time recovery, encrypted with AES-256
• Object Storage: Amazon S3 with 99.999999999% (11 nines) durability, cross-region replication for critical data
• Backup Rotation: Daily backups retained 30 days, weekly backups retained 90 days, monthly backups retained 1 year
• Backup Encryption: All backups encrypted with the same per-tenant KMS keys as primary storage
• Backup Testing: Quarterly backup restoration tests to verify data integrity and recovery procedures

14.2 High Availability

• Multi-Availability Zone (multi-AZ) deployment for all critical services
• MongoDB Atlas replica set with automatic failover
• Automated health checks and service restart
• 99.9% uptime target as defined in our Service Level Agreement

14.3 DR Testing

• Annual full disaster recovery test including failover, data restoration, and service verification
• Quarterly tabletop exercises for incident response and BC/DR scenarios
• Post-test review and plan updates based on findings

15. Security Awareness & Training

All Rymeda workforce members participate in security awareness training to maintain a security-conscious culture and meet HIPAA §164.308(a)(5) requirements.

Training completion is tracked and documented. Workforce members who fail to complete required training within the designated timeframe may have access privileges restricted until training is completed.

16. Policy Review & Updates

This Policy is subject to regular review to ensure continued effectiveness and regulatory compliance.

• Annual Review: Comprehensive review of all policy sections at minimum once per calendar year, led by the CISO with input from Privacy Officer and Engineering
• Triggered Review: Policy is reviewed and updated within 30 days of: (a) a security incident or breach, (b) significant infrastructure changes, (c) new regulatory requirements, (d) penetration test or audit findings, (e) changes to the subprocessor list
• Risk Assessment Review: Risk register and treatment plans reviewed quarterly
• Version Control: All policy versions are retained with effective dates. Material changes are communicated to all workforce members and affected customers
• Regulatory Alignment: Policy is reviewed against the latest NIST CSF, HIPAA Security Rule guidance, and SOC 2 trust service criteria

Contact

For questions about this Information Security Policy or to report a security concern:

Related Policies