Data Protection Policy

Sigmund (Pty) Ltd Last updated: 16 September 2026

1. Purpose

This policy explains how Sigmund (Pty) Ltd (registration number 2025/064420/07) handles the personal information that flows through our platform when a customer uses it to collect and assess documents from applicants.

It is written for two audiences: the businesses that use our platform and need to satisfy themselves that we are a safe pair of hands, and the applicants whose documents pass through it. It reflects our obligations under the Protection of Personal Information Act 4 of 2013 ("POPIA").

Our public-facing Privacy Policy covers a different set of information — website visitors, enquiries and our mailing list. This document covers the platform.

2. Our role, and our customer's role

POPIA distinguishes between two roles:

The responsible party decides why and how personal information is processed.
The operator processes personal information for the responsible party, on that party's instructions, and does not decide the purpose itself.

Our customer is the responsible party. Sigmund is the operator. The lender, originator, rental agent or insurer using our platform decides which applicants to invite, what documents to require, what to conclude from them, and how long to keep them. We supply the software and process the information on their behalf.

Section 21 of POPIA requires that relationship to be recorded in a written contract. Which contract applies depends on how the customer came to us:

Self-service customers accept our Terms of Service and Data Processing Addendum at signup. The Addendum is the section 21 contract, and is available countersigned on request.
Enterprise customers typically negotiate their own agreement and data processing agreement. Those supersede ours for that customer's account.

This policy is a public description of our practices. It is not itself the contract, and where it differs from a signed agreement, the agreement governs.

This division of roles has practical consequences:

The customer is responsible for having a lawful basis for collecting the information, and for giving applicants the notice required by section 18 of POPIA.
Applicants who want access to their information, or want it corrected or deleted, should approach the business they applied to. We will assist that business in responding.
Sigmund does not use applicant information for its own purposes, except as described in section 8 below.

3. What information passes through the platform

The exact set is configured by each customer. In practice it typically includes:

Identity documents, passports and proof of address
Payslips, bank statements and proof of income
Tax documents issued by the South African Revenue Service
Employment letters, contracts and affordability information
Contact details and application correspondence
Metadata generated by the platform: upload times, validation outcomes, document quality flags, and the analyst's review decisions

Some of this may constitute special personal information under section 26 of POPIA, or information relating to a child under section 34. Where a customer configures the platform to collect such information, the customer is responsible for establishing that one of the statutory grounds in sections 27 to 35 applies.

4. Processing only on instruction

In line with section 20 of POPIA:

We process applicant information only with the knowledge and authorisation of the customer, and only to provide the services set out in our agreement with them.
We treat all applicant information as confidential and do not disclose it, except where the law requires us to and, where we are permitted to do so, after telling the customer first.
We do not sell applicant information, share it with other customers, or use it to market to applicants.
Configuration choices — what is collected, who may see it, how long it is kept — sit with the customer, and we implement them.

4A. Notices to applicants

Section 18 of POPIA requires the responsible party to notify a data subject when their information is collected. Because we control the applicant-facing touchpoint, we deliver that notice on the customer's behalf.

Every collection email identifies the customer as the responsible party, states the purpose, and links to the Applicant Privacy Notice.
The upload portal displays the section 18 notice before the first upload, and links to the full notice from every page.
The notice names the customer, describes the purpose, states that supplying documents is voluntary and what follows if they are not supplied, identifies the recipients, discloses cross-border processing, and sets out the applicant's rights and the route to the Information Regulator.

Customers may configure the fields that describe their own organisation and purposes, and remain responsible for the accuracy of what they configure. Customers may not remove the notice.

Where consent rather than notice is the correct basis, being special personal information under section 26, the personal information of a child under section 34, or authorisations required by a customer's own regulatory framework, the portal presents a separate, specific, unticked consent control. A refusal does not block the rest of the upload. We record the version of every notice displayed and the outcome of every consent control.

We do not ask applicants for consent to marketing, and we do not market to applicants.

5. Security safeguards

Section 19 of POPIA requires us to secure the integrity and confidentiality of personal information through appropriate, reasonable technical and organisational measures. Ours include:

Encryption. Data is encrypted in transit using Transport Layer Security, and encrypted at rest through our cloud provider's managed key service.

Access control. Access to production systems follows the principle of least privilege and is granted to named individuals under a documented process. Access is revoked when a person leaves.

Tenant separation. Each customer's data is logically separated, and access controls prevent one customer from reaching another's records.

Logging and monitoring. System and access events are logged and monitored for unusual activity.

Backups and recovery. Encrypted backups are taken regularly and retained for a defined period.

Secure development. Code changes are peer reviewed before release, and secrets are held in a managed secrets store rather than in code.

People. Everyone who works with Sigmund signs a written confidentiality undertaking before being given access to applicant data.

Vendors. Every service provider with access to applicant data is contracted in writing with terms at least as protective as those in this policy.

We review these safeguards periodically and whenever we make a material change to our architecture.

6. Sub-operators

The service providers that process applicant data on our behalf are listed, with the purpose of each engagement, at getsigmund.co/subprocessors.

