Introduction

This page describes how Velarya LLC ("Velarya," "we," "us," or "our") protects practice data and client data across the Velarya platform, including the Velarya mobile applications, the clinic dashboard, and the Velarya API. It is written for practice owners, their security reviewers, and their advisors, and it describes controls that are implemented in the platform today.

Velarya is a technology provider and does not deliver medical services. Velarya acts as a Business Associate to the practices that use the platform, under a Business Associate Agreement executed with each practice before any protected health information is processed.

1. Where Your Data Lives

The Velarya platform runs on Amazon Web Services in the US East (Northern Virginia) region. All production data, including the application database, uploaded files, and encryption keys, is stored and processed inside the United States, and production data stays within that footprint.

A Business Associate Addendum is in place between Velarya and Amazon Web Services, covering the services used to host the platform.

2. Encryption

Clinical data at rest. Clinical free-text fields are protected with field-level envelope encryption, implemented against HIPAA Security Rule 164.312(a)(2)(iv). The cipher is AES-256-GCM, an authenticated cipher, so any tampering with stored ciphertext is detected on read rather than silently returned.

Key hierarchy. Data encryption keys are generated by AWS Key Management Service under a customer-managed key dedicated to clinical field encryption, with automatic key rotation enabled. Plaintext data keys exist only in process memory; only the wrapped form is persisted alongside the ciphertext. An active data key is retired after one hour or 50,000 operations, whichever comes first, and a new key is minted from KMS.

Practice binding. The practice identifier is bound to every ciphertext as additional authenticated data. Ciphertext belonging to one practice cannot be decrypted in the context of another, even if an underlying record were somehow misrouted.

Fail-closed by design. The service refuses to start, and refuses to write, unless an encryption key is configured. Every write path for clinical free text runs through the encryption layer.

Files and images at rest. Before-and-after photography, documents, and other uploaded files are stored in Amazon S3 with server-side AES-256 encryption applied on every object write. File access is granted through short-lived presigned URLs rather than public object permissions.

Data in transit. All application and dashboard traffic is served over TLS. HTTP Strict Transport Security is set with a one-year max-age and applies to subdomains, so browsers refuse to downgrade to plaintext HTTP. The application connects to the database with TLS required.

3. Authentication and Access Control

How people sign in. Velarya uses one-time passcode authentication delivered by SMS or email, so there is no password for a practice to manage, reuse, or have stolen.

Sessions. Authenticated sessions use short-lived signed access tokens, valid for fifteen minutes, paired with longer-lived refresh tokens. Refresh tokens are stored only as SHA-256 hashes, so a database disclosure yields no usable session. Refresh tokens rotate on every use; if a previously rotated token is ever presented again, the platform treats the chain as compromised, revokes every session for that user, and records the event in the audit log. Account status is re-checked on every refresh, so a deactivated account stops working immediately rather than at the end of a token lifetime, and sessions can be revoked server-side at any time.

Abuse resistance. Passcode request, passcode verification, session refresh, and session validation are each independently rate limited, and those limits are enforced in shared storage rather than per server, so they hold under load. Passcode verification runs against a fixed timing floor and returns an identical response for accounts that do not exist, so the endpoint cannot be used to discover who holds an account.

Network restrictions. A practice may restrict staff dashboard access to a defined set of IP addresses.

What people can see. Access is governed by a role and permission model rather than by a single administrator flag. Permissions are declared per resource, and every resource that carries protected health information is explicitly marked as such, so clinical access is gated separately from operational access. A front-desk role can be granted scheduling access without being granted chart access, and staff can be scoped to specific locations. Denied access attempts are written to the audit log rather than silently dropped.

Support access. When Velarya support needs to view a practice's account, it happens through an explicit, time-boxed impersonation session that expires automatically and is recorded on every resulting audit record, so support activity is always distinguishable from practice staff activity.

4. Tenant Isolation

Velarya is a multi-tenant platform, and separation between practices is enforced at every layer. Every application query is scoped to a single practice using the identifier carried in the verified session token, never a value supplied by the caller; a request that attempts to assert a different practice is rejected. Reporting and analytics endpoints are hard-scoped to one practice, with no cross-practice aggregation path. Encryption binds ciphertext to the owning practice, as described in section 2. A dedicated regression suite asserts, for every surface that touches protected health information, that a session belonging to one practice cannot reach another practice's data, including when the caller forges request headers or guesses record identifiers.

5. Audit Logging

Every route that touches protected health information writes an audit record, implemented against HIPAA Security Rule 164.312(b). The log is append-only and records are retained rather than deleted.

Each record captures the practice the request belonged to; the acting user; the administrator acting under a support impersonation session, where one applies, recorded separately from the acting user; the action, resource type, and resource identifier; the HTTP method, path, and response status; the originating IP address and user agent; and the timestamp. Both successful access and denied access attempts are recorded.

6. Application and Platform Security

