Trust

Security and compliance

What the platform does today, what it does not hold, and where it runs. If a claim is not on this page, do not assume it.

Hosting: Fly.io, one region (Ashburn, Virginia, US), managed Postgres. Fly.io's own certifications cover its platform, not Norvya's application.
Agreements: A business associate agreement is required before protected health information is exchanged. Norvya has a BAA with its host.
Report a vulnerability: /.well-known/security.txt on the API host (https://norvya.fly.dev).

What exists

Consent decides what you see

Members choose section by section what your organisation may use. What they have not shared is never computed, and responses say what was held back. Each call is scoped to one organisation.

Pseudonymous references

You never see Norvya's internal ids. A member_ref is an HMAC-SHA256 pseudonym, stable for your organisation and different for every other partner.

Hash-chained audit log

Every read of member data is written to an audit log in which each row carries the hash of the one before; the chain is verified nightly. If the log is unavailable, the read is refused rather than left unrecorded. It makes tampering evident; it cannot stop someone who holds the database credential from rewriting the whole chain.

Small-cell suppression

Population counts from 1 to 4 are withheld (shown as null with suppressed: true); zero is shown. Group reports never name an individual.

Credentials

OAuth 2.0 client credentials. Secrets are stored only as PBKDF2-HMAC-SHA256 hashes (at least 100,000 iterations) and compared in constant time. Tokens last about 15 minutes, carry only the scopes requested, and the client is re-checked on every call, so revocation is immediate.

Staff multi-factor authentication

Required for Norvya administrators and clinic staff accounts (TOTP); without it an account can only enrol. For members it is optional.

Signed, data-free webhooks

HMAC-SHA256 signatures with a per-endpoint secret and a five-minute replay window. Payloads carry a reference to fetch with your token, never health data. Endpoints must be HTTPS on public addresses, checked at registration and on every send; redirects are not followed.

Rate limits

A token bucket per client (and a tighter one for patient matching). It runs per machine, not globally.

Sandbox isolation

Sandbox organisations hold synthetic members only; environment, client, vendor and organisation are re-checked on every call, and any mismatch is refused.

FIPS-ready hashing

Security uses approved algorithms (SHA-256, HMAC, PBKDF2), and non-security hashing is marked as such so the code can run on a FIPS host. This is readiness only: Norvya does not run a validated cryptographic module and claims no FIPS 140-3 validation.

In transit and at rest

HTTPS only, TLS 1.2 or later, with HSTS. Files and stored secrets are encrypted by the application; other clinical data relies on the host's volume encryption.

Backups

Platform snapshots kept 14 days. The first quarterly restore test passed on 30 September 2026.

Vulnerability disclosure

A disclosure policy and /.well-known/security.txt on the API host. It is not a bug bounty.

What Norvya does not have

No SOC 2 report, no ISO/IEC 27001 certification and no HITRUST certification.
No FedRAMP authorization and no Authority to Operate (ATO) of its own; federal work runs inside a prime contractor's authorized environment.
No third-party assessment of any kind: the NIST SP 800-53 and 800-171 documents are self-assessments, and the nightly continuous-monitoring checks are self-run.
No penetration test of the application yet (it is an open plan-of-action item).
No validated FIPS 140-3 module.
Measures are not certified (eCQM-style), and QRDA, UDS and syndromic outputs are not submission-validated.

Known limits

One hosting region and no off-platform copy of backups yet.
Rate limits are enforced per machine, not across machines.
The audit chain detects tampering after the fact; an insert-only database role for the log is an operations step, not enforced in code.

Stated from Norvya's own security documentation and code. Questions: [email protected].