Compliance Mapping
How dbtrail capabilities map to SOC 2, HIPAA, PCI-DSS, and GDPR compliance controls
dbtrail indexes MySQL binary logs in real time for row-level recovery and data change forensics. This page maps dbtrail capabilities to specific compliance controls across SOC 2, HIPAA, PCI-DSS, and GDPR.
dbtrail is not a certified product
These frameworks audit your organization, not individual tools. dbtrail is a technical control that supports specific requirements within your broader compliance program.
SOC 2 Availability (A1.2, A1.3)
A1.2: Data backup processes and recovery infrastructure
| dbtrail capability | How it supports A1.2 |
|---|---|
| Recovery SQL generation | Row-level, point-in-time recovery without full database restores. Reduces effective RPO to the last committed transaction. |
| Continuous binlog indexing | Every data change is captured as it occurs. Provides evidence that backup processes are operational and current. |
A1.3: Testing of recovery plan procedures
| dbtrail capability | How it supports A1.3 |
|---|---|
| On-demand recovery validation | Recovery SQL can be generated and verified at any time. Output serves as auditable evidence of tested restore procedures. |
Scope
dbtrail is the MySQL backup and point-in-time-recovery layer — logical snapshots via bintrail dump (mydumper) plus continuous binlog streaming, with row-level recovery on top. In open source, snapshot scheduling is up to the operator (e.g., cron); dbtrail Cloud provides managed backup schedules. dbtrail does not replace offsite replication, cross-region disaster recovery, or full infrastructure recovery; those remain part of your broader availability program.
HIPAA Security Rule
§164.308(a)(7): Contingency Plan
| Implementation specification | Status | dbtrail capability |
|---|---|---|
| (ii)(A) Data Backup Plan | Required | Recovery SQL restores exact pre-incident state of specific ePHI records. Supplements full backups for partial data loss scenarios. |
| (ii)(B) Disaster Recovery Plan | Required | Continuous binlog indexing ensures recovery data is not dependent on backup schedule intervals. |
| (ii)(D) Testing and Revision Procedures | Addressable | Recovery SQL generation is repeatable and verifiable on demand. |
§164.308(a)(1)(ii)(D): Information System Activity Review
| dbtrail capability | How it supports activity review |
|---|---|
who_changed | Identifies which MySQL user modified a specific row, when, and from which host. Includes before/after values. |
user_activity | Lists all recent data changes by a specific MySQL user. |
Requires dbtrail Cloud
who_changed and user_activity are part of dbtrail Cloud forensics, which enriches indexed events with MySQL user and host attribution. The open-source index records each change's raw connection_id only.
Scope
dbtrail does not replace full ePHI backup/restore procedures, BAA agreements, workforce security training, access controls, or encryption requirements. It is one technical control within a contingency plan.
PCI-DSS v4.0: Requirement 10
10.2: Audit logs for anomaly detection and forensic analysis
| dbtrail capability | What it records |
|---|---|
who_changed | MySQL user, timestamp, source host, and before/after row values for any specific row change. |
user_activity | All data modifications by a specific MySQL user across all indexed tables. |
connection_history | Connections from specific MySQL users or source hosts/IPs. |
dbtrail captures data-level changes that application-layer logging typically misses: direct SQL executed against the database by privileged users, scripts, or application bugs.
Requires dbtrail Cloud
who_changed, user_activity, and connection_history are dbtrail Cloud forensics tools. In open source, bintrail query exposes each event's raw connection_id for manual correlation, without user/host attribution.
10.3: Protect audit trails from modification
Indexed binlog data is stored in append-only fashion. Each indexed event references the original binary log event by binlog file, position, and GTID.
10.5: Audit log retention
| Requirement | PCI-DSS minimum | dbtrail support |
|---|---|---|
| Total retention | 12 months | Configurable retention with long-term archiving |
| Immediately available | Most recent 3 months | Indexed data is queryable in real time |
In open source, retention is set per stream via rotation settings (--rotate-retain, default 30d; off disables partition drops), with Parquet payload archiving to S3 for long-term retention. On dbtrail Cloud, retention is configured per tenant from the dashboard.
Scope
dbtrail provides the database-level data change audit trail. It does not replace application-layer logging (failed logins, permission changes, API access), SIEM integration, network monitoring, or file integrity monitoring.
GDPR Article 32: Security of Processing
32(1)(c): Timely restoration of personal data
Point-in-time row recovery generates SQL to restore specific affected rows in seconds. This is the proportionate response when the incident is partial data loss (accidental deletion, application bug, unauthorized modification) rather than total infrastructure failure.
32(1)(d): Regular testing of security measures
Recovery SQL generation is repeatable and can be validated at any time as part of regular security measure evaluation.
32(2): Risks of accidental destruction, loss, or alteration
Recovery SQL reverses accidental or unauthorized data modifications. who_changed and user_activity forensics detect the change and attribute it to a MySQL user and source host.
Requires dbtrail Cloud
Change attribution (who_changed, user_activity) is part of dbtrail Cloud forensics. Recovery SQL generation is available in both open source and Cloud.
Right to Erasure (Article 17)
Retention of indexed binlog data containing personal information must be aligned with your data retention policy. dbtrail retention is configurable — via rotation settings (--rotate-retain) in open source, and per tenant from the dashboard on dbtrail Cloud — to support purge of personal data when required by erasure requests, while respecting minimum retention periods imposed by other frameworks (e.g., PCI-DSS 12-month minimum). Consult your DPO on the appropriate configuration.
Scope
dbtrail supports one specific technical capability under Article 32: timely, granular data restoration. It does not replace DPIAs, encryption, pseudonymization, access controls, DPO appointment, or lawful basis documentation.
Summary
| Framework | Control | dbtrail capability | Coverage |
|---|---|---|---|
| SOC 2 | A1.2 | Recovery SQL, continuous indexing | Row-level recovery, reduced RPO |
| SOC 2 | A1.3 | On-demand recovery validation | Auditable restore evidence |
| HIPAA | §164.308(a)(7)(ii)(A) | Recovery SQL | Exact-state recovery of specific records |
| HIPAA | §164.308(a)(7)(ii)(D) | On-demand recovery testing | Verifiable contingency plan testing |
| HIPAA | §164.308(a)(1)(ii)(D) | who_changed, user_activity (dbtrail Cloud) | Data modification audit trail |
| PCI-DSS | 10.2 | who_changed, user_activity, connection_history (dbtrail Cloud) | Data-level forensics with before/after values |
| PCI-DSS | 10.3 | Append-only storage | Tamper-resistant audit trail |
| PCI-DSS | 10.5 | Configurable retention | 12-month retention, 3-month immediate access |
| GDPR | Art. 32(1)(c) | Point-in-time row recovery | Seconds vs. hours for targeted restoration |
| GDPR | Art. 32(1)(d) | On-demand recovery validation | Repeatable security measure testing |
Supporting documentation
If you are undergoing a compliance audit and want to include dbtrail as a documented control, we can provide:
- Architecture and data flow documentation
- Encryption in transit (TLS) and at rest specifications
- Retention configuration reference
- Recovery validation procedures with sample output
Contact hello@dbtrail.com for compliance-related requests.