01 — Foundations

What is solicitor-client privilege

Solicitor-client privilege (also called legal professional privilege, or LPP) is a common-law right, codified in the Evidence Act 1995 (Cth) ss 118–119, that protects confidential communications between a lawyer and their client where the dominant purpose is the obtaining of legal advice or the preparation for litigation. In Australia it is reinforced by professional conduct obligations under the Legal Profession Uniform Law Australian Solicitors' Conduct Rules 2015 — in particular rules 9 and 10, which impose an absolute duty of confidentiality on solicitors independent of privilege doctrine.

Privilege is a right of the client, not the lawyer. Only the client can waive it. It survives the end of the retainer and is not defeated by the passage of time. Unlike the protections in the Privacy Act 1988 (Cth), which permit many uses of personal information with consent or for a primary purpose, privilege admits almost none of those uses — disclosure of privileged material without the client's consent is a breach regardless of intent.

Three forms of privilege are relevant to Obsidia's customer base:

Why this matters for Obsidia customers. When a law firm or in-house legal team uploads privileged material to Obsidia — client advice memos, litigation strategies, matter notes, precedent analyses — they are extending the circle of privilege to include the platform. From that moment, Obsidia is bound to protect the confidentiality of that content to the same standard as the lawyer's own office systems. A breach of privilege is not just a compliance finding: it can destroy the evidentiary value of the work product and expose the firm to negligence claims or conduct-rule proceedings.
02 — Our posture

How Obsidia protects privileged content

Obsidia is designed to hold privileged material. Customer firms retain all privilege rights; Obsidia asserts no rights over customer content that would be inconsistent with that posture. The following controls operate in combination to maintain this commitment.

Technical
Encryption and access controls
All data is encrypted in transit (TLS 1.2+) and at rest (AES-256). Row-level security enforces strict workspace isolation — no user or operator can read content outside their authorised workspace. JWT authentication with step-up for administrative actions.
Operational
No-staff-read invariant
Obsidia staff must not read customer content outside of a documented support scenario — a user-reported issue with the affected user's explicit, documented consent. Every out-of-band staff read creates a security audit log entry reviewed monthly. Unauthorised reads are classified as security incidents (P0). See ADR-012.
Operational
Staff privilege training
All staff with any access to platform infrastructure complete mandatory privilege-awareness training (Part 6 of the staff privacy training programme). Training covers: what privilege is, how it is waived, why staff must not read customer content, and the inadvertent-disclosure response procedure.
Contractual
Terms of Service and DPA
Terms of Service s 3.5 explicitly acknowledges that customer content may constitute legally privileged material and that nothing in the Terms constitutes a waiver of any privilege. The Data Processing Addendum commits to a narrow operational licence — storage, retrieval, and service delivery only. No training, no analytics, no cross-customer use.
Technical
Error monitoring scrubbing
Sentry is configured to transmit error messages and stack traces only — never request bodies, conversation content, document content, or matter identifiers. Session replay is permanently disabled. This prevents privileged content from reaching Sentry's US-hosted infrastructure as a side-effect of error reporting. See ADR-005.
Governance
Privilege invariant (ADR-013)
The technical and operational architecture is documented in ADR-013, which states the privilege invariant, maps it to the no-staff-read controls, and confirms that each third-party processor has been reviewed for privilege-compatibility. ADR-013 is reviewed annually and on any processor change.
03 — Metadata

Metadata as privileged information

The fact of a client-matter relationship is itself privileged, independent of the content of any communication. A query such as "summarise the litigation risk for Matter 4421" reveals the existence of a matter, the identity of a client, and the firm's legal position — all of which may carry privilege — even if no privileged document is attached.

Obsidia treats workspace titles, matter identifiers, query text, and workflow run metadata with the same technical protections as document content. This posture is documented in ADR-002 (Metadata Sensitivity), which classifies metadata at the same sensitivity level as the content it describes and enforces the same access controls.

Practically, this means:

04 — Third-party processors

Third-party processor privilege posture

Customer content passes through a small number of third-party sub-processors to deliver the platform. Each has been assessed for privilege-compatibility — specifically whether the processor's terms assert any rights over content, whether staff at the processor could access customer content, and whether a subpoena directed at the processor could surface content without notice to the customer firm.

A summary of the privilege posture for each processor is listed on the Sub-Processor Register. The key points:

