Security

OralOS runs entirely on AWS in Frankfurt, Germany (eu-central-1) . inside the EU data protection boundary. No data is stored outside this region without explicit notice.

Application containers run on Amazon ECS (Fargate). The database is Amazon RDS PostgreSQL in a Multi-AZ deployment . automatic failover to a standby instance occurs within seconds if the primary becomes unavailable.

Redis (Amazon ElastiCache) is used for session caching and background job queuing. All Redis instances are deployed in private subnets with no public internet exposure.

Static assets and the marketing site are served via Amazon CloudFront (CDN). Infrastructure is defined entirely in Terraform . no manual console changes are made to production.

All services run inside a dedicated VPC with strict security group rules. No application database or cache port is reachable from the public internet.

AWS WAF (Web Application Firewall) is deployed in front of all public-facing endpoints to detect and block common web attack patterns (SQL injection, XSS, SSRF, malformed requests).

AWS Shield Standard provides automatic DDoS mitigation on all CloudFront and load balancer endpoints. Rate limiting is enforced at the API gateway layer to limit brute-force and credential-stuffing attacks.

Internal service-to-service communication stays within the VPC and uses IAM roles rather than shared credentials. No inter-service traffic leaves AWS infrastructure unencrypted.

All data in transit is encrypted with TLS 1.2 or higher. HTTP is automatically redirected to HTTPS. TLS certificates are managed via AWS Certificate Manager and auto-renewed.

RDS database storage is encrypted at rest using AES-256. ElastiCache Redis instances are encrypted at rest and in transit.

S3 buckets are encrypted at rest (AES-256) and are not publicly accessible. Patient files (X-rays, DICOM, consent forms, photos) are accessed only via pre-signed URLs with a short expiry . no permanent public links are issued.

Application secrets (database passwords, API keys, Stripe keys, Firebase credentials) are stored in AWS Secrets Manager and are rotated on a defined schedule. They are never committed to source code or environment files in the repository.

Every clinic's data lives in a dedicated PostgreSQL schema, entirely separate from every other clinic on the platform. This is not just a filter . it is a hard database boundary enforced by schema ownership.

On every incoming API request, middleware reads the clinic's subdomain from the Host header, looks up the corresponding tenant, and activates the correct schema before any application code runs. A query that bypasses the middleware layer would land in the public schema, which contains no patient data.

For multi-branch organisations, all branches share a single tenant schema. Branch-level data segregation is enforced by the application RBAC layer . staff from Branch A cannot query Branch B's records unless explicitly granted cross-branch access by the organisation's Admin.

Teliyadu super-admin access to any tenant schema requires a separate explicit activation step, is logged in an immutable audit trail, and requires internal approval.

Clinic staff log in via secure session-based authentication (server-side sessions with HttpOnly, Secure, SameSite cookies). Patient mobile app and API users authenticate via short-lived JWT access tokens with refresh token rotation.

Passwords are hashed using Django's PBKDF2-SHA256 algorithm with a per-user salt. Plain-text passwords are never stored, logged, or transmitted after initial entry. Password reset links are single-use and expire after 1 hour.

Multi-factor authentication (MFA) via TOTP authenticator app is available for all staff accounts and is enforced by default for Admin-role users. Clinic Admins may make MFA mandatory for all staff roles.

Concurrent session limits, idle session timeouts, and device management are configurable per clinic. API keys are scoped, rotatable, and revocable from the dashboard without contacting support.

OralOS enforces granular RBAC across all features. The four built-in roles (Admin, Dentist, Receptionist, Dental Assistant) carry predefined permission sets that reflect clinical workflow boundaries.

Custom roles are available on Pro and Enterprise plans, allowing Admins to define exactly which modules, reports, and actions each role can access. Permissions are enforced server-side on every API request . removing a permission takes effect immediately without requiring a logout.

Sensitive operations (payroll data, corporate account details, super-admin reports, cross-branch aggregation) are restricted to Admin-role users. No Receptionist or Dental Assistant role user can access clinical notes or invoices beyond their defined scope.

Every read of a patient record is audit-logged . timestamp, staff member, action type, patient ID, and source IP. This log is immutable: no staff member, including Admins, can delete or modify audit entries.

Financial mutations (invoice creation, payment recording, refunds, write-offs) are immutably logged with the before/after state. Voided records are marked as voided, never deleted, to maintain a complete financial trail.

AI-assisted actions are logged separately . each AI suggestion that is accepted, modified, or rejected by a clinician is recorded to maintain a clear human-AI accountability boundary.

Teliyadu platform-staff access to any clinic schema is logged with the authorising manager's ID, the stated reason, and the duration of access. Clinic Admins can request their tenant's access log on demand.

Audit logs are retained for 7 years to meet healthcare regulatory requirements.

