How to evaluate property-software security

Why security is a buyer's responsibility, not just the vendor's

When you load tenant ID numbers, bank details, lease documents, levy rolls and trust-account ledgers into a platform, you are handling personal information. POPIA treats the organisation that decides why and how that information is processed as the responsible party — that is generally you, the managing agent, trustee body or landlord — while the software vendor typically acts as an operator processing on your behalf. That distinction matters: you cannot fully outsource accountability. If the platform leaks data, your organisation is the one that answers for it.

Because of this, evaluating a vendor's security is really an extension of your own compliance work. POPIA is designed to require that responsible parties secure the integrity and confidentiality of personal information through reasonable technical and organisational measures, and that operators process only under a written contract with appropriate safeguards. The practical takeaway is to ask for an operator agreement (or data-processing addendum) and to confirm the controls described below in writing before you commit.

Hosting and data residency: where does your data actually live?

Start with the most basic question: where is the data physically hosted, and does it stay in South Africa? Data residency matters for two reasons. First, POPIA places conditions on transferring personal information outside the country, so in-region hosting generally simplifies your compliance story. Second, hosting close to your users typically improves performance and keeps you within a familiar legal jurisdiction.

Ask the vendor to name the hosting provider and the region. A credible answer identifies a specific cloud region — for South African operations, an in-country or in-region data centre is generally preferred. Regalis hosts production data in a South African region, which is designed to support POPIA data-residency expectations. If a vendor cannot tell you where the data sits, treat that as a red flag.

• Which cloud provider and which region hosts production data?
• Does any personal information leave South Africa, and if so under what POPIA transfer mechanism?
• Are backups stored in the same jurisdiction as the primary data?
• Is the database isolated per environment, or is production mixed with test data?

Encryption in transit and at rest

Encryption has two distinct jobs. Encryption in transit protects data as it moves between the browser and the servers — this is what HTTPS/TLS does, and every modern platform should enforce it on every page and API call, with no unencrypted fallback. Encryption at rest protects the stored data itself, so that database files and backups are not readable if the underlying storage is ever compromised.

Ask whether sensitive fields — particularly banking details used for trust accounting and electronic banking — receive additional application-level encryption beyond the database's default. A thoughtful platform encrypts highly sensitive items such as bank-account credentials at the field level, so that even an internal database view does not expose them in plain text. Regalis enforces TLS in transit, relies on encryption at rest for stored data, and applies additional encryption to particularly sensitive banking fields.

• Is TLS enforced everywhere, including file uploads and API endpoints?
• Is the database encrypted at rest, including automated backups?
• Are especially sensitive fields (bank details, identity numbers) given extra protection?
• How are encryption keys managed and rotated?

Access controls and roles: who can see and do what?

A property platform is multi-tenant by nature — multiple agencies, schemes, trustees, landlords and tenants share the same software. The single most important control is that one organisation can never see another's data, and that within an organisation, people only see what their role permits. This is role-based access control (RBAC), and it should be enforced on the server for every request, not merely hidden in the user interface.

Ask how roles are structured. A trustee should not have the same access as the managing agent's bookkeeper; a tenant should see only their own lease and statements. Strong platforms scope every database query to the organisation and check the user's role before returning data, so a logged-in user cannot reach another portfolio by guessing a URL. Regalis enforces organisation-scoped, role-based access on its API layer so that data access is checked on the server for each request.

Also ask about administrative access on the vendor's side: which staff at the vendor can reach production data, under what controls, and is that access logged. The fewer people with standing access, and the more that access is logged and time-bound, the better.

• Is access control enforced server-side, or only hidden in the UI?
• Are roles granular enough to separate agents, bookkeepers, trustees, landlords and tenants?
• Can the vendor's own staff access your data, and is that access logged and restricted?
• Is multi-factor authentication available for privileged accounts?

Audit logs: can every action be traced?

For trust accounting and levy management, traceability is not optional. The Property Practitioners Act imposes strict obligations on how trust money is handled, and the STSMA and CSOS framework expect accountability for scheme funds. An audit log that records who did what, when — who edited a ledger, who approved a payment, who changed a banking detail — is how you demonstrate that accountability to an auditor, a trustee meeting or a regulator.

Ask whether audit logs are append-only (so they cannot be quietly altered), how long they are retained, and whether you can export them. The most sensitive events — payment approvals, banking-detail changes, document deletions and permission changes — should always be logged. A platform that can produce a clear, exportable trail of financial and administrative actions makes your own oversight far easier.

Backups, disaster recovery and business continuity

Security is not only about keeping data out; it is also about not losing it. Ask how often backups are taken, where they are stored, how long they are retained, and — critically — whether restores are actually tested. A backup you have never restored from is a hope, not a plan. A credible vendor can describe a recovery-point objective (how much data you might lose, measured in time) and a recovery-time objective (how long it takes to come back online) even if the exact numbers vary by plan.

Disaster recovery extends this to whole-region failures and accidental deletion. The practical questions are simple: if the database were corrupted today, how far back can you restore, and how long would it take? If a user deletes a property or tenant by mistake, can it be recovered? Many platforms (Regalis included) use soft deletion for records like properties and tenants, so that an accidental removal is reversible rather than permanent.

• How frequently are backups taken and how long are they retained?
• Are backup restores tested, and how recently?
• What are the recovery-point and recovery-time objectives?
• Are accidental deletions reversible through soft-delete or backup restore?

Incident response and breach notification

No system is perfectly secure, so the real test of maturity is what happens when something goes wrong. POPIA is designed to require that, where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person, the responsible party notifies the Information Regulator and the affected data subjects. Because you are generally the responsible party, you need a vendor who will alert you promptly and give you the facts you need to meet that obligation.

Ask for the vendor's written incident-response process: how they detect issues, how quickly they will notify you, who your contact is, and what information they will provide. A vendor that has thought this through can describe escalation steps and notification timelines rather than improvising. Pair this with your own internal plan so that, if a breach occurs, your notification duties are met without scrambling.

POPIA-supporting controls to confirm before you sign

Beyond the technical controls above, a few POPIA-supporting capabilities are worth confirming. POPIA gives data subjects rights to access and, in some cases, deletion of their personal information, and it expects responsible parties to keep information only as long as needed. A platform that supports subject-access exports, data-retention handling and deletion workflows makes those duties practical rather than manual.

Finally, ask for the operator agreement, a plain description of sub-processors (any third parties the vendor relies on, such as the cloud host or email provider), and confirmation that the vendor has a designated contact for security and privacy questions. None of these are exotic — they are the baseline you should expect from any platform trusted with tenant, owner and scheme data in South Africa.

• Is there an operator agreement (data-processing addendum) you can sign?
• Can the platform export a data subject's information on request?
• Are data-retention and deletion workflows supported?
• Are sub-processors disclosed, and where are they located?