Law firms handle some of the most sensitive information in any industry — client identities, case strategies, financial records, and privileged communications. Digiiworks Legal is built from the ground up to protect that information with the same rigour your clients expect from you.

This page explains what we do to keep your firm’s data safe. If you have questions beyond what is covered here, contact us at privacy@digiiworks.co.

1. Encryption

Every sensitive field — client names, identity numbers, matter details, contact information, financial data — is encrypted with 256-bit AES encryption at the application level before it is written to the database. Your data is protected not only at rest, but before it ever reaches storage.

Per-firm key derivation. Each firm’s data is encrypted with key material derived exclusively for that firm. One firm’s key cannot decrypt another firm’s records, even if the underlying ciphertext is somehow obtained.
Searchable encryption. So the platform remains useful, we can find encrypted records (for example, looking up a matter by client name) without ever decrypting the stored value. The search indexes are themselves cryptographically scoped to each firm — one firm’s indexes can never match another firm’s data.
TLS 1.2+ in transit. All traffic between your browser and our servers is encrypted end-to-end, so information cannot be intercepted during transfer.

2. Tenant isolation

Digiiworks Legal is a multi-tenant platform, but your firm’s data is strictly isolated from every other firm’s data. Isolation is enforced in layers so that no single mistake can bridge the boundary. Platform-wide aggregate reporting functions are restricted to the administrative console only — they are not exposed to client-portal traffic.

Row-level security at the database. Every query is filtered by firm at the database engine itself — not just by our application code. A bug in our code cannot expose another firm’s rows.
Row-level security applied through views. Database views inherit the calling user’s tenant context, and our most sensitive system tables use forced row-level security so that even a privileged database role cannot bypass firm filtering.
Cryptographic separation. Per-firm key derivation (see section 1) means the ciphertext itself is useless outside the firm that owns it.
Separate administrative console. The internal operations console used by our team runs on a completely separate hostname from the client portal. Client traffic cannot reach administrative paths, and the administrative hostname refuses client-portal requests outright.

3. Authentication & access control

We use passwordless magic-link authentication. Passwords have been removed from the platform entirely — there is no password-based sign-in flow for clients or for our own team. Each login link is single-use and time-limited.

Enforced 30-minute inactivity timeout. Portal sessions expire after 30 minutes of inactivity. The timeout is enforced on the server by a tamper-resistant, cryptographically signed cookie — not by the browser alone. A modified or forged cookie is rejected automatically and forces re-auth.
Role-based access control. Firm owners and members have different permission levels, ensuring staff only access what they need.
Rate limits on sensitive endpoints. Login link requests, administrative sign-in, and privileged operations are rate-limited to block credential-stuffing, enumeration, and abuse.
Signing-key rotation without forced sign-out. Session integrity cookies are signed with the current key but accept signatures from the immediately previous key during a rotation window. If a key ever needs to be rotated — as a planned operational change or in response to a suspected leak — we can do so without logging every active user out in the middle of their work.

4. AI & data privacy

Our AI-powered features (intake processing, document generation, and deadline extraction) are designed with privacy as the default:

AI processing uses short-lived, scoped temporary tokens that expire automatically. No long-lived credentials are exposed during processing.
Client data sent to the AI is decrypted temporarily in a secure server environment, processed, and then discarded from memory. It is never persisted outside your database.
Your data is never used to train AI models. Your client information remains yours alone.

5. Document security

Documents stored on the platform are never accessible via public URLs. Every document download uses a signed URL with a short expiration window (default one hour). Once the link expires, it cannot be reused. Documents cannot be accessed without valid authentication and the correct firm scope.

Uploads are validated on both file extension and declared content type, filenames are sanitised, and every file is stored under a firm-scoped path so that one firm’s uploads are physically namespaced from another’s.

6. Application hardening

Beyond encryption and isolation, the application itself is hardened against common web attacks:

Strict input validation at every API boundary. Every request is validated against a typed schema before it reaches any business logic. Malformed or unexpected input is rejected at the edge.
Browser security headers. The platform sends headers that block clickjacking, prevent content-type sniffing, restrict referrer leakage, disable unused browser APIs (camera, microphone, geolocation), and apply a Content Security Policy against mixed content and framing.
Per-request Content Security Policy nonces. Every page load receives a fresh, single-use nonce. Scripts that do not carry the correct nonce are refused by the browser, closing off entire classes of script-injection attacks even if one slipped past our input validation.
Inbound webhook signature verification. Every incoming webhook (email delivery events, support integrations) is cryptographically verified before our servers act on it. Forged or replayed webhooks are rejected.
Distributed rate limiting. Abuse-prone endpoints are rate-limited consistently across server instances, not per-process.
Administrative audit trail. Every privileged operation — firm creation, knowledge-base change, support triage, access-level change — is recorded in an append-only audit log with actor, target, timestamp, and originating network details. Our own team is auditable.

7. POPIA compliance

Digiiworks Legal is built for South African data protection requirements under the Protection of Personal Information Act (POPIA). POPIA compliance is embedded in our architecture and our data handling practices, not bolted on.

We have designated an Information Officer responsible for POPIA obligations within our organisation.
We require sub-processors we rely on to meet equivalent data-protection standards, and we select providers whose own certifications support that requirement.
Data subjects may exercise their rights — access, correction, deletion — at any time.
For full details, see our POPIA Statement and Privacy Policy.

8. Infrastructure

The platform runs on infrastructure providers that maintain SOC 2 Type II compliance and publish regular independent security attestations.

Automated daily backups with point-in-time recovery are provided at the infrastructure layer, reducing the window of any potential data loss.
Hosting in geographically distributed data centres with redundancy built in at the infrastructure layer.
All cross-border data transfers comply with POPIA section 72 requirements.

9. Monitoring & incident response

We operate real-time application monitoring with automatic scrubbing of personally identifiable information from all diagnostic data. Identity numbers, email addresses, phone numbers, access tokens, and authentication headers are redacted before any diagnostic event leaves our servers. IP addresses are not stored in our monitoring systems.

In the unlikely event of a security incident, we are committed to:

Notifying the Information Regulator and affected firms as soon as reasonably possible, in accordance with POPIA section 22.
Providing a clear account of what happened, what data was affected, and what steps have been taken to prevent recurrence.
Cooperating fully with any regulatory investigation.

10. Secure development

Security is not a one-time project. Every change to the platform passes through a consistent set of gates:

Automated secret scanning on every commit — both locally before a commit is created and again in our continuous-integration pipeline — prevents credentials from ever entering the codebase.
Mandatory code review on every change before it reaches production.
Environment-only secret management. No credentials live in source control; every deploy is verified against our secret-scanning rules.
Prompt patching of dependencies as security advisories are published.
When we expand encryption coverage to a new field, existing records are migrated to ciphertext by an operator-run process rather than left in plaintext.
Self-service firm data export. Firm owners can download a machine-readable copy of their firm’s data directly from the portal (rate-limited and owner-only) to support data-subject access requests under POPIA section 23 without waiting on operator intervention.

Questions?

If you have any questions about our security practices or would like to discuss your firm’s specific requirements, please contact our team at privacy@digiiworks.co.

Trust & Security