About usServicesTrainingAcademyKnowledge hubAI solutions Book a consultation

Home / Knowledge hub / Articles

Why your transformation data belongs on your own systems

Transformation records hold some of the most sensitive data a company keeps. Why we build local-first systems, what POPIA asks of you and when the cloud is fine.

By Terrance Thabang Baloyi · · AI and data

Ask a transformation manager where the company's B-BBEE data lives and you will usually get a list rather than an answer. Some of it is in payroll. Some is in the procurement system. The EE declarations sit in a folder on the HR drive, the supplier certificates in someone's inbox, and the working file that pulls it all together has been emailed back and forth so often that nobody is sure which version is current.

When companies decide to fix this, the usual answer is a cloud platform: upload everything, log in from anywhere and let the vendor worry about the rest. I understand the appeal. But for this particular kind of data, I think that default is often wrong. I want to set out why we build local-first systems for our clients, and when I would happily recommend the cloud instead.

This is not ordinary business data

Transformation records are personal in a way that most operational data is not. An EE workforce profile lists people by race, gender and disability status, next to their occupational level and pay. A skills register records who was trained, who received a bursary and who was absorbed into a job. Ownership records may name individual Black shareholders and trust beneficiaries.

Under the Protection of Personal Information Act (POPIA), race and health information is special personal information (section 26), and disability information will usually be treated as health information. Processing it is prohibited unless one of the specific authorisations in the Act applies. Put all of this together and you have one of the most sensitive collections of information a company holds. It deserves the thinking you would give to payroll banking details, not the thinking you would give to a shared marketing calendar.

What the law asks of you

POPIA does not tell you where to keep data. It tells you what you are responsible for wherever you keep it.

Section 19 requires the responsible party, which is your company, to secure the integrity and confidentiality of personal information in its possession or under its control, through appropriate and reasonable technical and organisational measures. It is more specific than a general duty of care. You must identify the reasonably foreseeable internal and external risks, put safeguards in place against them, check regularly that those safeguards work and update them as the risks change.

Sections 20 and 21 deal with operators: anyone who processes personal information on your behalf. A cloud vendor holding your EE data is an operator. You need a written contract that obliges it to maintain security measures, and it must tell you immediately if it believes the data has been compromised. The responsibility stays with you.

Section 72 deals with sending personal information to a third party in a foreign country. That is allowed only on specific grounds: for example, where the recipient is bound by a law, binding corporate rules or an agreement that gives an adequate level of protection, substantially similar to POPIA's, or where the person concerned consents. If your platform stores or processes data outside South Africa, someone in your company should be able to say which ground applies, and show it.

None of this makes the cloud unlawful. It does mean that every step away from your own systems adds a contract to manage, controls you cannot see directly and, often, a cross-border question to answer.

What local-first means in practice

When we say local-first, we do not mean a spreadsheet on a laptop. We mean a properly built system that runs on the client's own devices or servers, works without an internet connection and keeps the data where the client already keeps its other confidential records.

  • The records live on infrastructure you control, under your existing IT and security policies.
  • The system keeps working when the connection drops, which in South Africa is a practical point rather than a theoretical one.
  • Backups should be encrypted with a passphrase that you hold, so a copy kept offsite remains unreadable to anyone who should not see it.
  • Access is set by role, and every change, check and approval is written to an audit trail that your verification agency can follow.
  • Where AI reads a document, we design so that it does so inside an environment you control, and so that your records are not used to train a model you do not control.

The result is easier to explain. When a supplier, an employee or the Information Regulator asks where the information is and who can see it, the answer is one sentence long.

Local is not automatically safe

I want to be fair to the other side of the argument. Keeping data on your own systems moves the work to you. Somebody has to update the server, test the backups, look after the encryption keys, remove access when people leave and notice when something goes wrong. Section 19 applies just as firmly to a server in your building as to one in a data centre abroad.

A poorly run local system is worse than a well-run cloud one.

That is why we design the operational side together with the software: who restores a backup, how keys are held, what happens when a laptop is lost or stolen. A local-first system that your team cannot maintain is not a good system, however private it looks on paper.

When the cloud is the right answer

There are situations where I would recommend a cloud service without hesitation.

  • The data contains no personal information, or only totals. A dashboard showing procurement spend by B-BBEE level and supplier category does not need anyone's ID number.
  • The service is hosted in South Africa, the operator contract meets sections 20 and 21, and you have confirmed in writing how your data is used, including whether it is used to train AI models.
  • Your company already runs a mature cloud environment with its own security team, and transformation data would simply join records that are already well governed there.
  • Many people across many sites need to work on the same records at the same time, and the effort of keeping local copies in step outweighs the benefit.

The test I apply is simple. For each category of data, can you say where it is stored, who can read it, which ground in section 72 covers any transfer abroad and how you would know if it leaked? If the answer is yes for a cloud service, use it. If the answer is a shrug and a link to the vendor's terms, keep the data closer to home.

Start with an inventory

For most companies the first step is not choosing a system at all. It is listing what you hold: which transformation records contain personal information, which contain special personal information, where each one lives today and how many copies are travelling by email. That list usually makes the decision for you.

If you would like help drawing up that list, or want to see what a local-first system for your scorecard and EE data could look like, write to me and the team at sales@bsvision.co.za. We will start with what you hold and build from there.

Talk to BS Vision. We are B-BBEE and transformation consultants in Johannesburg, serving clients across South Africa.

Email sales@bsvision.co.za More articles