3.2 Account data storage minimization for PCI DSS

What PCI DSS 3.2 account data storage minimization requires

Requirement 3.2.1 asks for two things: documented data retention and disposal policies and procedures that cover every location of stored account data, and a process that verifies at least once every three months that stored account data past its defined retention period has been securely deleted or rendered unrecoverable. An assessor will expect both to exist, to match how the systems actually behave, and to leave evidence that the quarterly check ran. The risk behind the requirement is simple: account data nobody needs is still breach exposure. Every stored copy that outlives its purpose enlarges the cardholder data environment, adds to the systems an attacker can reach and extends the impact of a compromise. PCI DSS sets no fixed retention period. The standard's FAQ 1318 makes clear that the organization must define how long data is kept, and that the period must be limited to what legal, regulatory or business purposes require. Your job is to write those periods down with a justification for each data type, and to tie each one to a disposal method.

The policy is the easy part. The hard part is finding every copy. Account data often sits in places the original design never considered: database replicas, application logs and debug dumps, exports to spreadsheets, support ticket attachments, message queues, analytics warehouses, file shares and backup sets. Backups deserve particular attention, because a deletion in production does not remove the copies in older backup sets unless your backup design and retention settings account for them. Ask the backup owner how long each backup set is kept, how restores would reintroduce expired data, and whether the quarterly check covers backup media. If a third-party service provider, such as a cloud provider or SaaS vendor, stores account data for you, the SAQ D note to this requirement expects you to work with that provider to understand how it deletes all geographic copies. Get that answer in writing before the assessment, not during it.

Before your next assessment, build a data location inventory that lists each store, its owner, its retention period, its justification and its deletion method, then run one manual deletion check against a sample of expired records and keep the output as evidence. Confirm with your QSA how they expect the quarterly verification to be documented, since the standard does not prescribe a format. Open-source backup tools can help with the backup side of this work. Bareos, for example, keeps a catalog of backed-up files and runs verify jobs, and restic provides a check command that confirms repository consistency, but neither tool decides what expired data should be deleted. Confirm the exact deletion and retention behavior of any tool in your own environment before you rely on it as evidence.

Which stored account data and systems fall under 3.2.1

Requirement 3.2.1 applies to every location where stored account data sits, not only the primary payment database. The cards below cover the storage points that most often expand the retention and deletion work, and who usually owns each one.

Primary transaction databases

The production payment or order database is the obvious starting point, but it is rarely the only copy. Retention rules must define how long authorization and settlement records are kept, what the business and legal purpose is for each field, and how expired rows are purged. Application owners and database administrators usually own the purge jobs, while the compliance lead owns the retention schedule that drives them. Check whether soft-deleted rows still hold PAN.

Backups and archives

Backups and long-term archives often hold card data for far longer than production systems, and their deletion depends on backup rotation rather than a delete statement. Your retention policy must state how long backup copies persist and how expired data is removed or rendered unrecoverable within that cycle. Infrastructure or backup teams usually own the rotation settings, and they need documented proof that old restore points age out. Tools such as Bareos keep a catalog of backed-up files, which helps identify where copies exist.

Logs, exports and reports

Application logs, debug traces, CSV exports, support tickets and report files frequently capture PAN or other account data by accident. Each of these needs its own retention period and disposal method, because a database purge does not touch a file on an analyst's laptop. Ask engineering to inventory log sinks and export paths, and ask support teams where they store attachments. Ownership is often split across development, operations and customer support, so assign a single accountable owner for each source.

Analytics and data warehouse copies

Data warehouses, reporting replicas and machine learning feature stores usually copy transactional data on a schedule and keep the history indefinitely. Each copy is stored account data under 3.2.1 and needs the same retention rule as its source, applied on the warehouse's own deletion schedule. Data engineering teams usually own the pipelines, and the analytics owner should confirm whether PAN is needed at all or whether a truncated or tokenized value would serve the purpose.

Third-party and cloud-hosted storage

