10.5 Audit log retention: requirements and evidence

What PCI DSS 10.5.1 asks for audit log retention

If you are the compliance lead or engineer who must prove that logs exist for a full year, Requirement 10.5.1 asks for at least 12 months of audit log history, with at least the most recent three months immediately available for analysis. The requirement is the only sub-requirement under Requirement 10.5, so the work is narrow but unforgiving: the retention period must be configured, provable and actually met on every system whose logs fall in scope. The reason is practical. When a breach or payment fraud is investigated, the forensic team often needs to reconstruct activity that happened months earlier, and a log that was rotated away after a few weeks cannot answer that question no matter how well the rest of the program runs.

The requirement describes two tiers of storage. The first tier is the hot store, where the last three months of history must be searchable without restoring anything from backup, so analysts can query it during an active incident. The second tier is the longer archive that brings the total to at least twelve months. Assessors usually test this by examining the retention policy, the configuration that enforces it on each log source, and the logs themselves to confirm that older entries really are present. The Self-Assessment Questionnaire D for Service Providers lists these expected testing steps, and it is worth reading alongside your own configuration review.

Retention is usually the hardest part of 10.5.1 for three reasons. Logs are spread across operating systems, databases, firewalls, cloud control planes and applications, each with its own rotation settings, so one policy rarely maps cleanly to every source. The hot tier fills up faster than teams expect, and a quiet rollover can silently drop the three-month window. Finally, many organizations have a written retention policy that does not match what their systems do. Requirement 5.3.4 ties anti-malware audit logs to the same retention period, so those logs need to be covered too. Confirm with your assessor which systems fall in scope and whether the 12-month test is applied per source or to the aggregated store.

Which logs and systems the 12-month rule covers

Requirement 10.5.1 applies to audit logs from systems in scope for PCI DSS, so the retention work depends on which systems and log sources you put in scope. The cards below cover the decisions that most change the storage volume, cost and evidence you need to keep.

Cardholder data environment audit logs

Audit logs from systems that store, process or transmit account data are the core of 10.5.1. Each of these log sources needs at least 12 months of history, with the most recent three months immediately available for analysis. Confirm with your assessor which hosts, databases, applications and network devices sit inside the CDE, because every additional in-scope source adds retention volume. Ask how the log tier separates recent searchable data from older archived data.

Connected systems that can affect the CDE

Systems outside the CDE that could affect its security, such as directory servers, jump hosts, build pipelines and management consoles, are often in scope for logging even when they hold no card data. Their logs can be a large share of total volume, so the scoping decision directly changes storage cost. Document why each connected system is in or out of scope, and confirm the boundary with your assessor during scoping rather than after the first assessment.

Security and administrative system logs

Logs from security tools and privileged administrative actions, including firewalls, authentication services, and changes made by administrators, usually carry the most investigative value. Retention for these sources runs on the same 12-month rule, and they often grow quickly when verbose debug output is enabled. Decide which event types are audit logs under 10.2 and which are operational noise, and retain the first group in full so the history stays complete and defensible.

Anti-malware logs under 5.3.4

Requirement 5.3.4 ties anti-malware audit logs to the retention period in 10.5.1, so endpoint protection and malware scanner logs must be kept for the same 12 months. Teams often forget this link because the logs sit in a security tool rather than in the CDE log pipeline. Check that your anti-malware console or SIEM forwards these logs to the retained store, and that the three-month immediate availability requirement also applies to them.

Logs held by third-party and cloud providers

When a cloud logging service, managed SIEM or service provider holds your audit logs, the retention obligation still applies to you, and you need evidence that the provider meets it. Ask the provider how long logs are kept by default, whether the retention period can be set to 12 months, and how quickly the most recent three months can be searched. Confirm how you would obtain the logs for an assessment, and document these arrangements in your responsibility matrix.

How an assessor tests 10.5.1 retention

This table walks through the three things an assessor examines for Requirement 10.5.1: the written retention policy, the configured retention settings, and the audit logs that actually exist. Read each row as a test step with the evidence to prepare, because the configured period and the history on disk or in the platform must both match the 12-month and three-month expectations. The main takeaway is that a policy alone does not pass; the assessor will trace it back to live settings and stored logs.

