Log Retention Schedule Template: Periods and Legal Basis

When an investigator asks how long a particular log is kept, and why, most organisations can only point to a platform default. Regulators increasingly expect a written answer per source: the EU DORA ICT risk management standard, Delegated Regulation (EU) 2024/1774 Article 12, requires financial entities to identify the retention period of their logs and to set it with regard to business and security objectives, the reason the event is logged and the ICT risk assessment, and the NIS2 Implementing Regulation (EU) 2024/2690 requires logs to be kept and backed up for a "predefined period". This template is that schedule: one row per log source with its searchable and retrievable periods, legal basis, storage tier, location, owner and disposal method, plus the rules for holds, exceptions and review. It is for SOC leads, security engineers, records managers and privacy teams. It does not repeat retention theory or the full list of regulatory periods: those are in the Log Management and Retention Guide and the Log Retention Requirements Map.

How to use this template

Replace text in square brackets, such as [Organisation], [SIEM] and [13 months], with your own values. "Must" is mandatory; "should" may be skipped with a recorded reason.
Every period in this template is illustrative. Take the governing minimum for each source from the Requirements Map and your legal counsel, then add your detection and investigation needs on top.
Fill one row per log source, not per platform. A cloud tenant may produce four sources (control plane, data access, identity, network flow) with different periods.
Record two periods per row: searchable (queryable now in the SIEM or log platform) and retrievable (can be restored for an investigation, possibly with preparation). Several rules set these separately.
Keep the schedule in a spreadsheet or GRC tool with version history. Section 5 lists the columns; section 6 gives worked rows.

1. Purpose

This schedule sets how long [Organisation] keeps each category of security and audit log, in which storage tier and location, on what legal or business basis, who owns it and how it is disposed of, so that:

Logs needed to detect and investigate incidents exist for long enough to cover realistic detection delays.
Statutory, regulatory and contractual minimums are met and can be evidenced.
Logs containing personal data are not kept longer than necessary, in line with the storage limitation principle in GDPR Article 5(1)(e) and equivalent laws.

2. Scope

The schedule covers logs generated by or for [Organisation] across on-premises, cloud, SaaS, OT and managed service environments, including logs of activity by human users and by non-human identities such as service accounts, API keys, workload identities and AI agents. Business records that happen to be stored as logs (for example trade audit trails or communications archives) are covered where they are security relevant, and must also follow the [Records retention schedule]. The format and content of logs are set by the Logging and Monitoring Policy Template; this schedule sets only retention.

3. Roles and responsibilities

Schedule owner ([Head of Security Operations]): maintains this schedule, approves changes and reports compliance.
Source owner: the system or platform owner for each row; ensures the source is configured to forward or export and that platform-side retention matches the row.
[Legal counsel] and [Records manager]: confirm the legal basis and statutory minimum for each row; issue and release legal holds.
[Data Protection Officer]: confirms the personal data justification and maximum period for rows containing personal data.
[Platform engineering]: implements tiering, immutability, deletion jobs and capacity planning.

4. Retention rules

Baseline: unless a row states otherwise, security logs must be searchable for at least [6] months and retrievable for at least [13] months. The UK NCSC recommends holding logs that answer your incident questions for a minimum of six months; US OMB M-26-14 asks federal agencies for six months searchable and one year retrievable; the Australian ISM control ISM-1988 asks for event logs to be retained in a searchable manner for at least 12 months.
Longest rule wins for the minimum: where several rules apply to one source, the row takes the longest minimum and records every basis.
Necessity sets the maximum: rows containing personal data must state a maximum period and the reason it is needed. Do not keep logs indefinitely "just in case".
Location: rows subject to a localisation rule must state the jurisdiction. India's CERT-In Directions of 28 April 2022 require logs of all ICT systems to be kept for a rolling 180 days within Indian jurisdiction.
Integrity: logs in every tier must be protected from tampering, deletion and unauthorised access, as DORA RTS Article 12(2)(d) requires of financial entities and ISM-1815 requires of Australian government systems. Rows marked "immutable" must use write-once or object-lock storage for the stated period.
Legal hold overrides deletion: a hold issued by [Legal counsel] suspends deletion for named sources and date ranges until released in writing. See the eDiscovery and Legal Hold Guide.
Disposal: at the end of the period logs must be deleted by an automated job, with deletion events logged and kept for [the life of the schedule plus 2 years].

