Sphinx HTML and 17-page LaTeX PDF for the audit-ready pack

source/ is the Sphinx tree. Companion PDF hrefs are relative, not Markdown.

source/baa-dpa.rst

@@ -0,0 +1,76 @@
+BAAs and DPAs when ciphertext has no host keys
+==============================================
+
+This is **guidance for an evidence pack**, not legal advice.
+
+The operator statement
+----------------------
+
+Data at rest lives in the **encrypted Peergos cryptree**. Restore uses
+**distributed, hash-verified, encrypted IPFS blocks**. Hosts and backup
+media see **opaque blobs** (and random CHAMP labels), not filenames, not
+PHI, not social graph — if keys never leave the client / customer HSM.
+
+That is **true of the Peergos design** (see :doc:`verification`).
+It **changes the BAA/DPA conversation**. It does **not** auto-delete the
+need for contracts.
+
+HIPAA (US) — Business Associate
+-------------------------------
+
+A Business Associate is a person who **creates, receives, maintains, or
+transmits ePHI** for a covered entity.
+
+**Technical argument you can make (and should document):**
+
+1. ePHI is encrypted **before** it leaves the endpoint (Peergos client /
+   DataCube writer).
+2. The storage node, IPFS, disk, and backup hold **ciphertext + hashes**.
+3. Private keys **do not** reside on the storage host (customer HSM /
+   client). Hash verification detects tampering.
+4. Therefore the host **cannot maintain ePHI in intelligible form**.
+
+HHS distinguishes **conduits** and parties that never have access to
+ePHI. Many programs still **sign a BAA** when a vendor touches
+infrastructure, because misconfiguration, support exports, or logs could
+later expose plaintext. OCR looks at **your** risk analysis.
+
+**Practical pack:** risk analysis memo citing cryptree + IPFS hash checks
++ key custody; BAA **or** written determination that the vendor is
+**not** a BA because they cannot decrypt; list every party with
+disk/backup (ns1, IPFS cluster, offsite replica).
+
+GDPR (EU/UK) — processor vs technical measure
+---------------------------------------------
+
+Encrypted data can still be **personal data** if it is reasonably
+attributable (usernames, IPs, invoice identity). GDPR **Art. 32** lists
+encryption as a security measure.
+
+Peergos is designed so the **server is an adversary** for content and
+most metadata. EU-based **independent pentests** (Cure53 DE, ROS NL)
+evaluated that design. Processing location for **self-host** is *your*
+ns1 / customer region, not peergos.net’s Germany hosting, unless you use
+peergos.net.
+
+You may still need a **DPA (Art. 28)** with anyone who **processes**
+personal data (usernames, logs, billing). Ciphertext-only storage
+**narrows** the DPA’s technical annex.
+
+NATS operators
+--------------
+
+NATS is an **untrusted broker**. Content is HPKE; destinations and
+subjects are in the clear. A NATS operator **cannot** read bodies without
+endpoint private keys; **can** see routing metadata; **can** drop/delay
+copy **ciphertext**. Treat like a transit provider: DPA/BAA depends on
+whether routing metadata is personal data in your jurisdiction.
+
+What “making yourself audit-ready” means
+----------------------------------------
+
+You are **not** buying Peergos’s Cure53/ROS reports as *your* SOC 2.
+You are **reusing** those public evaluations as **vendor/component
+assurance**, then adding your scope, RoPA, key-custody, inspect k-of-n,
+admin-history, instance evidence, and contracts that match who can
+actually see plaintext.