peergos-making-yourself-audit-ready-with-verae-datacubes/BAA-DPA.md

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.