Guide: Achieving Compliance (GDPR, SOC 2)
Relevant source files
The following files were used as context for generating this wiki page:Cyberpath Sentinel is a document-based DBMS designed with trust, transparency, and compliance as its core priorities. Unlike traditional databases that prioritize speed, Sentinel's architecture is fundamentally built to support regulatory requirements such as GDPR, SOC 2, HIPAA, and ISO 27001. Its "filesystem is the database" approach makes every piece of data inspectable, auditable, and versionable by default.
This guide explains how Sentinel's features and planned components facilitate compliance, turning audit trails and data governance from afterthoughts into intrinsic properties of the system. The goal is to provide a "transparency layer" in the modern data stack, where compliance is a built-in function rather than an add-on.
Sources: README.md:11-12, 45-51, IMPLEMENTATION_PLAN.md:13-19
Core Architectural Principles for Compliance
Sentinel's design is guided by principles that naturally align with compliance and security frameworks.
| Principle | Description | Compliance Implication |
|---|---|---|
| Filesystem is the Database | All data is stored as files on disk, tables are folders, and document primary keys are filenames. | Enables use of standard OS tools (grep, rsync) and OS-level ACLs for access control. Data is easily inspectable for audits. |
| Immutability by Default | Deletions are soft (moved to a .deleted/ folder), and changes can be versioned with Git. Append-only patterns are encouraged. | Creates a transparent, verifiable history of all data changes, which is a core requirement for SOC 2 and other audit standards. |
| Security First | The system is designed to leverage file permissions, encryption, and cryptographic verification for security. | Provides foundational controls for protecting sensitive data, as required by GDPR, HIPAA, and PCI-DSS. |
| UNIX Philosophy | Do one thing well and compose with standard tools. | Simplifies operations and reduces the need for specialized database administration, making security and backup procedures more reliable. |
Sources: README.md:31-32, 45-46, 110-114, IMPLEMENTATION_PLAN.md:22-26
GDPR Compliance: Right to Deletion
The General Data Protection Regulation (GDPR) includes the "Right to be Forgotten," which requires organizations to delete a user's personal data upon request. In Sentinel, this is a straightforward and auditable filesystem operation.
The process for deleting a document is a soft delete, moving the file to a .deleted/ directory. This maintains an audit trail. A permanent deletion is a simple rm command, which can also be logged by the system.
Sources: README.md:19, 47, 137, IMPLEMENTATION_PLAN.md:435-438
This diagram illustrates the GDPR-compliant deletion process.
SOC 2 and Auditability
SOC 2 compliance requires organizations to establish and follow strict information security policies and procedures. Sentinel's architecture is designed to make demonstrating this trivial.
Intrinsic Audit Trails
Every change to a document can be an atomic file operation. When integrated with Git, Sentinel provides a complete, transparent audit trail out of the box.
- Who: Git commit author.
- What: The
git diffof the JSON file. - When: The commit timestamp.
- Why: The Git commit message.
This native versioning satisfies key SOC 2 requirements for change management and auditing without requiring a separate, complex logging system.
Sources: README.md:17, 33, 45, 138
Planned Audit & Compliance Engine
The implementation plan includes a dedicated AuditTrail component to formalize event logging and a ComplianceStandard enum for generating framework-specific reports.
The following diagram shows the relationship between the core AuditTrail struct and its related data structures as defined in the implementation plan.
Sources: IMPLEMENTATION_PLAN.md:316-347
The AuditEvent struct is planned to contain the following fields:
| Field | Type | Description |
|---|---|---|
timestamp | DateTime<Utc> | The exact time the event occurred. |
operation | Operation | The type of operation performed (e.g., Insert, Delete). |
user | Option<String> | The user or principal that initiated the operation. |
resource | String | The resource that was affected (e.g., document ID). |
status | OperationStatus | The outcome of the operation (e.g., Success, Failure). |
details | Value | A JSON value containing additional context about the event. |
Sources: IMPLEMENTATION_PLAN.md:320-327
The proposed compliance architecture centralizes audit logs and governance policies into dedicated collections within the store.
This diagram shows the proposed folder structure for managing compliance-related data.
Sources: IMPLEMENTATION_PLAN.md:441-454
Security Features Supporting Compliance
Sentinel's security model is built on layers of controls that are essential for meeting compliance mandates.
Encryption
Sentinel is planned to support encryption at rest using modern, authenticated encryption algorithms. The EncryptionManager component will handle this.
- Algorithms: AES-256-GCM or ChaCha20-Poly1305.
- Key Management: A master key will be used for key derivation with Argon2.
- Granularity: PII can be encrypted at the field level within a document.
The choice of these cryptographic libraries is reflected in the project's dependencies.
Sources: README.md:49, 135, IMPLEMENTATION_PLAN.md:214-232, Cargo.toml:18-20
Access Control
Instead of complex internal user management, Sentinel leverages robust, OS-level Access Control Lists (ACLs). This simplifies administration and allows for integration with existing identity and access management (IAM) systems. For compliance, this means access policies are managed and audited using standard, well-understood tools.
Sources: README.md:18, 34, 51, 133, IMPLEMENTATION_PLAN.md:401-404
Data Integrity
To ensure data has not been tampered with, a critical requirement for financial (PCI-DSS) and security (SOC 2) audits, Sentinel plans to use multiple layers of cryptographic verification.
- Checksums: SHA-256 hashes are stored with each document to detect corruption.
- Digital Signatures: Documents can be signed (e.g., with RSA-2048) to provide a non-repudiable record of authorship and integrity.
- Merkle Trees: For advanced integrity, Merkle trees can be used to verify the state of an entire collection efficiently.
Sources: README.md:35, 135, IMPLEMENTATION_PLAN.md:80, 108, 393-400
The following sequence diagram illustrates how a write operation would be logged for audit purposes.
This flow shows how durability and audit logging are planned as separate but integrated steps in a write operation.
Sources: IMPLEMENTATION_PLAN.md:124, 316-331
Conclusion
Cyberpath Sentinel is engineered to make compliance a native feature, not an operational burden. By leveraging the filesystem and established tools like Git, it provides unparalleled transparency and auditability. The planned features for dedicated audit logging, compliance reporting, and robust security controls are designed to directly address the requirements of standards like GDPR and SOC 2, making Sentinel a strong candidate for organizations that manage sensitive security and compliance data.