5. Schedule columns

Column	What to enter
Row ID	LR-001 onwards; never reused
Log source	Specific source and log type, for example "Identity provider sign-in logs"
Systems in scope	Platforms, tenants, accounts or subscriptions producing it
Contains personal data?	Yes or no; data types (user names, IP addresses, device IDs)
Identity coverage	Human, non-human or both (service accounts, keys, agents)
Searchable period	Months in the hot tier
Retrievable period	Total months including cold or archive tier
Legal or business basis	Every rule or need that sets the period, with clause reference
Maximum period and justification	For personal data rows
Storage tier and platform	Hot: [SIEM]; warm: [data lake]; cold: [object storage archive]
Location	Region or jurisdiction
Immutable?	Yes or no; mechanism
Source-side retention	What the platform itself keeps, and any licence dependency
Owner	Named source owner
Disposal method	Automated deletion job, lifecycle rule or crypto-shred
Last verified	Date the actual retention was checked against the row

6. Retention schedule

Worked rows for a [mid-sized, EU and UK based, card-accepting] organisation. Periods are examples; replace them with your own after legal review.

ID	Log source	Searchable	Retrievable	Basis	Tier and location	Owner
LR-001	Identity provider sign-in and audit logs (users, service principals, workload identities)	[12] months	[24] months	Investigation of credential misuse; NCSC minimum; [DORA Art. 12 access control and identity events]	Hot SIEM, then [EU] archive; immutable	[IAM lead]
LR-002	Directory and privileged access logs (domain controllers, PAM sessions, vault access)	[12] months	[24] months	NIS2 IR Annex 3.2.3 privileged access; detection delay	Hot SIEM; session recordings in [PAM store]; immutable	[PAM owner]
LR-003	Cardholder data environment system and application logs	[3] months	[12] months	PCI DSS Requirement 10.5.1	Hot SIEM, then archive	[PCI owner]
LR-004	Cloud control plane logs (all accounts, subscriptions, projects)	[6] months	[24] months	Key and role misuse investigation; change management events	Hot SIEM; full copy in [org-level archive bucket], object lock	[Cloud platform lead]
LR-005	SaaS audit logs (email, collaboration, CRM, code repositories)	[6] months	[13] months	OAuth and token abuse investigation; source-side periods vary by licence	Exported to [SIEM] via API; archive	[SaaS owner]
LR-006	Endpoint detection and response telemetry	[30 to 90] days raw	[13] months for alerts and summaries	Volume; raw data needed mostly in the first weeks	EDR console; alerts to SIEM	[Endpoint lead]
LR-007	Firewall, proxy and DNS logs	[3] months	[13] months	NCSC priority category for external communications; NIS2 IR network traffic	Hot SIEM (filtered); full in archive	[Network lead]
LR-008	Network flow logs	[1] month	[6] months	Volume; scoping lateral movement	Data lake	[Network lead]
LR-009	CI/CD pipeline and secrets manager audit logs	[12] months	[24] months	Pipeline token and secret misuse investigation	Hot SIEM; immutable	[Platform engineering]
LR-010	AI agent tool-call and decision logs	[6] months	[13] months	Investigation of agent actions; data minimisation for prompt content	Agent platform, then archive; prompt text redacted after [30] days	[AI platform owner]
LR-011	Indian operations ICT system logs	[6] months	Rolling 180 days minimum, within India	CERT-In Directions, 28 April 2022	[India region]; no export of only copy	[India IT lead]
LR-012	Logging system health and log deletion events	[13] months	[Schedule life plus 2 years]	Evidence that logging worked; DORA Art. 12 detection of logging failures	Separate account from monitored systems	[SOC lead]
LR-013	Security risk assessment, access review and audit evidence records	Not applicable	[6] years	HIPAA 45 CFR 164.316(b)(2)(i) where applicable; ISO/IEC 27001 records	GRC tool	[GRC lead]

