Privacy & POPIA

Privacy Policy

Last updated: 5 August 2026 · Practicore is in early access; this policy may change as the product develops.

Practicore is practice-management and compliance software for accounting firms. This page explains, in plain language, how we handle personal information and how that maps to the Protection of Personal Information Act (POPIA). Where a firm uses Practicore, the binding terms are set out in the Data Processing Agreement (DPA) between the firm and Practicore; this page is a summary, not a replacement for it.

Who is responsible for what

• The firm is the Responsible Party. The accounting firm using Practicore holds the lawful basis for processing its clients' personal information, established with its clients at engagement.
• Practicore is the Operator. Practicore Technologies (Pty) Ltd operates the software and hosting that holds the firm's data, and processes it on behalf of the firm under the firm's lawful basis (POPIA Section 20). A Data Processing Agreement between the firm and Practicore is mandatory and part of firm onboarding.
• Sub-operators are any third party the firm opts in to (for example an in-region LLM provider, a bank-feed source, or an email relay). Each is named in the DPA's sub-operator schedule, with its own residency commitment.

Where your data lives

Residency defaults to the data subject's jurisdiction. For South African firms that means South Africa: the database, document storage, audit records and backups for the SA zone are held within South African jurisdiction. A thin global control plane may hold firm-level commercial metadata only (billing and licensing). It never holds client personal information.

On-premises hosting is available as a premium/reseller option under a separate DPA addendum; it is not the default.

We can decrypt your data, and here is the limit on that

Practicore is not zero-knowledge. Server-side compute and AI inference need plaintext, so the operator is technically capable of decrypting a tenant's data. Isolation between firms is structural: a per-firm identifier, row-level security and per-tenant keys at rest. No other tenant or outside party can read your data.

The DPA limits what we may do with that capability. Operator-side access to a firm's data happens only for: a support request with the firm's written consent, a lawful court order, or security-incident triage logged in the audit ledger. The firm is notified in writing within 72 hours of any operator-side read.

Cross-border transfers (Section 72)

Practicore exposes zero default cross-border transfer. Any AI call that carries a client value runs on Practicore's own in-region infrastructure, verified at run time — no client data reaches a third-party LLM. Calls that carry no client data at all (structure-only, fully tokenised) are not restricted to that endpoint. Direct US-jurisdiction LLM endpoints are disabled at build time and are not available. Adding any new cross-border endpoint requires an explicit Section 72 basis, not a configuration change.

AI suggests, a person decides (Section 71)

Practicore's AI reads context and offers suggestions; it never writes to your records. A practitioner reviews and accepts a suggestion before anything is saved, and there is always a human approval gate before any outbound regulatory filing. Nothing is submitted automatically. Every AI-influenced decision is traceable in the audit ledger, so the firm can produce the trace on request and the right to human review is preserved.

Security safeguards (Section 19)

• In transit: TLS 1.2+ across every connection (client to API, API to database, API to storage, API to any LLM provider).
• At rest: AES-256 envelope encryption for document storage, with a key derived per tenant. See the early-access note below for where this stands today.
• Access control enforced in code, checked at compile time.
• An append-only, immutable audit ledger of the actions people take.
• Idle session lock, hashed session tokens, and TOTP multi-factor authentication.

Early-access note: at-rest encryption is switched on per deployment, and on the current pilot deployment it is not yet enabled. Documents are stored as ordinary files, unencrypted at the application layer, on South-Africa-resident infrastructure at our hosting provider, protected by the access controls and isolation described above rather than by per-document encryption. Enabling envelope encryption and re-encrypting the documents already stored is a near-term milestone; so is backup-artifact encryption with distinct per-tenant keys, and pilot backups currently rest on in-region control of the backup destination. We would rather write this down than let the paragraph above read as done.

Breach notification (Section 22)

The firm remains responsible for notifying the Information Regulator and affected parties. Practicore provides the evidence pack from the audit ledger and an incident timeline, and the DPA commits us to notify the firm within 72 hours of any operator-detected incident.

Deletion and your rights (Section 24)

Because the audit ledger is append-only, an erasure request is fulfilled by de-identification: we hard-delete the identity (credentials, email and the identity numbers attached to it) and replace the person's identifiers in the remaining audit records with a salted-hash sentinel. What survives is a bare attribution token with no readable personal information, retained only for the statutory record-keeping window.

Requests to access, correct or delete personal information a firm holds in Practicore should be made to that firm as Responsible Party. A firm can raise a request or ask a question about this policy with us at support@practicore.co.za.

Onboarding documents

The firm onboarding pack includes a template DPA, a Section 18 notice clause for the firm's own privacy notice, a template PAIA manual and a pre-filled DPIA. The firm completes the firm-specific sections.

Contact

Questions about this policy: support@practicore.co.za. Practicore is operated by Practicore Technologies (Pty) Ltd.