API endpoints require a valid authentication token on every request. Unauthenticated requests return 401 with no data. Rate limiting is enforced per API key to prevent abuse and scraping.

Webhook payloads are signed with a clinic-specific HMAC-SHA256 secret. Receiving endpoints should verify the signature on every delivery. Signed secrets are displayed once at creation and can be rotated at any time.

API key permissions are scoped at creation . a read-only key for a lab integration cannot write to patient records. Unused API keys are automatically expired after 90 days of inactivity.

All API activity is logged and visible to the clinic Admin in the integrations dashboard. Anomalous activity patterns (sudden spike in reads, unexpected geographic origin) trigger automated alerts.

The patient mobile app and staff mobile app are built with Flutter. Authentication tokens are stored in the device's secure keychain (iOS Keychain / Android Keystore), not in plain SharedPreferences or local storage.

The apps implement certificate pinning to prevent man-in-the-middle attacks. Push notification payloads delivered via Firebase contain only metadata . they do not contain patient health data. The full record is fetched from the API after the user opens the notification and authenticates.

App releases are distributed via the Apple App Store and Google Play Store, which enforce their own code signing and malware review processes. We do not distribute production builds via any other channel.

DICOM files (dental X-rays, CBCT scans) are stored in a dedicated S3 bucket with bucket-level encryption (AES-256). Access is restricted to authenticated staff users with at minimum the Dentist role.

DICOM viewer sessions are issued time-limited pre-signed S3 URLs. Images are never served from a public CDN path. DICOM metadata is parsed server-side and stored in the tenant schema; raw DICOM files remain on S3 and are referenced by a secure internal ID, not a patient-identifiable filename.

Patient identifiers embedded in DICOM headers are reviewed during upload. Clinics are responsible for ensuring imported DICOM files from external sources do not contain unexpected PHI in extended metadata fields.

AI features (voice dictation, charting suggestions, note summaries) are processed by an approved inference provider under a strict Data Processing Agreement that prohibits training use, log retention beyond the request, and any use of the data outside the immediate inference task.

Audio submitted for voice transcription is transmitted over TLS, processed in real time, and not retained by the inference provider after the transcription is returned. The transcription result is stored in OralOS as part of the clinical note, subject to the same access controls as all other note content.

AI inference calls are isolated per clinic session . data from one clinic is never used to generate outputs for another clinic, and no cross-tenant context is included in prompts. AI feature activity is audit-logged.

Application errors are captured and triaged in real time via Sentry. Error payloads are scrubbed to remove patient identifiers before leaving OralOS infrastructure. Infrastructure health, latency, and uptime are monitored via Better Stack with on-call alerting.

Anomalous access patterns (bulk record reads, unusual login geography, API key abuse, failed authentication spikes) trigger automated security alerts to the engineering team.

We maintain a documented incident response plan. In the event of a confirmed data breach affecting patient records: (1) we will contain the breach as fast as possible; (2) we will notify affected clinic account holders within 72 hours of confirming the breach; (3) we will cooperate fully with any regulatory investigation. Notification will include the nature of the data involved, likely consequences, and the measures we have taken.

Automated RDS snapshots run daily and are retained for 30 days. Point-in-time recovery (PITR) is enabled . we can restore the database to any 5-minute window within the retention period.

S3 versioning is enabled on the documents and imaging buckets. Deleted or overwritten files are recoverable for 30 days via version history.

Recovery Time Objective (RTO): 4 hours for a full-region failure scenario. Recovery Point Objective (RPO): 5 minutes (PITR window) for the database; 0 for S3 (versioned). Recovery procedures are tested at least quarterly.

Backup snapshots are stored in the same AWS region as production data. Cross-region replication of snapshots is enabled for Enterprise accounts.

Application dependencies (Python packages, npm packages, Flutter packages) are scanned for known vulnerabilities on every CI build. Critical and high-severity CVEs are patched within 7 days of disclosure.

Infrastructure changes are made exclusively via Terraform through a peer-reviewed pull request process. No production infrastructure changes are made via the AWS console directly.

We conduct annual penetration tests by an independent third-party security firm. Critical findings are remediated before the report is finalised. Summary findings are available to Enterprise customers under NDA upon request.

Common web vulnerabilities (OWASP Top 10) are mitigated through a combination of framework-level controls (Django's CSRF protection, ORM parameterisation, Content Security Policy headers) and mandatory security code review on all pull requests.

All code changes go through peer review before merging. Security-sensitive changes (auth, tenant isolation, payments, RBAC) require sign-off from a senior engineer.

Tests are written before code (TDD). Integration tests for security-critical paths (login, tenant routing, permission checks, payment flows) are mandatory and run on every pull request in CI. No bypass of test requirements is permitted.

Static analysis (Ruff for Python, ESLint for TypeScript) runs in CI. Secrets scanning is enabled on the repository to prevent accidental credential commits.