For per-platform source-side periods and licence dependencies behind LR-005, see the SaaS Audit Log Retention and Licensing Guide.

7. Exceptions

A source that cannot meet its row (for example a SaaS plan that keeps 90 days and has no export) must have an exception recorded with the gap, the compensating measure, the risk owner's acceptance and an expiry no later than [12] months. Exceptions are reviewed by the schedule owner each [quarter].

8. Compliance and monitoring

Monthly automated check that the oldest searchable event per source meets the row's searchable period.
Quarterly restore test of one archived source to confirm it is retrievable within [48] hours.
Alert when any source stops sending for more than [1 hour for identity, 24 hours for others].
Annual sample of deletion jobs to confirm data past its maximum period has gone.

9. Review and approval

The schedule is reviewed at least [annually], after any significant incident whose investigation lacked logs, when a new regulation applies, and when a source is added or retired. The NIS2 Implementing Regulation requires logging procedures to be reviewed and updated at regular intervals. Version [1.0], approved by [CISO] and [DPO] on [date], next review [date].

Implementation guidance

Building the schedule

Inventory sources: list every log source feeding or that should feed the SIEM, starting with identity, privileged access, cloud control planes and SaaS admin logs.
Find the governing rules: for each source, look up the applicable minimums in the Requirements Map and confirm with counsel. Where a rule only says "predefined period" (NIS2) or "establish the retention period" (DORA), record your reasoning: detection delay, investigation need and risk assessment.
Measure what you actually keep: check the oldest event per source today. Gaps between the schedule and reality are the first findings.
Cost the tiers: estimate daily volume per source and price hot, warm and cold storage. Volume-heavy sources (flow, EDR raw, proxy) usually move to cold storage first.
Configure and test: set lifecycle rules, object lock and deletion jobs in a test account, run a restore test, then apply to production. To roll back, disable the deletion job before anything else; lifecycle rules that delete data cannot be undone.
Approve and publish: sign-off by the CISO and DPO, then track exceptions.

Decisions by size

A small organisation can run three tiers in one platform and a dozen rows; the identity, cloud and SaaS rows matter most. A large or multi-jurisdiction organisation needs per-region rows, a localisation column, a separate immutable archive account and legal holds integrated with deletion jobs.

Measures

Percentage of sources whose actual retention meets the schedule (target 100%).
Percentage of identity sources, human and non-human, in the schedule and forwarding.
Restore test success rate and time to retrieve.
Open exceptions and exceptions past expiry.
Investigations in the last year that failed for lack of logs.

Common failure patterns

Platform default treated as policy: a SaaS or cloud source silently drops events after its default period because nobody exported them.
One period for everything: keeping flow logs as long as identity logs wastes budget; keeping identity logs as briefly as flow logs loses the evidence that matters most.
Machine identity logs missed: service principal sign-ins, secrets manager access and pipeline audit logs are left out. In the Codecov breach, the stolen material was CI secrets, so pipeline and key usage logs are what an investigation needs.
No maximum: logs with personal data kept forever, creating a privacy liability and a larger breach.
Archive never restored: the cold tier exists on paper but the first restore attempt is during an incident.

Framework mapping

Schedule element	NIST SP 800-53 Rev. 5	NIST CSF 2.0	Other
Retention periods (sections 4, 6)	AU-11, SI-12	PR.PS-04	DORA RTS Art. 12; NIS2 IR Annex 3.2.5; ISM-1988
Capacity and tiering	AU-4	PR.PS-04	NCSC: plan for storage roll-over
Protection and immutability	AU-9	PR.PS-04	ISM-1815; DORA Art. 12(2)(d)
Review and use of logs	AU-6	DE.CM-01	NIS2 IR Annex 3.2.7

Standards and references

This template is provided for guidance and must be adapted to your organisation. It summarises retention requirements and is not legal advice. Related NHI Mgmt Group resources: Log Management and Retention Guide · Log Retention Requirements Map · SaaS Audit Log Retention and Licensing Guide · CIS Control 8 Audit Log Management Guide

Log Retention Schedule Template: Sources, Periods, Legal Basis and Storage Tier