Edge protection. A web application firewall sits in front of the API and filters traffic before it reaches the application. It runs managed rule sets for common web exploits, known-bad inputs, and SQL injection, blocks traffic from IP addresses with known malicious reputation, and applies per-address request caps, with a tighter cap on authentication endpoints so credential-stuffing attempts are blocked within a minute. The real client address is established at the edge and cannot be spoofed by a forged header.

Monitoring and alerting. Production carries automated alarms on firewall block spikes and on authentication rate-limit events, so sustained attack traffic and credential-stuffing signals raise an alert rather than waiting to be noticed.

Secrets management. Application secrets and encryption key identifiers are held in AWS Secrets Manager and injected at runtime, and are kept out of source control. Credentials are separated by blast radius, so a single disclosure does not hand over multiple systems, and highly sensitive credentials such as per-practice app signing keys are written by one component and readable only by another.

Least privilege. Each component holds only the permissions it needs. The application can generate and decrypt clinical data keys, and nothing more, on the key dedicated to that purpose.

Hardened responses. API responses carry a hardened security header set, including HSTS, content type options, frame options, and referrer policy. Request bodies are validated against explicit schemas at the route boundary, and errors are returned through a sanitizing layer so internal detail, including database structure, is not exposed to callers.

7. Security Review and Testing

How often we review. Security review at Velarya is continuous rather than occasional. Every change that touches protected health information, permissions, or audit surfaces gets a targeted security review before it ships, and the platform additionally receives periodic full-codebase security audits, the most recent of which was completed in June 2026. Findings from every audit are tracked to closure and covered by regression tests so the same class of issue cannot return unnoticed.

What ships to production. The platform is covered by an automated suite of more than 8,000 tests, including suites that specifically assert permission enforcement, cross-practice isolation, and data purge behavior on offboarding. A production release runs the full type check, the complete test suite, and a database migration lineage check, and any failure stops the release. Coverage thresholds are enforced in continuous integration. Production deploys are a deliberate, human-initiated action, never an automatic consequence of a code push, and schema changes are applied through a reviewed migration pipeline rather than at runtime.

8. Subprocessors

Velarya uses the following subprocessors, each of which may process protected health information in the course of delivering the service:

Amazon Web Services, Inc. Compute, database, object storage, key management, and secrets management.

Stripe, Inc. Card processing and payment method storage. Card numbers are handled by Stripe and are not stored on Velarya systems.

Twilio Inc. SMS delivery, including appointment reminders and sign-in passcodes.

Twilio SendGrid. Transactional email, including sign-in passcodes and receipts.

Google LLC (Firebase Cloud Messaging). Mobile push notification delivery.

Velarya requires every subprocessor that handles protected health information to be bound in writing by restrictions at least as protective as those Velarya owes the practice, as provided in the Business Associate Agreement. Velarya will confirm the current status of each subprocessor agreement in writing on request, and will notify the practice before adding a subprocessor that will handle protected health information.

Velarya never sells practice data or client data, and never uses it to train third-party machine learning models.

9. Data Ownership, Export, and Deletion

Ownership. The practice owns its practice data and its client data. Velarya processes that data to provide the service and for no independent purpose.

Export. A practice administrator can export the client list to a CSV file directly from the dashboard at any time, without contacting Velarya and without a support ticket. The export is permission-gated and audit-logged like any other access to client data.

Deletion. A practice can archive or permanently delete a client record. Permanent deletion purges the associated records rather than hiding them from the interface. Velarya publishes an account deletion route for individual app users at velarya.com/legal/account-deletion.

Retention. On account deletion, personal information is deleted or anonymized within 30 days, except where retention is required by law or regulation.

On termination. Velarya returns or destroys protected health information at the practice's direction, as set out in the Business Associate Agreement.

10. Incident Response

Velarya monitors the platform with automated alerting on production error conditions and on the attack signals described in section 6.

In the event of a breach of unsecured protected health information, Velarya notifies the affected practice without unreasonable delay and no later than ten business days after discovery, and provides the information the practice needs to meet its own notification obligations under 45 CFR 164.404. Reporting obligations, including for unsuccessful security incidents, are set out in full in the Business Associate Agreement.

11. Compliance Posture

HIPAA. Velarya operates as a Business Associate and executes a Business Associate Agreement with each practice before protected health information is processed. The administrative, physical, and technical safeguards described on this page implement the Security Rule requirements cited throughout.

Amazon Web Services. A Business Associate Addendum is in place with Amazon Web Services covering the services used to host the platform.

Demonstrable controls. Every control described on this page is implemented in the platform and can be demonstrated on request, including a walkthrough of the encryption, permission, and audit surfaces with Velarya's engineering team. Velarya will provide its full Security and Privacy Overview, its Business Associate Agreement, and written confirmation of subprocessor status to any practice or advisor who asks.

Practice responsibilities. The practice remains the Covered Entity. Determining whether HIPAA applies to a given use, managing its own workforce access, and meeting its own notice and consent obligations remain with the practice.

12. Contact

Security questions, documentation requests, and vulnerability reports are welcome. Velarya reviews every report received and will acknowledge it.

Velarya LLC Email: hello@velarya.com Website: https://velarya.com