Test step	What the assessor samples or inspects	Evidence requested	Common findings
Examine the retention policy	Written policy and procedures that state the 12-month retention period and the three-month immediate availability requirement	Approved retention policy with version history, owner and review date	Policy states a shorter period or omits the hot-tier requirement
Examine log system configuration	Retention, rotation and archive settings on each in-scope log source, including the central log platform	Configuration exports or screenshots showing retention values and the date they were taken	Rotation deletes logs after fewer than 12 months, or retention differs between systems
Examine the history on disk or in the platform	Oldest available audit log entry on each in-scope system, compared with the current date	Query output or file listings showing the earliest timestamp retained	Earliest retained entry is less than 12 months old for a system in scope
Confirm the most recent three months are immediately available	Whether the last three months can be queried directly without restoring tapes, cold storage or external media	Saved search or query results returned in a reasonable time from the live log store	Only archived copies exist for recent months, forcing a manual restore before analysis
Sample archived logs	A selection of archived logs older than three months, restored to a test location	Restore records and the restored log files with readable, complete entries	Archives exist but cannot be restored, or restored files are truncated or unreadable
Check related anti-malware log retention	Anti-malware logs on in-scope systems, which Requirement 5.3.4 ties to the 10.5.1 period	Anti-malware log history and the retention setting applied to it	Anti-malware logs are purged on a shorter cycle than other audit logs
Review deletion and exception handling	Any purge jobs, manual deletions or storage changes that removed audit logs before the period ended	Change records, approvals and the reason for each deletion	Undocumented purges, or storage migrations that dropped history
Interview log administrators	Whether staff can explain the retention settings, where archives sit and how a restore is requested	Interview notes and the runbook used for restores	Staff cannot describe the restore path or disagree with the documented period

How to implement 10.5.1 in sequence

This sequence takes an organization from an agreed list of audit log sources to a retention setup that keeps at least 12 months of history, with the most recent three months immediately available for analysis, and proves it works through queries and a restore test. Each step ends with a record the assessor can examine.

Confirm the scoped log sources
Start by listing every system component that generates audit logs in or connected to the cardholder data environment, using the scope your assessor has accepted. Your team owns this list, and your implementation partner or internal engineers can draft it from the network diagram, asset inventory and data-flow records. Include applications, databases, operating systems, network devices, cloud control planes and security tools such as anti-malware, since Requirement 5.3.4 ties those logs to the same retention period. The step is complete when you hold a signed source inventory that names each log source, its owner and where its logs are sent today.
Document the retention policy
Write a retention policy record that states the 12-month minimum history for audit logs, the requirement that at least the most recent three months are immediately available for analysis, and the source-by-source exceptions your inventory revealed. Name the role that approves changes to the policy and the systems that enforce it. Confirm the wording with your assessor before you rely on it, because they will examine the policy alongside the configurations. The output is an approved retention policy record with a version number and approval date.
Configure each source and the central store
For each source in the inventory, enable audit logging at the level your Requirement 10.2 design calls for, and forward the events to the central log store. Apply the retention settings in each platform's own configuration, for example the logging path and audit scope in Nextcloud's admin_audit app, the audit devices in OpenBao, or the log destinations in your other systems. Where a platform cannot hold logs for the full period, route them to the central store and document that choice. The output is a configuration export for every source and a central store configuration record showing the retention period applied. Confirm each platform's options in its own documentation before you commit to a setting.
Set up hot and archive tiers
Split retention into a hot tier that holds at least the most recent three months and is queryable by your analysts, and an archive tier that holds the remaining history up to the 12-month minimum. Define how logs move from hot to archive, who may read each tier, and how archived data is protected from modification. Backup tools can support the archive tier. Bareos, for example, keeps a catalog of backed-up files and can restore from a point in time, and restic can verify backup data integrity with its check command. Confirm the tooling against your storage design. The output is a tier design record and a tiering job configuration export.
Test that the most recent three months can be queried
Run queries against the hot tier for dates across the most recent three months, using the same tools your analysts will use during log review. Record the query, the time range, the source and the result, and confirm that the response is immediate for the purposes of analysis. Repeat the test for each log source in the inventory and document any gaps. Your assessor will likely ask to see these results alongside the audit log history. The output is a query test report with dated entries for every source.
Run a restore test from archive
Select a sample of logs from the archive tier that are older than three months but within the 12-month window, restore them to a test location, and confirm that the records are complete and readable. Compare the restored data against the original hash or backup catalog where your tooling supports it. Document who ran the test, which logs were selected, the date, and the outcome, including any failed restores and how you fixed them. The output is a restore test report signed by the owner of the archive tier.
Set up recurring checks
Schedule recurring checks that confirm retention settings have not changed, that the 12-month history exists for every source, that the most recent three months remain queryable, and that archive restores still work. Assign an owner for each check and define the evidence each one leaves behind, such as an automated report or a dated checklist. Review the results on the cadence your own policy sets, and escalate failures to the person who approves policy changes. Confirm with your assessor which evidence they expect to see for the audit period. The output is a recurring check schedule and a log of completed check records.

