MedIQGPT
MedIQGPT
Back to Policies

Data Security Policy

An honest description of how MedIQGPT secures your medical records in Phase 1 of the platform.

Effective Date: February 19, 2026

1. Overview

MedIQGPT is currently in Phase 1 of its security architecture. We are committed to being transparent about the controls that are in place today and what additional protections are on our roadmap. We will never claim a security control that is not fully implemented.

This document describes the security measures that are active and enforced in the current production environment, operated by DialectAI Technologies Private Limited.

2. Document Storage - Cloudflare R2

All uploaded medical documents (PDFs, images, scans) are stored in Cloudflare R2, Cloudflare’s S3-compatible object storage service.

  • Encryption at rest: Cloudflare R2 encrypts all objects using AES-256-GCM by default. This is on for every object stored - no additional configuration is required from our side or yours.
  • Encryption in transit: All data transferred to and from R2 is encrypted using TLS (HTTPS). Unencrypted HTTP connections are rejected.
  • Access control: R2 buckets are private. Access is granted only through short-lived signed URLs generated by our API for authenticated users. There is no public read access to any storage bucket.
  • API token security: R2 API credentials are stored as environment secrets and are never exposed to client-side code.

3. Database & Row-Level Security

User account data, document metadata, family groups, roles, and audit logs are stored in Supabase Postgres, deployed as a self-hosted Docker instance.

  • Row-Level Security (RLS): Every table containing user data has Postgres RLS policiesenabled. No row can be read, written, or deleted unless a matching RLS policy explicitly permits it based on the authenticated user’s identity and role.
  • Role isolation: Four roles are enforced at the database layer - owner, family_member, care_provider, and admin. RLS policies check auth.uid() and the JWT role claim for every query.
  • Family-group scoping: Data belonging to a family group is isolated by a family_group_id. Members can only access records of groups they have been explicitly added to.
  • No bypass: Even if application code contains a logic error, RLS is enforced at the database engine level - the data layer cannot be bypassed by API mistakes.
  • Audit logging: Every significant access event (view, download, share, export, role change) is recorded in an immutable audit log table.

4. Authentication

Authentication is handled by Supabase Auth (self-hosted). Supported sign-in methods:

  • Email and password (with secure password hashing via bcrypt).
  • Google OAuth 2.0.
  • Twitter / X OAuth 2.0.
  • Apple ID Sign-In.

Additional authentication security measures:

  • JWT sessions:Sessions are represented as short-lived JWTs. The API layer verifies tokens against Supabase’s JWKS endpoint on every request.
  • Session management: Users can view and revoke active sessions from Settings → Security.
  • Two-factor authentication (2FA): TOTP-based 2FA is available and strongly recommended for all accounts.

5. Data in Transit

  • All connections between your device and our API are over TLS 1.2 or higher.
  • Connections to Cloudflare R2, Supabase, and external AI processing APIs (Azure OpenAI) are made over TLS.
  • HTTP requests are redirected to HTTPS at the Cloudflare and Nginx layers.

6. SOC 2 Alignment

DialectAI Technologies Private Limited maintains internal security practices and controls aligned with the SOC 2 Trust Service Criteria, including the principles of Security, Availability, Processing Integrity, Confidentiality, and Privacy.

The following controls are actively implemented:

  • Encryption of data in transit using TLS protocols
  • Encryption of data at rest (AES-256-GCM via Cloudflare R2)
  • Role-based access control (RBAC) enforced at the database layer
  • Multi-factor authentication for account and administrative access
  • Secure cloud infrastructure with continuous availability monitoring
  • Audit logging of system activity and administrative actions

A formal SOC 2 Type II audit by an independent third-party assessor is planned prior to regulated-industry scale deployment. We will publish audit results when available.

7. Security Controls Not Yet in Scope (Phase 1)

We believe in being upfront about what we have not yet implemented so you can make an informed decision:

  • Field-level encryption in the database: Document metadata in Postgres is protected by RLS but is not encrypted at the field level. Full field-level encryption (using per-family encryption keys wrapped by a KMS) is planned for Phase 2.
  • Client-side encryption before cloud upload: Documents are encrypted by R2 at rest, but are not additionally encrypted client-side before upload in Phase 1. Client-side envelope encryption is on the Phase 2 roadmap.
  • HIPAA / DPDP Act formal third-party certification: The Company actively follows HIPAA and DPDP Act compliance principles in its data handling, access controls, and breach response procedures. However, formal third-party certification and independent audit have not yet been completed. These are targeted for completion before regulated-industry scale deployment. Users in strictly regulated industries should factor this into their evaluation.
  • Third-party security audit: An independent penetration test and security audit has not yet been completed. We plan to commission one before launching paid tiers at scale.

8. Incident Response

In the event of a confirmed security breach affecting user data:

  • We will notify affected users by email within 72 hours of confirming the breach.
  • Notification will include: what happened, what data was affected, steps we have taken, and what you can do to protect yourself.
  • We will report to relevant authorities as required by applicable law (DPDP Act, GDPR, or applicable US state laws).

9. Responsible Disclosure

If you discover a security vulnerability in MedIQGPT, please disclose it responsibly by emailing us before making it public. We commit to:

  • Acknowledging your report within 48 hours.
  • Providing a status update within 7 business days.
  • Not pursuing legal action against good-faith researchers.
  • Crediting you (with permission) when the issue is fixed.

10. Security Contact