§ Liquet

Data‑security & MNPI posture

How Liquet treats engagement data and MNPI.

For prospective buyers and their advisers.

This document sets out how Liquet treats engagement data, material non‑public information (MNPI), and the operational discipline that surrounds both. It is intended for buyer‑side procurement, legal, and deal teams considering engaging Liquet for pre‑close trade‑compliance diligence.

We update this document as the operational posture matures. The status of each control is marked.

1. Confidentiality posture

Engagement scope. Each Liquet engagement is conducted by a named team behind contractual confidentiality terms tailored to the engagement — NDA, engagement letter, and bespoke MNPI clauses where parties are public or PE‑backed. [In place]

Engagement walls. Where Liquet is engaged on concurrent transactions, deal teams are walled — no shared access to other engagements’ materials or systems. Each engagement carries an internal codename; underlying party identities are visible only to the engagement team and named firm leadership. [Contract, in build]

Identity blinding by request. The default posture is that Liquet knows the identity of all engagement parties at contract level. Where a buyer requires full blinding — Liquet operating without seeing the target identity — this is offered as a paid option requiring an additional operational mode and pricing. [Contract, on request]

2. Material non-public information (MNPI)

Recognition. Liquet treats the fact of any engagement, the identity of any target, and any data submitted by either party as MNPI for the duration of the engagement and until publicly disclosed by the parties or otherwise lawfully releasable. [In place]

Personal trading policy. All Liquet personnel are bound to a personal trading policy: no transactions in public‑company securities related to any active or recently‑closed engagement; blackout periods; pre‑clearance for any restricted trades. The policy is documented and acknowledged at hire and on each engagement intake. [In place]

Disclosure boundaries. Engagement details are shared only on a need‑to‑know basis within the named engagement team. The fact of an engagement is not referenced in marketing, public channels, or external communications without explicit written consent from the engaging party. [In place]

3. Data handling architecture

Encryption in transit. All catalogue and reference data is transmitted under TLS 1.3 or equivalent. [In place]

Encryption at rest with customer‑managed keys. Engagement data is held under a customer‑managed key envelope — the customer (or the customer’s nominated KMS) holds the keys; Liquet’s infrastructure cannot decrypt the data without the customer’s active KMS reference. [In build]

Isolated processing. Processing of engagement catalogues occurs in dedicated, project‑isolated compute environments — separate VPC per engagement, ephemeral instances, no shared storage between engagements. [In build]

Trusted execution. Critical analysis steps run inside attested trusted‑execution environments (e.g. AWS Nitro Enclaves), allowing the customer to cryptographically verify that the code that processed their data is the code we agreed would. [In build]

Ephemeral processing. Decrypted data exists only in execution memory during processing; nothing is persisted in plaintext on Liquet’s infrastructure at any time. [In build]

Audit logging. All access to engagement data is logged immutably; logs are made available to the customer on request, covering access events, processing events, and lifecycle events. [In build]

Break‑glass access. A small number of named senior personnel have emergency access to processing environments for incident response. Every use of break‑glass access is logged, notified to the customer within agreed timeframes, and reviewed in a post‑incident report. We disclose that this exists rather than imply zero‑access; the discipline is the audit trail, not the absence of human capability. [Contract, in build]

4. Data lifecycle

Intake. Engagement data is delivered through a customer‑approved channel — typically a secure data room or direct CMK‑wrapped transfer. Liquet provides ingest verification, including hashes of received data. [In place]

During engagement. Data is processed only for the engagement’s defined scope. No copies are made for general infrastructure use, analytics, model training, or other purposes. [In place]

At engagement close. Within an agreed window (default 30 days post‑deliverable acceptance), all engagement data is securely deleted from Liquet’s systems. Deletion certificates are provided to the customer on request. [Contract, in place]

Reports. Final reports remain available to the customer in their original encrypted form for an agreed retention period; underlying source data does not. [Contract]

5. Personnel discipline

Vetting. All personnel handling engagement data are vetted proportionate to engagement sensitivity (background checks, references, contracted confidentiality). [In place]

Training. Annual training on MNPI handling, personal trading policy, data‑handling procedures, and incident response. [In place]

Sub‑processors. Use of any third‑party sub‑processor is disclosed in the engagement letter; no sub‑processor receives identifying engagement data without explicit customer consent. [In place]

6. Insurance

Liquet arranges professional indemnity and cyber‑liability insurance on a per‑engagement basis, sized to the engagement scope. Cover is bound at the point of engagement; coverage details and limits are disclosed in the engagement letter before signing. Underwriting is conducted on engagement‑shape information — type of work, scope, duration, geographies — without disclosing target identity to the broker. [Contract, on engagement]

7. Contact

For further detail on any of the above, or for the Liquet data‑protection terms in template form, write to engagements@liquetma.com.

This document is reviewed quarterly. Last updated: 10 June 2026.