POPIA and your project records: a practical guide for construction teams
Your project holds more personal information than you think: contact lists, site photos, years of correspondence. What POPIA expects from the teams holding it, in plain language.
The fluxems team · Product
A project directory and audit trail illustrating controlled access to personal information
blog/popia-and-your-project-records/cover.png
Ask a contractor what personal information they hold and most will say "not much, we build things". Then look at an actual project: a directory of names, phone numbers, and email addresses across a dozen companies. Site photos with recognisable faces. Years of correspondence full of personal detail. Under South Africa's Protection of Personal Information Act, all of that is personal information, and the team holding it is responsible for it. POPIA has applied in full since 2021, and clients increasingly ask about it in prequalification.
Guidance, not legal advice
We build project software, we do not practise law. This post explains how POPIA tends to apply to project records and how fluxems supports the obligations. For your specific situation, speak to your legal adviser or information officer.
What POPIA actually asks of a project team
The Act comes down to a handful of duties: collect personal information for a purpose, secure it, limit who can see it, keep it only as long as you need it, and be able to account for what you did with it. None of that is exotic. It is the same discipline good document control already demands, applied to people's information instead of drawings.
Access: the right people, and only them
POPIA's security safeguards start with a simple test: can people see personal information they have no business seeing? On a shared drive, the honest answer is usually yes. In fluxems, access is role based, so what a subcontractor's estimator sees is not what the principal agent sees, and managing users and teams is an admin task, not a habit of forwarding links. For genuinely sensitive material, think disciplinary correspondence or a photo set you should not broadcast, confidentiality levels and private documents restrict an item to named people even inside the project.
Retention: keep it as long as you must, not forever
Construction pulls in two directions here. Latent defects and contract terms mean you must keep project records for years after handover. POPIA says do not keep personal information longer than the purpose requires. The way through is knowing what you hold and why. A structured register with controlled versions gives you that; a folder called "Old Projects" on a server does not. When a retention period genuinely ends, you can act on a defined set of records instead of guessing.
Accountability: being able to show what happened
If a data subject or the Information Regulator asks what happened to someone's information, "we think only the QS had access" is not an answer. fluxems keeps an audit trail of access changes, permission grants, and record activity, so the answer is a lookup: who was given access, by whom, on what date. Reading the audit log is open to your admins today, and the same trail that satisfies a client audit serves a POPIA query.
Where your data lives
POPIA restricts sending personal information across borders unless conditions are met. The simplest way to reduce that surface is to keep project data in region. fluxems hosts South African projects in region, encrypts data in transit and at rest, and keeps encrypted backups. We will not claim certifications we do not hold; what we offer is infrastructure choices that make your compliance story shorter.
Tip
A practical first step: list every place project correspondence and contact information currently lives. If the list includes personal inboxes and a shared drive, that is your POPIA exposure, and consolidating it is the fix.
The pattern across all of this: POPIA rewards teams that already run disciplined records. See how the audit trail underpins it, or talk to us about how your projects hold personal information today.