Skip to content
DA DataAcuity by The Geek Network
Contact Get an API key

DataAcuity — BI Compliance Map

Status: 🔵 DESIGNED — to be reviewed by compliance + legal counsel before BI Pipeline Phase 2 ships Owner: Tinashe Bhengu Companion docs: DataAcuity_BI_Anonymisation_Standard.md (the controls), DataAcuity_Security_Posture.md (the network/access controls), .claude-memory/banking-compliance-rules.md (broader TGN banking compliance)

This document maps each clause of every regulation that applies to The Geek Network's data flows to specific BI pipeline controls that satisfy it. Use it for:

  • Compliance review sign-off before each pipeline phase ships
  • Regulator audit response (here's the clause, here's the control, here's the test that proves it works)
  • New-team-member onboarding (what's the why behind the controls)

1. Scope

In scope: every flow of TGN user/customer data through the BI pipeline (extract from .104/.105 → warehouse on .106 → push-back to .104 analytics_db).

Out of scope (covered elsewhere):

  • App-layer authn/authz (in TGN AuthAPI and per-app threat models)
  • Live transaction flows (in the per-API services, not the BI pipeline)
  • Marketing automation flows (TBD — separate consent model)
  • Broader corporate compliance (HR data, financial reporting, etc.)

2. Regulations covered

Regulation Jurisdiction Why it applies
POPIA South Africa TGN is a South African company processing SA residents' personal info
GDPR EU / EEA Any TGN user accessing the apps from the EU triggers GDPR jurisdiction
FICA South Africa, financial SDPKT wallet, BidBaas auctions, Takemehome bookings involve financial transactions
CCPA / CPRA California Same logic as GDPR — California residents trigger jurisdiction
PCI-DSS Global, card data We touch card PANs in SDPKT (briefly, via PayFast tokenisation) — must ensure card data NEVER reaches warehouse

We are NOT (currently) subject to HIPAA (no health data in scope), SOX (not US-listed), CCPA child-specific provisions (no targeted-to-minors flow). Re-evaluate if scope changes.

3. POPIA mapping (South Africa)

3.1 The 8 conditions for lawful processing (Sec 8–25)

# Condition Statutory ref Pipeline control Test
1 Accountability Sec 8 Named owner per intermediate.* model in dbt metadata; compliance reviewer signs off Audit log of approvals; presence of meta.owner on every dbt model
2 Processing limitation Sec 9 Extract job pulls only fields needed for declared mart purposes; no SELECT * from source DBs Source column allow-list per mart; PR check that any new column being extracted has a purpose statement
3 Purpose specification Sec 13 Each mart's dbt model has a description: block stating the purpose dbt docs auto-generated; review on PR
4 Further processing limitation Sec 15 Marts only built from declared purposes; analytics can't repurpose without new compliance review Lineage graph; alert if a mart is consumed by a downstream system not declared in its purpose
5 Information quality Sec 16 dbt tests for not_null, unique, freshness; data dictionary Test suite runs daily; freshness alert
6 Openness Sec 17–18 Public-facing privacy notice + records of processing (Art 30 equivalent) Annual review; user-visible privacy notice references this pipeline
7 Security safeguards Sec 19 See §3.2 below Annual penetration test + monthly lynis audit
8 Data subject participation Sec 23–25 RTBF flow in DataAcuity_BI_Anonymisation_Standard.md §10; data export on request 30-day SLA tracked in compliance.deletion_completion

3.2 Sec 19 security obligations — what "reasonable measures" means in practice

Sec 19(1) requires "appropriate, reasonable technical and organisational measures." Our specific measures:

Measure Implementation
Identify reasonably foreseeable risks Threat model in DataAcuity_Security_Posture.md §2
Establish and maintain safeguards Hardening plan §6, Phases A–G
Verify safeguards are effectively implemented Phases include verification steps; quarterly Grafana review
Ensure safeguards are continually updated Monthly lynis baseline; image scans via trivy; quarterly tabletop exercise
Have regard to generally accepted information security practices We follow CIS benchmarks where they apply; we use POPIA Code of Conduct guidance
Implement specific procedures for processing personal info Documented in this folder; reviewed annually

3.3 Sec 22 — Notification of security compromises

72-hour notification required. Our process:

  1. Incident detected → on-call paged (per DataAcuity_Security_Posture.md Phase D runbook)
  2. Within 24 h: scope assessed by compliance officer + tech lead
  3. Within 48 h: notification draft prepared (to Information Regulator + affected data subjects)
  4. Within 72 h: notification sent if breach confirmed material

Materiality threshold: any unauthorised access to or disclosure of PII covered by this pipeline.

3.4 Sec 25 — Quality of records of processing operations

Records maintained:

  • intermediate.* and marts.* SQL with version control (git)
  • compliance.deletion_completion (record of each RTBF fulfillment)
  • compliance.token_access_audit (record of each break-glass token recovery)
  • Annual data processing register reviewed by compliance officer

4. GDPR mapping (EU)

4.1 Principles (Art 5)

Principle Pipeline control
Lawfulness, fairness, transparency Legal basis recorded per processing purpose in compliance.processing_register. Most BI uses are legitimate interest (Art 6(1)(f)); marketing uses are consent (Art 6(1)(a)).
Purpose limitation Same as POPIA Sec 13 — each mart declares purpose; downstream consumers must match a declared purpose
Data minimisation Same as POPIA Sec 9 — explicit column allow-list per mart
Accuracy dbt tests + freshness; user-initiated corrections propagate within 24h
Storage limitation Retention table per source DB; raw.* purged at 90 days, downstream as defined per mart
Integrity and confidentiality Encryption at rest (Postgres TDE or volume encryption), TLS in transit between .105 ETL → .106 warehouse, access controls per DataAcuity_Security_Posture.md §8.4
Accountability Documented controls; named compliance reviewer; audit log

4.2 Lawful basis (Art 6)

Purpose Lawful basis Justification
Ops analytics, fraud detection, system health Legitimate interest (Art 6(1)(f)) Necessary for service operation; minimal privacy impact (anonymised); compatible with user expectations
Personalised in-app analytics ("your activity this week") Legitimate interest User benefits directly; uses only their own data
Marketing analytics (cohorts, attribution) Consent (Art 6(1)(a)) User opts in at signup; can withdraw
Financial transaction analysis Legal obligation (Art 6(1)(c)) for FICA reporting; legitimate interest otherwise FICA mandates this analysis
Sharing with third parties Consent for marketing partners; legal obligation for regulators Must be granular consent (Art 7)

4.3 Rights of data subjects (Art 12–22)

Right Article Mechanism
Right of access Art 15 User requests via AuthAPI → compliance officer exports all data including BI-derived aggregates linked to their user_hash
Right to rectification Art 16 User corrects in source app → propagates to warehouse on next extract
Right to erasure Art 17 RTBF flow per Anonymisation Standard §10. 30-day SLA
Right to restriction Art 18 compliance.legal_hold flag freezes processing of specific user records
Right to portability Art 20 Same as Right of access but in machine-readable format (JSON / CSV)
Right to object Art 21 Especially marketing analytics — consent withdrawal → user removed from marketing marts within 7 days
Rights re: automated decision-making Art 22 Currently NO automated decisions made about users from BI data. If/when ML scoring is used, separate Art 22 process required

4.4 Cross-border transfer (Art 44–50)

EU user data flows from .104 (in South Africa) → .105 → .106 → .104 analytics_db. All servers are in South Africa.

  • SA does not have a GDPR adequacy decision (as of 2026-05). Cross-border transfer needs Standard Contractual Clauses (SCCs) or Binding Corporate Rules (BCRs) between the EU controller (TGN's EU presence, if any) and the SA processor (TGN South Africa).
  • Action: if TGN markets to or processes EU users, the company contract needs SCCs in place BEFORE the pipeline carries EU PII. Compliance + legal counsel to verify.

4.5 DPIA (Art 35) — Data Protection Impact Assessment

Required when processing is "likely to result in a high risk to the rights and freedoms of natural persons." The BI pipeline qualifies because:

  • Large-scale processing of personal data
  • Combining data from multiple sources
  • Profiling (cohorts, lifecycle stages)

A DPIA must be completed before Phase 2 (anonymisation layer) ships. Template:

  1. Description of processing (this whole folder)
  2. Necessity and proportionality assessment
  3. Risk assessment (re-identification risk, breach risk, profiling risk)
  4. Measures to mitigate risk (anonymisation standard, access controls, k-anonymity)
  5. Sign-off by DPO (or equivalent)

5. FICA mapping (South Africa, financial)

FICA primarily applies to the SDPKT wallet, BidBaas auctions (where money changes hands), Takemehome bookings, and any payment flow.

5.1 Customer due diligence (Sec 21–22)

Apps already handle KYC at signup. The BI pipeline:

  • MUST NOT generate KYC decisions
  • MAY use anonymised KYC tier (no-kyc, basic, verified) for analytics (Class E)
  • MUST retain raw KYC records for 5 years after relationship ends (per Sec 22)

5.2 Record-keeping (Sec 22)

5-year retention for:

  • Identification documents
  • Transaction records (amount, parties, date, purpose, payment instrument)
  • Suspicious transaction reports

In the BI pipeline:

  • Raw transaction records stay in source DBs on .104 for at least 5 years
  • marts.fct_ledger_transactions_anon may be kept indefinitely (no PII)
  • Tokenised identifiers (Class B) in compliance.token_vault retained 5 years minimum

5.3 Reporting (Sec 28)

Suspicious transactions reported to Financial Intelligence Centre (FIC). The BI pipeline:

  • MAY surface anomaly flags (marts.fct_ledger_transactions_anon.anomaly_score)
  • The actual reporting decision and form-filing happen in TGN's compliance workflow, NOT in the warehouse
  • Tokens enable de-anonymisation under controlled access if FIC requests details

5.4 Training (Sec 43)

Compliance training records kept separately, not pipeline concern.

6. CCPA / CPRA mapping (California)

If TGN has California users (likely once apps go global):

Right Mechanism
Right to know (what's collected) Same as GDPR Art 15 — export endpoint
Right to delete Same as GDPR Art 17 — RTBF flow
Right to opt out of sale We don't sell data; controls in place to ensure we couldn't accidentally start
Right to non-discrimination Service quality must not degrade based on exercising privacy rights — tested by compliance review

CPRA additions:

  • Right to correct inaccurate info — same mechanism as GDPR Art 16
  • Right to limit use of sensitive personal info — Class B fields gated behind explicit consent for any use beyond the original collection purpose

7. PCI-DSS — what we DON'T do

We do NOT store card data in scope of this pipeline. Cards are tokenised at PayFast (out of our control) and we hold only card_pan_last4 (4 digits, not full PAN — explicitly NOT in scope of PCI's Account Data definition).

Controls to ensure no PCI scope creep:

  • Extract job has a hard deny on any column named *pan*, *cvv*, *card_full*, *track_data*
  • Compliance review of any new source table that mentions cards
  • Annual scope review with security team

8. Combined controls matrix

A single matrix view: regulation × control. Useful for audit response.

Control POPIA GDPR FICA CCPA Implementation reference
Named compliance owner ✓ S8 ✓ Art 24 — — dbt meta.owner; PR review
Purpose specification ✓ S13 ✓ Art 5(1)(b) — ✓ dbt model description:
Data minimisation ✓ S9 ✓ Art 5(1)(c) — ✓ Per-mart column allow-list
Consent record (where applicable) ✓ S11 ✓ Art 7 — ✓ AuthAPI consent table
Anonymisation ✓ S19 ✓ Art 5(1)(f) ✓ S22 (records) ✓ DataAcuity_BI_Anonymisation_Standard.md
Encryption at rest ✓ S19 ✓ Art 32 — ✓ Postgres TDE / volume encryption
Encryption in transit ✓ S19 ✓ Art 32 — ✓ TLS on .105 → .106 and .106 → .104
Access controls ✓ S19 ✓ Art 32 ✓ S22 ✓ Role separation per DataAcuity_Security_Posture.md §8.4
Audit logging ✓ S19 ✓ Art 30 ✓ S43 ✓ compliance.token_access_audit, Loki, Postgres audit
Incident response ✓ S22 ✓ Art 33–34 — ✓ Phase D runbook
Right of access ✓ S23 ✓ Art 15 — ✓ AuthAPI export endpoint
Right to erasure ✓ S24 ✓ Art 17 (subject to S22 retention) ✓ RTBF flow in Anonymisation Standard §10
Records of processing ✓ S25 ✓ Art 30 ✓ S22 ✓ compliance.processing_register
Cross-border transfer (cf. S72) ✓ Art 44 — — SCCs / BCRs (if EU users)
DPIA (not mandated but good practice) ✓ Art 35 — — Per Phase 2 ship
K-anonymity for aggregates (S19 best practice) (Art 4(5) pseudonymisation) — — dbt test on every user-aggregate mart

9. Open items

  1. Named DPO — if TGN serves EU users at scale, a DPO is mandatory under GDPR Art 37. Who's it going to be?
  2. EU SCCs in place? — block GDPR data flow until verified
  3. Privacy notice updated to reflect the BI pipeline's processing — coordinate with marketing/legal
  4. External privacy / compliance counsel engagement — at minimum for the initial DPIA + ongoing annual review
  5. Information Regulator (SA) registration as a responsible party — confirm current status
  6. POPIA Code of Conduct — does TGN subscribe to one (e.g., the financial services one)? If yes, additional obligations apply
  7. Children's data — any TGN app accessed by minors? Triggers additional protections (POPIA Sec 35, GDPR Art 8, CCPA-K)

10. Cross-references

11. Change log

Date Change By
2026-05-28 Initial document — clause-by-clause mapping extracted from BI Pipeline §6.7 Tinashe Bhengu
Something went wrong on this page. Reload