Compliance posture
This page is for the person completing a security questionnaire about Tavrik, or deciding whether it can go near patient data.
What a control mapping is
Section titled “What a control mapping is”Tavrik maintains a control mapping against each framework below. A mapping walks the framework’s controls one at a time and records what Tavrik does about each, and what evidence demonstrates it.
A mapping is the working document used to prepare for an audit. It is the route to a certification rather than a substitute for one, and nobody independent has signed it yet. Read it as the answer we would give and the evidence we would show, which is what you need when scoping a pilot.
Where each framework stands is in the assurance roadmap below.
Frameworks
Section titled “Frameworks”| Framework | Why a hospital asks | Status |
|---|---|---|
| HIPAA | Required for any US healthcare customer, and the basis of the healthcare pack. | Mapped against the Security Rule. A Business Associate Agreement is signed by Tavrik Pty Ltd once readiness is independently assessed. |
| SOC 2 | The default enterprise procurement gate. | Mapped. Security is the committed Trust Services Category. Availability, Confidentiality and Processing Integrity are mapped for Type II. |
| ISO 27001 | Required by many international and government buyers. | Mapped. Certification follows the SOC 2 work. |
| Australian Privacy Act | Governs patient information held by Australian hospitals. | Mapped, including the Notifiable Data Breaches scheme. Tavrik Pty Ltd is a service provider handling data on your behalf. |
| EU AI Act | Phasing in through 2026 and 2027. | Mapped by role. Tavrik is not a foundation-model provider. Where a vertical pack forms part of a high-risk system, your hospital is the provider of that system and Tavrik supplies a component. |
What the product enforces
Section titled “What the product enforces”These are in place today and can be demonstrated live.
- Role-based access control on the admin API, with a closed three-role vocabulary and a permission check on every request that fails closed on an unknown role or action.
- Credentials hashed with Argon2id, never stored or logged in the clear, and shown exactly once at creation.
- Tenant isolation at the database layer, not only in application code.
- Encryption in transit with TLS 1.2 or later, 1.3 by default, and mutual TLS where your systems support it. Provider keys are held as ciphertext and unwrapped in memory at the moment of a call.
- A hash-chained, append-only audit log covering every request, policy decision, redaction and administrative action. Reads of the audit log are themselves audited, so nobody browses it silently. Verification runs on demand over a single event, over a range, or over the whole chain end to end. From the point a deployment moves its chain into the database, that whole-chain verification covers one ordered history; a pre-cutover file-backed record on a deployment that ran two writers against one file is verifiable per event and per branch, not as one ordered history, and is retained with its state recorded in the first event of the chain that replaced it.
- Every change through a reviewed pull request with automated gates.
What your hospital is responsible for
Section titled “What your hospital is responsible for”Tavrik Pty Ltd handles data on your behalf, so several controls can only be satisfied on your side.
- The policy and the data. You decide what your people may send to AI tools and which providers are permitted. Tavrik enforces the decision.
- Identity. Operators sign in through your identity provider. Joiner, mover and leaver processes stay yours, and a revocation in your directory is what removes access.
- The host and the network on the on-premises and dedicated cloud shapes: patching, backups and the perimeter around the machine.
- Retention. Tavrik does not persist prompt or response bodies unless you opt in. If you opt in, the retention period is yours to set.
- Your audit aggregation. Tavrik writes categorical audit events into the systems you already run. Their retention, monitoring and alerting live there.
Evidence available today
Section titled “Evidence available today”For a pilot or a security review: the control mappings themselves, the architecture and data-flow documentation on this site, a live demonstration of audit-chain verification against real events, the third-party dependency inventory with licences, and documentation of exactly what is installed and where on each deployment shape.
Assurance roadmap
Section titled “Assurance roadmap”Four items are scheduled rather than complete. Each is dated.
Independent penetration test. Scheduled ahead of the first pilot go-live, against the deployed configuration a hospital would run. An annual third-party test is the standing commitment after that.
SOC 2 Type I. The auditor is engaged and the observation period begins after the first pilot.
ISO 27001 certification. Follows the SOC 2 work, on the same control set.
Automated evidence collection. Access reviews, change logs and scan results are assembled by hand today. Automating that collection is scheduled alongside the SOC 2 observation period, which is when it starts paying for itself.
Organisational controls that an auditor samples on a schedule, such as security training records, formal access reviews, vendor risk management and tabletop exercises, are designed and begin operating with that observation period.
Asking about something not covered here
Section titled “Asking about something not covered here”Write to security@tavrik.ai. Questionnaire responses are acknowledged within one business day.