Evidence that passes a retention review

An assessor testing Requirement 10.5.1 looks for proof that retention is defined, configured, and actually met across every log source. The artifacts below work together: the policy states the intent, the configuration shows the settings, and the storage, query and restore records show the logs exist and can be used. Keep each one dated and refreshed on a schedule so it reflects the environment at assessment time.

Written retention policy

The policy states the retention period, the three-month immediately available window, which log sources it covers, and who owns each one. It should also name the systems that hold audit logs, including any central log platform and archive tier. Check that the policy matches what the configuration exports actually show. A policy that promises 12 months while one source keeps 90 days will fail review. Record the approval date and review cycle on the document itself.

Configuration exports per log source

Export the retention settings from each log source, such as the Nextcloud admin_audit output in audit.log, OpenBao audit devices, and the central log store. Each export should show the retention value and the file or index it applies to. Schedule the exports and store them with timestamps so the record reflects the current setting, not last year's. Note any source where retention is set by a process outside the platform, such as a logrotate rule, and export that rule too.

Storage and index reports

Storage or index reports show the oldest retained event date for each source and confirm that roughly twelve months of history is present. Pair this with a count of events in the most recent three months, which is the hot window that must be immediately available for analysis. Generate these reports on a fixed schedule and keep the outputs. A gap in the oldest date is the most common sign that rotation or archiving removed history earlier than the policy allows.

Hot-tier query records

Keep records of queries run against the most recent three months to show the logs can be searched without restoring archived data. Save the query text, the time range, the user, and the result count. Run representative queries, such as failed logins or administrator actions, on a regular cadence rather than only before an audit. If a query against the hot tier takes so long that analysts cannot use it, confirm the hot window is truly immediate before relying on it.

Restore test records

Archived audit logs must come back intact when an assessor or incident responder asks for them. Record restore tests that retrieve logs from the older portion of the retention period, including the date range requested, the restore duration, and a check that the restored records match the originals. For backup-based archives, tools such as Bareos can restore files from a chosen date, and restic check with --read-data-subset can confirm stored data is unmodified. Document any failures and the fix applied.

Deletion and rotation logs

Deletion and rotation logs prove that data was removed only after the retention period ended. Keep a record of each purge or rotation job with its run time, the date range affected, and the job owner. Make sure no deletion removes logs younger than twelve months, and that the retention clock is not reset by a configuration change. Dated change records for retention settings should sit beside these logs, so an assessor can match each change to the process that caused it.

What meeting 10.5.1 costs in money and effort

This table compares the main cost components of keeping 12 months of audit log history, with three months immediately available. Read each row for who is paid, whether the cost is one-time or recurring, what pushes it up, and what to request in a written quote. No figures are given because none were supplied for this requirement, so use the questions in each row to build a comparable quote.

Cost component	One-time or recurring	What drives it up and how to keep it down
Storage or log platform licenses	Recurring	Driven by daily log volume, retention length and the number of in-scope sources. Keep it down by limiting sources to the cardholder data environment and security systems, and by using self-hosted open-source platforms that remove per-volume license fees. Ask for licensing based on volume and retention in writing.
Engineering time to configure retention tiers	One-time, with occasional rework	Rises with the number of log sources, each with its own format and retention setting. Keep it down by defining one retention policy and applying it to a standard set of sources. Ask the implementer to list each source and its configuration step in the quote.
Hot storage for the most recent three months	Recurring	The three-month immediate-availability window is the costliest tier because it must be searchable. Drivers are log volume and query performance needs. Keep it down by sizing hot storage to the three-month window only and moving older history to lower-cost archive tiers. Confirm the search speed you need with your QSA.
Archive storage for the full 12-month history	Recurring	Grows with total log volume and the number of sources kept. Keep it down with compression, tiered storage and deletion once the 12-month period ends. Confirm with the QSA that the retained history is complete and not partial for each in-scope system.
Evidence upkeep	Recurring	Covers retention policies, configuration exports and sample log extracts kept current for assessors. Drivers are the number of sources and how often configurations change. Keep it down by automating configuration exports and storing them with version history. Ask which artifacts the QSA expects.
Restore and retrieval testing	Recurring	Restore tests prove archived logs can be read back. Drivers are how often tests run and how many sources are sampled. Keep it down by scripting a repeatable test on a fixed schedule, and document results. Ask the QSA how many restore tests they will expect to see.
External review or consultant support	One-time for readiness, optional recurring	Paid for a gap check against 10.5.1 and help with evidence packs. Drivers are scope size and the team's prior experience. Keep it down by limiting consultant work to readiness review rather than ongoing operation. Consulting must stay independent of the assessment, so confirm the QSA is a separate firm.
Assessor sampling time	Recurring, once per assessment cycle	The QSA samples retention settings and log history during the assessment. Drivers are number of sources, the complexity of the environment and the quality of evidence provided. Keep it down by preparing a clear index of retention settings and history for each in-scope source. Ask the QSA for their estimated sampling effort in writing before the assessment begins.

