Incident Response Policy

This policy governs how DeskLabs identifies, responds to, and communicates about security incidents, privacy incidents, and material service compromises affecting MediDesk. Given that MediDesk processes patient health information, a structured response is both an operational and legal requirement under POPIA.

Part A — Internal Policy

A1. What Counts as an Incident

An incident is any actual or reasonably suspected event that compromises or threatens the security, confidentiality, integrity, or availability of MediDesk or Customer data. Examples include:

• cross-practice patient data exposure;
• unauthorised access to patient records, documents, or communications;
• compromised credentials, API keys, or admin accounts;
• compromised hosting, database, messaging, AI voice, or payment provider accounts;
• malware, ransomware, or destructive payloads;
• SMS or email sent to wrong recipients containing patient data;
• AI Voice Receptionist misrouting calls or disclosing patient data to unauthorised callers;
• unauthorised access to AI call recordings or transcripts;
• payment webhook abuse or subscription fraud;
• subprocessor breach affecting MediDesk data;
• material data loss or corruption.

A2. Severity Levels

A3. Roles

A4. Response Procedure

Step 1 — Open incident record capturing: reference number, detection time, severity, reporter, affected systems, and initial description.

Step 2 — Preserve evidence. Do not delete or alter any logs, tickets, records, or data until the Legal lead approves. Preserve: Supabase logs, Vercel logs, Twilio logs, Retell.ai logs, PayFast logs, Sentry events, AI call recordings and transcripts, support tickets, screenshots, and timestamps.

Step 3 — Stop active harm using minimum necessary action: disable compromised accounts, rotate exposed secrets, block abusive IPs, pause affected routes, disable SMS sending, disable AI Voice Receptionist, take public links offline, or suspend the affected account.

Step 4 — Assess scope: which practices and patients are affected; what data categories; was health information involved; were AI call recordings or transcripts compromised; was data viewed, exported, or acquired; is the incident ongoing.

Step 5 — Engage external support if needed: subprocessor support teams, legal counsel, cyber insurer, or law enforcement.

Step 6 — Set update cadence: every 30 minutes for SEV-1; every 2 hours for SEV-2.

A5. Investigation Record

The incident record must capture:

• what happened and how it was detected;
• full timeline from start to resolution;
• affected practices, data subjects, and data categories;
• whether health information or Special Personal Information was involved;
• whether AI call recordings, transcripts, or voice data was involved;
• whether data was viewed, exported, modified, or acquired by third parties;
• containment and remediation actions taken;
• regulatory and customer notifications made;
• residual risks.

A6. POPIA Notification Assessment

Before notifying customers or the regulator, the Legal / Privacy Lead must assess:

• Was personal information accessed or acquired by an unauthorised person? (POPIA Section 22 trigger).
• Does the incident involve Special Personal Information (health data, identity numbers)?
• Is the risk of harm to data subjects real (identity theft, financial harm, discrimination, distress)?
• Which practices are affected, and do they need to assess their own Section 22 obligations?
• What is the minimum information DeskLabs can confirm before notification?

DeskLabs will notify affected Customer practices without undue delay upon becoming aware of a security compromise affecting their data. Initial notification may be made before all facts are confirmed, with follow-up as the investigation progresses.

Internal target: DeskLabs aims to make initial customer notification within 72 hours of becoming aware of a qualifying incident. This is an internal operational target, not a guarantee or legal commitment. Actual timing will depend on the nature and scope of the incident and counsel's advice.

Customer practices, as responsible parties, are responsible for determining their own obligations to notify the Information Regulator and affected patients under POPIA Section 22. Reference: inforegulator.org.za.

A7. Customer Notification Template

Subject: Security Incident Notification — MediDesk

Dear [Practice Administrator], We are writing under our Data Processing Agreement and POPIA obligations. We have identified a [suspected / confirmed] security incident that may affect your practice's data. What we know: [Describe incident type, date/time window, affected data categories, whether health information or AI call data is involved — no exploit details.] Steps taken: [Describe containment actions and investigation status.] What we ask of you: [State whether the practice should review its own POPIA Section 22 notification obligations. List any specific actions required.] We will provide a further update by [date/time]. Joshua Botha | DeskLabs | security@desklabs.co.za

Notifications must not include exploit details, production credentials, or unconfirmed conclusions.

A8. Post-Incident Review

A review must be completed within 14 days of resolution for every SEV-1 and SEV-2 incident. The review must capture: root cause, full timeline, impact assessment, what worked, what failed, remediation actions with owners and due dates, and any policy or control updates required. Incident records must be retained for at least 5 years from resolution or the duration of any related legal proceeding, whichever is longer.

Part B — Customer-Facing Commitment

B1. Our Commitment

DeskLabs maintains an internal Incident Response Policy and investigates security and privacy incidents affecting MediDesk promptly. This document summarises our commitments to customers.

B2. Notification

If DeskLabs becomes aware of a security compromise affecting your practice's data, we will notify you without undue delay. We will provide available facts about the nature of the incident, data categories affected, containment steps taken, and what we need from you.

B3. Your Obligations as Responsible Party

As the responsible party for your patient data, you are responsible for deciding whether and how to notify the Information Regulator and/or affected patients under POPIA Section 22. DeskLabs will provide you with the information we have to support that decision. DeskLabs does not make that notification assessment on your behalf.

B4. Limitation

DeskLabs' incident notification obligations are subject to the liability limitations in the Terms of Service. DeskLabs is not liable for losses arising from the Customer's own POPIA notification decisions or delays.

B5. Contact

Security incidents: security@desklabs.co.za
Incident Owner: Joshua Botha

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