Initial pack: Peergos EU audit verification and DataCube audit-ready checklist

Cure53 Berlin 2019 and ROS Amsterdam 2024 are pentests, not HIPAA/SOC2/ISO
certificates. BAA/DPA guidance for ciphertext-at-rest on cryptree+IPFS.

BAA-DPA.md

@@ -0,0 +1,85 @@
+# 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 `PEERGOS-VERIFICATION.md`).
+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 has long distinguished **conduits** and parties that never have
+access to ePHI. Many security programs still **sign a BAA anyway** when
+a vendor touches infrastructure, because:
+
+- misconfiguration could later expose keys or plaintext logs;
+- support staff might be asked to handle a decrypted export;
+- OCR looks at **your** risk analysis, not only crypto papers.
+
+**Practical pack:** risk analysis memo citing cryptree + IPFS hash
+checks + key custody (`HSM-CUSTODY` in system-git-sync); 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**
+explicitly lists encryption as a security measure.
+
+**Technical argument:**
+
+- 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 (even usernames, logs, billing). Ciphertext-only storage
+**narrows** the DPA’s technical annex (they never see PHI bodies) but
+rarely deletes the contract if they run the VM.
+
+## NATS operators
+
+NATS is an **untrusted broker**. Content is HPKE; destinations and
+subjects are in the clear. A NATS operator:
+
+- **cannot** read message bodies if they lack endpoint private keys;
+- **can** see routing metadata (who talks to which inbox, sizes, timing);
+- **can** drop/delay/copy **ciphertext**.
+
+Treat NATS like a **transit provider**: DPA/BAA depends on whether
+routing metadata is personal data in your jurisdiction. Document
+passthrough + HPKE in the data-flow diagram.
+
+## What “making yourself audit-ready” means here
+
+You are **not** buying Peergos’s Cure53/ROS reports as *your* SOC 2.
+You are **reusing** those public evaluations as **vendor/component
+assurance** (like using an audited TLS library), then adding:
+
+- your scope, RoPA, key-custody, inspect k-of-n, admin-history;
+- evidence *your* instance ran those controls;
+- contracts that match who can actually see plaintext.