Anthropic (Standard tier AI inference — USA). No training on customer data per Anthropic's API usage policy. Narrow operational use only. Content transits to the US for inference and is not retained by Anthropic after the API response is returned. Anthropic's terms do not assert ownership over customer content. Privilege-compatible.
Voyage AI (Standard tier embeddings — USA). Zero-day retention (ZDR) opt-out in place. Document text is transmitted for embedding generation and is not retained by Voyage AI after processing. No model training on customer data. Privilege-compatible.
Supabase (Database and storage — Sydney). All data stored in the ap-southeast-2 (Sydney) region. Data Processing Addendum executed. No use of content outside the operational purpose. Privileged content remains in Australian jurisdiction. Privilege-compatible.
Sentry (Error monitoring — USA). Receives error messages and stack traces only after scrubbing. No conversation content, document content, or matter identifiers are ever transmitted. The scrubbing implementation is documented and enforced by CI checks. Privilege-safe by design — no customer content reaches Sentry.
AWS / AWS Bedrock (Compliance tier — Sydney). All inference, storage, and embedding stays onshore in ap-southeast-2. No overseas disclosure of customer data. IRAP assessed. For customers with strict privilege-and-sovereignty requirements, the Compliance tier is the recommended deployment. Privilege-compatible (onshore).

If Obsidia receives a subpoena or other legal process directed at a specific customer's data held by a third-party processor, Obsidia will take reasonable steps to notify the affected customer before producing any content, to the extent legally permitted. See Section 06 for the full compelled-production response policy.

05 — Inadvertent disclosure

Responding to inadvertent disclosure of privileged content

The realistic privilege risk for a SaaS platform is not malicious exfiltration — it is inadvertent disclosure through routine product behaviours: a support engineer attaching a workflow output to a support ticket, an error report including a document excerpt, a misconfigured integration surfacing content to an unintended recipient.

Obsidia maintains a written Inadvertent Disclosure Playbook (distinct from the NDB Playbook, which covers the Privacy Act) that sets out the response procedure for these events. The playbook is held at client/docs/inadvertent-disclosure-playbook.md and is rehearsed at least annually via a tabletop exercise.

The response phases are:

1
Discovery and escalation
Any staff member who suspects privileged content has been disclosed outside the authorised circle must escalate immediately to the Privacy Officer and Platform Lead. The incident log is opened and the discovery time is recorded.
2
Containment
Immediate action to revoke access, identify the scope of disclosure, preserve evidence, and prevent further disclosure. No deletion of logs or evidence until the Privacy Officer has assessed scope.
3
Privilege assertion and claw-back
Obsidia supports the affected customer firm in asserting privilege over the disclosed material and requesting return or destruction from downstream recipients. Claw-back letter templates are held in the playbook. The privilege assertion is the firm's right to exercise — Obsidia does not waive privilege on the firm's behalf.
4
Notification
The affected customer firm is notified first — before any downstream recipients. If the inadvertent disclosure also constitutes a notifiable data breach under the Privacy Act (for example, because the content contains personal information that meets the serious-harm test), the NDB Playbook runs in parallel. OAIC notification is only required if the NDB eligibility test is satisfied — privilege alone does not trigger OAIC notification.
5
Remediation
Root-cause analysis of the disclosure vector. Technical fix deployed and verified. Post-incident review conducted within 14 days. Playbook and training updated if a process gap is identified.
06 — Compelled production

Subpoena and compelled-production response

If Obsidia receives a subpoena, court order, search warrant, or other legal process requiring production of customer content, the following policy applies.

Default: notify the firm first

Obsidia will take reasonable steps to notify the affected customer firm of the compelled-production request before producing any content, to the extent legally permitted. If a gag order or non-disclosure obligation prevents advance notice, Obsidia will notify the firm as soon as that obligation lifts.

Minimum production

Obsidia will produce only the minimum content required by the order. We will not voluntarily expand the scope of production beyond the express terms of the legal process.

Privilege deferred to the firm

Obsidia does not waive privilege on behalf of a customer firm. If a production order encompasses content that may be privileged, Obsidia will notify the firm and allow the firm to assert privilege before any production occurs. Obsidia will not resist a valid legal order but will facilitate the firm's privilege assertion to the extent possible within the timeline of the order.

Internal escalation

Every compelled-production request is escalated to the Privacy Officer and external legal counsel before any action is taken. No staff member may respond to a legal process directed at customer content without Privacy Officer authorisation.

Contact

All compelled-production matters should be directed to legal@obsidia.com.au. This inbox is monitored and will be escalated to external counsel within one business day.

07 — Transparency

Annual transparency report

Obsidia publishes an annual transparency report covering legal process received in respect of customer data. The report includes:

The report does not identify specific customers, specific orders, or the content of any production. The first report covering the period from platform launch to 31 December 2026 will be published in Q1 2027.

To receive the report when published, email legal@obsidia.com.au with the subject line "Transparency report — subscribe".

08 — Related documents

Further reading

The following documents provide additional detail on the controls described in this policy.