Privacy

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. 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 controller. The accounting firm using Practicore holds the lawful basis for processing its clients' personal information, established with its clients at engagement.
• Practicore is the processor. 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. A Data Processing Agreement between the firm and Practicore is mandatory and part of firm onboarding.
• Sub-processors are any third party the firm opts in to, for example an in-region LLM provider, a bank-feed source, or an email relay. They are named in the DPA's sub-processor schedule, each with its own residency commitment.

Where your data lives

Residency defaults to the data subject's own jurisdiction. The metadata, obligation state, content and audit records for a region are partitioned and kept in that region. A thin global control plane may hold firm-level commercial metadata only (billing and licensing), never client personal information. The first live region is South Africa; a South-Africa-domiciled sovereign host is our committed target.

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, using a per-firm identifier, row-level security and per-tenant keys at rest, so 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

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 endpoints that would move data to another jurisdiction are disabled in the product at build time. Adding any new cross-border endpoint requires an explicit legal basis, not a configuration change.

AI suggests, a person decides

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.

Security safeguards

• 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.

Deletion and your rights

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 applicable record-keeping window.

Requests to access, correct or delete personal information a firm holds in Practicore should be made to that firm as controller. A firm can raise a request or ask a question about this policy with us at info@getpracticore.com.

Contact

Questions about this policy: info@getpracticore.com. Practicore is operated by Practicore Technologies (Pty) Ltd.