Information Security Policy

1. Purpose

This policy describes DeskLabs' approach to protecting MediDesk, Customer data, and patient health information. It applies to all DeskLabs personnel, contractors, and third-party providers with access to production systems.

2. Security Objectives

• Confidentiality: Customer and patient data is accessible only to authorised users and systems.
• Integrity: Data is protected against unauthorised modification or deletion.
• Availability: MediDesk is made available using reasonable efforts.
• Tenant isolation: No practice can access another practice's data.
• Least privilege: Access is limited to what each role requires.
• Auditability: Sensitive actions are logged and traceable.

3. Access Control

• All access to production systems requires individually named accounts. Shared accounts are not permitted.
• Access is granted on a least-privilege basis.
• Staff access is reviewed regularly and revoked promptly when personnel leave or change roles.
• The Supabase service-role key and all production secrets are stored in environment variables only and never committed to source code.
• Multi-factor authentication is required for DeskLabs staff on production dashboards where available.
• Within MediDesk: Practice data isolation is enforced through Supabase Row Level Security. Role-based and module-level permissions control what each practice user can access. The MediDesk admin area is restricted to authorised DeskLabs operators.

4. Internal Access to Patient Data

DeskLabs staff may access customer or patient data only for:

• responding to a support request;
• investigating a security incident;
• authorised billing or account administration;
• maintenance or legal compliance.

Staff must access only the minimum data required, must not copy or export patient data outside approved systems, and must log any access in the relevant support ticket or incident record.

DeskLabs staff must not paste patient personal information into Slack, email, GitHub, Linear, Sentry comments, ChatGPT, or any unapproved external tool.

5. Data Storage

• All data in transit is encrypted using HTTPS/TLS.
• Data at rest is encrypted by our hosting and database providers.
• Patient documents, consent PDFs, and clinical files are stored in private storage buckets — not publicly accessible.
• Branding assets are the only content in public storage buckets.
• Production patient data must not be used in development or staging environments.
• AI Voice Receptionist call recordings and transcripts are stored in the same encrypted infrastructure as other patient data, subject to the same access controls and retention policies.

6. Application Security

• All unsafe API operations include origin validation.
• Cron endpoints require bearer-secret validation.
• Payment webhook callbacks include signature validation.
• AI Voice Receptionist webhook callbacks include authentication validation.
• Rate limiting is applied to sensitive endpoints.
• Input is validated and output is sanitised to prevent injection attacks.
• Pre-deployment checks include linting, type checking, automated tests, build validation, and a dependency vulnerability audit.
• PII is scrubbed from error monitoring data before transmission to Sentry.

7. Secret and Credential Management

Production secrets are managed as follows:

• All secrets are stored as environment variables in the deployment platform (Vercel). None are committed to source code.
• Secrets include: Supabase service-role key, WinSMS API key and webhook secret, Twilio credentials, PayFast secret key and webhook secret, Retell.ai API key, OpenAI API key, Upstash credentials, Sentry DSN, and cron bearer secret.
• Secrets are rotated at a minimum annually and immediately upon: personnel departure, suspected compromise, or any incident that could have exposed them.
• Access to secret values is restricted to personnel with a need-to-know basis.

8. Logging and Monitoring

MediDesk maintains:

• patient audit logs for view, create, update, delete, and export actions;
• admin audit logs for DeskLabs operator actions;
• feature flag audit logs;
• AI Voice Receptionist call logs including call metadata, duration, and consent status;
• application error monitoring via Sentry;
• infrastructure and access logs via hosting providers.

Logs are retained for operationally appropriate periods and are accessible only to authorised personnel.

9. Backups

Database backups are maintained by Supabase in accordance with their platform's backup schedule. Restoration is tested periodically.

DeskLabs does not commit to specific recovery time objectives (RTO) or recovery point objectives (RPO) unless separately agreed in writing with the Customer. Customers requiring specific RTO/RPO guarantees must raise this before subscription.

Customer data exports are the Customer's responsibility. Practices are encouraged to export records regularly and before any anticipated changes to their subscription.

10. Vulnerability Disclosure

DeskLabs operates a responsible disclosure process for security vulnerabilities:

Reports must be sent to security@desklabs.co.za. DeskLabs will acknowledge, investigate, and remediate in good faith. Security researchers who report responsibly will not face legal action.

Third-party penetration testing of MediDesk is not permitted without DeskLabs' prior written approval.

11. Vendor Security

Third-party providers are selected with security and data protection in mind. Access to vendor dashboards is limited to authorised DeskLabs personnel. Vendor incidents are assessed under the Incident Response Policy.

AI subprocessors (Retell.ai, OpenAI) are subject to the same vendor security assessment standards as other subprocessors. DeskLabs monitors their data processing practices and security posture on an ongoing basis.

12. Policy Review

This policy is reviewed at least annually and after any material security incident. The Security Owner is responsible for maintaining and updating this policy.

Contact: security@desklabs.co.za | desklabs.co.za