Processing register
Pleks's POPIA processing-purpose register — all 12 platform purposes and 26 operator purposes, with lawful bases, data categories, retention periods, and the full operators directory.
Plain-language summary
What this register covers
- Pleks operates in two roles: as Responsible Party for 12 platform purposes (authentication, billing, support — Part A) and as Operator for 26 agency-side purposes (tenant data, leases, inspections, credit screening, property-intelligence — Part B).
- For Part B data, the agency is the Responsible Party. Data-subject requests about tenant or lease records must be directed to the agency, not to Pleks.
- Credit checks (B4) require the applicant’s explicit consent under POPIA · S11(1)(a) and the Credit Bureau Code of Conduct (issued under POPIA, October 2020) before any bureau query is submitted.
- AI processing (B22) is assistive only. Pleks does not make automated decisions about tenants or applicants — all decisions remain with the agency or landlord.
- All cross-border transfers to US/international vendors are governed by Standard Contractual Clauses under POPIA · S72(1)(a).
00 · Background
About this register
This document is Pleks’s processing-purpose register under POPIA · S17 (accountability principle — Responsible Party must have measures in place to ensure compliance) and POPIA · S18 (notification to data subjects of processing purposes). It is published publicly because public accountability is stronger than private accountability, and because agencies evaluating Pleks for procurement have a legitimate need to review exactly what the platform does with personal information before they commit.
If you are an agency or property practitioner using Pleks: under POPIA you are the Responsible Party for every natural person whose personal information you collect — tenants, applicants, landlords, contractors, references, household members. Pleks is your Operator, processing data on your behalf under the Pleks Operator Agreement. This document describes what Pleks does as your Operator; your own register must describe what your agency does, with Pleks listed as one of your Operators.
If you are a data subject (tenant, applicant, landlord, supplier): this document tells you what the platform does and who the actors are. For Part B data, your rights under POPIA are exercised against the agency — the Responsible Party for that data. For Part A data (your Pleks account), your rights are exercised against Pleks directly. Under PAIA, requests for access to records held by Pleks on behalf of a client agency must be directed to that agency’s Information Officer, not to Pleks. Pleks will acknowledge any misdirected request within 2 business days and route it to the correct Responsible Party within 5 business days — so the agency’s statutory 30-calendar-day response clock under s23(1) (per PAIA s25, extendable under s26) is not materially eroded.
Purposes prefixed A are Pleks as Responsible Party. Purposes prefixed B are Pleks as Operator for agencies. This distinction is preserved throughout the register and is load-bearing for all data-subject rights and accountability obligations.
01 · Roles
Controllers
Pleks’s processing activities fall into two distinct controller relationships:
Pleks as Responsible Party (Part A) — for data arising from the platform itself: authentication, security telemetry, error monitoring, product feedback, uptime probes, cost observability, billing, marketing, and support communications. Pleks is the sole decision-maker about this processing and is accountable under POPIA for it.
Pleks as Operator (Part B) — for data arising from agency use of the platform: tenant profiles, leases, inspections, maintenance, communications, trust transactions, deposits, applications, credit checks, owner statements, and every other artefact of property management. The agency is the Responsible Party; Pleks processes this data on the agency’s behalf under section 09 of the Pleks Terms of Service (“ToS §09”), which constitutes the mandatory written-contract terms required by POPIA · S20 and POPIA · S21. Under POPIA · S21 (Operator-to-RP notification), Pleks will notify the agency immediately once Pleks has reasonable grounds to believe that personal information for which the agency is the Responsible Party has been accessed or acquired by an unauthorised person. The agency must then assess whether its own POPIA · S22 obligations to notify the Information Regulator and affected data subjects are triggered; s22 requires those notifications as soon as reasonably possible. The breach-notification obligation is given contractual force in ToS §09.4.
Agency audit rights over Pleks as Operator. Under POPIA · S21, agencies as Responsible Parties have the right to verify Pleks’s compliance with ToS §09. Pleks supports this right through: (a) this publicly available processing-purpose register; (b) provision of a completed security questionnaire or equivalent on written request (at no cost, once per 12 months); and (c) cooperation with reasonable compliance audits on 30 days’ written notice, subject to confidentiality obligations protecting other agencies’ data. The full audit-rights framework is set out in ToS §09.5.
Sovereign-trust invariant. Pleks holds no client funds. Client funds reside in the agency’s own Section 54 trust account at the agency’s own bank. Pleks does not initiate payments and is not the trustee. This is the financial expression of the same principle: Pleks is an Operator, not a custodian.
Mixed-role processing. Purpose B9 (application fee processing) and all Part A observability purposes operate at the Pleks-RP layer even where initiated within an agency workflow. These are structurally separated from Part B processing and are listed under their correct controller in this register.
02 · Officers
Information officer
The Information Officer for Pleks-RP purposes (Part A) is named below. For Part B purposes, the Information Officer is the agency’s own — not Pleks’s. Agencies set their Information Officer details at /settings/privacy/information-officer.
officer
(Part A)Stéan Bouwer · Pleks (Pty) Ltd
legal@pleks.co.za
successionRole vacant — to be appointed under POPIA · S56 as the organisation grows. In the interim, any IO incapacity is covered by the board director of Pleks (Pty) Ltd.
Pleks is registered with the Information Regulator under POPIA s55. Registration number on file with the IO.
RegulatorInformation Regulator of South Africa
JD House, 27 Stiemens Street, Braamfontein, 2001 · inforegulator.org.za · 010 023 5207
Every data subject has the unconditional right to complain to the Information Regulator independently of Pleks or the agency’s response. The Regulator’s contact details are surfaced on every data-subject-rights interface in the platform. Formal information-access requests to Pleks under PAIA must be submitted on Form 2 (Request for Access to Record of Public/Private Body), available from the Information Regulator. Pleks will respond using Form 3 (Outcome of Request and Notice of Fees) within the statutory 30-day window. In compliance with PAIA · S51(3) and the 2021 Regulations, the Pleks PAIA manual is published on this website at /paia-manual.
03 · Safeguards
Security safeguards
Pleks implements appropriate technical and organisational measures consistent with POPIA · S19:
- Encryption in transit: TLS 1.3 for all connections; HSTS enforced; no plaintext fallback.
- Encryption at rest: AES-256 at the database layer via the database and storage provider (see §C); sensitive fields (bank account numbers, TOTP secrets, passkey credentials) additionally encrypted at the column level.
- Row-Level Security: Postgres RLS enforced on every table carrying personal information; service-role access restricted to server-side only with org-scoped gateway helper; no broad-access admin views.
- Authentication: magic-link auth for tenant/landlord/supplier roles; password + mandatory MFA for agent roles; MFA step-up required for fiduciary-class actions.
- Immutable audit logging: every state-changing operation recorded in
audit_logwith actor, target, event type, timestamp, and change payload; no UPDATE or DELETE policies on the log. - PII scrubbing for observability: error monitoring and log aggregation tools receive PII-scrubbed events only; scrubber runs pre-transmission and strips request bodies from sensitive routes and PII patterns from all payloads.
- Signed URLs with TTL: all sensitive downloads use time-limited signed URLs; no public bucket access to customer data.
- Operator contractual controls: every third-party Operator operates under a Data Processing Addendum with SCCs where cross-border, and documented retention and breach-notification terms.
Data quality (POPIA · S16 / S11(2)). Pleks is obliged to keep personal information complete, accurate, not misleading, and updated. For Part A data, Pleks owns this obligation directly. For Part B data, the agency is the Responsible Party and holds the quality obligation; Pleks provides the mechanism (the s23 in-platform correction interface in Purpose B23) to discharge it. Accuracy is especially consequential in credit checking (B4), FitScore generation (B5), and arrears management (B11) — an inaccurate data point in any of these purposes can have legal and financial consequences for the data subject. Pleks surfaces data-quality alerts when it detects internally inconsistent records (e.g., arrears balance vs trust reconciliation mismatch). Agencies must act on correction requests within the 30-calendar-day window under s23(1) (per PAIA s25). Pleks will propagate confirmed corrections to all downstream records that derived from the corrected source data.
Where multiple retention periods apply to the same record, Pleks enforces the longest applicable statutory, contractual, or evidentiary period. Purpose-level retention periods in this register are minimum commitments and may be overridden by mandatory statutory retention (Tax Administration Act s29 — 5 years; PPRA trust records; FIC Act s23 — 5 years; Companies Act s24 — accounting records, 7 years), active legal holds, subject-request restrictions, ongoing disputes, or subpoenas.
Special personal information (POPIA · S26–S27). Pleks does not solicit special personal information as defined in POPIA s26 (religious/political beliefs, race/ethnicity, trade-union membership, health/sex life, criminal behaviour, biometric information). However, special PI may appear incidentally in free-text fields or photos: a maintenance request may reference a tenant’s medical condition; an inspection photo may incidentally capture religious symbols or other s26 attributes. Where this occurs, the agency as Responsible Party must hold a valid s27 ground for processing (typically s27(1)(a) explicit consent or s27(1)(d) law-compliance necessity). Pleks’s UI includes contextual nudges discouraging agents from entering special PI in free-text fields that are not structured for it. Agencies should configure their own data-minimisation policies for their teams. Pleks will flag any pattern of systematic special-PI collection identified through its Operator oversight function.
DPIA programme. Pleks conducts a Data Protection Impact Assessment before deploying or materially changing any processing purpose that involves: (a) credit data or financial scores about natural persons (currently B4, B5); (b) special personal information (s26); (c) AI-derived assessments of natural persons (B22); (d) persistent or precise location data, including EXIF GPS metadata in inspection photography (B14); or (e) systematic processing of children’s personal information (B3). A completed DPIA is a deployment prerequisite — no such purpose ships without one. DPIA records are retained for the life of the purpose.
Sub-processor authorisation and change notification. Pleks uses general written authorisation from agencies for the sub-processors listed in Section C of this register (consistent with POPIA s21(2) and industry practice). When Pleks changes a sub-processor in a way that materially affects agencies’ data, Pleks will notify agencies by email to their registered Information Officer address at least 30 days before the change takes effect, giving agencies a reasonable right to object. Changes that do not materially affect data processing (e.g., infrastructure migration within the same legal entity or jurisdiction) are recorded in the register’s version history without the 30-day window. The current sub-processor list is maintained in Section C of this register and is updated on every version increment.
04 · Rights
Data-subject rights
POPIA confers the following rights on every data subject whose personal information Pleks processes (as Responsible Party — Part A) or processes on behalf of an agency (as Operator — Part B). For Part B rights, exercise them against the agency (the Responsible Party); Pleks will support the agency’s response. The channel for each right is shown below.
- Right of access (s23). Request a copy of the personal information Pleks holds about you, the categories of recipients, the source, and the purpose. Channel: submit Form 2 to our Information Officer at legal@pleks.co.za or via the in-platform subject-rights dashboard. Response within 30 calendar days, extendable per PAIA s26.
- Right to correction (s24). Request correction or deletion of inaccurate, misleading, outdated, incomplete, or unlawfully obtained personal information, and notification to third parties to whom it was disclosed. Channel: in-platform settings (immediate self-serve for profile data) or Information Officer for other records.
- Right to deletion / restriction (s25). Request destruction or deletion of personal information Pleks is no longer authorised to retain. Note: statutory retention obligations (s29 Tax Administration Act, PPRA, audit logs) may prevent deletion during the applicable retention window; Pleks will explain the basis for any retention that continues after a deletion request. If you are not satisfied with Pleks’s response, you may apply to the Information Regulator under POPIA · S74 or to a court under POPIA · S99. Channel: Information Officer.
- Right to object (s11(3)). Where Pleks’s lawful basis is legitimate interest (POPIA · S11(1)(f)) — purposes A3, A5, A6, A10, A12, B11, B16 — you have the right to object to processing on reasonable grounds relating to your particular situation. Pleks will cease processing unless it can demonstrate compelling legitimate grounds that override your interests, or processing is necessary for the exercise or defence of legal claims. Channel: Information Officer or the in-platform subject-rights dashboard.
- Automated-decision rights (s71). Pleks does not make automated decisions about data subjects that produce legal or similarly significant effects. FitScore (B5) is assistive only — final tenancy decisions remain with the agency. If this changes, affected data subjects will have the right to request human review, to express their point of view, and to receive an explanation of the decision. Channel: Information Officer.
- Direct-marketing opt-out (s69 / s11(3)). Where Pleks sends any direct marketing (A7 waitlist communications, any future B25 agency marketing), you may opt out at any time via the unsubscribe link in every message or by contacting the Information Officer. Opt-outs are honoured within 5 business days. Channel: unsubscribe link or Information Officer.
- Right to complain (POPIA s74). You may lodge a complaint with the Information Regulator at any time, independently of Pleks’s or the agency’s response. See §02 for the Regulator’s contact details.
A · Pleks as Responsible Party
Platform purposes
These 12 purposes are those for which Pleks itself is the Responsible Party. The lawful basis for each is normally either performance of the contract between Pleks and the platform user (the Terms of Service, POPIA · S11(1)(b)), or Pleks’s legitimate interest in operating a reliable and secure service (POPIA · S11(1)(f)), with appropriate balancing against the data subject’s interests.
§07 Charter · Agency isolation
Enforced at 4 layers
Layer 1 · Database
Row Level Security on every table
Postgres RLS policies are defined on every agency-scoped table and enforced by the database engine, not the application layer. Every policy carries both USING and WITH CHECK clauses — reads and writes are equally gated. The anon key, used on all client-facing paths, cannot bypass RLS. A direct SQL query using the anon key fails the policy check if org_id does not match the session organisation.
Layer 2 · Application
Gateway org_id binding
Every server-side read and write path passes through gateway() or requireAgentWriteAccess(), which bind the session orgId to the Supabase client before any query executes. Project rules mandate that every query include the org_id scope. Omitting it is a policy violation caught in code review. No server route queries across org boundaries.
Layer 3 · Computation
FitScore scoped at compute time
FitScore results (Purpose B5) are computed within the requesting org context and inserted with org_id bound at the point of write. The FitScore engine has no API surface that accepts a cross-org context. The archived PDF report-of-record is stored under the originating org storage path. A result produced for Agency A cannot be read by Agency B — RLS blocks the read at the database layer.
Layer 4 · Integration
No external aggregation pool
Pleks maintains no external data warehouse, analytics platform, or ML training dataset that aggregates applicant or tenant data across agencies. Each agency's data is a closed silo from ingest to deletion. A successful intrusion yields one agency's data — not a cross-agency pool, because the aggregation system does not exist.
platform_authenticationmfa_totp_passkeyserror_monitoringuser_feedbackuptime_monitoringcost_usage_observabilitymarketing_waitlistplatform_billingsupport_communicationsaudit_logproduct_analyticsplatform_administrationB · Pleks as Operator
Operator purposes
These 26 purposes are those for which an agency using Pleks is the Responsible Party and Pleks is the Operator. Every purpose here is processed on behalf of the agency, under the lawful basis the agency holds for the processing, under ToS §09. Lawful basis caution: the basis shown for each purpose is the basis typically applied by agencies in the SA rental property management sector. It is not a determination by Pleks, and it does not bind any individual agency. An agency may operate on a different basis (e.g., relying on s11(1)(f) legitimate interest rather than s11(1)(b) contract for a given purpose). Each agency must confirm and document its own lawful basis in its own register. Where the agency relies on s11(1)(f) legitimate interest, it must conduct and retain a balancing test.
§02 Charter · Mandate mechanics
No inbound rail — how rent collection works
Pleks does not initiate payments. Rent collection runs through a DebiCheck or NAEDO mandate held between the tenant’s bank and the agency’s bank — Pleks is not a party to that mandate and holds no bank account numbers for this purpose. What Pleks does is read your bank statement after the collection run, match the incoming receipts to your trust ledger, and flag any mismatches. The 26 Operator purposes in this section reflect that reconciliation-observer role — not a payment-initiation role.
property_portfoliolandlord_crmtenant_applicationAccept rental applications from prospective tenants via the public /apply/[slug] portal. Capture form data, supporting documents (ID, proof of income, bank statements, employer letter), and consent records. Support the agency’s shortlist-and-screen workflow. Also processes personal information of third parties named in the application: references, employer contacts, household members, emergency contacts.
Reference contacts as data subjects (POPIA · S12 / S18). References named by an applicant are data subjects in their own right. Under s12 (collection directly from the data subject) and s18 (notification), references must be informed that their personal information has been collected and for what purpose. ToS §09.1 contractually requires the agency to send a s18 notice to each reference at the point of first contact — stating that they have been named as a reference for a rental application, what information will be requested from them, how long it will be retained, and how to exercise their rights. Pleks provides a template s18 notice that agencies may use. Compliance with this obligation is auditable via the communication log.
Children’s personal information (POPIA s34–s35). Applications routinely include dependent details and household members who are minors. Under POPIA s34, processing a child’s personal information requires consent from a competent person (parent or legal guardian). By submitting an application that includes dependent or household-member details for a person under 18, the applicant represents that they are the competent person within the meaning of s34 and are providing consent on behalf of that minor. Processing of minors’ information is limited strictly to housing-suitability necessity — establishing occupancy count and dependent-support obligations relevant to affordability. No credit check, identity verification, or marketing processing is performed against minor household members.
credit_check_searchworxObtain a credit bureau report on an applicant for the purpose of assessing tenancy suitability. The credit bureau aggregator (see §C) consolidates TransUnion, Experian, Compuscan, and XDS. A DPIA (Data Protection Impact Assessment) is in progress for this purpose and will be completed before the feature ships to production — credit data is among the highest-sensitivity personal information categories. No credit check is performed without explicit written consent under POPIA s11(1)(a), in compliance with the Credit Bureau Code of Conduct (issued under POPIA, October 2020) and the credit bureau aggregator’s user agreement (see §C). The NCA s69 register of credit agreements does not provide the consent basis for bureau enquiries — that basis is POPIA s11(1)(a) alone. Consent is captured and verified through a two-step SMS verification — a one-time code sent to the applicant’s own mobile number must be entered before any bureau enquiry is initiated — so the consent is demonstrably the applicant’s own (operationally live since 2026-05-14).
Single-bundle architecture. Credit checks are offered as one standard bundle — a Searchworx report consolidating TransUnion, Experian, Compuscan, and XDS. Each person screened pays for their own check, after their own consent. For a commercial (juristic) applicant, the signatory pays the company’s check for the company only, and each surety director pays for their own — see B9 and B5.
Dual-output reports. Each check produces two outputs: a Consumer Report (PDF delivered to the applicant via a 7-day TTL signed URL under POPIA s18 transparency obligations — contains only the applicant’s own credit data) and an Agent Report (structured credit result and FitScore inputs surfaced in the agent’s applicant dashboard — not transmitted to the applicant). The Consumer Report is generated regardless of the check outcome.
fitscoreGenerate a numeric affordability-and-suitability score for a rental applicant by combining credit check results (B4), verified income (B22 income extraction), rental history, and employment stability. Displayed to the agent alongside a human-readable rationale. Where an application has more than one party, the application’s consolidated assessment — its score and band, the affordability line, and the parties it was computed on — is also shown to each party who completed their part and consented to that sharing; no party’s individual report or per-party result is shown to another party. FitScore is an assistive tool — it does not constitute an automated decision under POPIA s71. Final decisions are made solely by the agency or landlord.
Commercial composite FitScore. For juristic applicants (companies applying for commercial or semi-commercial tenancies), a commercial composite FitScore is generated by combining the company’s credit result with individual FitScores for each named surety director. Each director generates a separate FitScore under their own individual B4 consent — the composite result reflects both entity-level creditworthiness and principal-level affordability. The number of surety directors is configurable per application.
The agency isolation guarantee extends to FitScore data specifically: results are scoped to the originating agency at the point of computation and cannot be queried across org boundaries at any layer. See the four-layer enforcement structure for how this isolation is verified at the database, application, computation, and integration levels.
lease_generation_signinglease_lifecyclerent_invoicing_trackingapplication_fee_processingAccept the applicant’s rental application fee directly via the payment gateway (see §C). The fee is a Pleks-to-applicant service charge covering the cost of the underlying credit bureau report and Pleks’s cost of operating the application-processing service. The agency receives no portion of any application fee under any tier or commercial arrangement.
Pricing. Each person screened pays their own screening fee, after their own consent; the fee covers that person’s credit check, Consumer Report PDF delivery, and bank-statement income analysis (B22). In a joint application each co-applicant pays for their own check — no one pays for another person’s. Commercial / juristic applicants: the signatory pays the company’s screening fee for the company only, and each surety director pays their own per-person fee.
Refund mechanics. The screening service commences upon successful payment. The screening checks are then initiated and the resulting reports are generated as part of that service. Fees are not refundable merely because the applicant changes their mind after screening has commenced, subject to any rights or remedies that cannot lawfully be excluded.
If a bureau or screening provider experiences a technical failure and, after reasonable retries, no screening report is generated, Pleks will refund the screening fee to the extent required by applicable law.
owner_statementsrent_ledger_arrearstrust_reconciliationdeposit_managementinspection_managementmaintenance_managementcritical_incidenttenant_communicationssupplier_managementmunicipal_bill_processinghoa_scheme_managementdocument_generationai_assisted_processingBounded, assistive AI processing across multiple workflows — income extraction and classification from bank statements, FitScore rationale, maintenance triage, deposit deduction justification, lease clause conflict checking, arrears letter drafting, wear-and-tear assessment, municipal bill extraction, AGM notice drafting, and trust audit narrative. AI processing is assistive only: Pleks does not make automated decisions about tenants or applicants. All decisions remain with the agency or landlord. Prompts and responses are not retained — the AI model provider (see §C) operates under a zero-retention Enterprise DPA. PII minimisation is applied before cross-border transfer: prompts contain structured context values (amounts, dates, categories) and exclude direct identifiers (name, ID number, contact details) where the task does not require them. This minimisation reduces but does not eliminate identifiability — structured context (property address, exact rent, exact arrears, dates) may remain reasonably linkable to an individual and constitutes pseudonymised, not anonymised, personal information under POPIA s1. All cross-border AI transfers therefore remain personal information transfers and are governed by SCCs under POPIA s72(1)(a). The agency remains solely responsible for ensuring deductions comply with the Rental Housing Act and applicable Tribunal standards. Agencies are expected to review AI-generated outputs for accuracy, fairness, and contextual appropriateness before relying on them operationally.
Bank statement income and classification. A single Sonnet call performs six simultaneous analyses on each uploaded bank statement: (1) identity match — name on statement against applicant ID document; (2) statement-quality validation — detects missing months, unexplained gaps, account closures, and statement-period truncation; (3) 13-category recurring-debit classification — rent, vehicle finance, insurance, telco, streaming, gym, maintenance levies / HOA, school fees, medical aid, loan repayments, food / utilities, gambling / FICA-flag items, and other; (4) declared-rent fuzzy match — validates the amount the applicant claims to pay in rent against actual debit entries; (5) Pleks invoice-reference detection — identifies whether invoices from Pleks-managed properties appear as expected in the statement; (6) income-reasonableness check — flags implausible declared income against visible credits. The classified output feeds the B5 FitScore affordability model and is included in the B4 Agent Report. Under POPIA s71 this output is advisory — no automated decision is made on the basis of bank statement classification alone.
popia_subject_requestsfica_kyc_storageagency_direct_marketingproperty_intelligencePull public-register information about properties and landlords to verify mandate legitimacy and support property valuation decisions. Three product families: (1) Deeds Office searches — confirming the registered owner of a property matches the person presenting themselves as the landlord at mandate-taking; (2) Lightstone Erf Valuation Short — indicative property market value for owner pitches, FFC due diligence, and insurance value confirmation; (3) CIPC Company and Director lookups — verifying that juristic landlords exist, are in good standing, and that the natural persons claiming to act for them are listed as directors. CIPC Director pulls are limited to first-layer corporate ownership — directors of the named juristic landlord only. Beneficial-ownership chains beyond the first layer constitute a distinct processing purpose with their own balancing test and are out of scope here.
Lawful basis — nature of data matters. For Deeds Office and CIPC pulls (which surface personal information about landlords and directors): POPIA · S11(1)(c) compliance with law — including mandate-taking and due-diligence obligations under the Property Practitioners Act, its Regulations, and the PPRA Code of Conduct — stacked with POPIA · S11(1)(f) legitimate interest — agency-side mandate-fraud prevention and protection of the genuine landlord’s interests against impersonators. The balancing test under s11(1)(f) favours processing: the data subjects’ privacy interests are minimally impacted because the Deeds Office and CIPC are statutorily public registers accessible to any member of the public. For Lightstone Erf Valuation Short in isolation: POPIA does not apply — the return values are property-domain only (no natural-person data subject). Where valuation data is stored alongside Deeds-pulled owner identity data, the combined record is personal information and falls under the Deeds Office analysis above — this prevents a “no POPIA” framing from being misread as a categorical exemption for the combined record.
Distinction from Purpose B4 (credit screening). B27 is structurally distinct from B4 despite both using Searchworx as aggregator. (1) Lawful basis: B4 is POPIA · S11(1)(a) explicit consent — the applicant actively consents to a credit check; B27 stacks s11(1)(c) compliance with law and s11(1)(f) legitimate interest because the data subjects are landlords and directors whose information is in public registers and the agency has a statutory mandate-due-diligence obligation — consent is neither required nor appropriate. (2) Data classification: B4 surfaces credit-bureau data (privacy-sensitive even where lawful); B27 surfaces public-register data (statutorily accessible). (3) Retention: B4 applies POPIA minimisation against credit data (12 months); B27 follows PPA s54 + Regulation 33 mandate-records retention (5 years from end of mandate, or longer where the record supports an audit trail). Conflating B27 with B4 produces incorrect retention enforcement and an incorrect consent posture.
Safeguards. ID numbers from Deeds Office and CIPC Director pulls are stored encrypted at the column level and masked in all display surfaces (last four digits by default; full disclosure gated behind an explicit action and audit-logged) — matching the §03 safeguards pattern applied to FICA records (B24) and credit-screening records (B4). Prior-owner data disposition: where prior-owner data appears incidentally in a deed-history response, it is retained in the raw vendor-response audit payload but not surfaced in the agency UI, not parsed into operational extracted fields, and not used for any operational purpose. POPIA · S18 notification posture: individual s18 notification is not provided to incidental data subjects (first-layer directors and prior owners surfaced in vendor responses). Reliance is placed on the s18(4) notification exceptions — the personal information is derived from a statutory public register; notification would prejudice a lawful fraud-prevention purpose; notification is not reasonably practicable given the manner and source of collection. Operationally engaged directors receive notification through the agency relationship itself per standard s18 practice.
C · Appendix A
Operators directory
Every third party Pleks uses in the course of processing personal information. For each: what they do, where they are domiciled, what contractual instrument governs the relationship, and which purposes they serve.
| Operator | Role | Domicile | Instrument | Purposes |
|---|---|---|---|---|
| Supabasedatabase · storage · auth | Backend-as-a-service — Postgres database, authentication, storage, realtime | Ireland (EU — eu-west-1) | Terms of Service + Data Processing Addendum with SCCs. Sub-processor: AWS. | A1–A12, B1–B25, B27 |
| AnthropicAI model provider | Claude Haiku 4.5, Sonnet 4.6, Opus 4.6 — bounded assistive-only AI processing | US (San Francisco) | Anthropic Commercial Terms + DPA with SCCs + zero-retention Enterprise agreement (no API inputs or outputs retained for training) | B22 |
| Yodleebank-feed aggregator | Bank-feed aggregation — reads the agency's connected bank account transactions for trust reconciliation, when the agency connects a feed | US | Envestnet | Yodlee Terms + DPA with SCCs | B12 |
| Sentryerror monitoring | Exception tracking for platform defect detection. All events PII-scrubbed before transmission. | US (San Francisco) | Sentry Terms of Service + DPA with SCCs | A3 only |
| Resendtransactional email | Transactional and marketing email delivery. Suppression list and DKIM/SPF/DMARC enforced. | US | Resend Terms of Service + DPA with SCCs | A1, A4, A7–A9, A12; B2, B7, B10, B11, B17, B21, B23 |
| Africa's TalkingSMS · WhatsApp aggregation | SMS and WhatsApp Business Platform aggregation for SA mobile networks. Routes WhatsApp through Meta. | Kenya (Nairobi) | Africa's Talking Terms of Service + DPA | B2, B11, B15–B18 |
| PayFastpayment gateway | Payment processing for application fees and Pleks subscription payments. PCI DSS Level 1 certified. | South Africa (domestic) | PayFast Merchant Agreement. Pleks never sees full card PAN — PayFast is the PCI boundary. | B9, B27, A8 (limited) |
| DocuSeale-signature · self-hosted | Digital signature and document-signing workflow. Self-hosted on Hetzner SA (South African infrastructure) — no cross-border transfer. | South Africa — Hetzner SA (domestic; no SCCs required) | DocuSeal open-source licence. No third-party DPA required — no data leaves Pleks's infrastructure. | B6 |
| MetaWhatsApp Business | Upstream WhatsApp Business Platform provider — reached via Africa's Talking. Meta-approved templates for transactional messages only. | US (California) / Ireland (EU) | Meta's terms mediated through Africa's Talking relationship | B17 |
| Better Stackuptime monitoring | Uptime monitoring, heartbeat tracking, and alerting. No PII in probe traffic. | US (Delaware) | Better Stack Terms of Service + DPA with SCCs | A5 only |
| Vercelapplication hosting | Next.js hosting, edge-function invocation, CDN. Hosts the entire Pleks application. | US (San Francisco), global edge | Vercel Terms of Service + DPA with SCCs. Logs are POPIA-scrubbed consistent with observability policy. | A1–A12, B1–B25, B27 |
| Searchworxcredit bureau aggregator | Multi-product data intermediary — aggregates TransUnion, Experian, Compuscan, and XDS (credit products); Deeds Office of South Africa (property ownership); CIPC (company and director data); Lightstone (property valuations); Home Affairs (DHA); TPN. Explicit applicant consent required per credit check (B4). Property-intelligence pulls (B27) operate under s11(1)(c)/(f) — no applicant consent required. Lightstone operates as a sub-Operator to Searchworx for the valuation product family. | South Africa (Johannesburg — domestic) | Searchworx Services Agreement + POPIA-compliant DPA. Searchworx is itself bound by NCA, POPIA, and FICA regulatory obligations. Data residency: asserted as SA-domiciled; Pleks is seeking written confirmation from Searchworx that all credit data (including data transiting to underlying bureaus TransUnion, Experian, XDS, Compuscan) remains within SA infrastructure. This entry will be updated on receipt of confirmation. Lightstone POPIA compliance incorporated by reference per POPIA s21(2). | B4, B27 |
| Lightstoneproperty valuations | Commercial property-data vendor providing Erf Valuation Short — estimated market value, value-band, last-sale data. Accessed exclusively via the Searchworx operator chain; Lightstone does not receive or process Pleks customer personal information directly. | South Africa (domestic) | Lightstone data licence via Searchworx operator chain. Lightstone POPIA compliance posture incorporated by reference into the Pleks/Searchworx commercial agreement per POPIA s21(2). No direct Pleks–Lightstone DPA required — relationship governed through Searchworx. | B27 (property valuation sub-purpose only) |
| GitHubsource code hosting | Source-code hosting. Processes contributor PII (commit author identities) only — no customer personal information. | US (San Francisco) | GitHub Terms of Service. Secret-scanning and Dependabot enabled. No customer data in code. | None for customer data |
| Google Maps Platformaddress autocomplete | Address autocomplete when an agent adds a property. Receives the typed address text and the agent's browser IP; no tenant, applicant or ID data. | US (Mountain View) | Google Maps Platform Terms of Service + Google's data protection terms for Maps Platform | B1 |
This register is maintained as a living document. Every new processing purpose or new Operator introduced by a subsequent Pleks build specification requires an entry here before the feature ships. The version number increments on every material change (new purpose, new Operator, new cross-border transfer, retention period change, lawful basis change). Material changes also trigger a re-consent notification flow to affected agencies.
For questions about this register or to exercise your rights as a data subject, contact our Information Officer — see §02 above. The data-processing obligations that give this register contractual force for Part B purposes are set out in section 09 of the Pleks Terms of Service. Agencies evaluating Pleks for procurement are encouraged to review ToS §09 alongside this register before contracting.