Security Overview

Effective 19 July 2026 · Version 1.0 · For privacy officers, security reviewers and procurement

1. What this document is, and what it is not

This describes the security controls in place today, honestly and specifically. It is written for someone whose job is to find the gap.

We are not SOC 2 certified and we do not hold ISO 27001. No third party has audited these controls. Vivantal is operated by an individual developer, pre-pilot, with no clinical deployments. Where a control does not exist, this document says so rather than describing an aspiration in the present tense.

2. Data-flow: where protected health information does and does not go

The distinction that governs everything below is between clinical records and account data. They travel entirely different paths.

Clinical records: never leave the device

• A record is read from the user's file system or clipboard into browser memory.
• Parsing, de-identification (the Transcriptor), rule evaluation, suppression, equity analysis and ranking all execute in that browser tab.
• Results render locally. Nothing is persisted server-side; nothing is transmitted.
• Closing the tab discards it. We hold no copy, because we never received one.

Because no clinical record reaches our infrastructure, there is no server-side store of ePHI to encrypt, back up, breach, or subpoena. The strongest control here is architectural: the data is not in our custody.

Account data: the only thing we receive

• Email address, a hashed password (handled by our authentication provider), an organisation name the user supplies, role, and non-clinical preferences.
• Audit counts: how many records an analysis covered and how many were critical. Never which patients, never a clinical value, never an identifier.
• Billing identifiers, if the user subscribes. Card details go directly to Stripe; we never receive or store them.

The optional local agent

Vivantal Autopilot can run as a command-line agent on a clinic's own machine. It reads local exports and writes local briefs. It is covered by a separate automated test asserting it makes no outbound network calls, because it is the one component that may hold real medical record numbers. Its re-identification keymap is encrypted at rest with AES-256-GCM and PBKDF2 (600,000 iterations).

3. Technical safeguards

• Encryption in transit. HTTPS enforced site-wide; HSTS with a one-year max-age, includeSubDomains and preload.
• Encryption at rest. Account data is encrypted at rest by our database provider. The local agent's keymap is encrypted with AES-256-GCM / PBKDF2-600k.
• Content Security Policy. script-src 'self' with no unsafe-inline, object-src 'none', frame-ancestors 'none', base-uri 'self'. Third-party script execution is blocked, which also means no injected script can exfiltrate what is on screen. Fonts are self-hosted; no CDN receives a user's IP address.
• Authorisation. Every endpoint exposing a paid capability verifies both identity and entitlement server-side, reading the plan from the database rather than from the request. These checks fail closed: a misconfiguration or lookup failure denies access rather than granting it.
• Tenant isolation. Row-level security policies are enforced in the database on every user-facing table, so a user's session can reach only their own rows. Entitlement columns are additionally protected by column-level privilege revocation, so a client cannot write its own plan or role even if a policy were later loosened.
• Rate limiting. Per-user hourly ceilings on every endpoint that costs money, with limit breaches recorded for review.
• Output encoding. Uploaded record content is escaped before rendering. A sink inventory is asserted by an automated test, on the principle that script running in a page holding clinical data would defeat every other control here.
• Real-time sessions. Co-review sessions are peer-to-peer; the server carries signalling only. Joining requires explicit host approval, so a leaked session code is not sufficient for entry.

4. Administrative and organisational safeguards

Stated plainly, because overstating this is where small vendors lose credibility:

• Access. One person (the operator) has production access. There is no support team with a console, because there is no support console.
• Change control. Every deployment runs an automated gate suite covering authentication, entitlement, output encoding, de-identification, no-egress, and clinical rule correctness. A failure blocks the release. The deploy also refuses to publish if a re-identification keymap or research corpus is present in the bundle.
• Least privilege in the data layer. The browser holds read access to its own rows and insert access to three non-sensitive columns. It has no update privilege on the users table at all.
• What we do not have. No formal security training programme, no dedicated security officer, no penetration test by a third party, no SOC 2 or ISO certification, no bug bounty. These are appropriate gaps for the current stage and we do not pretend otherwise.

5. Subprocessors

Complete list. Each is verifiable in the source served to your browser.

No analytics, advertising, session-recording, error-reporting or crash-capture service is used. There is no mechanism by which record content could reach a third party incidentally. We will update this list before adding a subprocessor, not after.

6. Incident response and breach notification

The realistic incident surface is account data, not clinical data, because clinical data is not in our custody. Our commitments:

• Report an issue. security@vivantal.com. We acknowledge within 2 business days. We will not pursue legal action against good-faith security research that avoids privacy violations and service degradation.
• Containment. On confirming an incident we revoke affected credentials, rotate secrets, and deploy a fix ahead of any other work.
• Notification. Affected users are notified without undue delay and within 72 hours Of confirming a breach of personal data, by email to the account address. The notice states what happened, what data was involved, what we have done, and what you should do.
• Regulatory notification. Where a breach triggers obligations under HIPAA, state breach-notification law, or GDPR Article 33, we will make the required notifications and support any covered entity's own obligations with the facts we hold.
• Post-incident. We publish what happened. A vendor's incident history is more informative than its certification list.

7. Business continuity

Honest limits: Vivantal is operated by one person. There is no 24/7 on-call rotation and no contractual uptime SLA on free or self-serve plans. Because analysis runs in the browser, a Vivantal outage does not stop a clinician from analysing a record they already have open — the failure mode is inability to sign in or subscribe, not loss of clinical function or data.

8. Verify rather than trust

Two things you can check without contacting us:

• Open developer tools, select the Network tab, and run an analysis. Confirm no request carries record content. Our live self-audit page walks through this.
• Inspect the response headers on any page for the CSP and HSTS values described above.

For a security questionnaire, DPA, or Business Associate Agreement, write to partnerships@vivantal.com. See also the Data Processing Addendum and our regulatory position on device classification.

← Back to Vivantal · Privacy Policy · Terms of Service · DPA · Trust & Safety

Research & quality-improvement tool — not a diagnostic device. Vivantal surfaces process gaps for human review. It does not diagnose.