Data Breach Response Plan

This Data Breach Response Plan (the “Plan”) sets out how KlikSend, the NanoCrew secure file-transfer service operated by Municipex (Pty) Ltd t/a NanoCrew (the “Operator”, “we”, “us”), prepares for, detects, responds to, and reports a compromise of the personal information contained in files that users upload and share through the service. It is designed to support compliance with the Protection of Personal Information Act, 2013 (POPIA), in particular the notification obligations in section 22, and with the access-to-information framework of the Promotion of Access to Information Act, 2000 (PAIA).

This Plan is a template. It must be reviewed, adapted to the Operator’s actual systems and contractual arrangements, and approved by qualified legal counsel and the Operator’s Information Officer before it is relied upon. It does not constitute legal advice.

1. Scope

This Plan applies only to the KlikSend secure file-transfer service: the upload, secure storage, password protection, secure share links, link expiry, and download of files that users themselves choose to send. It does not cover any other product or activity. Where a shared file contains personal information about identifiable people, that information is protected under POPIA, and a compromise of it triggers this Plan.

2. Definition of a personal-information breach

For the purposes of this Plan, a “security compromise” or “breach” means any event where there are reasonable grounds to believe that personal information in a file transferred through KlikSend has been accessed or acquired by an unauthorised person. This aligns with the trigger for notification under section 22 of POPIA.

In the file-transfer context a breach includes, without limitation: a secure share link reaching an unintended recipient; a download password being guessed, intercepted, or leaked; unauthorised access to a user’s KlikSend login account; a stored file being read, copied, or exfiltrated without authorisation; a misconfiguration that exposes files or links beyond their intended audience; or the loss, theft, alteration, or destruction of uploaded files. Both confidentiality breaches (unauthorised access or disclosure) and integrity or availability incidents that place personal information at risk are treated as reportable events under this Plan. A near-miss with no actual exposure is logged but may not amount to a notifiable breach.

3. Detection and internal escalation

Breaches may be detected through automated monitoring and alerting (anomalous download volumes, unexpected access locations, spikes in failed authentication), review of access and transfer logs, notifications from infrastructure providers, or reports from users, recipients, or external researchers. Any employee, contractor, or operator who becomes aware of a suspected breach must report it immediately and without delay to the Information Officer or the Incident Lead using the contacts in section 9. Suspicion is enough; staff must not wait for confirmation before escalating.

On receipt, the Information Officer or Incident Lead logs the report in the incident register (date and time detected, reporter, files or links affected, initial description), assigns a severity rating, and convenes the response team. The clock for the “as soon as reasonably possible” notification standard in section 22 of POPIA starts running from the point at which we have reasonable grounds to believe a breach has occurred.

4. Containment

The immediate priority is to stop or limit the compromise while preserving evidence. Containment actions are chosen to fit the file-transfer context and may include: revoking or expiring the affected secure share links so they can no longer be opened; disabling or rotating the associated download passwords; suspending or forcing a credential reset on a compromised KlikSend login account; rotating service and storage credentials and access tokens; isolating affected storage; applying emergency patches; and engaging the storage and infrastructure providers. Wherever possible, logs and other forensic evidence are preserved before remedial changes are made so that the cause and scope can be established. Actions taken, and the time of each, are recorded in the incident register.

5. Assessment of risk to data subjects

Once contained, the response team assesses the nature and scope of the breach, including: which categories of personal information appeared in the affected files; the number and identity of affected data subjects; how the breach occurred and whether it is ongoing; whether the affected files were password-protected; whether the information was actually accessed or only potentially exposed; and the realistic potential for harm, including identity theft, fraud, distress, or other prejudice to the data subjects. Because users control what they upload, we may need to work with the relevant user to understand the contents and sensitivity of the affected files.

The assessment determines whether the section 22 notification obligation is triggered and informs the content and timing of any notifications.

6. Notification under POPIA section 22

Where there are reasonable grounds to believe that personal information has been accessed or acquired by an unauthorised person, we will notify both the Information Regulator and the affected data subjects as soon as reasonably possible after the discovery of the compromise, in line with section 22 of POPIA. Notification to data subjects may be delayed only if a public body responsible for the prevention, detection, or investigation of offences, or the Regulator, determines that notification will impede a criminal investigation.

Notification to data subjects is made in writing and communicated in at least one of the manners permitted by section 22(4) of POPIA (for example by email to the last known address, posted to our website, or published in the news media). Each notification provides sufficient information to allow data subjects to take protective measures and includes, to the extent known: a description of the possible consequences of the breach; the measures we intend to take or have taken to address it; a recommendation as to what the data subject can do to mitigate possible adverse effects; and, if known, the identity of the unauthorised person who may have accessed or acquired the personal information. Where we act as an operator for a user under POPIA, that user is informed promptly so they can meet their own notification duties.

Notification to the Information Regulator is made in accordance with the Regulator’s prescribed form and guidance current at the time of the breach. Contact details for the Information Regulator are maintained in section 9.

7. Remediation

After containment, we implement corrective measures to eliminate the root cause and reduce the risk of recurrence. Depending on the cause these may include correcting a misconfiguration that exposed links, strengthening link-expiry and password-protection defaults, tightening access controls and least-privilege policies, rotating all potentially affected secrets, hardening storage configuration, improving monitoring and alerting, reinforcing user guidance on safe sharing, and updating internal procedures. Remediation actions are tracked to completion with owners and target dates. Where infrastructure providers are involved, we require evidence of their remediation.

8. Post-incident review and records (PAIA)

Within a reasonable period after the incident is closed, the Information Officer leads a post-incident review covering the timeline, root cause, effectiveness of the response, and lessons learned. The review produces an action list with owners and deadlines, and the outcomes are used to update this Plan, the underlying safeguards, and staff training.

We maintain records of all breaches and our responses in the incident register, including the assessment, decisions on notification, and copies of notifications issued. These records support our accountability obligations under POPIA and are managed alongside our obligations under the Promotion of Access to Information Act, 2000 (PAIA), including any request for access to information relating to an incident. Such requests are routed to the Information Officer.

9. Roles and contacts

The Information Officer holds overall accountability for POPIA compliance and for decisions on breach notification, and is the point of contact for the Information Regulator. The Incident Lead coordinates the operational response, the response team carries out containment, assessment, and remediation, and counsel advises on legal obligations. Users report suspected breaches and cooperate on assessing the contents of affected files. Contact details below should be kept current.

Information Officer / breach reporting for files shared through KlikSend: info@nanocrew.ai. A general illustrative contact for affected individuals is you@example.co.za.

Information Regulator (South Africa): Information Regulator, P.O. Box 31533, Braamfontein, Johannesburg, 2017; general enquiries enquiries@inforegulator.org.za; breach notifications via the Regulator’s prescribed channel breach@inforegulator.org.za. Confirm the current address and channels with the Regulator before submitting.

Last updated: June 2026 · Municipex (Pty) Ltd t/a NanoCrew · info@nanocrew.ai