Storage held by processors, cloud providers, SaaS tools and managed service providers is still within your retention obligations. The SAQ D note to 3.2.1 says you must work with a cloud provider to understand how it deletes all geographic copies, including replicas and snapshots. Procurement and the contract owner should request written deletion commitments and evidence of how deletion is verified. Confirm these details with each provider, because the provider's own retention settings govern what you can promise.

Paper and removable media

Printed receipts, paper files, USB drives, tapes and laptop disks can hold account data outside any system the IT team manages. Each needs a defined retention period, a secure disposal method such as cross-cut shredding or certified media destruction, and a log of what was destroyed. Facilities, branch or store managers, and the individuals who handle these records usually own the disposal step, so the policy must reach them directly.

How an assessor tests 3.2.1 and what they ask to see

This table lists what a QSA examines for requirement 3.2.1, the evidence they request for each step, and the gaps that most often appear in assessments. Read it as a preparation checklist: each row is a test the assessor performs, so the evidence column shows what your team should have ready before fieldwork begins.

Test area	Evidence requested	Common findings
Retention and disposal policy review	Current retention and disposal policy, procedures, and the business, legal or regulatory reason recorded for each data type and period	Periods stated without justification, policy not updated after product or process changes, no owner named
Stored account data location mapping	Data inventory and data-flow diagrams covering databases, backups, logs, file shares, exports, and third-party or cloud copies	Backups, log files, or support exports missing from the inventory, unknown copies in test or analytics environments
Sampling of data past retention	Queries or reports showing records older than their retention period, and the deletion or expiry jobs that should have removed them	Sampled records still present past the defined period, deletion jobs that fail silently, exceptions with no approval
Quarterly verification records	Dated records of each check at least once every three months, the method used, results, and who reviewed and signed off	Gaps between checks, checks that only confirm a job ran rather than that data is gone, no follow-up on exceptions
Deletion and unrecoverability test	Test showing selected data is deleted from primary stores, backups, and replicas, and that restores do not bring it back	Data recoverable from backup snapshots or replicas after deletion, deleted rows still present in indexes or caches
Third-party storage review	Provider responsibility documentation and evidence the provider deletes all geographic copies on request or on schedule	No documented provider process, retention settings left at vendor defaults, copies in regions not covered by the review

How to set retention periods that survive an assessment

PCI DSS sets no minimum or maximum time for storing cardholder data, so the retention period for each data type has to come from a documented legal, regulatory or business purpose. The assessor will ask for the period and the reason behind it, so record both in the retention policy. For each data type (authorization records, settlement files, chargeback evidence, support tickets containing PAN, backup sets and log extracts), write the purpose, the governing rule or contract clause, the period, the owner who approved it, and the disposal method. Confirm the legal and contractual periods with your legal counsel and acquirers rather than assuming them, because a period that cannot be traced to a source is the first thing a QSA will challenge. Then check that each data store actually has a deletion job or procedure that enforces its period, and keep the evidence that the job ran.

The most common gap we see in readiness reviews is sensitive authentication data that reaches storage before authorization completes, such as data captured in a payment flow that is held in a queue, a log, a temporary file or a cache. Under Requirement 3.2.1 this case is now required, not a best practice, so it belongs in the retention policy with its own short period and a deletion trigger tied to the authorization result. Search the transaction path, message queues, application logs, crash dumps and any debugging or fraud-review tooling for this data, and record each location in the inventory. Ask your developers to confirm in writing which fields are written before authorization and which are discarded, because retention rules cannot protect data that the team did not know was stored.

The SAQ D note to Requirement 3.2.1 says that when a third-party service provider, including a cloud provider, stores your account data, you must work with that provider to understand how it meets the requirement, including deletion of all geographic copies. Ask each provider for its documented deletion behavior for backups, replicas, snapshots and archive tiers in every region where data is held, and for the period after which those copies are gone. Object storage lifecycle rules, backup retention settings and disaster recovery replicas are the usual places where copies survive longer than the primary record, so verify them in your own accounts rather than relying on the provider's summary. Keep the provider's written answers with the policy, because the assessor will test whether you understood where your data was, not only where you intended it to be.

