This page describes how Kimya Labs LLC protects the information collected through the Ruya Health product family. It complements our Privacy Policy (which describes what we collect and why) and our Terms of Service (which describes the legal terms of using the services).

The intended audience is users who want to understand our security posture in detail — including security-minded individuals, IT teams at prospective enterprise customers, and security researchers.

1. Honest disclosure: where we stand today

Before listing controls, we want to be transparent about what we have NOT yet earned:

• We are not SOC 2 Type I or Type II certified. No third-party auditor has assessed our controls. We have begun pre-audit preparation; we will publicly disclose when an engagement is in flight and when a report is available.
• We are not HITRUST certified.
• We are not ISO 27001 certified.
• We are not a HIPAA Covered Entity, and the consumer app at app.ruyahealth.com is not designed to receive PHI. When platform.ruyahealth.com enters production with enterprise customers, we will execute Business Associate Agreements (BAAs) as required, and our environment will be configured to meet HIPAA Security Rule technical safeguards. Until then, no BAA is in effect.
• We have not yet completed a penetration test by an independent firm. Roadmap.
• We have no published Service Level Agreement (SLA) for uptime or incident response yet. When enterprise customers enter into MSAs, SLAs will be defined contractually.

If those constraints are dealbreakers for your use case, please reach out at security@ruyahealth.com to discuss timeline. We would rather lose the deal honestly today than win it on claims we can't back up.

2. What we do today

The controls below are implemented as of the "Last updated" date.

2.1 Encryption

• In transit: TLS 1.2 minimum, TLS 1.3 preferred. All API endpoints reject non-TLS connections. We pin the AWS RDS CA bundle in our database client to defeat MITM attacks.
• At rest: AES-256 encryption on all databases, file storage, and automated backups. Encryption keys are managed by AWS KMS with the default aws/rds and aws/s3 key policies.
• Passwords: stored as one-way scrypt hashes. We never see, log, or transmit plaintext passwords. Cookie sessions are signed, HttpOnly, Secure, and SameSite=Lax.

2.2 Authentication and access controls

• Better Auth handles user authentication for the consumer app. Email/password sign-up requires email verification before sign-in.
• Optional sign-in via Google OAuth with minimal scopes (email, profile, openid only).
• Per-account rate limits on sign-in, sign-up, and password reset endpoints.
• Server-side session storage with immediate revocation on sign-out. Stolen session cookies cannot be used after the user signs out from any active session.
• Internal access to production systems is limited to named individuals, requires MFA, and is logged.

2.3 Infrastructure

• Compute: Vercel serverless functions (consumer app) and Cloudflare Pages (marketing site).
• Database: AWS RDS PostgreSQL in us-east-1, single-AZ today, Multi-AZ planned with the enterprise launch. Public endpoint with security group restricting inbound to TLS-only port 5432; application-side TLS enforces certificate validation against the AWS RDS CA bundle.
• Network egress: TLS-only outbound to a limited set of trusted providers (Anthropic, Google, Resend, Cloudflare). DNS is managed by Cloudflare.

2.4 Application security

• TypeScript strict mode and ESLint enforce baseline code quality.
• All SQL queries use parameterized statements (no string interpolation of user input).
• Content Security Policy (CSP) headers on all marketing-site responses; consumer-app CSP is in progress and will tighten script-src to nonce-based delivery before public launch.
• Strict Transport Security (HSTS), X-Content-Type-Options: nosniff, X-Frame-Options: DENY, and Referrer-Policy: strict-origin-when-cross-origin on all responses.
• Dependencies are tracked with npm audit and updated on a regular cadence; known CVEs are patched within seven calendar days of disclosure for critical/high severity.

2.5 Logging and monitoring

• Application logs include request paths, response codes, error context, and authentication events. Logs do NOT include the bodies of API requests or the content of AI conversations.
• Logs are retained for 30 days. Authentication events (IP, user-agent at sign-in) are retained for 90 days.
• We monitor for unusual authentication patterns (repeated failed sign-ins from a single IP, geographic anomalies) and rate-limit accordingly.

