New AI-assisted clinical decision support and dental imaging features are now available Free Demo →

Trust & Security at WIO CLINIC

Built like the clinic it serves: serious, layered, and accountable.
Healthcare data is high-sensitivity, regulator-watched, and irreplaceable. This page is for the security officers, IT leaders, and procurement teams who need to know what we actually do — not what the marketing brochure says. Where specific contractual details belong under NDA, we point that out instead of inventing numbers.
1. Security overview

WIO CLINIC is a multi-tenant clinical operations platform designed around the realities of healthcare data: high sensitivity, regulatory complexity, strict per-clinic isolation, and the absolute requirement that patient data never be lost, leaked, or corrupted.

Security is not a single feature. It is a layered architecture spanning authentication, authorization, encryption, audit logging, input validation, infrastructure hardening, and operational discipline. Each layer assumes the others might fail, so a breach in one does not become a breach across all.

The platform is built multi-tenant from the schema up, with strict data isolation between organizations and clinics. Audit trails are immutable from the customer side and queryable through the clinic admin console.

2. Authentication
Signed token authentication
Industry-standard signed authentication tokens, stored in HttpOnly cookies — never accessible to client-side JavaScript, which eliminates an entire class of token-theft attacks. Tokens are bound to an explicit account type and a defined session expiration window, refreshed on activity, and validated against the clinic context on every protected request.
Multi-portal authorization
The platform supports five distinct portal classes — Clinical, Organization Admin, Lab Partner, System Admin, and Patient. A user authenticated for one portal cannot access endpoints from another. The separation is enforced at the gateway, not by application code.
Per-clinic session policy
Each clinic chooses its session policy: multi-device (users can log in from multiple devices simultaneously) or single-device (logging in from a new device automatically terminates the previous session). This is a clinic-administrator-controlled setting, surfaced in the org console under Security settings.
Device fingerprinting & suspicious-login detection
Every authenticated session is associated with a device fingerprint computed from request characteristics. Unfamiliar device patterns, unusual geography, and impossible-travel events can be surfaced for review or trigger forced re-authentication.
Multi-factor authentication
Multi-factor authentication is supported and recommended for clinic admin and organization admin roles, with progressive backoff and lockout on failed attempts.
3. Authorization
Role-based access control modeled on real clinic roles
The platform ships with role definitions appropriate to healthcare environments: System Admin, Organization Admin, Clinic Admin, Physician (with optional Chief Physician flag), Assistant (with optional Nurse flag), Lab Technician, Receptionist, Accountant, IT Staff, Patient, and a base authenticated User. Custom role compositions are supported for clinics with unusual organizational structures.
Granular permissions across functional modules
Beneath roles sit dozens of granular permissions organized across roughly fourteen functional modules: Patient Management, Appointment Management, Treatment Management, Financial Management, Inventory Management, User Management, Clinic Management, Organization Management, Tenant Management, System Management, Reporting, File Management, Communication, and Consultation. Permissions follow a consistent verb pattern (view, create, edit, delete, export, approve).
Per-clinic permission scopes
A single user can be assigned different permissions in different clinics within the same organization. A receptionist in one clinic can be a manager in another. The permission system models this natively, without requiring duplicate user accounts.
4. Encryption
Encryption in transit
All API and web traffic is encrypted in transit using modern transport-layer cryptography. Unencrypted HTTP is not accepted on any endpoint.
Encryption at rest, with field-level protection
Sensitive personally identifiable information and protected health information is encrypted at the field level in the database, beyond the disk-level encryption provided by the storage layer. A database backup file, taken alone, does not expose decrypted patient data.
File storage encryption
Patient documents, clinical images, and other uploads are stored in cloud object storage that encrypts data at rest. Files are accessed through short-lived signed URLs — every download is auditable and time-limited.
Encryption key rotation
The system supports encryption key rotation through operational tooling. Keys can be rotated periodically without downtime, and the system maintains backward compatibility with prior keys during transition windows.
5. Audit logging

The platform maintains comprehensive audit trails of all sensitive operations. Audit logs are immutable from the customer side — they can be queried and exported but not modified or deleted by end users. They are scoped per clinic and viewable by clinic admins through the org console.

Authentication & authorization events
Login, logout, failed attempts, password resets, MFA challenges, permission grants, role changes.
Patient data access and modification
Patient access events are recorded as part of the audit trail. Every create, edit, and delete carries before/after values, the acting user, and a timestamp.
Financial operations
Every payment, refund, invoice generation, and cash register operation is logged with elevated detail for accounting reconciliation and audit-readiness.
System administration
Role changes, permission updates, and clinic configuration changes are tracked separately from operational logs and retained per the clinic's policy.
6. Multi-tenancy

