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 you keep each security evidence artifact?
Updated
Set retention per artifact, not per organisation. A few periods are fixed by law or contract — PCI DSS asks for 12 months of audit logs. Most are your own defensible choice, commonly 12 months plus the audit period. Not legal advice.
Retention checklist, last verified 10 September 2026 against PCI DSS v4.0.1 Requirement 10.5.1, ISO/IEC 27001:2022 (Clause 7.5 documented information and Annex A 8.15), the AICPA Trust Services Criteria, GDPR Article 5(1)(e) storage limitation, and the Sarbanes-Oxley Act record-retention provisions at 15 U.S.C. §7201 et seq. together with 18 U.S.C. §1520. Retention is one of the most jurisdiction-dependent questions in this cluster: employment records, personal data, and financial records carry local minimums and maximums that no vendor page can resolve for you. This page does not determine YOUR obligations, does not start a clock, and does not file with an auditor.
What this page is, and what it is not
Audience: a compliance lead, security engineer, or founder who needs a defensible retention answer per artifact rather than a single organisation-wide number. The output you want is a short table you can show an auditor: what the artifact is, who owns it, where it comes from, how long it is kept, and why that period.
This page is not legal advice. It does not determine YOUR obligations, does not decide which frameworks or statutes apply to you, does not start a clock, and does not file anything with an auditor or a regulator. Retention minimums that come from employment law, tax law, financial-reporting law, sector regulation, or data-protection law vary by jurisdiction and by the kind of record — settle those with counsel. Last verified 10 September 2026.
Two forces pull in opposite directions and both are real. Security and audit want longer retention so that a period can be reconstructed. Data-protection law wants the shortest period consistent with the purpose. Recording which force set each number, and why, is the whole point of the table below.
- Retention has three separate parts that teams often merge: how long the record exists, how long it is immediately queryable, and how long it is recoverable from cold storage. PCI DSS is explicit about the middle one.
- A retention period you cannot demonstrate is not a retention period. Prefer a platform retention setting or a lifecycle policy over a written intention.
- Deleting on schedule is as much a control as keeping. An over-retained personal-data export is a finding in a data-protection review even when it helps a security audit.
- Where a legal hold, litigation, or an open incident applies, retention stops being a schedule. Preservation overrides the routine period — see the incident-management page in this cluster.
The retention checklist
This table is the checklist artifact for this page. Copy the columns into your own record and fill in the owner names; there is nothing to download, and the value is in your names and your systems, not in ours. The retention column separates what a named requirement states from what we recommend as a defensible default. Where a row is jurisdiction-dependent, it says so. Last verified 10 September 2026. Not legal advice.
| Artifact | Typical owner | Source system | Retention | Driving requirement |
|---|---|---|---|---|
| Audit and access logs for in-scope systems | Security engineering | Cloud audit log service, identity provider, application log store | At least 12 months, with at least the most recent 3 months immediately available for analysis, where PCI DSS applies. Where it does not, 12 months plus the audit period is a common defensible default. | Legal requirement in the contractual sense — PCI DSS v4.0.1 Requirement 10.5.1, for entities in scope. Otherwise ShipReady Metrics recommendation, with ISO/IEC 27001:2022 Annex A 8.15 requiring logs be produced, kept, and protected without naming a period. |
| Access-review records and sign-offs | Security or IT operations | Identity provider reports, ticketing system, review spreadsheet of record | Retain the last 2 review cycles at minimum; 3 years is a common default so that a Type 2 report period and the prior year are both covered. | Best practice, plus attestation criteria: AICPA TSC CC6.2–CC6.3 require the review, not a retention period. Jurisdiction-dependent where reviews name employees and fall under local employment or personal-data rules. |
| Joiner, mover, and leaver records | People operations with IT | HR information system, identity provider, ticketing system | Follow the employment-record retention set by local law for the personnel file; keep the access-provisioning and deprovisioning artifact for at least the audit period plus one year. | Jurisdiction-dependent legal requirement — employment and personal-data law set the personnel-record period, which differs by country and sometimes by region. Counsel decides. The access artifact itself is best practice plus AICPA TSC CC6. |
| Change records: pull or merge requests, approvals, required checks | Engineering leadership | GitHub or GitLab, CI system | Keep for the life of the repository where practical; at minimum the audit period plus one year. Repository history normally satisfies this without a separate archive. | Best practice plus attestation criteria — AICPA TSC CC8.1 and ISO/IEC 27001:2022 Annex A 8.32 require controlled change, not a retention period. Longer where a financial-reporting audit reaches the system. |
| Deployment and release records | Platform or DevOps | CI/CD platform run history, release tags, deployment tooling | 12 months minimum; 3 years where a SOX ITGC scope applies to the system. | Jurisdiction-dependent legal requirement where SOX applies — 18 U.S.C. §1520 requires audit and review records be kept for 7 years for issuer audits, and PCAOB AS 2201 governs ITGC testing. Elsewhere best practice. |
| Vulnerability scan results and remediation records | Security engineering | Scanner, code-scanning and dependency-alert feeds, ticketing system | 12 months of scan history plus remediation records for the audit period. Keep exception and risk-acceptance records for as long as the exception is live, plus one year after closure. | Legal requirement in the contractual sense where PCI DSS v4.0.1 Requirements 6 and 11 apply. Otherwise best practice, with ISO/IEC 27001:2022 Annex A 8.8 requiring vulnerability management without naming a period. |
| Penetration test reports, attestation letters, and retest evidence | Security leadership | Testing provider deliverables, evidence repository | Keep the current report plus the prior one at minimum; 3 years is common because customers ask for a trend, not a snapshot. | Legal requirement in the contractual sense where PCI DSS v4.0.1 Requirement 11.4 applies. Otherwise best practice and customer contract terms. |
| Security training completion records and policy acknowledgements | People operations with security | Learning platform, HR system, policy tool | Retain the current period plus the prior 2 periods; 3 years is a common default. | Best practice plus ISO/IEC 27001:2022 Annex A 6.3 and PCI DSS v4.0.1 Requirement 12.6 where in scope, neither of which names a period. Jurisdiction-dependent where records identify employees. |
| Incident records, timelines, and post-incident reviews | Security or incident commander of record | Incident tooling, ticketing system, comms archive | 3 years is a common default. Where a statutory reporting regime applied to the incident, keep the submitted notifications and their supporting evidence for as long as counsel advises, which is often longer. | Jurisdiction-dependent legal requirement where a reporting regime applies. GDPR Article 33(5) requires documentation of all personal-data breaches without naming a period. Otherwise best practice. |
| Vendor assessments, contracts, and received certifications | Procurement with security | Contract repository, vendor management tool | Keep for the life of the relationship plus the contractual limitation period; 6 years after termination is a widely used default that counsel should confirm. | Jurisdiction-dependent legal requirement — contract and limitation periods are set by local law. Best practice for the assessment artifact, with AICPA TSC CC9.2 requiring the assessment. |
| Approved policies, risk assessments, and management review records | Compliance owner | Policy tool, ISMS documentation set | Keep every approved version for the life of the management system, and at minimum through the current certification cycle plus one. | Certification requirement — ISO/IEC 27001:2022 Clause 7.5 requires documented information be controlled, retained, and available; Clause 9.3 requires management review records. Not a statute unless a contract makes it one. |
| SBOMs and release manifests | Engineering leadership | Build pipeline artifact store, release registry | Keep one SBOM per released version for as long as that version is supported, plus the support tail. Where the EU Cyber Resilience Act applies, counsel will set a longer keep tied to Article 13. | Jurisdiction-dependent legal requirement where the CRA applies to a product with digital elements placed on the Union market. Otherwise best practice, with NTIA and CISA materials as guidance rather than law. |
Legal minimum, guidance, best practice, or our recommendation
Every number in the table above came from one of four places. Write down which one, next to the number, in your own record. A period whose origin nobody can state is the period that gets argued about in audit week — and the period a data-protection reviewer will ask you to justify. Last verified 10 September 2026. Not legal advice.
| Source of the number | Which kind of authority | How to treat it |
|---|---|---|
| PCI DSS v4.0.1 Requirement 10.5.1 — 12 months of audit log history, 3 months immediately available. | Legal requirement in the contractual sense, binding through card-brand and acquirer agreements for entities in scope. | Treat as a floor for in-scope systems, and record that it does not apply to systems outside cardholder-data scope. |
| 18 U.S.C. §1520 and the Sarbanes-Oxley Act record provisions at 15 U.S.C. §7201 et seq. | Legal requirement — statute, for issuers and their auditors, with a 7-year keep for audit and review workpapers and related records. | Scope it with counsel. It reaches ITGC evidence for in-scope systems, not every security artifact you hold. |
| GDPR Article 5(1)(e) storage limitation and Article 33(5) breach documentation. | Legal requirement — a regulation with direct effect where the processing is in scope. It sets a ceiling of necessity rather than a floor of months. | Use it to justify deleting, and to force a purpose statement next to every long retention period touching personal data. |
| ISO/IEC 27001:2022 Clause 7.5 and Annex A 8.15; AICPA Trust Services Criteria. | Certification requirement and attestation criteria. Both require that records exist, be controlled, and be available; neither names a number of months. | Do not cite them as the source of a period. Cite them as the reason the artifact must exist and be retrievable. |
| NIST SP 800-92 log-management guidance and NIST SP 800-53 Rev. 5 AU-11. | Regulatory and standards guidance. AU-11 is an organisation-defined period — the catalogue asks you to define it, it does not pick one. | Use as the reason you must have a defined period, not as the period itself. |
| 12 months plus the audit period, as a default where no requirement names a number. | ShipReady Metrics recommendation and common industry best practice. It covers a Type 2 report window with margin. | Adopt it consciously and record it as our recommendation, not as a legal minimum. |
Jurisdiction-dependent rows, and how to flag them
Three categories in the checklist above are jurisdiction-dependent often enough that a single number is misleading: employment and personnel records, personal data of any kind, and financial-reporting records. Rather than guessing, mark the row and route it.
- Add a jurisdiction column to your own copy of the table, and a flag for rows where the period is set outside security. Those rows get a named legal owner, not a security owner.
- Where you operate in multiple jurisdictions, record whether you apply the longest applicable period globally or a per-region period. Both are defensible; an unstated choice is not.
- Where a personal-data retention period and a security retention period conflict, record the conflict and the decision. A documented balancing decision is evidence of the reasoning; silence is not.
- Where an incident, a legal hold, or a regulatory inquiry is live, suspend deletion for the affected records and record the suspension and its scope. See the incident-management page in this cluster for preservation practice.
Checklist
A question list for the retention record you are building. Not a determination that any statute or framework applies to you. Last verified 10 September 2026. Not legal advice.
- Does every artifact in our evidence set have a stated retention period, or are some simply never deleted by default?
- For each period, can we name its source, and is it labelled as a legal minimum, guidance, best practice, or our own default?
- Which periods are enforced by a platform setting or lifecycle policy, and which exist only in a document?
- Which rows are jurisdiction-dependent, and does each of those have a named legal owner rather than a security owner?
- Where is personal data retained longer than the stated security purpose requires, and is that difference justified in writing?
- Is the immediately-queryable window distinct from the total retention window, and does the queryable window meet any in-scope requirement?
- Is there a documented way to suspend deletion for a legal hold or an open incident, and has it ever been tested?
- When was each period last reviewed, and who reviews them next?
What to do now
Ordered so that the highest-risk gaps close first. None of these steps is a legal determination, and none starts a clock or files anything with an auditor.
- Take the table above, add a jurisdiction column and an owner column, and fill in your systems. That filled table is the artifact an auditor and a data-protection reviewer both want.
- Confirm the in-scope legal minimums with counsel first — PCI DSS scope, SOX scope, sector regulation, employment records, and personal data. Do not set those numbers from a vendor page, including this one.
- Enforce each period in the platform rather than in prose: cloud log-retention settings, object-storage lifecycle rules, log-store index policies, identity-provider report exports on a schedule.
- Separate the immediately-available window from the archive window explicitly, and check that the queryable window meets any in-scope requirement such as PCI DSS v4.0.1 Requirement 10.5.1.
- Add a deletion side to the record. A retention schedule that only ever keeps is a data-protection finding waiting to happen.
- Write down the preservation override for incidents and legal holds, and name who can invoke it.
- Re-verify the cited requirements annually against the primary sources below, and record the date. Ours says 10 September 2026.
Where this shows up in ShipReady Metrics
Only shipped behaviour is described here. This product does not set your retention periods, does not enforce deletion in your systems, does not determine which statutes apply, and does not file anything with an auditor.
If you already have a session: signed-in app → Compliance holds evidence collection, which records control-mapped artifacts for 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. That is a timestamped compliance artifact — not a forensic chain of custody, not a downloadable evidence binder, and not a regulator filing pack.
The obligation map lists the frameworks your organisation marked in-scope. That mark is a scoping input you control, not a legal opinion that a framework applies, and not a retention determination. This product does not automatically retain your SOC 2, ISO/IEC 27001, or CRA technical documentation pack.
Where connectors are attached, the artifacts they surface live in their source systems and keep those systems' retention. The GitHub App is read-only and ingests Dependabot, code-scanning, and secret-scanning alerts as findings; it does not change your repository retention or export your audit pack.
Primary sources (last verified 10 September 2026)
Every retention claim above is taken from one of these, and each 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. ISO/IEC 27001:2022 Clause 7.5 and Annex A 8.15 are certification requirements that require control and availability of records without naming a period. The AICPA Trust Services Criteria are professional attestation criteria. GDPR Articles 5(1)(e) and 33(5) are legal requirements where the processing is in scope. The Sarbanes-Oxley Act at 15 U.S.C. §7201 et seq. and the records provision at 18 U.S.C. §1520 are statutes reaching issuers and their auditors. NIST SP 800-92 and NIST SP 800-53 Rev. 5 AU-11 are guidance that require an organisation-defined period rather than supplying one. Not a complete list of authorities, and not legal advice.
The log-retention page in this cluster goes deeper on log-type-by-log-type periods. The audit evidence repository page covers where retained evidence lives and how freshness is tracked.
Frequently asked questions
Is this legal advice?
No. It is an operational retention checklist with each period labelled by the kind of authority behind it. Retention minimums for employment records, personal data, financial records, and sector-regulated records vary by jurisdiction and by record type. Settle those with counsel on your facts; this page does not determine YOUR obligations.
Is there one retention period we can apply to everything?
You can adopt a single default, and many teams do, but you should not treat it as compliant by itself. In-scope requirements such as PCI DSS v4.0.1 Requirement 10.5.1 set a floor for particular records, storage-limitation obligations under GDPR Article 5(1)(e) set a ceiling of necessity for personal data, and employment and financial-record law sets periods you do not control. A single number hides all three.
How long should we keep security logs specifically?
Where PCI DSS applies, at least 12 months with the most recent three months immediately available for analysis. Where it does not, no framework named on this page picks a number: ISO/IEC 27001:2022 Annex A 8.15 and NIST SP 800-53 Rev. 5 AU-11 both require a defined period rather than supplying one. Twelve months plus the audit period is our recommended default, and the log-retention page in this cluster breaks it down by log type.
Can we delete evidence after an audit finishes?
Usually not immediately, and the decision is not only about the audit. The next audit period typically overlaps, customers ask for prior-period evidence, and any live legal hold, litigation, or open incident overrides the routine schedule. Where personal data is involved, the opposite pressure applies and keeping it without a stated purpose is its own exposure. Record the decision either way.
Does ShipReady Metrics enforce retention for us?
No. It records control-mapped artifacts for starter control subsets and lets a named human accept or reject manual evidence rows with a timestamp. It does not set retention in your cloud, source-control, identity, or log systems, does not delete anything on a schedule for you, and does not automatically retain your audit documentation pack. Enforcement belongs in the source platforms.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.