HIPAA & BAA Posture

Navaryn is operated by Jeskel Group LLC. When a HIPAA covered entity - a health center, hospital, clinic, or their business associate - uses Navaryn, Navaryn acts as a Business Associate as that term is defined at 45 CFR 160.103.

We say this plainly because vendors sometimes do not. Navaryn receives, encrypts, stores, and processes Protected Health Information (PHI) on your behalf, and we are directly liable under the HIPAA Security Rule and the applicable provisions of the Privacy Rule and the Breach Notification Rule for doing so.

We execute a Business Associate Agreement (BAA) with every customer organization BEFORE any PHI is transmitted to the platform. It is part of onboarding for every customer, not an add-on and not a feature of a particular plan tier.

Our BAA template is in final legal review. The version you sign will be the reviewed version, and you are welcome to redline it. If your organization requires its own BAA form, send it and we will work from yours.

We will not accept production PHI from an organization that has not executed a BAA with us.

Depending on which workflows you use, Navaryn may hold patient identifiers (such as name, date of birth, medical record number, and account or member numbers), the documents and records your staff upload or import, and the operational metadata generated as your team works those records.

Patient identifiers are stored two ways at once: as keyed one-way hashes used for matching, and as ciphertext in an encrypted vault used for display to authorized staff. The matching index cannot be reversed to recover the identifier; the vault can be, and every reveal is authorized and audited as described below.

Before any content is sent to an AI model, Navaryn's tokenizer replaces the patient identifiers it finds with opaque tokens. A value it cannot confidently classify is tokenized anyway and the record is held for a person to confirm - never guessed at, never left raw.

Every AI call in the platform goes through a single gateway that sits behind the tokenizer, so there is one place to inspect rather than a policy to trust. The patient-matching path makes no AI-model call at all.

We do not use the content of your compliance work, or any PHI, to train AI models.

• Patient identifiers encrypted with AES-256-GCM in a vault readable only by the server-side service role
• Organization-scoped row-level security enforced in the database on every table in the application schema, in addition to application-layer checks - and forced on the tables holding identifiers, so not even the table owner can bypass a policy
• An append-only, hash-chained audit log: INSERT is restricted to a dedicated database writer role, and UPDATE and DELETE are denied to every application role, administrators included
• Every PHI reveal writes its audit row BEFORE the value is served, and the value is withheld if that write fails
• Uploaded files are virus-scanned on the raw bytes before any parser or extractor reads them
• TLS for all data in transit; all storage and processing in United States AWS regions
• Deployments are atomic and roll back automatically on a failed health check

A notice that lists only what exists is not much use to someone evaluating risk. As of the date below:

• We do not hold a SOC 2 report of any type
• No third-party penetration test has been performed
• Multi-factor authentication is not available; neither is SSO/SAML
• There is one platform encryption key rather than per-organization keys, and no scheduled rotation
• Business associate agreements with our infrastructure subcontractors are being put in place ahead of our first production customer

We do not transmit production PHI to a subcontractor before the agreement covering it is executed, and we will not accept production PHI before the items a customer's risk analysis requires are addressed. If a specific control is a condition of your pilot, tell us and we will sequence it.

If we discover a breach of unsecured PHI, we will notify the affected covered entity without unreasonable delay and within the timeframe set out in the executed BAA, and in any event no later than the outer limit permitted by 45 CFR 164.410. Our notice will identify the individuals affected so far as we can determine, what happened, when, and what we are doing about it.

The hash-chained audit log exists so that the answer to “what was accessed” is reconstructable rather than estimated.

Access within the platform is role-based with least-privilege defaults, and every privileged action is checked on the server and again by database policy.

You can request an export of your organization's data at any time. On termination, we return or destroy PHI in accordance with the executed BAA, except where retention is required by law - audit records inside their required retention period cannot be deleted, and the BAA says so explicitly.

For HIPAA, security, or BAA questions:

**Jeskel Group LLC - Navaryn** security@navaryn.com

For privacy questions: privacy@navaryn.com

This notice supplements our Privacy Policy and Terms of Service. Where this notice and an executed Business Associate Agreement differ, the BAA controls.