Why self-hosting changes the compliance conversation
When you run workloads on AWS, Azure, or Google Cloud, a chunk of your "appropriate technical and organisational measures" obligation under Section 19 of POPIA is covered by the provider's own certifications (ISO 27001, SOC 2, etc.) for the infrastructure layer. When you self-host — your own servers, your own Nextcloud instance, your own database — that entire burden sits on your configuration choices. That's not a reason to avoid self-hosting (data sovereignty is often the whole point), but it does mean compliance has to be deliberate rather than assumed.
The technical checklist
Access control
- Named user accounts only — no shared logins for admin access to servers holding personal information
- SSH key-based authentication, password login disabled
- Role-based access so staff only reach the data their job requires (principle of least privilege)
- Multi-factor authentication on anything internet-facing
Encryption
- Data encrypted at rest on disk (LUKS or equivalent) for any volume storing personal information
- TLS enforced for all data in transit — no plain HTTP, no unencrypted database connections across the network
- Backup files encrypted before they leave the primary site
Logging and accountability
- Centralised, tamper-resistant logging of who accessed what personal information and when
- Log retention policy that's documented and actually followed
- A way to answer "who touched this record" within hours, not days, if a data subject ever asks
Backup and recovery
- Documented, tested restore process — an untested backup is not a control, it's a hope
- Retention periods aligned with your actual legal basis for holding the data (POPIA's data minimisation principle cuts both ways — don't keep data "just in case")
- A documented breach response plan, because POPIA requires notification "as soon as reasonably possible" after a breach is discovered
Patch and vulnerability management
- A defined patching cadence for OS and application-level updates, not ad hoc
- Periodic vulnerability scanning of anything holding personal information
- A documented record showing the above actually happened — auditors and regulators want evidence, not assurances
The organisational side (don't skip this)
Technical controls are half the picture. You also need an Information Officer registered with the Information Regulator, a documented PAIA manual, a data processing register noting what personal information you hold and why, and staff awareness training. None of that is solved by infrastructure — but infrastructure that can't produce an access log or prove encryption is in place will undermine even a well-written policy document the moment it's tested.
Where we usually start with clients
Most self-hosted environments we audit are missing two things first: centralised logging (so there's no real answer to "who accessed this") and a tested backup/restore process (so recovery time after an incident is unknown rather than documented). Both are foundational, both are fixable in days rather than months, and both directly support a POPIA defence if you're ever asked to demonstrate compliance.
Not sure where your environment stands?
Our security assessment maps your current controls against frameworks including POPIA, with a prioritised remediation list.