How to implement 3.2.1 in sequence, with the output of each step

This sequence turns the retention requirement into working controls: you first learn where account data lives, then decide how long each element may stay, then build the deletion and verification steps that prove it happened. Each step leaves a document or record that an assessor can trace.

Inventory every location of stored account data
Start by finding every place account data is kept, including production databases, file shares, logs, exports, backups, test copies, analytics stores, support tickets and copies held by third parties such as cloud providers. Involve engineering, operations, finance and customer support, because stray copies often sit outside the systems people design for. The output is a dated location inventory that lists each store, its owner, the data elements it holds and whether it is in the cardholder data environment. The step is done when system owners have confirmed the list in writing.
Classify data elements and set retention periods
For each data element in the inventory, record why it is kept and for how long. PCI SSC FAQ 1318 notes that the standard sets no fixed minimum or maximum period, so the limit must come from legal, regulatory or business needs that your organization can document. Ask legal and finance to confirm any statutory retention duties, and ask business owners to justify every period in writing. The output is a retention schedule that assigns each element a period, a justification, an owner and an approver. The step is done when the schedule has been approved by someone with authority over the data.
Define disposal methods for each location
Decide how each store is emptied when its retention period ends. Databases may use scheduled deletion jobs, file stores may use lifecycle rules, and backups need a rule that removes or renders unrecoverable copies after the backup retention window closes, which is often the step teams overlook. For third-party copies, confirm with the provider how deletion works, including geographic copies, as the SAQ D note to Requirement 3.2.1 describes. The output is a disposal procedure with one entry per location, stating the method, the trigger, the operator and the evidence produced. The step is done when each entry names a method that a tester could observe.
Automate or schedule deletion
Build the disposal methods into jobs, configuration or provider settings, and test them on non-production copies before enabling them on live data. Where automation is not possible, write a manual procedure with a named owner and a log entry for each run. Keep job definitions under change control so the deletion logic is reviewed like any other system change. The output is working deletion jobs or a signed manual procedure, together with test records showing that expired records were removed and that the job logs show the action. The step is done when a sample test confirms the expected deletion.
Build the quarterly verification job
Requirement 3.2.1 requires a process that confirms, at least once every three months, that stored account data past its retention period has been securely deleted or rendered unrecoverable. Write a verification procedure that queries each location in the inventory for records older than their defined period, and that checks backups and third-party copies through their own reports or attestations. Where the platform supports it, use backup integrity tooling to confirm the state of stored copies; for example, restic's check command can verify repository structure and, with its read-data options, confirm that stored pack data is unmodified. The output is a verification script or runbook with defined inputs, expected results and exception handling. The step is done when a dry run produces a clean result or a documented exception.
Run the first full cycle and record the results
Execute the verification procedure across every location in the inventory and record what was found, what was deleted, what remained and why. Any expired data that remains becomes a tracked exception with an owner and a remediation date. Have the control owner and a second reviewer sign the record, and store it in a document system with version history so that later quarters can be compared against it. The output is a signed first-cycle verification record and an exceptions register. Confirm with your assessor, before the formal assessment, how they expect the records to be retained and presented. The step is done when the record is complete and the next quarterly run is scheduled.

Evidence that passes 3.2.1 and how to keep it current

Requirement 3.2.1 is tested through records, not intentions. The cards below cover the artifacts an assessor typically asks to see, how often each should be refreshed between audits, and who in the organization should approve it. Owners and approvers should be named in the policy itself so the sign-off trail is clear.

Retention and disposal policy

The written policy sets out what account data is kept, where it lives, how long it is kept and how it is destroyed or made unrecoverable at the end of that period. It must cover every location of stored account data, including backups, logs, exports and copies held by third parties. Check that it names an accountable owner, that it is reviewed at least annually, and that it matches what the systems actually do. A policy that says deletion is automatic while jobs are disabled will fail review.

Data inventory and data-flow record

This record lists every system, database, file share, backup set and log source where account data appears, along with how data enters and moves between them. Assessors use it to confirm the retention schedule covers all locations, so an omitted system is a common finding. Refresh it whenever a system changes and review it at least quarterly alongside the verification run. Sign-off usually comes from the system owner and the security or compliance lead.

