Data Protection Processing Policy (POPIA Operator Mandate)

 

Governing Law: Protection of Personal Information Act, 4 of 2013 (POPIA)

Issued by: Swarm Apps (Pty) Ltd (The Operator), a B2B SaaS Services Provider (Loyalty, Rewards, Gift Cards, and Marketing Automation)

 

1. Scope, Purpose, and Definitions

 

1.1 Scope

This policy applies to all processing activities performed by Swarm Apps (Pty) Ltd (the “Operator”) on behalf of its Business-to-Business (B2B) clients (the “Responsible Parties” or “Clients”) who utilise the Operator’s PoS and eCommerce integrated loyalty, rewards, gift card, and marketing automation platform (the “Service”).

 

1.2 Key Definitions (in context of POPIA)

• Responsible Party (RP)

  • Role in the Service: The Client (e.g., Retailer, Hotel) who contracts the Service.

  • Primary POPIA Obligation: Determines the purpose for processing Personal Information (PI) and is responsible for obtaining lawful consent from Data Subjects.

• Operator (OP)

  • Role in the Service: Swarm Apps (Pty) Ltd (The SaaS Provider).

  • Primary POPIA Obligation: Processes PI strictly on the written instruction of the Responsible Party and ensures adequate security safeguards.

• Data Subject (DS)

  • Role in the Service: The End-Customer (e.g., loyalty programme member, gift card recipient).

  • Primary POPIA Obligation: The individual whose Personal Information is being processed.

• Personal Information (PI)

  • Description: Names, Date of Birth, contact details (email, mobile), loyalty ID, transactional history, basket data, and purchase patterns.

  • Primary POPIA Obligation: To be protected at all times against loss, unauthorised access, or destruction.

 

2. Operator’s Mandate and Lawful Processing

2.1 Mandate to Process (POPIA Section 20)

The Operator is mandated to process Personal Information (PI) solely for the purpose of executing the Services contracted by the Responsible Party. The Operator:

1. Will only process PI with the knowledge and authorisation of the Responsible Party.

2. Will treat all PI as confidential and shall not disclose it to any third party, unless specifically instructed in writing by the Responsible Party, or if required by law.

3. Acknowledges that the Responsible Party is the ultimate custodian of the PI and retains final accountability for compliance with POPIA.

2.2 Scope of Processing

The Operator’s Service requires the processing of PI for the following explicitly defined purposes:

• Loyalty Management: Calculating, issuing, tracking, and redeeming rewards based on transactional history and frequency, specifically linked via PoS integration.

• Gift Card Facilitation: Processing sales, loading value, tracking balances, and facilitating redemption of digital and physical gift cards.

• Targeted Communication & Marketing Automation: Segmenting Data Subjects based on purchasing behaviour (using basket data) and age (derived from Date of Birth) to deliver relevant offers, promotions, or system notifications (SMS/Email) on behalf of the RP to increase customer lifetime value.

• Data Analysis and Reporting: Generating anonymised and aggregated reports for the RP concerning customer lifetime value, campaign success, and consumption trends, including linking customer identifiers with basket data.

2.3 Minimality and Data Types

The PI processed by the Operator is limited to what is adequate, relevant, and not excessive for the aforementioned purposes. This typically includes:

• Customer Identifiers: Name, Surname, Date of Birth, Email Address, Mobile Number, Loyalty Card/App ID.

• Transactional Data: Date/Time of transaction, PoS location, Basket details (items purchased, quantities), total spend, loyalty points earned/redeemed.

• Behavioural Data: Redemption history, campaign response rates, and preferred communication channels.

 

 

3. Compliance with POPIA’s Conditions

The Operator shall implement the necessary safeguards and processes to assist the Responsible Party in complying with the conditions for the lawful processing of PI.

3.1 Accountability and Governance

• Information Officer: The Operator maintains an appointed Information Officer responsible for overseeing POPIA compliance within the organisation.

• Internal Compliance Framework: The Operator implements a documented framework that includes internal policies, training, and regular audits of processing activities.

3.2 Security Safeguards (POPIA Section 19 & 21)

This is the Operator's primary direct responsibility under POPIA. The Operator shall establish and maintain appropriate, reasonable technical and organisational measures to prevent:

• Loss of, damage to, or unauthorised destruction of PI.

• Unlawful access to or processing of PI.

• Technical Measures:

  • Encryption in Transit: PI is encrypted while in transit (using TLS/SSL protocols) to protect data moving between the client systems and the Operator’s Service.

  • Access Control: Strict, role-based access control (RBAC) is implemented, ensuring staff access PI only on a “need-to-know” basis related to their job function.

  • Network Security: Use of firewalls, intrusion detection systems, and vulnerability scanning on all network components hosting the Service.

  • Data Isolation: Client data is logically segregated within the platform to prevent cross-contamination or unauthorised access between Responsible Parties.

• Organisational Measures:

  • Confidentiality: All personnel processing PI are subject to a written duty of confidentiality and receive mandatory POPIA training.

  • Physical Security: Hosting environment security (whether owned or provided by a certified cloud provider) adheres to industry standards (e.g., ISO 27001).

3.3 Data Subject Participation and Rights 

The Operator shall assist the Responsible Party in responding to Data Subject requests (e.g., right to access, rectification, or deletion of PI).

• Request Handling: If the Operator receives a request directly from a Data Subject, the Operator will immediately notify and forward the request to the Responsible Party, awaiting their formal instruction before taking action.

• Deletion/Return: Upon termination of the Service Agreement, the Operator will, at the instruction of the Responsible Party, either securely destroy or return all PI processed on their behalf, unless legal retention requirements override this instruction.

 

4. Data Breach Management and Reporting

4.1 Breach Notification (POPIA Section 22)

In the event that the Operator has reasonable grounds to believe that the PI of a Data Subject has been accessed or acquired by any unauthorised person (a “Security Compromise” or “Breach”), the Operator shall:

1. Immediate Notification: Notify the affected Responsible Party immediately and without undue delay, providing all known details of the breach.

2. Mitigation: Take all reasonable steps to mitigate the harm caused by the breach and restore the integrity and security of the Service.

3. Assistance: Provide the Responsible Party with all relevant information necessary for the RP to comply with its own notification obligations to the Information Regulator and the affected Data Subjects.

4.2 Liability

The Operator’s liability for any loss or damage arising from a breach or non-compliance will be governed by the specific terms and conditions set forth in the formal Data Processing Agreement (DPA) and the main service contract between the Operator and the Responsible Party.

5. Sub-Contracting and Trans-Border Flow

5.1 Sub-Contracting

The Operator shall not engage any sub-processor (another Operator) to process the PI without the prior written general or specific authorisation of the Responsible Party. Where authorisation is given, the Operator remains responsible for ensuring the sub-processor adheres to the same POPIA obligations and security standards as set out in this policy and the DPA.

5.2 Trans-Border Flow

PI received from a Responsible Party located in South Africa shall not be transferred outside of the Republic of South Africa unless:

• The transfer is to a country that provides an adequate level of protection (as prescribed by POPIA or through binding corporate rules).

• The Responsible Party and the Data Subject have provided prior explicit consent for the transfer.

• The transfer is necessary for the performance of a contract between the Data Subject and the Responsible Party.

 

​