Technical controls that support compliance

Health Insurance Portability and Accountability Act requires patient data protection, access controls, and audit trails.

• End-to-end encryption ensures patient data is never visible to servers
• Signed write history — every change is Ed25519-signed, proving who wrote what and when
• Fine-grained access control with named keys for different care teams
• Data retention strategies via time-sharded databases and archival
• Offline operation for field healthcare workers and remote clinics

⚠️ HIPAA also requires read-access logging, BAAs, administrative safeguards, and physical security — these are your responsibility to implement around MindooDB.

See healthcare use cases → | Detailed patterns →

Sarbanes-Oxley Act requires financial audit trails, immutable records, and access controls.

• Immutable records through append-only architecture
• Cryptographic integrity — hash-chained entries prove records haven't been altered
• Complete write history with signed authorship for audit requirements
• Time travel to reconstruct any historical state
• Signed changes prove authorship of all modifications

⚠️ SOX also requires internal controls, management certifications, and segregation of duties — these are organizational responsibilities.

See financial services use cases → | Detailed patterns →

General Data Protection Regulation requires right to be forgotten, data portability, consent tracking, and data protection by design.

• Coordinated data erasure — purgeDocHistory() propagates deletion requests via the directory DB to all synced clients
• Data portability through document export capabilities
• Data protection by design through end-to-end encryption
• Write audit trail — signed, append-only history of all data changes

⚠️ Purge requests reach clients on their next directory sync — devices that never reconnect retain the data. GDPR also requires consent management, DPO appointment, and processing records — these are your responsibility.

See compliance patterns →

Payment Card Industry Data Security Standard requires payment card data protection, access controls, and audit trails.

• Strong encryption — AES-256-GCM at rest, per-user RSA in transit
• Access controls with named keys for restricted access to sensitive data
• Write audit trail — signed, append-only history of all data changes

⚠️ PCI-DSS is a comprehensive standard covering network segmentation, vulnerability management, monitoring, and more. MindooDB addresses the encryption and access control requirements — the rest is your responsibility. Consider whether you need to store card data at all.

See compliance patterns →

• ✅ Complete write history (append-only)
• ✅ Cryptographic signatures (authorship proof)
• ✅ Tamperproof records (hash-chained)
• ✅ Time travel (reconstruct any state)
• ✅ Timestamped changes

• ✅ Client-side encryption (AES-256-GCM)
• ✅ Fine-grained access control (named keys)
• ✅ Key management (password-protected KeyBag)
• ✅ Coordinated data erasure (directory-propagated purge)
• ✅ Data sovereignty (client-side tenants)

• ⚙️ Read-access logging (application layer)
• ⚙️ Consent management (application layer)
• ⚙️ Role-based access control (using named keys)
• ⚙️ Data retention policies (using time-sharding)
• ⚙️ Compliance reporting (using audit data)

• Every write is cryptographically signed with the author's Ed25519 key
• Timestamps are included in every change entry
• Document history can be traversed with iterateDocumentHistory()
• Time travel allows reconstructing any historical state
• Deletions are marked with tombstones (preserving history)

Note: MindooDB automatically logs writes (who changed what). Read access logging (who viewed what) must be implemented at the application level.

• Prove who changed what and when
• Reconstruct state at any point in time
• Demonstrate data integrity to auditors
• Build application-level read-access logging on top
• Support legal discovery requirements

See time travel docs →

• Time-based sharding — Create databases by time period (yearly, monthly)
• Archival databases — Move old data to read-only archive databases
• Document lifecycle — Mark documents as archived instead of deleting
• Coordinated purge — Admin-signed purge requests propagate via directory DB; clients execute on next sync

See data modeling patterns →

• Append-only nature means data accumulates over time
• Plan for growth management from the start
• Use time-based sharding for efficient archival
• Consider retention requirements per document type
• Coordinated purge propagates to synced clients; offline devices retain data

See compliance patterns →