11 — Compliance Concerns

The regulatory surface for a multi-tenant file platform, and how the architecture is compliance-ready by construction. Stance (NG8): build the controls now; pursue certification with a real customer (certs are evidence-gathering exercises, cheap once the controls exist).

1. The architecture is audit-ready by design

Several existing decisions are compliance controls:

Control family Provided by
Access control OIDC/MFA (03), Cedar/RBAC/ReBAC (04), RLS (05)
Change management GitOps — every change is a reviewed, audited commit (platform/06)
Monitoring / logging tamper-evident audit + SIEM (07), OTel (ADR-0013)
Encryption TLS + envelope at rest + crypto-shredding (10)
Availability / DR backups, PITR, DR runbooks (platform/11)
Vulnerability mgmt scanning, SBOM, signing, SLSA (ADR-0032)
Vendor/sub-processor multi-cloud abstraction + residency (ADR-0020)

The GitOps + tamper-evident-audit combination is unusually strong evidence: change management and monitoring are provable from Git history and a verifiable log, which is most of a SOC2 audit.

2. GDPR

Requirement How
Lawful basis / roles BitVault = processor; tenant = controller; DPA + documented sub-processors
Right to access (DSAR export) per-tenant/user data export (04 contexts)
Right to erasure crypto-shredding — delete the key, data is gone everywhere incl. backups (10 §3)
Data residency pin tenant to region/jurisdiction + prove it (ADR-0020, product/02 E4)
Data minimization don’t log secrets/PII-in-clear (07); pseudonymize
Breach notification (72h) SIEM/alerting (07) + IR plan (12) 
flowchart LR
    classDef e fill:#fde68a,stroke:#b45309,color:#111827;
    classDef d fill:#bbf7d0,stroke:#15803d,color:#111827;
    dsar["DSAR request"]:::e --> kind{"access or erasure?"}:::e
    kind -- access --> exp["export tenant/user data (scoped)"]:::d
    kind -- erasure --> shred["destroy per-tenant/per-object key → crypto-shred"]:::d
    shred --> proof["data unrecoverable across live + replicas + backups (provable)"]:::d

Erasure vs immutable audit tension: crypto-shred the data; keep the audit trail’s integrity by logging pseudonymous IDs (07 §4).

3. SOC 2 (Type II) — the five Trust Services Criteria

TSC Architecture evidence
Security access control, MFA, deny-by-default, network policies, supply chain
Availability SLOs, HPA/PDB, DR/backup, multi-AZ (platform/)
Confidentiality encryption, tenant isolation, least privilege
Processing integrity content hashing, commit protocol, idempotent events (storage/)
Privacy data minimization, DSAR, residency, retention

Type II requires operating effectiveness over time → the continuous controls (audit log, GitOps history, automated tests) supply the evidence.

4. Other regimes

Regime Posture
HIPAA (if PHI) BAA, encryption, audit, access controls, minimum-necessary — primitives exist; enable per-tenant
ISO 27001 ISMS wraps the existing controls; gap-assess when pursued
CCPA/CPRA overlaps GDPR (access/delete/opt-out)
PCI-DSS avoid storing card data (use a PCI provider) → stay out of scope
FedRAMP / sovereignty aspirational; single-region/dedicated-cluster + residency are the on-ramp

5. Compliance concerns specific to this product

References