Security & Incident Response

Cavitech AI is built to the strictest healthcare-grade standards our current scale allows. Every layer is designed on the principle of defence-in-depth — the compromise of a single subsystem must not expose customer data on its own.

• Encryption at rest: AES-256 on all stored personal and health data (database records, uploaded radiographs, signatures, CBCT volumes, scribe audio, generated reports).
• Encryption in transit: TLS 1.3 between every client, every internal service, and every sub-processor.
• Organisation-scoped isolation: every database query, file-storage lookup, and AI-inference request is scoped to the calling organisation. No cross-practice data access is possible through any public API surface.
• Authentication & session management: Lucia v3 session cookies, 14-day sliding expiration, CSRF protection on every state-changing request, rate-limiting on authentication endpoints.
• Access control: production data access is restricted to named personnel under contractual confidentiality obligations. All access is audited.
• No model training on customer data: our sub-processor agreements (Groq, OpenRouter, Modal, Railway) contractually prohibit the use of customer data for model training. See the Sub-processor list.
• Private inference: our cleared medical-device AI features run on private infrastructure. No patient PHI is transmitted to third-party general-purpose AI APIs for device-classified features.

We notify affected customers of a confirmed security incident without undue delay — and in any event within 72 hours of awareness — consistent with GDPR Article 33, UK-GDPR, POPIA §22, and HIPAA 45 CFR §164.410.

An “incident” is a confirmed or strongly-suspected breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal or health data held by Cavitech.

Our incident response process follows these stages:

• Detect. Automated alerting on authentication anomalies, request-rate spikes, infrastructure alarms from our sub-processors, and reports from the vulnerability-disclosure programme described below.
• Contain. Immediate session revocation, credential rotation, and — where justified — isolation of the affected component while investigation proceeds.
• Investigate. Named Incident Commander coordinates the investigation, maintains a write-only timeline (date, time, action, actor), and determines the scope of any data exposure.
• Notify. Customers are notified directly via the primary billing contact email within 72 hours of confirmed awareness, with updates as investigation proceeds. Supervisory authorities (Information Regulator, ICO, local DPAs, HHS Office for Civil Rights) are notified where required.
• Remediate & learn. Root cause is fixed, controls are strengthened, and a post-incident review is documented. Major incidents trigger an external review.

Notification to customers includes, as far as known at the time: the nature of the incident, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed to address the incident, and the name and contact details of our point of contact.

We welcome responsible disclosure from security researchers, customers, and the broader community. We do not take legal action against researchers who act in good faith under this policy.

How to report

Send a detailed description of the vulnerability to our HIPAA Security Officer at security@kuumba.dev. Include reproduction steps, the affected URL or endpoint, the versions or dates of the observed behaviour, and any supporting screenshots or logs. We will acknowledge receipt within 2 business days.

Good-faith rules

• Do not access, modify, or delete data that does not belong to you.
• Do not perform denial-of-service testing, social engineering of our staff or customers, or physical intrusion attempts.
• Do not publish the vulnerability before we have had a reasonable opportunity to remediate (90 days by default, negotiable for high-severity issues).
• Provide sufficient information to reproduce the issue; vague reports cannot be investigated.

Our commitment to you

• Acknowledgement within 2 business days.
• A triage status update within 10 business days, including a target remediation date for valid findings.
• Public credit (with your permission) in the release notes for the fix, where the finding is confirmed.
• No retaliation, legal threats, or account action against researchers who act within this policy in good faith.

Not in scope: our sub-processors’ infrastructure. Report issues found in Convex, Cloudflare, Groq, OpenRouter, Modal, Railway, Resend, or Vercel directly to the vendor concerned, with a copy to security@kuumba.dev so we can assist with disclosure coordination.

Customer data is retained for the life of the subscription plus a 30-day export window on termination, after which personal and health data is deleted from production systems. Statutory investigational-device evidence (signed consents, acknowledgements, adverse-event records) is pseudo-anonymised rather than hard-deleted to preserve the audit trail regulators require for a minimum of six years under SAHPRA / FDA / MHRA / MDR investigational frameworks. See the Data Processing Addendum §10 for detail.

Every third party that may process customer data on our behalf is listed publicly at /legal/subprocessors with its role, region, and governing privacy statement. We provide reasonable advance notice of any addition or replacement.