How we secure your patients' files

Encryption at rest

Every uploaded file is encrypted at rest with AES-256-GCM using server-side encryption powered by AWS Key Management Service (SSE-KMS). The encryption key is a customer-managed CMK in our AWS account, not a shared AWS-managed key. Each S3 object receives a unique data encryption key derived from the CMK via S3 Bucket Keys, so the compromise of any one DEK affects exactly one transfer.

Bucket policy denies any upload that does not present the correct SSE-KMS header for our CMK, and denies any S3 API call made over plain HTTP. Encryption is not optional and is not enforced only client-side — three independent layers prevent plaintext from landing.

Encryption in transit

Traffic to and from HUUMEDI is encrypted with TLS 1.2 or higher; modern browsers negotiate TLS 1.3. Strict Transport Security is enforced with a 2-year max-age, includeSubDomains, and preload. Browsers refuse downgrades to plain HTTP for the domain.

Two-step recipient verification

Possessing the recipient's download link is not enough to access a file. When a recipient opens the link, they must request a one-time numeric code, which is delivered to the recipient email and is valid for ten minutes. The platform allows at most five verification attempts per code; after that, a fresh code must be requested.

Auto-deletion

The application deletes the S3 object the moment the recipient's download stream completes. If a file is never collected, or if a delete ever fails, an hourly sweep removes it shortly after the 24-hour link expires and records the deletion in the audit trail. Beneath both, an S3 lifecycle rule expires every object at the storage layer, independent of the application; Amazon rounds that expiry up to the next UTC midnight, so it takes effect 24 to 48 hours after upload. The first layer is immediate, the second is bounded and auditable, and the third holds even if the application is entirely broken.

Audit trail

Transfer lifecycle events are appended to an audit log: transfer creation, upload completion, download link sent, code requested, code verified, code failed, file downloaded, file deleted, and transfer revoked. Each row captures the actor, the IP address, the user-agent string, and a timestamp. Access attempts rejected before authentication — an expired link, a revoked transfer — are not currently logged. Authentication events are recorded separately and are not part of this log. Retained for 7 years in keeping with PIPEDA's accountability principle, and enforced append-only at the database level.

Data residency

File contents are stored in AWS ca-central-1 (Montreal). Account information, transfer records, and audit logs are stored in Supabase, also in ca-central-1. Application compute runs in Montreal. We do not store or replicate personal information outside Canada. Our email and payment providers process limited personal information abroad; see the sub-processor list.

Six sub-processors, each with where the company itself is based and where the data it handles resides — not always the same:

• Amazon Web Services Canada, Inc. (storage + key management) — encrypted file contents and the customer-managed encryption key. Canadian company; data in ca-central-1
• Supabase (database) — account details, transfer records including patient names, and the audit log. Company jurisdiction unclear: its terms name a Singapore entity, its privacy policy a United States one; data in ca-central-1
• Vercel (application compute) — in transit, everything the application handles, including patient names and file contents while a download streams. United States company; compute in Montreal
• Upstash (rate limiting) — IP addresses, and email addresses on password-reset requests. United States company; data in Canada
• Resend (transactional email) — sender and recipient email addresses, account name, one-time codes, and single-use token links. Never file contents, file names, file sizes, or patient names. United States company; data abroad
• Stripe (billing) — payment details and account email. United States company; data abroad

Identity and access

Passwords are hashed with argon2id (memory 19 MiB, two iterations, single thread — OWASP 2024 baseline). Email verification is required before the dashboard unlocks. Password reset uses single-use tokens with one-hour expiry.

Backend AWS access is via a least-privilege IAM principal scoped to a single bucket and a single KMS key. The IAM policy grants no wildcards, no “*” resources, no admin actions. The roadmap calls for migrating this to OIDC-based role assumption from Vercel so that no long-lived access keys exist at all.

Application hardening

• Content Security Policy restricts script origins, inline form submissions, and connection targets (outbound connections are allow-listed to our own origin and *.s3.ca-central-1.amazonaws.com)
• frame-ancestors 'none' + X-Frame-Options DENY — HUUMEDI is never embeddable
• Anti-enumeration on auth endpoints (forgot-password returns the same response for known and unknown emails; sign-in runs a dummy hash check for non-existent accounts to equalize timing)
• Per-transfer rate limits on download code requests (5 per transfer per hour)
• All input validated server-side, including MIME-type allow-list (DICOM, PDF, JPEG, PNG, ZIP, STL, PLY) and 5 GB file cap

Compliance posture

HUUMEDI is built specifically for the Canadian regulatory environment.

• PIPEDA — federal baseline for personal information handling
• Quebec Law 25 — additional consent, breach notification, and Privacy Officer requirements for transfers involving Quebec residents
• Provincial health-information statutes (PHIPA in Ontario, HIA in Alberta, etc.) — applicable to the dental clinic as the custodian; HUUMEDI provides the technical safeguards needed to support clinic compliance

We are not HIPAA-regulated (we operate in Canada, not the United States) and do not offer a Business Associate Agreement.

Responsible disclosure

If you believe you've found a security vulnerability, please email security@huumedi.com with details and reproduction steps. We commit to acknowledging reports within 48 hours and to working in good faith with researchers acting in good faith — we will not pursue legal action against research that:

• Does not access, modify, or destroy other users' data
• Does not degrade the service for other users
• Does not publicly disclose the issue before we've had a reasonable opportunity to remediate

Incident response

In the event of a confidentiality incident involving personal information, we will:

1. Contain the incident and preserve evidence
2. Notify affected individuals and the applicable supervisory authority (OPC under PIPEDA; CAI under Law 25) as soon as feasible after determining a real risk of significant harm
3. Conduct a post-incident review and publish a redacted summary