Who does what: your team, a partner and the assessor

Your organization owns Requirement 10.5 in full. Assessors expect the retention decision to come from you, documented in a policy that states how long audit logs are kept, which systems feed the retention store, and who approves exceptions. Your team also owns the configuration in production and the evidence that proves it works over time.

Retention policy: Set the minimum retention period and the period during which logs must be immediately available, then assign an owner who reviews it on a schedule you define.
Scope of log sources: Maintain the list of systems that generate audit logs in or connected to the cardholder data environment so none are missed by retention.
Operational configuration: Keep the settings for log rotation, archive and search tiers under change control, with named approvers.
Ongoing evidence: Retain configuration exports, retention reports and records of any log gaps or exceptions, and be able to show them for the full period.
Access to the logs: Decide who can search and export archived logs, and record those accesses.

Before engaging anyone, confirm that you can produce the policy, the configuration and a sample of stored logs from the past year without relying on a single administrator's memory.

How self-hosted open-source tools support retention evidence

Requirement 10.5.1 is met by the organization's retention configuration and the logs it keeps, not by any single product. The four tools below each generate or protect a different kind of record that an assessor may examine when testing 12 months of retained history and three months of immediate availability.

Nextcloud admin_audit logs

The admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. For 10.5, the retained file is the evidence, so the operator must confirm how the log is rotated, how long rotated copies are kept and whether the 12-month history and three-month online window are met. Confirm that the log path sits on storage covered by the retention policy and that the logs are copied to a central location before local rotation removes them. Rotation and retention are not set by the app alone.

OpenBao audit device logs

OpenBao audit devices record a detailed JSON log of every API request and response, including errors, with most sensitive values hashed using HMAC-SHA256. This gives an assessor a complete record of secrets access over time. The operator must decide where each audit device writes, how the JSON files are shipped to retained storage and how long they are kept, then test that a log from twelve months earlier can still be read and searched within the online window.

Bareos archive job records

Bareos is licensed under AGPL-3.0-only. Its Director schedules backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, which shows what was archived and when. That catalog supports evidence that retained data exists and can be restored. Confirm that the catalog itself is backed up, that job retention settings match the 12-month requirement, and that archived audit logs are included in the job definitions rather than assumed to be covered.

restic archive integrity checks

restic is licensed under BSD-2-Clause. Its check command verifies the structural consistency of snapshots, trees and pack files. Adding --read-data or --read-data-subset reads pack files back to confirm the stored data has not been modified. For retained audit logs, this supports a claim that archived records are intact at the time of the check. Operators should confirm check frequency, keep the check output as a record, and understand that a passing check does not prove that every log event was captured in the first place.

Where retention programs usually fall short

The most common failure under Requirement 10.5 is a gap between what the policy says and what the systems actually keep. A retention policy may state 12 months, while one source, such as a SaaS admin console, a container runtime or a network device, rolls its own logs over at 90 days. An assessor will test the systems, not the policy text, so every log source in scope needs its own retention setting confirmed and recorded. Export the configuration from each platform, compare it to the 12-month requirement, and keep the exports as evidence. Where a vendor cannot store that long natively, the fix is to forward logs to a central store with the required retention, then document that forwarding as the retention mechanism.

The second gap is hot storage that quietly expires the most recent three months. Requirement 10.5.1 expects at least the most recent three months to be immediately available for analysis, which is different from being archived somewhere that takes a restore job to reach. Many teams move older data to cold object storage on a lifecycle rule and never check whether the rule also deletes or demotes recent data. Confirm the index or hot tier retention in the SIEM or log platform, and test a query against a log from roughly 90 days ago with the time to return results recorded. Keep the query output and the lifecycle policy as evidence. Anti-malware logs also belong in this scope, because Requirement 5.3.4 ties them to the same retention period, and they are often sent to a separate endpoint console with shorter defaults.

How much work is 10.5.1 and can we do it in-house?

How much does meeting requirement 10.5.1 cost?

