Skip to main content
AuditRails stores every audit event across two independent storage tiers — a hot tier for fast search and analytics, and a cold tier for long-term immutable archiving. Retention periods are determined by your plan and, where applicable, by the compliance frameworks you have enabled. This page explains how each tier works, when data is cleaned up, and what happens when you need to delete data for a DSAR request.

​
Storage Tiers

Hot Storage — Fast Search

Events land here first. Hot storage provides sub-second full-text search, time-range queries, and aggregations across millions of events. Data is removed automatically at the end of the retention period.

Cold Storage — S3 Object Lock

Every event is simultaneously written to Amazon S3 with Object Lock in COMPLIANCE mode. This creates a tamper-proof, immutable archive. The retention expiry is set at write time and cannot be shortened by AuditRails, your AWS account, or anyone else — including AWS support.
S3 Object Lock COMPLIANCE mode meets the immutable storage requirements of SEC Rule 17a-4(f), FINRA Rule 4511, and CFTC Regulation 1.31, making it suitable for financial services audit trails.

​
Retention Periods

Every plan — Starter Trails, Framework Trails, and Compliance Trails — includes the same base retention, applied identically to both storage tiers:
Compliance frameworks can extend the effective retention period. For example, enabling SOX automatically raises your retention to 7 years; HIPAA sets a 6-year minimum; NIS2 and DORA both require 5 years. The longest applicable period always wins, and this applies on any plan that has the relevant framework enabled — retention is not itself a plan-tier feature.

​
Cleanup Process

AuditRails runs a daily cleanup job at 02:00 UTC.
1

Hot storage cleanup

The cleanup job removes events from hot storage whose retention period has elapsed. Removed records are unrecoverable from hot storage.
2

S3 Object Lock expiry

S3 Object Lock expiry dates are set at write time. When an object’s lock expires, AWS automatically makes it eligible for deletion. AuditRails does not need to take any action — the lifecycle policy handles this.
3

Data deletion certificate

After each cleanup run, AuditRails generates a data deletion certificate for any data removed during that run.

​
Data Deletion Certificate

A deletion certificate is generated every time AuditRails removes data — either through scheduled retention cleanup or in response to a DSAR deletion request. Certificates are stored indefinitely and are accessible at Dashboard → Settings → Data Retention. Each certificate contains:
Deletion certificates provide auditable proof that data was purged on schedule. Include them in your evidence package for SOC 2, HIPAA, and PCI DSS audits to demonstrate that data is not retained beyond the required period.

​
DSAR Deletion and WORM Limitations

When you submit a right to erasure (Art.17) request via the DSAR workflow, AuditRails handles the two storage tiers differently.
S3 WORM records cannot be physically deleted before the retention period expires. This is a fundamental property of S3 Object Lock COMPLIANCE mode — no user, administrator, or even AWS can remove a locked object early. If a DSAR deletion request is received while WORM records are still within their retention window, those records are logically marked as deleted and excluded from all reads, exports, and API responses, but the underlying bytes remain in S3 until the lock expires.
Retaining WORM-locked records after a deletion request is lawful under GDPR Art.17(3)(e), which permits continued storage where processing is necessary for the establishment, exercise, or defence of legal claims. Audit logs serving as evidence of system activity fall within this exception. AuditRails documents this legal basis in the Data Processing Agreement (DPA) available at Dashboard → Settings → Legal.

​
Frequently Asked Questions

The 180-day base retention is the same on every plan. To extend it, enable a compliance framework that requires a longer minimum (e.g., SOX for 7 years, HIPAA for 6 years, NIS2 or DORA for 5 years) — the longest applicable minimum always wins. There is currently no self-service or account-manager-mediated way to set a custom retention period independent of an enabled framework.
You cannot set a retention period shorter than the 180-day base. If a compliance framework is enabled, its mandatory minimum also applies. Disabling a framework does not retroactively shorten the retention period for data already written.
Data already written is retained for the period that was in effect at the time of writing. Since retention is driven by which compliance frameworks are enabled rather than by plan tier, downgrading your plan only affects retention if it also forces you below your framework limit and a framework gets disabled as a result. Existing WORM-locked data remains locked until its original expiry date regardless.
Use the data deletion certificates in Dashboard → Settings → Data Retention. Each certificate is hashed for integrity and can be presented directly as audit evidence.
Starter Trails and Framework Trails store data in us-east-1 (Northern Virginia, USA). Compliance Trails can choose us-east-1 or eu-west-1 (Ireland, EU). EU storage is required for GDPR data residency compliance in certain jurisdictions.