2.6 Backup and disaster recovery

• AWS RDS automated backups with 14-day retention, plus point-in-time recovery (PITR) granularity to the second.
• Backups are encrypted with AES-256 and stored in the same AWS region as the primary database.
• We test restore procedures on the development instance regularly; formal disaster recovery drills will be scheduled before enterprise launch.

2.7 Vendor management

We use the sub-processors listed in Section 4. Each is bound by a data processing agreement that limits their use of data to providing services to us. We review each vendor's security posture before engagement and re-evaluate annually.

3. Data retention schedule

The table below is the canonical retention schedule for data collected through Ruya Health.

You may request deletion at any time using the in-app Profile → Delete my account flow, or by emailing support@ruyahealth.com.

4. Sub-processors

We share data with the following sub-processors, each bound by a contract that limits their use of data to providing services to us.

This list is current as of the "Last updated" date. We will update the list before adding new sub-processors that materially expand the categories of data shared.

To receive automatic notification of sub-processor changes, email support@ruyahealth.com with the subject "Subprocessor change notifications".

5. International data transfers

Kimya Labs is based in Massachusetts, United States. Data is stored and processed primarily in the AWS us-east-1 region. If you access the services from outside the United States, your information will be transferred to and processed in the United States.

For users in the European Economic Area, United Kingdom, or Switzerland, we rely on Standard Contractual Clauses with our sub-processors that hold or process data on our behalf, where those clauses apply.

6. Breach notification

If we experience a security incident that compromises information covered by this page, we will:

1. Investigate the scope and impact within 72 hours of detection, where reasonably feasible
2. Notify affected users by email at the address on their account
3. Notify the Federal Trade Commission within 60 days of discovery for breaches involving health information (per the FTC Health Breach Notification Rule, 16 C.F.R. Part 318)
4. Notify the Massachusetts Office of Consumer Affairs and Business Regulation, the Massachusetts Attorney General, and affected Massachusetts residents per the Massachusetts Data Breach Notification Law (M.G.L. c. 93H)
5. Notify other state and federal regulators as required by applicable law
6. For enterprise customers, follow notification timelines defined in the applicable MSA / BAA, which take precedence

We will not over-notify on minor or speculative events.

7. Responsible disclosure

We welcome reports from security researchers. To report a suspected vulnerability:

• Email security@ruyahealth.com
• Include a clear description of the issue and steps to reproduce
• Allow us reasonable time to investigate and remediate before public disclosure (we target 90 days for high-severity issues)

Acceptable testing:

• Use a test account you own (do not access other users' accounts or data)
• Do not run automated scanners that may degrade service
• Do not extract data beyond what is necessary to demonstrate the vulnerability

We will acknowledge receipt within five business days and provide a remediation timeline. We currently do not have a paid bug bounty program; we are happy to credit researchers who follow responsible disclosure (with their consent) on a future security acknowledgments page.

8. Enterprise: Business Associate Agreements

If your organization needs a Business Associate Agreement (BAA) under HIPAA to use platform.ruyahealth.com, contact hello@ruyahealth.com. BAAs become effective only after both parties execute the agreement and the platform environment is configured to meet HIPAA Security Rule technical safeguards for that customer's data.

A signed BAA is required before any Protected Health Information is transmitted to or stored on platform.ruyahealth.com.

9. Children's data

The consumer service is for users 18 and older. We do not knowingly collect data from anyone younger. If we discover that a minor has created an account, we delete it and notify the parent or guardian where contact information is available.

10. Changes to this page

We may update this page from time to time as our security posture and sub-processor list evolve. Material changes will be communicated via in-app banner and (for enterprise customers under contract) per the notice provisions in the relevant MSA.

The "Last updated" date at the top reflects the most recent modification.

11. Contact

For data protection and security questions, including DPA requests, sub-processor inquiries, and responsible disclosure: