Data Processing Addendum

In this DPA, unless the context otherwise requires:

• "Australian Privacy Law" means the Privacy Act 1988 (Cth) and any subordinate legislation, including the Australian Privacy Principles (APPs).
• "Controller" (or "Data Controller") has the meaning given to it under applicable Privacy Law — the entity that determines the purposes and means of processing Personal Data.
• "Customer" means the entity or individual that has entered into a subscription agreement with Obsidia.
• "Customer Data" means all data submitted to or processed by the Service on behalf of the Customer, including Personal Data.
• "DPA" means this Data Processing Addendum.
• "Obsidia" means Client Plus Solutions Pty Ltd (ABN 38 081 835 430) trading as Obsidia, with registered office in Sydney, New South Wales, Australia.
• "Personal Data" (or "Personal Information") means information or an opinion about an identified individual, or an individual who is reasonably identifiable, as defined under the Privacy Act 1988 (Cth).
• "Privacy Law" means Australian Privacy Law and any other applicable data protection legislation in the jurisdiction(s) where Customer Data is processed.
• "Processor" (or "Data Processor") means the entity that processes Personal Data on behalf of the Controller.
• "Service" means the Obsidia platform provided under the subscription agreement.
• "Sensitive Information" has the meaning given in section 6 of the Privacy Act 1988 (Cth) — a subset of Personal Information subject to heightened protection under APP 3, including health information, racial or ethnic origin, and other categories listed in clause 2.4.
• "Sub-processor" means any third party appointed by Obsidia to process Personal Data on its behalf in connection with the Service.

The Customer is the Controller of Customer Data. Obsidia is the Processor of Customer Data and processes it only on the Customer's instructions and as necessary to provide the Service.

Schedule A to this DPA sets out the subject matter, nature, purpose, and duration of processing, together with the types of Personal Data and categories of data subjects involved.

Obsidia processes Customer Data only on the Customer's documented instructions — primarily as set out in the subscription agreement and this DPA. If Obsidia is required by law to process Customer Data in a way not covered by the Customer's instructions, it will inform the Customer before doing so (unless prohibited by law).

The Customer warrants that, before uploading or ingesting any sensitive information (as defined in section 6 of the Privacy Act 1988 (Cth)) to the Services, it has obtained all consents and undertaken all notifications required under the Australian Privacy Principles. Sensitive information includes information or opinions about an individual's:

• racial or ethnic origin
• political opinions
• membership of a political association
• religious beliefs or affiliations
• philosophical beliefs
• membership of a professional or trade association or trade union
• sexual orientation or practices
• criminal record
• health information
• genetic information (that is not otherwise health information)
• biometric information used for the purpose of automated biometric verification or biometric identification, or biometric templates

The Customer acknowledges that Obsidia is a processor of such information and that the obligation to hold appropriate consents rests with the Customer as Controller. Obsidia does not warrant that the Services are suitable for the storage or processing of sensitive information without the Customer first establishing a compliant consent framework.

Obsidia may ingest Customer-supplied content — including knowledge management library content, internal policies, counsel opinions, and firm-specific procedures — into the Customer's workspace knowledge base. Such content remains the intellectual property of the Customer, is segmented to the Customer's workspace, is the Customer's responsibility to maintain for accuracy and currency, and is subject to the same data handling protections as other Customer Data.

Obsidia will process Customer Data in compliance with applicable Privacy Law, including the Australian Privacy Principles.

Obsidia ensures that personnel authorised to process Customer Data are subject to appropriate confidentiality obligations, whether contractual or statutory.

Obsidia will not process Customer Data for its own purposes, including for model training, product improvement, or marketing, except where the Customer has provided express written consent or where Obsidia is acting as a Controller for separately collected data (e.g. account registration data).

Obsidia will, to the extent technically feasible and at the Customer's reasonable request, assist the Customer in meeting its obligations under Privacy Law — including in responding to requests from data subjects to access, correct, delete, or port their Personal Data.

The Customer provides general authorisation for Obsidia to engage the sub-processors listed in the Sub-Processor Register. Obsidia will impose data protection obligations on each sub-processor equivalent to those in this DPA.

Obsidia will give at least 30 days' advance notice before engaging a new sub-processor or making material changes to an existing sub-processor's role. Notice will be given by updating the Sub-Processor Register and emailing subscribers. Customers may subscribe to change notifications at the Sub-Processor Register page. If a Customer objects to a new sub-processor and the parties cannot resolve the objection within 14 days, either party may terminate the subscription agreement on written notice without penalty.

Obsidia remains liable to the Customer for the acts and omissions of its sub-processors to the same extent as if it had carried out the processing itself, subject to the liability limitations in the subscription agreement.

Obsidia implements and maintains appropriate technical and organisational security measures to protect Customer Data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access. Schedule B sets out the current measures. These include, at minimum:

• Encryption in transit (TLS 1.2+) and at rest (AES-256)
• Role-based access controls with least-privilege principles
• Multi-factor authentication for all administrative access
• Regular penetration testing and vulnerability management
• Audit logging of all administrative access to customer data
• IP allowlisting for administrative interfaces (where enabled by Customer)

Obsidia treats operational metadata with the same protections as Customer Data content. Specifically:

• Query audit logs — verbatim query and response text is stored encrypted and accessible only to Obsidia platform administrators with a legitimate operational need. Access is itself audited. Workspace administrators and members cannot access verbatim query text.
• Error reporting — application error reports transmitted to third-party monitoring services (including Sentry) are scrubbed of request bodies, navigation breadcrumbs, and any other fields that could carry customer content or matter identifiers before transmission.
• Transactional notifications — email and push notification subjects and bodies sent to users do not include workspace names, matter references, or client identifiers. Users must sign in to the application to access the associated context.
• Workspace deletion — on deletion of a workspace, all associated query logs, security audit entries, and pipeline data are explicitly purged in addition to cascading database deletions.

Obsidia generates vector embeddings (numerical representations) from Customer Data for the purpose of semantic search and document retrieval (RAG). Published research demonstrates that text embeddings can be partially reconstructed to source text. Accordingly, Obsidia treats vector embeddings as sensitive data equivalent to the source content from which they were derived. Specifically:

• Storage — embeddings are stored in the same encrypted database as Customer Data and subject to the same access controls, including row-level security scoped to the Customer's workspace.
• No logging — embedding vectors are never written to application logs, error monitoring services, or any external telemetry.
• No export — raw embedding vectors are excluded from all data exports and API responses to end users.
• Deletion — embeddings are hard-deleted (not soft-flagged) when the source document is deleted, via a cascading database constraint. Deleted embeddings may remain in encrypted backup systems for the period described in clause 10.2.
• Provider retention — Obsidia has enabled zero-day retention (ZDR) with its embedding provider (Voyage AI) per installation, such that document text transmitted for embedding generation is not retained by the provider after processing.

Obsidia may update its security measures from time to time to reflect changes in technology or regulatory requirements, provided that updates do not materially reduce the overall level of protection afforded to Customer Data.

Obsidia configures all infrastructure to use Australian regions:

• Standard Tier — Supabase project provisioned in the Oceania (Sydney) / ap-southeast-2 region. Obsidia does not enable read replicas or replication features that would move data outside Australia. Supabase's underlying infrastructure is AWS ap-southeast-2. Function hosting via Netlify — function execution is global (auto-routing); log storage region is not formally published by Netlify.
• Compliance Tier — AWS ap-southeast-2 (Sydney). All storage, compute, and AI inference is contractually confined to this region.

On the Standard Tier, queries are processed by the Anthropic API (USA). Anthropic does not use API customer data for model training per their API usage policy. On the Compliance Tier, AI inference is performed exclusively via AWS Bedrock in ap-southeast-2. No Customer Data leaves Australia on the Compliance Tier. A third-party vendor risk assessment for Anthropic — covering data handling, zero data retention posture, security certifications, incident response, and contractual terms — is available on request from legal@obsidia.com.au. An AI model card describing the model's capabilities, limitations, and intended use is also available on request.

On the Standard Tier, Customer Data is transmitted to the Anthropic API (USA) for AI inference, and document text chunks are transmitted to Voyage AI (USA) transiently for embedding generation. Obsidia has enabled the Voyage AI zero-day retention (ZDR) opt-out per installation — customer data is not retained or used for model training by Voyage AI after embedding generation is complete. Customers with strict cross-border transfer restrictions should use the Compliance Tier, where all processing remains in Australia.

A signed Data Processing Addendum (DPA) is in place with Supabase, Inc. (executed 23 April 2026). Clause 6.2 of the Supabase DPA contractually commits Supabase to store and primarily process Covered Data in the ap-southeast-2 (Sydney) region as directed by the Customer. Some processing may occur via Supabase's global operations team for support and monitoring purposes. Customers requiring a copy of the executed Supabase DPA should contact legal@obsidia.com.au.

Obsidia will notify the Customer without undue delay, and in any event within 72 hours, after becoming aware of a personal data breach affecting Customer Data. The notification will include, to the extent known at the time: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed.

Where a breach constitutes an eligible data breach under the Privacy Act 1988 (Cth) s 26WE, Obsidia will notify the OAIC and affected individuals in accordance with its Incident Response process. Obsidia will coordinate with the Customer on the content of any notification to affected individuals where the Customer is also subject to notification obligations.

Obsidia will cooperate with the Customer in investigating any breach affecting Customer Data and provide such information as the Customer reasonably requires to meet its own notification obligations.

If Obsidia receives a request from a data subject exercising rights under Privacy Law (access, correction, deletion, or export) in relation to Customer Data, Obsidia will promptly notify the Customer and, unless prohibited by law, refrain from responding to the request directly. The Customer is responsible for responding to data subject requests in relation to Customer Data it controls.

Obsidia provides platform-level tools to assist the Customer in responding to data subject requests, including user data export (APP 12) and user anonymisation (APP 11.2) functions accessible to platform administrators.

Obsidia will, on reasonable written request (not more than once per year), provide the Customer with information reasonably necessary to demonstrate compliance with this DPA, including responses to security questionnaires and up-to-date penetration testing summaries.

Where third-party certifications or audit reports are available (e.g. SOC 2, penetration test reports), Obsidia may provide these in lieu of direct access audits. Obsidia reserves the right to require a confidentiality undertaking before sharing audit materials.

On-site audits of Obsidia's processing facilities are available to Compliance Tier customers upon reasonable notice (minimum 30 days) and subject to agreement on scope. Audit costs are borne by the Customer. Obsidia may require the Customer's auditors to be bound by confidentiality obligations before access is granted.

Within 30 days of termination of the subscription agreement, Obsidia will, at the Customer's election: (a) delete all Customer Data from its systems and sub-processors; or (b) provide the Customer with a data export in a standard machine-readable format. After this period, Obsidia will delete Customer Data in accordance with its data retention policy, except where required by law to retain it longer.

Customer Data may persist in encrypted backup systems for up to 90 days after the deletion date, after which it will be permanently deleted. Obsidia will not restore or use backup data after deletion has been requested.

Upon request, Obsidia will provide written confirmation that deletion has been completed within 14 days of completion.

This DPA remains in force for the duration of the subscription agreement and until all Customer Data has been deleted or returned under clause 10.

In the event of conflict between this DPA and the subscription agreement, this DPA prevails with respect to the processing of Personal Data.

This DPA is governed by the laws of New South Wales, Australia.

Item	Details
Subject matter	Provision of the Obsidia AI-assisted productivity platform to the Customer's users
Nature of processing	Collection, storage, retrieval, transmission, use (AI inference and embedding generation), and deletion of Customer Data and derived representations thereof
Purpose	To provide the Service as described in the subscription agreement, including chat, document processing, workflow automation, and compliance tooling
Duration	For the term of the subscription agreement, plus any post-termination retention period under clause 10
Types of Personal Data	User account information (name, email, role); conversation content and documents uploaded by users; workflow inputs and outputs; usage and audit logs; IP addresses; session metadata (sign-in timestamp, last-activity timestamp) used solely for server-enforced session limits and idle timeout enforcement; vector embeddings derived from document content (treated as sensitive data equivalent to the source content — see clause 5.3)
Categories of data subjects	Customer's employees, contractors, and end users who use the Service; individuals whose information appears in uploaded documents or conversation content

Control area	Measure
Encryption in transit	TLS 1.2 minimum on all connections; TLS 1.3 preferred
Encryption at rest	AES-256 for all data at rest; key management via AWS KMS (Compliance) / Supabase managed keys (Standard)
Access control	Role-based access control with least-privilege; 4-tier role model (platform admin / org admin / workspace admin / member); MFA enforced for all admin accounts
Network security	VPC isolation (Compliance tier); IP allowlist capability; WAF (OWASP managed rules, rate limiting)
Audit logging	All administrative access and data export events logged to immutable audit log; logs retained 12 months
Penetration testing	Annual external penetration testing; results available to Compliance Tier customers under NDA
Vulnerability management	Automated dependency scanning; critical vulnerabilities patched within 14 days
Incident response	Documented incident response plan; see Incident Response page
Personnel	Background checks for personnel with access to Customer Data; confidentiality agreements; security awareness training
Vector storage	Document embeddings stored in encrypted pgvector database columns under the same access controls and encryption as source content; excluded from all data exports and error telemetry; hard-deleted via cascading database constraint on document deletion; embedding provider (Voyage AI) has zero-day retention enabled per installation
Upload controls	Customer-uploaded files are subject to server-side content-type allowlisting, magic-byte validation, a 50 MB size cap enforced at the storage layer, and filename sanitisation. Rate limiting is applied per user and per workspace at upload-URL issuance time. Raw files are stored AES-256 encrypted at rest in Supabase Storage and are deleted immediately when the corresponding document record is deleted.
Business continuity	Daily automated backups; point-in-time recovery; RTO/RPO targets defined per tier