No single price applies, because the cost depends on how many systems generate audit logs, where those logs are stored today, and how much of the retention setup already exists. Costs fall into three groups: internal staff time for policy and evidence work, platform engineering time to configure retention and storage, and any external fees for an implementation partner or a Qualified Security Assessor. Storage is usually the recurring item, since twelve months of history must stay on disk or in an archive, with the most recent three months searchable. Ask any provider for a written scope that lists each log source, the retention store, the expected storage growth and the assumptions behind the estimate. DeployOpen does not publish prices and provides a quote from that written scope.

How long does 10.5.1 implementation take?

The timeline depends mainly on the number of log sources, whether logs already flow to a central store, and how many retention settings must be changed by hand. A small environment with one central log platform is far simpler than a payment estate with dozens of applications, databases, network devices and cloud services, each with its own log configuration. Existing tooling also matters: if logs are already forwarded and indexed, the work is mostly verification and documentation. Confirm the duration in a written scope that names the systems in the cardholder data environment, the deliverables and the dates each party must meet before work starts.

Can our in-house team meet 10.5.1 without outside help?

Many organizations can do this in-house if they have engineers who understand their logging pipeline and a compliance owner who can read the standard's testing expectations. The main risks are gaps in coverage (a source that quietly keeps only thirty days) and weak evidence (retention settings that cannot be shown to an assessor). Before deciding, check whether your team has time to configure every source, test that history is complete, and produce retention policies and configuration exports on a schedule. An implementation partner can take on that build and documentation work, while your own team keeps ownership of the controls. The assessor still tests the result independently.

What roles does 10.5.1 need from our team?

Three roles usually carry the work. A policy owner defines the retention period, the searchable window and the exceptions, and approves them. A platform engineer configures each log source, the central store, archive tiers and access controls so that history is kept for at least twelve months and the latest three months remain immediately available. An evidence owner collects retention policies, configuration exports, sample queries that show old logs can be retrieved and records of periodic checks. One person can hold more than one role in a small team, but each role needs a named owner and a backup.

Does DeployOpen issue the PCI DSS report for 10.5.1?

No. DeployOpen plans, implements and documents the systems and evidence for requirement 10.5.1, but only an independent assessor issues a validation result. For most organizations that is a Qualified Security Assessor completing a Report on Compliance, or a Self-Assessment Questionnaire with an Attestation of Compliance where the entity's eligibility allows it. The organization owns its controls and the attestation decision. The assessor decides whether the evidence is sufficient, so ask your assessor early which retention evidence they expect to examine.

Do open-source logging tools remove the license cost for 10.5.1?

Open-source platforms remove per-seat or per-volume license fees for the software itself, but they do not remove the cost of running them. You still pay for infrastructure, storage for twelve months of logs, configuration, testing, backups, upgrades and staff time. Some sources, such as an application audit log or a secrets manager audit device, write their own files that must be forwarded and retained, so each source adds work. Check the license of each component before you rely on it, and confirm with the vendor whether any feature you need is part of the open-source edition. Your written scope should show which costs are one-time and which recur each year.

How DeployOpen scopes and prepares 10.5.1 evidence

DeployOpen works on 10.5 Audit log retention as a fixed-scope implementation effort inside your own infrastructure. We set up log retention and immediate-access storage for the systems in your cardholder data environment, then prepare the evidence an assessor will examine. Your organization owns the requirement, and a QSA or other independent assessor decides whether it is met.

How we scope

Agree in writing which systems in the cardholder data environment generate audit logs that fall under 10.5.1.
Record the retention period, the three-month immediate-access window and the owner of each log source in the scope document.
Confirm which log sources feed anti-malware logging tied to Requirement 5.3.4, so retention covers them too.

How we build

Configure audit log history so at least 12 months are retained and the most recent three months stay immediately searchable.
Set up open-source log sources such as the Nextcloud admin_audit app, OpenBao audit devices and backup catalogs where they apply in scope.
Test that a sample of older logs can be retrieved and that the configured retention settings match the written policy.

How we hand over

Document the retention policy, configuration settings and storage locations in a form an assessor can examine directly.
Provide the audit log history and configuration exports that show retention in practice, labeled by system and date range.
Walk your team through restoring logs and confirming retention, so the evidence can be reproduced after handover.

How we support

Ask for a quote that lists the in-scope systems, retention storage and the handover deliverables before work starts.
Ongoing support, upgrades and checks of retention settings are available as a retainer after handover.
Confirm with your QSA which evidence format they accept for 10.5.1 before the assessment begins.

10.5 Audit log retention