The platform is built multi-tenant from the schema up. Cross-tenant data leakage is architecturally impossible, not merely policy-prohibited.

Hierarchy
Organization → Tenant → Clinic → Branch → Department → Room. Each level provides its own configuration, data isolation, and user assignment options. The same platform serves a solo practitioner and a multinational dental group without ceremony for the solo case.
Isolation guarantees
Every record in the database carries its tenant ID and (where applicable) clinic ID. Every query is automatically scoped by the user's tenant and clinic context. Cross-tenant queries are not possible through standard API paths.
Shared vs. isolated data
Patient demographics, treatment libraries, and settings can be shared at the organization or tenant level when explicitly configured. Clinical records and financial records are isolated to the clinic by default. Cross-clinic patient access is permission-gated and audited.
7. Compliance posture

WIO CLINIC provides the technical safeguards expected of a healthcare platform. Compliance for a given clinic is a property of the combined system — your policies, our platform, and the workflow execution. We provide the platform-level foundation; you maintain the program.

Privacy-by-design principles
Data minimization (only data needed for clinical operations is collected), purpose limitation (patient data is used only for explicit consented purposes), storage limitation (retention rules configurable per clinic), and first-class patient rights (export, deletion, correction).
GDPR-aligned capabilities
Right of access (full patient data export), right to rectification (with audit trails), right to erasure (with cascading deletion and audit logs of the deletion itself), right to data portability (machine-readable formats), privacy audit logs.
HIPAA-aligned capabilities
Access controls, audit logging, encryption, integrity controls, and transmission security. Per-user accountability for every patient data access. Session management appropriate to clinical environments.
Regional healthcare compliance
Integrations with national healthcare and prescription systems where required by regional regulations. Tax and invoicing compliance configurable per jurisdiction. Identity document validation appropriate to the region.
Patient consent management
Versioned consent templates, electronic signatures with timestamp and identity binding, PDF generation for archival, multi-language consent forms, and per-clinic consent compliance validation.
Data sovereignty
The platform is deployed in distinct regional infrastructure clusters. Customer data does not cross regional boundaries except when the customer explicitly enables it. Each clinic's data resides in the region appropriate to its regulatory environment.
8. Backups & disaster recovery

Reliability is earned through consistent operational discipline, not just stated as a number. Specific cadence, retention windows, RTO/RPO targets, and infrastructure region details are available in the security packet under NDA — request it via your sales contact or security@wio.clinic.

Continuous backup program
Regular automated backups of database and file storage, with retention policies aligned to clinical and regulatory needs. Backups are a monitored program, not a script someone hopes still runs.
Restoration tested as a discipline
Restoring a backup is the only proof that the backup worked. Restoration drills are part of the operational rhythm — backups exist to be restored, not just held.
Multi-region redundancy for file storage
Patient documents and clinical images sit in geographically distributed object storage so a single facility failure does not take patient data with it.
Documented incident response
When something goes wrong, the response is rehearsed, not improvised. Incident response procedures are maintained by the operations team and reviewed on a recurring cadence.
Operational hygiene
Configuration validation at startup (the system refuses to boot with missing or invalid secrets), memory-safe background processing under sustained load, automated cleanup of expired sessions and stale signaling data, and stateless application servers that can be added or removed without coordination.
9. Responsible disclosure

We welcome reports from security researchers and customers who identify potential vulnerabilities in WIO CLINIC.

How to report
Email security findings to security@wio.clinic with a clear description of the issue, reproduction steps, and any impact you observed. Encrypted communication is available on request.
What to expect
We acknowledge initial reports promptly, triage based on severity, and keep the reporter informed of progress through to remediation. We do not pursue legal action against good-faith researchers who follow responsible disclosure principles.
Scope
In-scope: production WIO CLINIC services and customer-facing APIs. Out-of-scope: social engineering, physical attacks on offices, denial-of-service testing without prior coordination, and testing against tenant data you do not own.
10. Contact & security packet

For procurement, security questionnaires, and architecture documentation:

Security packet (NDA-gated)
Architecture diagrams, infrastructure region details, backup cadence and retention specifics, RTO/RPO targets, certification reports, and data processing agreements are available under NDA. Request via security@wio.clinic or your sales contact.
Request security packet
Security contact
security@wio.clinic — for vulnerability reports, security questionnaires, and procurement due diligence.
General contact
For non-security inquiries, hello@wio.clinic.
Talk to sales
This page describes platform-level capabilities. Final compliance for a healthcare provider is a property of the combined customer + platform + workflow system. The platform alone is not a compliance program — it is the foundation a compliance program can be built on.