Retention schedule with justifications

For each data type, the schedule states the retention period, the legal, regulatory or business reason for it, and the trigger that starts the clock. PCI DSS does not set a minimum or maximum storage period, so the justification must come from the organization's obligations, which legal or compliance counsel should confirm. Review the schedule when contracts, card brand rules or local law change, and have the business owner and legal counsel approve each period in writing.

Deletion job logs and backup expiry records

Scheduled purge jobs, database cleanup scripts and backup expiry events produce the proof that data past its period was removed. Keep logs that show the job ran, what it targeted, how many records or objects it affected and any errors. For backups, the expiry record must show that the restore point was removed from every copy and not just the primary catalog. Review failed jobs weekly and have the platform or operations owner sign off on exceptions.

Quarterly verification records

Requirement 3.2.1 requires a check at least once every three months that expired data has been securely deleted or made unrecoverable. The record should state the scope sampled, the method used, the results and every finding with an owner and a closure date. A verification with no findings is still valid evidence if the method is shown to reach the right locations. Quarterly sign-off should come from someone independent of the team that runs the deletion jobs.

Third-party attestations for geographic copies

If a cloud provider or other third party stores account data, the SAQ D note to 3.2.1 expects the organization to understand how that provider meets the requirement, including deletion of all geographic copies. Request written statements from the provider describing deletion and replication behavior, and file them with the contract. Refresh them at least annually and whenever the provider changes its storage regions or replication design. The organization, not the provider, remains responsible for the evidence it presents to the assessor.

What meeting 3.2.1 costs in money and effort

This table compares the main cost and effort components of meeting Requirement 3.2.1, who is paid for each, whether it is one-time or recurring, and what pushes it up. Costs depend on environment size and must come from a written scope and quote, so use the table to shape your questions rather than to estimate a budget.

Cost component	One-time or recurring	What drives it up	How to keep it down
Data discovery across locations	One-time, then repeated when systems change	Many databases, backups, logs, file shares and copies in other regions; undocumented exports	Start from the data-flow diagram and known storage inventory; scan only where account data can plausibly sit
Retention policy and schedule drafting	One-time, with periodic review	Many data types with different legal or business reasons; unclear owners for each retention period	Set one retention period per data type with a written business justification and a named owner
Deletion tooling or licenses	Usually one-time setup, with license renewals if commercial	Commercial tools priced per system or volume; separate tools for each storage type	Reuse existing open-source or native platform features where they meet the requirement; confirm coverage of every storage location
Engineering time to automate deletion and verification	One-time build, then ongoing maintenance	Manual deletion processes; legacy systems without retention hooks; backups that cannot expire data selectively	Automate deletion at the source and make backup expiry match the retention schedule before building custom jobs
Quarterly verification upkeep	Recurring, at least every three months	Large volume of stored data; no central inventory; manual evidence gathering	Script the check and keep its output as dated evidence; review exceptions only
Third-party assurance requests	Recurring, tied to each provider relationship	Cloud or hosting providers holding account data in several geographies; unclear provider deletion practices	Collect provider deletion statements and geographic copy details once, then refresh them on a set schedule
Assessor sampling time	Recurring, at each validation cycle	Missing or inconsistent evidence; samples that cannot be traced to a deletion record	Keep a deletion log that links each sample to the data, the retention rule and the verification result

Which self-hosted open-source tools support 3.2.1 evidence

Requirement 3.2.1 needs retention and disposal processes plus proof that expired data was removed. The tools below can help produce parts of that evidence, but none of them decides what to keep or when to delete it. Each card names the evidence it can support and the checks to run before relying on it.

Bareos backup and restore catalog

Bareos schedules backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files. That catalog shows which copies of stored account data exist and where they sit, which is the starting point for any retention review. Restores selected by date and time can show what a backup held at a given point. Confirm how Bareos handles pruning and volume expiry in your environment, because the deletion behavior that matters for 3.2.1 is not covered by the supplied facts. Bareos is licensed under AGPL-3.0-only, so review the obligations with counsel before modifying or distributing it.

