Security

1. Our approach

Practiq holds clinical information about real patients. Security is not a side concern, it is the spine of how we operate. This page describes the measures we take to keep that information safe, in the spirit of Section 19 of POPIA. It is updated whenever any of those measures change in a material way.

2. Where your data lives

Production data is hosted in the European Union, on infrastructure that meets recognised international security standards. We do not store production data on developer laptops, in non-production environments, or anywhere outside the controlled hosting environment.

Testing and development happen against synthetic fixtures and de-identified samples. No real patient information ever enters a non-production environment.

3. Encryption

• In transit. Every connection to Practiq application, booking page, API, is encrypted with current industry-standard transport encryption. Older, weaker protocols are refused at the edge.
• At rest.The underlying database and storage are encrypted. On top of that, the most sensitive identifiers , ID numbers and medical-aid numbers, are encrypted again at the application layer with a key unique to each practice. A practice's encrypted identifiers are unreadable even to someone with full database access.
• Key handling. Master encryption keys are held in a managed secret store, never written to source control or logs, and rotated on a documented schedule.

4. Practice isolation

Each practice's data is fenced off from every other practice's data at the database level. Access requires an active membership of the practice, there is no shared pool of records that one practice could ever query against another. Server-side actions enforce the same boundary at the application layer, so it would take a simultaneous failure of two independent safeguards for a leak to be possible.

5. Access control

• Within a practice, permissions are role-based and follow least-privilege defaults. Reception staff see scheduling and contact details; practitioners see the clinical record; owners and administrators see everything. Roles are assigned and revoked from the team settings page.
• Encrypted identifiers (ID number, medical-aid number) are masked by default. Revealing one requires a deliberate click, and every reveal is recorded with the user, the time, and the source.
• Our own staff have no routine access to customer data. Production access is granted only on a documented need, time-bounded, fully logged, and revoked the moment the work is complete. Two-factor authentication is mandatory for every internal account with any production reach.

6. Authentication

• Users sign in with email and password. Passwords are stored as salted, irreversible hashes, the plain value is never visible to us.
• Sessions are short-lived and refreshed silently in the background. Signing out invalidates the active session immediately.
• We monitor for credential-stuffing and password-reset abuse, and throttle suspicious activity per source.

7. Audit trail

Every change to a clinical record is recorded: who made it, when, from where, and what the values were before and after. Audio recordings, transcripts, and AI-generated drafts carry an additional fingerprint of the input that produced them, so any clinical decision can be retraced after the fact for an internal review, a regulator's request, or a curious practitioner's own peace of mind.

The audit log is append-only. Past entries cannot be edited or deleted by anyone, including our own staff.

8. AI and patient data

• Patient information is never used to train machine-learning models, neither ours nor anyone else's. The providers that power transcription and clinical drafting are contractually prohibited from training on the requests we send them, and are required to delete intermediate state once the response has been returned.
• AI requests are sent over encrypted channels with the minimum payload needed to produce the output. Identifiers are tokenised where the task allows.
• No AI output is ever issued without a practitioner's review and explicit sign-off. Prescription drafts also pass through a deterministic safety check against the patient's active medications and allergies before any model is consulted.

9. Backups and recovery

• Production data is backed up daily, encrypted, and retained for thirty (30) days. Point-in-time recovery is available for the most recent seven (7) days, so we can return to any minute-resolution moment in the last week.
• We run a backup-restore drill to an isolated environment at least monthly and verify the integrity of what comes out.
• Our recovery time objective for production is four (4) hours; our recovery point objective is fifteen (15) minutes.

10. Security testing and updates

• Software dependencies are continuously scanned for known vulnerabilities. Critical security advisories are applied within seventy-two (72) hours of a fix becoming available.
• Every change to the platform passes through automated security checks before it can reach production.
• An independent penetration test is conducted at least annually. Findings are remediated according to severity, and a summary is available to customers under a mutual non-disclosure agreement.

11. Incident response

We maintain a documented incident response procedure with defined severities, an on-call rotation, and clear communication paths. Where we have reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person, we notify the affected practice's Information Officer within seventy-two (72) hours of identifying the incident, in line with Section 22 of POPIA, and provide the information necessary for the practice to in turn notify the Information Regulator and any affected patients.

12. Reporting a security concern

We welcome reports of vulnerabilities or security issues. Please email support@starlightgroupsa.co.za with as much detail as you can. We acknowledge reports within one business day and commit to working with researchers in good faith.

For data-processing agreements, audit information, or detailed questions ahead of procurement, see /popia or contact support@starlightgroupsa.co.za.