Client data protection

01Roles under POPIA

For the data in your platform, you are the responsible party: you decide why and how it is processed, and you answer for it to your customers and the Information Regulator. Dynepta is your operator under section 21 of POPIA. We:

• process your data only with your knowledge and authorisation, on your written instructions;
• treat it as confidential and do not disclose it unless the law requires us to;
• maintain the security measures described on this page and in our data processing agreement with you;
• never use your data for our own purposes, never sell it, and never use it to train AI models.

These commitments are set out in a written data processing agreement that we sign with every client before any work starts.

02Where your data lives

Everything that touches your data runs in your own Google Cloud organisation, in projects you own, billed to your own account. Your data is never copied into Dynepta’s systems.

Our standard region is europe-west1 (Belgium), for every part of the platform. Google’s service for copying changes from live databases (Datastream) isn’t offered in any African region, and the platform’s layers have to sit in one region to work together. Keeping personal information outside South Africa has POPIA implications, so before anything is built we go through what that means for your business and record how our data processing agreement covers it.

03What Dynepta can see

To monitor many environments without logging into each one, we receive short health summaries from your environment:

The summaries contain no personal information. Sending them requires your consent, and you can switch them off at any time.

04How we access your environment

• Read-only by default. Day to day we see what support needs, such as build history, logs, check results and run history, and none of your business data. Changes reach your production environment only as settings changes your own approvers approve.
• Emergency access you grant. If we need to act directly in production, you grant it as a change you approve, for at most 72 hours, and it ends by itself.
• No keys. We never create service account keys. Engineers act through that account by impersonation, and our deployment pipeline authenticates with workload identity federation, so there are no stored credentials to leak.
• Groups, not individuals. People get access through groups, never one by one, so access can be granted and removed in one step and is auditable.
• Least privilege. Every job runs under its own service account with access only to the datasets it needs. No account has owner or editor rights.
• Access register. We keep a record of who can reach which client environment, remove access when someone leaves, and review it every quarter.
• Light on your systems. Database changes are read from the database’s own change log by a read-only user. Exports can come from a copy of your database instead.

05Personal data controls

• Classification. Every source column is labelled once as restricted, personal, internal or public. That label drives access in every layer.
• Masking. Restricted fields (such as ID numbers and bank details) and personal fields are masked, shown as empty, for anyone outside the groups you name to see them, from the first layer your people read onward.
• Labels carried into the warehouse. Warehouse tables hold personal columns only where the analysis needs them. Each one keeps its label, is masked for anyone whose role doesn’t need it, and a check confirms the masking.
• Division-level access. Each division reads its own data products, in its own datasets, and personal fields reach a division only with a recorded reason.
• Automated checks. Checks confirm that every personal column is masked and raise an alert if one isn’t.
• Audit logging. Audit logs from your three projects are kept in a log bucket in your own project, for as long as you choose, and only your auditors read them.
• Secrets. Credentials live in Secret Manager, never in code or configuration files.

06Service providers

Your platform runs on Google Cloud, billed to your own account; our data processing agreement lists Google, and any other sub-processor, by name. Dynepta’s own tools never hold your data:

We will tell you in advance before adding any provider that would process your data.

07Security incidents

If we have reasonable grounds to believe your data has been accessed or acquired by an unauthorised person, we will notify you immediately, as section 21(2) of POPIA requires, and in any event within [24 hours] of becoming aware of it, as set out in our data processing agreement. We will give you the information you need to meet your own duty to notify the Information Regulator and affected people under section 22, and we will help you contain and investigate the incident.

08Retention and deletion

You decide how long data is kept, and we configure partition expiry in the raw layer to match. For deletion requests from your customers, we provide a documented routine that removes a person’s records by key from the raw and stage layers, and from any warehouse tables that hold their data.

Please note that BigQuery keeps deleted data recoverable for a limited time afterwards (its time-travel and fail-safe features), and fail-safe cannot be switched off. This is stated in our agreement so you can tell your customers accurately.

09When the contract ends

You keep your data and the environment built for you, and may keep running it for your own use. We remove our ability to act in your environment and our staff from your access groups, update our access register, stop the health summaries, and hand over documentation. New versions and support end, and the Dynepta toolkit’s code and templates remain our property.

10Documents available on request

Prospective clients can ask for copies of our standard master services agreement, scope sheet template and data processing agreement before signing. Email hello@dynepta.com.