Security & Incident Response Policy

This policy sets out how eRunna (Pty) Ltd (registration number [TBD: company registration number]) implements technical and organisational security safeguards under the Protection of Personal Information Act 4 of 2013 (POPIA s19), and how it detects, contains, and notifies in the event of a personal-information breach (POPIA s22). It also addresses the handling of incidents involving payment data and KYC/identity documents.

[ATTORNEY-REQUIRED: Confirm whether eRunna's breach-notification obligations extend beyond POPIA s22 — in particular, whether any payment-industry obligation (e.g., Paystack contractual SLA, PCI-DSS incident reporting) or FICA/FIC obligation applies, and whether the 72-hour internal-escalation target below aligns with any current or anticipated regulatory guidance from the Information Regulator.]

1. Scope

This policy applies to all personal information processed by eRunna across its platform, including customer, runner, merchant, and partner data, as well as payment transaction metadata, KYC/identity documents, and location data. It applies to all staff, contractors, and sub-processors with access to eRunna systems.

2. Security safeguards (POPIA s19)

POPIA s19 requires a responsible party to secure the integrity and confidentiality of personal information in its possession or under its control. eRunna implements the following measures:

2.1 Technical safeguards

• Encryption in transit (TLS) for all data moving between clients, services, and third-party providers.
• Encryption at rest for sensitive data stores including Firestore collections holding identity and payment-related records.
• Role-based and attribute-based access controls: access to production data is restricted to authorised personnel on a least-privilege basis (consistent with ADR 0007 runtime-SA least-privilege architecture).
• Payment data minimisation: eRunna does not store full Primary Account Numbers (PANs). Card data is tokenised via Paystack; only tokens and authorisation codes are retained (see Refunds & Payments).
• Dependency and secrets scanning integrated into the CI/CD pipeline.
• Continuous monitoring and alerting via Grafana for anomalous traffic, error rates, and service-health degradation.
• Infrastructure-as-code (IaC) security scanning; no hardcoded secrets in version control.

2.2 Organisational safeguards

• Access to production environments is restricted; all access events are logged.
• Sub-processors are bound by data-processing agreements that require equivalent security standards (see Sub-processors).
• Security incidents are reviewed in after-action postmortems; findings feed back into the security roadmap.
• Annual tabletop exercises are conducted to validate incident-response readiness. [ATTORNEY-REQUIRED: Confirm whether the frequency and form of testing is sufficient to satisfy any sector-specific regulatory expectation applicable to eRunna — in particular any FIC guidance on ICT security for accountable institutions, if that status is confirmed.]
• Information Officer: [TBD: full name and contact details of the designated Information Officer, once registered with the Information Regulator.] [ATTORNEY-REQUIRED: POPIA requires eRunna to designate and register an Information Officer with the Information Regulator. The Information Officer is responsible for ensuring compliance with POPIA, including security safeguards under s19 and breach notification under s22. Confirm designation status and whether a Deputy Information Officer is required.]

3. Incident classification

Not all security events constitute a "breach" for POPIA s22 purposes. eRunna classifies security incidents as follows to determine the appropriate response level:

• SEV-1 — Critical / Confirmed Breach: confirmed unauthorised access to, acquisition of, or loss of personal information; ransomware or destructive attack affecting personal-information stores; compromise of payment-data or KYC-document systems. POPIA s22 notification obligations are presumed to be triggered — legal review commences immediately.
• SEV-2 — Major / Probable Breach: suspected unauthorised access or exfiltration where the extent is not yet confirmed; a significant service outage that may have exposed personal information; a sub-processor reporting a security incident affecting eRunna data. Legal review commences within 24 hours.
• SEV-3 — Minor / Security Event: anomalous activity that has been contained with no evidence of personal-information exposure; failed intrusion attempts; policy violations with no data-loss consequence. No POPIA s22 notification obligation is expected; documented internally.

[ATTORNEY-REQUIRED: Confirm that the SEV-1 / SEV-2 classification threshold is consistent with the Information Regulator's interpretation of "compromise of personal information" under POPIA s22 — in particular whether a suspected (unconfirmed) breach triggers the notification obligation and at what point the clock starts running.]

4. Roles and responsibilities

• Incident Lead — coordinates response across all teams; escalates to legal/compliance for POPIA s22 assessment; owns the postmortem. [TBD: name or role title of designated Incident Lead.]
• Engineering / Security — detection, triage, containment, eradication, and recovery; preserves evidence; manages technical forensics.
• Legal / Privacy (Information Officer) — assesses whether POPIA s22 notification is required; drafts regulatory and data-subject notifications; advises on evidence-handling and legal-hold obligations; liaises with the Information Regulator and, where applicable, the Financial Intelligence Centre (FIC).
• Support / Communications — manages affected-user communications (where notification is required); handles inbound enquiries; coordinates with external parties (Paystack, sub-processors, law-enforcement if applicable).

5. Incident response runbook

1. Detection — automated monitoring (Grafana alerts, anomaly detection, dependency/secrets scanning) or manual report (staff, sub-processor, researcher, or affected user) identifies a potential incident.
2. Triage — Incident Lead and Engineering assess the event against the severity classification in §3 within four hours of initial report. Preliminary SEV level assigned.
3. Containment — immediate steps to limit further access or exfiltration: isolate affected services, revoke compromised credentials, disable affected API endpoints, or block network paths as appropriate.
4. Legal / Privacy assessment — Legal / Privacy team assesses POPIA s22 applicability in parallel with technical containment. For SEV-1 events, this assessment commences immediately; for SEV-2, within 24 hours.
5. Investigation — forensic review of logs, access records, and affected data sets to determine the nature, scope, and cause of the incident. Evidence is preserved under chain-of-custody (see §7).
6. Eradication — root cause is addressed: patch deployed, malicious access revoked, misconfiguration corrected. Affected systems are validated before return to production.
7. Recovery — affected services are restored; monitoring is heightened for recurrence.
8. Notification — where POPIA s22 requires notification, notifications are issued as set out in §6 below.
9. Postmortem — a written after-action review is completed within 14 days of incident resolution, recording timeline, root cause, impact, lessons learned, and remediation actions.

6. Breach notification obligations (POPIA s22)

POPIA s22 requires eRunna to notify the Information Regulator and affected data subjects of a security compromise of personal information in its possession, where there are reasonable grounds to believe that the personal information of a data subject has been accessed or acquired by an unauthorised person.

6.1 Notification to the Information Regulator

• Where a POPIA s22 obligation is triggered, eRunna will notify the Information Regulator of South Africa as soon as reasonably possible after becoming aware of the breach. [ATTORNEY-REQUIRED: Confirm the prescribed form of notification to the Information Regulator — whether there is a prescribed form, mandatory content fields, and any current regulatory guidance on timing. The 72-hour internal-escalation target below is an operational benchmark, not an assertion of the statutory deadline.]
• Internal escalation target: the Legal / Privacy team will make a preliminary POPIA s22 assessment within 72 hours of an incident being classified as SEV-1 or SEV-2.
• Information Regulator contact: [TBD: current postal address, email, and online notification portal for the Information Regulator of South Africa — verify at www.inforegulator.org.za at the time of notification, as contact details are subject to change.]

6.2 Notification to affected data subjects

• Where required under POPIA s22, affected data subjects will be notified as soon as reasonably possible. Notification will be made via in-app message, email, or SMS (using the contact information held for the relevant account), and will include:
  • a description of the possible consequences of the security compromise;
  • a description of the measures eRunna has taken or proposes to take to address the security compromise;
  • a recommendation with regard to measures to be taken by data subjects to mitigate the possible adverse effects of the security compromise; and
  • the identity of the unauthorised person who may have accessed or acquired the personal information (if known).
• Notification to data subjects may be deferred if the Information Regulator so directs, or if earlier notification would impede a criminal investigation. [ATTORNEY-REQUIRED: Confirm the deferral conditions permissible under POPIA s22 and any applicable Information Regulator guidance.]

6.3 Special handling — payment data and KYC incidents

Incidents involving payment transaction data or KYC/identity documents require additional handling steps:

• Payment data: eRunna does not store PANs; all card data is tokenised via Paystack. However, if an incident involves compromise of Paystack tokens, authorisation codes, or the Paystack integration itself, Paystack is notified immediately and card tokenisation is reviewed. eRunna will cooperate with any PCI-DSS incident response requirements applicable to Paystack as acquiring bank / PSP. [ATTORNEY-REQUIRED: Confirm whether eRunna has a contractual obligation to Paystack to notify within a specific timeframe in the event of a suspected compromise of payment-related data or credentials, and whether that obligation applies even where no PANs are stored.]
• KYC / identity documents: incidents involving identity documents (FICA CDD records, merchant onboarding documents, runner KYC materials) are treated as SEV-1 events by default, given the heightened risk of identity fraud. The FIC is notified where required. [ATTORNEY-REQUIRED: Confirm whether FICA or any FIC directive imposes a separate incident-notification obligation to the FIC in the event of a breach of CDD records, and whether such obligation currently applies to eRunna given its accountable-institution status.]
• Runner personal information: incidents involving runner data (identity, location history, earnings) are assessed for any additional obligations that may arise from the runner employment-vs-contractor classification. [ATTORNEY-REQUIRED: Confirm whether the runner classification affects any employment-law or SARS data-handling obligation in the event of a runner-data breach — in particular, whether a labour-law notification obligation applies if runners are found to be employees.]

7. Evidence handling and chain of custody

• All logs, audit trails, and artefacts related to a security incident are preserved in an immutable store from the moment of detection. No logs are deleted or modified during an active incident investigation.
• A chain-of-custody record is maintained for each incident, documenting who accessed the evidence, when, and for what purpose.
• Evidence is retained for a minimum of five years from the date of incident closure, or for such longer period as may be directed by the Information Regulator, the FIC, or a court. [ATTORNEY-REQUIRED: Confirm the minimum evidence-retention period for security incidents under any applicable regulatory obligation — including whether the FICA record-keeping period (if eRunna is an accountable institution) applies to incident-related records.]
• Evidence related to a confirmed breach is handled as a legal-hold item under the exceptions set out in the Data Retention Policy (§7, legal holds).

8. Sub-processor incidents

Where a sub-processor (e.g., Google Cloud Platform / Firebase, Paystack, a monitoring or analytics provider) reports or eRunna becomes aware of a security incident affecting eRunna personal information held by that sub-processor, the Incident Lead triggers the response runbook (§5) immediately. Sub-processor data-processing agreements require prompt notification to eRunna of any actual or suspected breach.

A list of current sub-processors and the categories of personal information they process is maintained in the Sub-processors policy.

9. Testing and continuous improvement

• Annual tabletop exercises are conducted to simulate breach scenarios, validate the runbook, and test notification workflows.
• Security scanning (attack-surface review, dependency audit, IaC scanning) is integrated into the CI/CD pipeline and run on each deployment.
• After-action reviews from each SEV-1 and SEV-2 incident feed directly into the security roadmap and are reviewed by the Information Officer.
• The responsible-disclosure programme (see Responsible Disclosure) provides a channel for external researchers to report potential vulnerabilities.

10. Limitations and honest acknowledgement

No security measure is absolute. eRunna cannot guarantee that its systems will never be compromised. This policy describes the measures and procedures we maintain in good faith to detect, contain, and respond to incidents, and to meet our legal notification obligations.

11. Changes to this policy

We may update this policy from time to time. Material changes will be communicated via in-app notification and/or email. The "Last updated" date at the top of this page reflects the most recent revision.