Each is bound by a written agreement requiring it to process the information only on our instructions, to keep it confidential, and to apply appropriate security measures. We remain accountable to our customers for their performance.

We update that page before appointing or replacing a sub-operator that processes applicant information, and notify customers where the change is material.

7. Cross-border processing

Applicant information is processed and stored within the Republic of South Africa and the European Union.

Section 72 of POPIA allows personal information to be transferred outside South Africa where the recipient is subject to a law, binding corporate rules or a binding agreement that upholds principles for lawful processing substantially similar to POPIA's. Our processing in the European Union rests on that ground: it is governed by the General Data Protection Regulation, and our agreements with the relevant providers incorporate the European Commission's Standard Contractual Clauses.

We may change the providers and facilities we use, provided processing continues to take place in a jurisdiction that meets section 72.

Customers who require processing to remain entirely within South Africa, or who require deployment within their own infrastructure, should raise this with us — our architecture is designed to support both, and the arrangement will be recorded in the customer agreement.

8. Using data to improve our models

We develop and improve the models and systems we operate over time. The following limits apply.

De-identification first. Where applicant data is used to improve our models, it is de-identified before it enters any training or evaluation set. De-identification means removing or irreversibly obscuring names, identity numbers, account numbers, addresses, contact details and any other identifiers, so that the individual can no longer be identified from the record, and so that we could not reasonably re-identify them. Section 6(1)(b) of POPIA does not apply to information that has been de-identified to that standard, and section 6(3) prohibits re-identification. We do not attempt to re-identify de-identified data.

Permission comes from the customer, as responsible party. We use a customer's data for model improvement only where that customer's agreement with us expressly permits it, being clause 11 of our Terms of Service for self-service customers, or the equivalent clause in a negotiated agreement. Where no such clause exists, that customer's data is used solely to deliver the service to them.

We do not separately ask applicants for consent to this, because information de-identified to the standard described above falls outside POPIA under section 6(1)(b) and consent is therefore not the applicable basis. A customer may exclude its data at any time, and the exclusion is enforced at the ingestion pipeline rather than downstream.

No cross-customer leakage of business logic. A customer's configuration, decision rules and analyst corrections are that customer's intellectual property. Improvements derived from them are not exposed to other customers other than as general model accuracy.

Third-party model providers. Where we use managed model inference, our provider is contractually prohibited from using our inputs or outputs to train its own models.

Opting out. A customer may direct us in writing to exclude its data from model improvement entirely, at any time, and we will do so from that date forward.

9. Retention and deletion

Retention periods are set by the customer, since the customer is the responsible party and the underlying legal retention obligations (for example under the Financial Intelligence Centre Act or the National Credit Act) are theirs.

By default:

Application records are retained for the period configured by the customer, and thereafter deleted. There is no post-termination export period; exporting is the customer's responsibility while the account is live.
Export tools are available throughout the life of an account, and exporting is the customer's responsibility. On termination we delete applicant data; we are not obliged to return or deliver it in any form.
Deleted data is removed from encrypted backups within our normal backup rotation.
De-identified data used for model improvement is not subject to return or deletion, since it is no longer personal information — but any record from which an individual could be identified is.

10. Security compromises

Section 22 of POPIA requires notification where there are reasonable grounds to believe that personal information has been accessed or acquired by an unauthorised person.

If that happens:

We contain the incident and begin investigating immediately.
We notify the affected customer without undue delay after becoming aware, with the facts we have at that point.
We give the customer the information it needs to notify the Information Regulator and affected applicants, and we assist with that notification.
The customer, as responsible party, makes the notifications to the Regulator and to data subjects. Where the customer asks us to do so on its behalf, we will.
We provide a written post-incident report covering cause, impact and remediation.

11. Requests from applicants

If an applicant contacts us directly to access, correct or delete their information, we will:

Not action the request ourselves, because we are not the responsible party;
Redirect the applicant to the business they applied to; and
Notify that business promptly and assist it in responding within POPIA's timelines.

12. Automated processing

Our platform validates documents, flags anomalies and produces analysis to support a human decision. Section 71 of POPIA restricts decisions that affect a person and are based solely on automated processing.

Sigmund does not make approval or rejection decisions. Our output is provided to the customer's analyst, who decides. Customers who configure the platform to automate any part of a decision remain responsible for complying with section 71, including providing an opportunity for the applicant to make representations.

13. Governance

Our Information Officer is Tapfuma Masunzambwa, info@getsigmund.co, registered with the Information Regulator as required by section 55 of POPIA and its regulations.
This policy is reviewed periodically and after any material change to our systems or sub-operators.
Customers may request our current security documentation. Nothing entitles a customer to inspect our systems, premises or records.

14. Contact

Questions about this policy: info@getsigmund.co

Information Regulator (South Africa) Woodmead North Office Park, 54 Maxwell Drive, Woodmead, Johannesburg, 2191 Telephone: 010 023 5200 Email: POPIAComplaints@inforegulator.org.za Website: https://inforegulator.org.za