Restic integrity checks

The restic check command verifies the structural consistency of snapshots, trees and pack files. With the read-data options, it reads pack files back to confirm the stored backup data is unmodified. This gives assessors evidence that backup repositories holding account data are intact before and after a retention cycle. It does not show that expired snapshots were removed, so pair it with a documented forget and prune routine and records of each run. Restic is licensed under BSD-2-Clause, a permissive license with a short attribution requirement. Confirm the exact prune behavior and retention settings in your own environment.

XWiki version-controlled policies

XWiki keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. This suits the retention policy, the disposal procedure and the quarterly verification schedule, because assessors can see when each defined retention period was set and approved. Confirm that your approval workflow and review cadence are enforced outside the wiki, since version history alone does not prove that reviews happened. XWiki is licensed under LGPL-2.1-or-later, so check the obligations that apply if you modify its code.

BookStack role-based policy access

BookStack assigns abilities through roles and lets administrators override permissions per role at the shelf, book, chapter or page level. Retention and disposal pages can be limited to the staff who own data deletion, which supports the assessor's question of who can change the policy. Access reviews of those roles become part of the evidence set. Confirm that the people with edit rights are the same people named in your data retention roles, and check any changes against your approval records. BookStack is licensed under MIT, a permissive license that requires the copyright notice to be kept.

Who does what: your team, an implementation partner and the assessor

Your organization owns the retention decisions. PCI DSS sets no fixed retention period, so the periods must come from your legal, regulatory and business needs, and the people who own the data must be able to explain why each period exists. Your team carries the accountability for the policy even when someone else builds the tooling.

Retention justifications: Business, legal and regulatory owners state why each category of account data is kept and for how long, in writing.
Data owner sign-off: Named owners for payment, dispute, refund and reporting data approve the periods and the disposal method.
Final policy and procedures: Your security or compliance lead approves the retention and disposal policy and the procedures that put it into practice.
Exception handling: Someone with authority decides when a legal hold or dispute extends a period, and records that decision.
Ongoing ownership: Your team reviews the policy when products, processors or legal obligations change.

Check that each retention period has a named owner and a written reason, and that the policy would still make sense to an assessor reading it without help from the people who wrote it.

What buyers ask before bringing in help with 3.2.1

How long does a 3.2.1 retention and disposal project take?

Duration depends on how much stored account data exists, how many locations hold it, and how many retention rules already exist. No supplied fact gives a timeline, so confirm the estimate in writing against your own environment. The main drivers are the number of systems and backups that hold account data, whether retention periods have been justified by legal, regulatory or business owners, and whether disposal jobs already run. A team that must first discover where data lives will spend more time on discovery than on policy. Ask the provider to state the systems in scope, the discovery method and the dependencies on your data owners before agreeing a schedule.

Does 3.2.1 need a ROC or an SAQ, and how does that change the evidence?

The assessment type is set by your payment brand or acquirer and by your validation level, not by requirement 3.2.1 itself. A Report on Compliance completed by a Qualified Security Assessor needs detailed evidence for each location of stored account data, including policy text, disposal logs and records of quarterly verification. A Self-Assessment Questionnaire still requires you to answer 3.2.1, but an assessor reviewing a ROC will test the evidence more deeply. Confirm with your acquirer which form applies before you build the evidence set, because the same retention process can be documented at different depths.

Can our own team complete 3.2.1 without an outside partner?

Many organizations can, provided they have clear ownership of the data and someone accountable for the disposal process. The work splits into four parts: defining retention periods with business justification, documenting the policy and procedure, configuring deletion or unrecoverability across systems, and running the quarterly verification. Internal teams often struggle with the first part, because retention decisions need legal and business input that sits outside engineering. A partner can prepare systems, scripts, backup configurations and evidence templates, but the organization must still own the retention decisions and approve the policy.

What do we need to provide to an implementation partner?

