Every compliance auditor eventually asks the same question: “How far back do your logs go?” The answer they want is not “forever” and not “we don’t know.” They want a number, tied to a policy, backed by a framework. Here is how the major frameworks answer, and what each answer means for your SFTP server.
Four frameworks, four numbers
| Framework | Minimum retention | What it says |
|---|---|---|
| PCI DSS 4.0 | 1 year (90 days immediately available) | Requirement 10.7: retain audit trail history for at least 12 months; at least three months must be immediately accessible for analysis. |
| HIPAA | 6 years | 45 CFR 164.530(j): documentation of policies, procedures, and actions must be retained for six years from the date of creation or the date it was last in effect. |
| SOX (Sarbanes-Oxley) | 7 years | Section 802: audit workpapers and records relevant to the audit of a public company must be retained for seven years. |
| GDPR | No fixed floor | Article 5(1)(e): personal data must be kept no longer than necessary. Retention must be justifiable. Audit logs containing IP addresses or usernames are personal data in many interpretations. |
PCI gives you a clean number. HIPAA gives you a larger one. SOX gives you the largest. GDPR flips the question: why are you still keeping this?
If you operate in more than one of these worlds — a healthcare company that accepts credit cards, say — the strictest floor wins. For that example, six years, with a documented justification that satisfies GDPR.
What “immediately available” means in practice
PCI’s 90-day rule is the most operationally specific. It means your incident-response team must be able to search the last 90 days of logs without restoring from a backup. The remaining nine months can live in cold storage — a compressed archive, a separate database, a SIEM’s long-term tier — as long as they can be recalled.
This maps naturally to a two-tier model: keep the live audit table at three to six months, then archive older rows to cheaper storage. Your SFTP server’s JDBC audit sink writes every event into the sftp_audit table with a timestamp, event type, username, IP address, filename, byte count, and success flag. That table is queryable from the Web Admin console and the REST API. The archive tier is yours to choose — a SIEM, a data lake, a second database with cheaper storage.
How large does the table get?
Each row in sftp_audit is roughly 200–400 bytes depending on filename and detail lengths. A busy server processing 10,000 file transfers per day generates around 30,000 audit events (connect, authenticate, transfer, disconnect, plus directory listings). At 400 bytes each, that is about 12 MB per day, or 4.3 GB per year.
Those numbers are modest by database standards. But at a six-year HIPAA retention, the table reaches 26 GB, and queries that scan the full history start to slow down. The ix_sftp_audit_occurred_at index keeps date-range queries fast, but a full-table report on seven years of data is never instant.
The practical solution is partitioning or periodic archiving. Move rows older than your hot window into a separate table or export, keep the live table lean, and satisfy the compliance floor from the archive.
GDPR complicates everything
GDPR does not give you a retention floor. It gives you a ceiling. If your audit log records usernames and IP addresses — and it does — then every row is personal data subject to data minimisation. You need a documented retention schedule that justifies why you keep six years of login records. “Because HIPAA says so” is a valid justification if HIPAA actually applies to your organisation. “Because we never delete anything” is not.
If your SFTP server handles EU personal data but you are not subject to HIPAA or SOX, your retention period is whatever your data protection officer can defend. One year is common. Two years is defensible for most file transfer operations. Indefinite is a finding waiting to happen.
A practical schedule
For most organisations running an SFTP server as part of a regulated file-exchange pipeline, the following schedule covers the common frameworks:
- Hot tier (0–90 days): live database table, searchable from the admin console. This is your
sftp_audittable, indexed and fast. - Warm tier (90 days–1 year): still in the database (or forwarded to your SIEM), still queryable, but no longer the primary investigation window. Satisfies PCI’s 12-month requirement.
- Cold tier (1–7 years): compressed exports or SIEM long-term storage. Satisfies HIPAA (6 years) and SOX (7 years). Retrievable within hours, not seconds.
- Deletion: rows past the applicable retention limit are purged. If GDPR applies and no other framework mandates longer, purge at the end of your justified window.
The exact boundaries depend on your regulatory exposure. The point is that “keep everything forever” is not a retention policy, and “delete after 30 days” fails every framework except an auditor who isn’t paying attention.
What your SFTP server needs to support this
A retention strategy for audit data needs the server to do two things well: record comprehensively, and make the records portable.
Stylus SFTP Server records over 80 distinct event types across four concurrent audit sinks — the JDBC database, the server log, RFC 5424 syslog for your SIEM, and signed webhooks for real-time integrations. Every login, every failed password, every file uploaded and downloaded, every admin action lands in all active sinks simultaneously. The syslog sink is particularly useful for long-term retention: forward every event to Splunk, the ELK stack, or QRadar, and let the SIEM handle tiered storage and lifecycle policies natively.
For the JDBC tier, archiving older rows is a scheduled SQL job. The occurred_at column is indexed. A nightly INSERT INTO archive SELECT ... WHERE occurred_at < ... followed by a DELETE keeps the live table at whatever hot-window size you choose.