Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
How long should security logs be retained?
Updated
For most companies: twelve months as the working baseline for security-relevant logs, with the most recent three months immediately searchable, plus whatever your audit period, incident-reporting windows, and contracts require. Very few log types have a legal minimum at all.
Log-retention guidance, last verified 10 September 2026 against PCI DSS v4.0.1 Requirement 10.5.1, ISO/IEC 27001:2022 Annex A 8.15, NIST SP 800-92, GDPR Article 5(1)(e), and the reporting windows in Regulation (EU) 2024/2847 and GDPR Article 33. This page is not legal advice, does not determine YOUR retention obligations, does not decide which regimes apply to you, does not start a clock, and does not file with an auditor. Retention that touches personal data is a data-protection question as much as a security one.
What this page is, and what it is not
Audience: a security or platform engineer setting retention on cloud audit trails, application logs, and platform records, who wants a period they can defend rather than a number somebody asserted in a meeting.
This page is not legal advice. It does not determine YOUR obligations, does not decide which regimes reach your organisation, does not start a clock, and does not file anything with an auditor. Retention periods interact with sector rules, contracts, litigation holds, and data-protection law, and the combination is a question for counsel and your data-protection owner. Last verified 10 September 2026.
The honest headline is that there is far less law here than the industry implies. PCI DSS names a period. Some sector regimes name periods. Most of the frameworks people cite — SOC 2, ISO/IEC 27001 — name no period at all; they require that you define retention appropriately and then honour your own definition. That means the common answer of one year is a defensible convention rather than a mandate, and the real driver for most companies is the audit period plus the incident window.
- Four drivers set your period: the audit period you need to cover, the longest plausible incident investigation and reporting window, any named legal or contractual minimum, and cost.
- Retention and searchability are different settings. Cheap archival for twelve months plus hot search for three is the pattern most requirements actually describe.
- Cloud platform defaults are usually shorter than anything on this page. Several are measured in days, and one is effectively permanent-but-not-in-the-way-you-want.
- Longer is not automatically better. Where logs contain personal data, keeping them beyond your stated purpose creates a data-protection problem, not extra safety.
Log-type-to-retention map, with the citation per row
First column is the log type, second the working baseline, third the citation or driver behind it, fourth what actually decides the period for you. Where the driver column says no named period, the number in column two is a convention, not a rule. Last verified 10 September 2026. Not legal advice.
| Log type | Working baseline | Citation or driver | What actually decides your period |
|---|---|---|---|
| Cardholder-data-environment audit trails | Twelve months, with at least the most recent three months immediately available for analysis | PCI DSS v4.0.1 Requirement 10.5.1 — a named period, binding contractually on entities in scope. | Whether you are in PCI scope at all. If you are, this is the closest thing to a hard number in this table, and your acquirer or assessor is the authority on it. |
| Cloud control-plane and management-API audit trail | Twelve to eighteen months, archived; ninety days hot | No named period in AICPA TSC or ISO/IEC 27001:2022 Annex A 8.15 — both require appropriate, defined retention. NIST SP 800-53 Rev. 5 AU-11 requires a defined period consistent with the record-retention policy. | Your audit period plus lookback. An audit covering twelve months needs configuration and administrative-action history across all twelve, and platform defaults frequently do not reach that far. |
| Identity provider and authentication logs | Twelve months, archived; ninety days hot | Annex A 8.15 and 8.16; AICPA TSC CC6.1, CC6.2 and CC7.2; NIST SP 800-53 AU-11. No named period. | Access-review evidence and incident lookback. Credential compromise is often discovered months after the initial authentication, which is the practical argument for twelve months. |
| Privileged-access and break-glass session records | Twelve to twenty-four months | Annex A 8.15 and 8.18; AICPA TSC CC6.1 and CC6.3. No named period. | How long you might need to reconstruct an insider or compromised-administrator scenario. This is the log type where longer retention buys the most. |
| Application access and security-event logs | Twelve months, archived; thirty to ninety days hot | Annex A 8.15; AICPA TSC CC7.2. No named period. NIST SP 800-92 discusses retention as a risk-based decision. | Volume and cost, balanced against investigation need. This is usually the largest and most expensive category, and the one to tier aggressively. |
| Network flow, load-balancer and firewall logs | Ninety days to twelve months | Annex A 8.15, 8.16 and 8.20; PCI DSS Requirement 10 where in scope. No named period outside PCI. | Investigation need against a large bill. Ninety days hot with selective longer archival for perimeter records is common and defensible if you say so in the policy. |
| Database audit and data-access logs | Twelve months where the data is sensitive | Annex A 8.15; AICPA TSC CC6.1 and the confidentiality criteria; GDPR accountability duties where personal data is accessed. | Whether you need to answer who accessed which records, which is the question after any suspected data incident and in some subject-access contexts. |
| Change, deployment and pipeline records | Full audit period, plus one period — practically eighteen to twenty-four months | AICPA TSC CC8.1; Annex A 8.32. No named period. | Your audit period, because the complete change population for the period is the control. Platform defaults for pipeline logs and artifacts are often far shorter and silently discard the evidence. |
| Security tool and alert-handling records | Twelve months | Annex A 8.15 and 8.16; AICPA TSC CC7.2 and CC7.3. No named period. | Whether you can show that alerts were triaged, not just generated, across the whole period. |
| Incident records and preserved incident evidence | Until closure plus a defined period, commonly two to seven years; preserved evidence retained on its own footing | GDPR Article 33(5) requires documentation of personal-data breaches with no period named; CRA Article 14 and NIS2 reporting create investigative windows; Annex A 5.27 and 5.28. | Limitation periods, regulator follow-up, litigation risk, and any legal hold. This is the row most worth asking counsel about, because it is the one where deleting on schedule can be the wrong move. |
| Backup and restore-test records | Twelve to twenty-four months | AICPA TSC A1.2 and A1.3; Annex A 8.13. No named period. | Showing restores were tested through the period rather than once. |
| Vulnerability scan and remediation records | Twelve months minimum; PCI-scope entities per their own requirement | PCI DSS Requirement 11 where in scope; Annex A 8.8; NIST SP 800-40 as guidance. | Whether you can evidence remediation within your stated service levels for the whole period, not just current state. |
| Financial-reporting-relevant system logs | As your record-retention policy and auditor require, frequently seven years | Sarbanes-Oxley Act record-retention provisions and the audit-documentation rules behind PCAOB AS 2201, where the systems are in scope of a financial-statement audit. | Your finance leadership and external auditor. These periods come from record-retention law and audit standards, not from security frameworks. |
| Logs containing personal data, considered as a category | The shortest period that meets a stated purpose | GDPR Article 5(1)(e) storage limitation — a legal requirement that pushes in the opposite direction from every other row. | Your documented purpose and lawful basis. Security monitoring is a legitimate purpose; indefinite retention because storage is cheap is not. |
The GDPR tension, stated plainly
Every other row in the table above argues for keeping logs longer. GDPR Article 5(1)(e) argues for keeping them no longer than necessary for the purpose. Both are real, and the resolution is not to pick a side — it is to write down the purpose and derive the period from it.
Security logs routinely contain personal data: usernames, internet-protocol addresses, device identifiers, and sometimes far more in request bodies. That makes retention a processing decision. The defensible position is a documented retention schedule that names, per log type, the purpose, the period, and the reasoning — which is also exactly what an auditor wants and what Annex A 8.15 asks for. One artifact satisfies both pressures.
- Name the purpose per log type. Detecting and investigating security incidents is a purpose. Keeping data in case it is useful is not.
- Derive the period from the purpose, then say so in the schedule. A twelve-month period justified by incident-lookback need is defensible; twelve months justified by nothing is harder.
- Minimise at ingestion rather than at deletion. Not logging a field you do not need removes the tension entirely, and reduces cost.
- Treat requests to erase personal data from security logs as a question for your data-protection owner, not a unilateral engineering decision — there are recognised grounds on both sides, and this page does not resolve them.
- Keep the schedule and the actual platform configuration in agreement. A policy saying twelve months against a bucket lifecycle rule saying thirty days is a finding in both directions.
- Where a legal hold or an open incident applies, suspend deletion and record that you did. Automated retention that quietly deletes evidence during an investigation is the worst version of this problem.
Which kind of authority each period carries
The reason retention advice is so contradictory is that people quote conventions as requirements. Label each one. Last verified 10 September 2026.
| Statement | Which kind of authority | What it does not mean |
|---|---|---|
| PCI DSS v4.0.1 Requirement 10.5.1: retain audit log history for at least twelve months, with at least the most recent three months immediately available for analysis. | Legal requirement in the contractual sense, for entities in scope through card-brand and acquirer agreements. | Does not apply outside cardholder-data scope, and does not set retention for your unrelated systems. It is the source most one-year conventions were copied from. |
| GDPR Article 5(1)(e): personal data kept no longer than necessary for the purposes for which it is processed. | Legal requirement where the Regulation applies to your processing. | Does not name a maximum period and does not forbid security logging. It requires that your period be derived from a stated purpose. |
| Sarbanes-Oxley record-retention provisions and audit-documentation rules behind PCAOB AS 2201. | Legal requirement for issuers and their auditors, for records within scope of a financial-statement audit. | Not a general security-log rule, and not applicable to a private company with no issuer obligations. The seven-year figure comes from here and is routinely misapplied to everything. |
| NIST SP 800-92 log-management guidance and NIST SP 800-53 Rev. 5 AU-11 audit-record retention. | Regulatory and technical guidance; AU-11 is binding where the control baseline is imposed, such as under a federal contract or FedRAMP. | AU-11 names no universal number even where it binds — it requires a defined period consistent with your record-retention policy. |
| ISO/IEC 27001:2022 Annex A 8.15 logging and AICPA TSC CC7.2. | Certification and attestation criteria, applying because you seek certification or a report. | Neither names a retention period. You are audited against the period you defined, which makes writing it down the actual control. |
| Twelve months archived with ninety days immediately searchable, as a general baseline. | ShipReady Metrics recommendation, and common industry best practice. | Not a legal requirement outside PCI scope. It is a convention that covers a typical audit period and a realistic incident lookback at manageable cost. |
| Retain change, deployment and pipeline records for the full audit period plus one. | ShipReady Metrics recommendation. | Not named anywhere. It exists because platform defaults for these records are short and their loss destroys the change-management population, which is the hardest evidence to reconstruct. |
| Write a per-log-type retention schedule naming purpose, period, and reasoning. | ShipReady Metrics recommendation, and what Annex A 8.15 and GDPR accountability both effectively ask for. | Not a legal determination. It is the single artifact that answers both the auditor's question and the data-protection one. |
Checklist
A question list for retention. Not a determination of YOUR obligations and not a determination that any regime applies to you. Last verified 10 September 2026. Not legal advice.
- Is there a written retention schedule naming, per log type, the purpose, the period, and the reasoning?
- Does the configured retention on each platform actually match that schedule — checked, not assumed?
- Does retention on every log type cover the full audit period we intend to be assessed over, plus lookback?
- Are pipeline logs, deployment history, and build artifacts covered, given their defaults are usually the shortest?
- Do we distinguish archival retention from hot searchability, and is the searchable window long enough to investigate without a restore?
- If we are in PCI scope, do we meet twelve months retained with three months immediately available?
- For logs containing personal data, is the period derived from a stated purpose rather than from convenience?
- Do we minimise personal data at ingestion, so we are not retaining fields we never needed?
- Can we suspend automated deletion for a legal hold or an open incident, and do we record that we did?
- Are incident records and preserved incident evidence on their own retention footing, separate from routine log retention?
- Do we know the retention on our vendors' logs, where they hold records we would need in an investigation?
- Is there an owner for the schedule, and a review date?
What to do now
Ordered so the cheapest correction of the most common gap comes first. None of these steps determines YOUR obligations or files anything.
- Inventory the actual configured retention on every log source today. The gap between assumed and configured is nearly always the finding.
- Fix the short defaults first — pipeline logs, container logs, and platform audit trails whose defaults are measured in days.
- Set the baseline to twelve months archived with ninety days searchable, then adjust per row where a named requirement or a cost reality says otherwise.
- Extend change and deployment record retention past your audit period, since that population is the hardest evidence to reconstruct.
- Write the retention schedule with purpose, period, and reasoning per log type. One table does the compliance and data-protection work at once.
- Reduce what you log where fields are personal data you never query. Minimising at ingestion is cheaper and safer than deleting later.
- Build the hold mechanism: a documented way to suspend deletion for an incident or a legal hold, with the suspension recorded.
- Ask counsel specifically about incident-record retention and about erasure requests touching security logs. Those two are genuinely legal questions.
- Re-verify the cited periods against the primary sources annually and record the date. Ours says 10 September 2026.
Where this shows up in ShipReady Metrics
Only shipped behaviour is described here. This product is not a log-management platform. It does not store your security logs, does not extend your retention, does not archive your audit trails, and does not delete anything in your environment.
The obligation map lists frameworks your organisation marked in-scope, which is where retention-relevant expectations surface as flags rather than as configuration. That mark is your organisation's statement, not a legal opinion that a framework applies.
The GitHub App is read-only across Contents, Metadata, Pull requests, Actions, Administration, the Dependabot, code-scanning and secret-scanning alert feeds, and organisation Members. It reads what those endpoints expose while they expose it — it does not extend GitHub's own retention, and once a record ages out on the platform it is gone from the source too. The same read-only posture applies to GitLab findings ingest.
If you already have a session: signed-in app → Compliance holds evidence collection for control-mapped artifacts across starter control subsets, and evidence review, where a named human accepting a manual row renders it met and rejecting it renders it a gap, with a timestamp. Your retention schedule itself is a manual evidence row. That produces a timestamped compliance artifact — not a downloadable evidence binder, not a log archive, and not an auditor's opinion.
Primary sources (last verified 10 September 2026)
Each source is labelled by the kind of authority it carries.
PCI DSS v4.0.1 Requirement 10.5.1 binds entities in scope through card-brand and acquirer contracts and names twelve months with three immediately available. Regulation (EU) 2016/679 (GDPR) Article 5(1)(e) is a legal requirement and names no period. NIST SP 800-92 is guidance; NIST SP 800-53 Rev. 5 AU-11 is binding only where the baseline is imposed, and even then requires a defined rather than a fixed period. ISO/IEC 27001:2022 Annex A 8.15, 8.16 and 8.18 are certification requirements and name no period; AICPA Trust Services Criteria CC6, CC7 and CC8 are attestation criteria and name none either. Sarbanes-Oxley record-retention provisions and the audit-documentation rules behind PCAOB AS 2201 are the source of the seven-year figure, within their own scope. Not a complete list, and not legal advice.
The retention checklist page in this cluster covers artifacts beyond logs, the cloud checklists cover where each platform's records live, and the incident-management page covers preservation, which overrides routine retention.
Frequently asked questions
Is this legal advice?
No. It is an operational mapping of log types to defensible periods, with each source labelled by the kind of authority it carries. Whether PCI DSS, GDPR, a sector regime, or a record-retention statute reaches your organisation is a question for counsel and your data-protection owner. This page does not determine YOUR retention obligations and does not file anything with an auditor.
Does SOC 2 or ISO/IEC 27001 require one year of logs?
Neither names a period. The AICPA criteria and ISO/IEC 27001:2022 Annex A 8.15 require that logging be appropriate and that retention be defined; you are then audited against the period you defined. The one-year convention is largely inherited from PCI DSS Requirement 10.5.1, which does name twelve months for entities in cardholder-data scope.
Is longer retention always safer?
No. Where logs contain personal data, GDPR Article 5(1)(e) requires that you keep them no longer than necessary for a stated purpose, so indefinite retention creates a data-protection exposure rather than extra safety. It also raises cost and widens the blast radius if the log store itself is compromised. Derive the period from a purpose and write the reasoning down.
What gets lost most often?
Pipeline and deployment records. Their platform defaults are frequently the shortest of anything you rely on, and they carry the change-management population — the artifact that is hardest to reconstruct after the fact. Container logs on ephemeral hosts are a close second, which is why incident response has to export them before rebuilding.
Does ShipReady Metrics retain our logs for us?
No. It is not a log-management platform: it does not store your security logs, extend your retention, or archive audit trails. Connectors read what the source exposes while the source still exposes it, so platform retention still governs. Your retention schedule is handled as a manual evidence row, where a named human accepting it renders it met with a timestamp.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.