The partner needs named data owners who can state why each category of account data is kept and for how long, and read access to the systems and storage locations that hold it. It also needs administrative access to the platforms where deletion runs, the existing retention or backup schedules, and a list of third parties that store or process the data. Without these inputs, the partner cannot produce a reliable inventory. Agree in writing who approves each retention period, who signs off the policy, and who receives the quarterly verification output.

How do cloud and backup copies change the effort for 3.2.1?

Each copy of stored account data is a location the policy must cover, so backups, snapshots, replicas, logs and archives can multiply the work. The SAQ D note to this requirement states that when a third-party provider, such as a cloud provider, stores account data, you must work with that provider to understand how it meets the requirement, including deletion of all geographic copies. Backups deserve particular attention because retention in backup tools is often longer than in the primary system. Tools such as Bareos keep a catalog of backed-up files and manage restore jobs, so the retention settings in backup and catalog systems must be checked against the defined periods, and the verification step must show that expired copies are gone.

What should a quote for 3.2.1 work include?

A quote should list the scope in systems and locations, the deliverables, the assumptions and the exclusions in writing. Ask for each deliverable to be named: a data inventory, the retention schedule with justifications, the disposal procedure, configuration changes, the quarterly verification method and the evidence pack. Separate one-time work, such as discovery and configuration, from recurring work, such as quarterly checks, policy reviews and support. Ask what is excluded, such as legal review of retention periods, changes to third-party contracts, or attestation fees charged by an assessor. DeployOpen works from a fixed written scope, so the quote follows from that scope rather than from a list price.

Can a consultant or implementation partner issue the 3.2.1 attestation?

No. Only an independent assessor can issue validation. A Qualified Security Assessor issues a Report on Compliance, and the organization completes an Attestation of Compliance on the official PCI SSC template. A self-assessment is completed and attested by the organization itself. PCI SSC does not accept certificates as validation. A partner such as DeployOpen can prepare systems, configurations and evidence for the assessment, but it does not issue reports, attestations or certifications. Keep the implementation partner and the assessor separate so that the assessor can test work independently.

What evidence will an assessor ask to see for 3.2.1?

An assessor typically asks for the written retention and disposal policy, the procedure that carries it out, and the defined retention period for each category of account data with its justification. They will want evidence that disposal runs in every location covered by the policy, including backups and third-party copies, and records of the quarterly verification showing that expired data was securely deleted or made unrecoverable. Keep dated logs, job outputs and sign-off records. Confirm the exact expectations with your assessor before the review, because the depth of evidence depends on the assessment type and the environment.

How DeployOpen scopes and prepares 3.2.1 evidence

DeployOpen works on requirement 3.2 by helping your team define where account data lives, how long each store may keep it, and how deletion is proven. Your organization owns the retention decisions, and an independent QSA or ISA decides whether the evidence meets the standard.

How we scope

Map every location of stored account data across self-hosted platforms, backups, logs, exports and archives before setting retention rules.
Record the legal, regulatory or business reason behind each retention period so the 3.2.1 policy has a documented justification.
Agree scope, deliverables and timelines in writing before work starts, since engagements are fixed-scope and priced from that written scope.

How we build

Configure backup retention and expiry in platforms such as Bareos so jobs reflect the defined retention periods for each data set.
Set up scheduled deletion and verification jobs, and confirm restores do not reintroduce data past its retention period.
Build access and change history for retention procedures, using tools such as XWiki or BookStack, so each policy revision is traceable.

How we hand over

Deliver the retention and disposal policy, data inventory and retention schedule in documents your assessor can trace to requirement 3.2.1.
Provide quarterly verification runbooks and sample records showing expired data was securely deleted or made unrecoverable.
Walk your team through the evidence set and confirm with your assessor which artifacts they expect for the ROC or SAQ.

How we support

Offer ongoing support and quarterly verification as a retainer, so the three-month check keeps running after handover.
Review third-party cloud and backup provider deletion commitments, including deletion of geographic copies, and document what they confirm.
Re-check retention rules when business needs, laws or the PCI DSS version change, and update the evidence accordingly.

3.2 Account data storage minimization