Skip to main content
Commerce Security Authority
Category: Data Protection Methods

Non-Primary Storage

Also known as: Secondary Storage
Simply put

Non-primary storage, often called secondary storage, is where data is kept for retention rather than for immediate use by the computer's processor. Unlike primary storage such as RAM, which is fast and typically loses its contents when power is removed, non-primary storage retains data when not actively in use and generally relies on devices like hard drives, solid-state drives, or optical media. It is usually slower and less costly per unit of capacity than primary storage.

Formal definition

Non-primary storage refers to storage that is not the main memory directly accessible by the CPU. Primary storage is typically volatile memory such as RAM that supports quick access but loses data when power is interrupted; non-primary (secondary) storage instead provides non-volatile data retention on devices such as HDDs, SSDs, and optical discs, at generally lower cost and lower access speed. Note that the evidence provided describes non-primary storage only at the general computing level and does not address PCI DSS storage requirements; whether cardholder data or sensitive authentication data may reside on any storage tier is governed by applicable PCI standards and controls, and readers should confirm requirements against the current published standard.

Why it matters

Non-primary storage is where data persists beyond the moment it is actively processed, which makes it the tier most relevant to questions of data retention. Because devices like hard drives, solid-state drives, and optical media retain their contents when power is removed, any data written to them remains available until it is deliberately overwritten, deleted, or otherwise rendered unrecoverable. For payment security teams, this persistence is precisely why storage decisions carry weight: data that lingers on secondary storage is data that could be exposed if that storage is lost, stolen, or improperly accessed.

The evidence provided describes non-primary storage only at the general computing level and does not itself address payment data handling. It is important not to read PCI DSS conclusions into the storage tier alone. Whether cardholder data (such as PAN, cardholder name, expiration date, or service code) may reside on any given storage device, and under what protections, is governed by the applicable PCI standards and their defined controls. Sensitive authentication data (such as full track data, CAV2/CVC2/CVV2/CID, or PIN blocks) must not be retained after authorization, even when encrypted, and the physical or logical storage tier does not change that prohibition.

Because non-volatile storage retains data by design, teams should confirm retention, protection, and disposal requirements against the current published PCI standard rather than assuming that a general definition of secondary storage settles any compliance question. The label "non-primary storage" describes a hardware and access characteristic; it does not by itself establish whether a given data element is permitted on that medium.

Who it's relevant to

Compliance Officers
Because non-primary storage retains data persistently, it is a natural focus when assessing where retained data resides and how it is protected. This general definition does not establish PCI DSS requirements on its own; compliance officers should map data flows to the applicable PCI standards and confirm retention, protection, and disposal obligations against the current published standard rather than inferring them from the storage tier alone.
Security Engineers
Security engineers design and operate systems that move data between fast volatile primary memory and slower non-volatile secondary storage. Understanding that secondary storage retains data when power is removed helps in reasoning about where data may persist and what controls are needed to protect or dispose of it, while recognizing that the storage tier itself does not determine what data is permitted to be stored there.
Payment Processors and Acquirers
Organizations handling payment data need clarity on where data is retained. Sensitive authentication data must not be stored after authorization regardless of the storage medium, and any storage of cardholder data is subject to defined controls under the applicable PCI standard. Non-primary storage is simply the durable tier where retained data would reside; its non-volatile nature reinforces the need to confirm what may lawfully persist and under what protections.

Inside Non-Primary Storage

Backup and Recovery Media
Copies of production data held on tape, disk-based backup appliances, or offline media. When these copies include cardholder data such as the PAN, they fall within PCI DSS scope and must be protected with the same rigor as primary storage, including access controls, encryption where applicable, and inventory tracking.
Archive and Long-Term Retention Stores
Data moved off primary systems for retention or historical purposes. If PAN or other cardholder data is retained, retention must be tied to a documented business, legal, or regulatory justification, and data must be securely disposed of when no longer needed.
Logs, Audit Trails, and Diagnostic Files
Application logs, error dumps, transaction traces, and debugging output that may inadvertently capture cardholder data or, more critically, sensitive authentication data such as full track data or card verification values. Sensitive authentication data must not be stored after authorization even in logs, regardless of encryption.
Temporary, Cache, and Scratch Storage
Transient locations such as memory-mapped files, spool directories, temporary tables, and caches where cardholder data may persist longer than intended. These locations often escape formal data inventories and can extend PCI DSS scope if not identified and controlled.
Removable and Portable Media
USB drives, external disks, and similar devices that can hold copies of cardholder data outside primary systems. Where such media store cardholder data, they require inventory, physical security, and controlled handling and disposal.

Common questions

Answers to the questions practitioners most commonly ask about Non-Primary Storage.

Does storing cardholder data in non-primary storage such as backups, logs, or archives take it out of PCI DSS scope?
No. Cardholder data does not leave scope simply because it resides in a secondary location. Backups, archives, log files, audit trails, temporary files, memory dumps, and similar non-primary storage that contain cardholder data remain in scope and are subject to the same protection, retention, and secure deletion controls as primary databases. Scope is determined by where the data actually exists and flows, not by whether a store is labeled primary or secondary.
Is it acceptable to keep sensitive authentication data in non-primary storage as long as it is encrypted?
No. Sensitive authentication data, which includes full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks, must not be retained after authorization, even when encrypted. This prohibition applies regardless of storage type. Encryption does not create an exception for backups, logs, debug output, or archives. If such data appears in non-primary storage after authorization, for example in application logs or captured payloads, it must be identified and eliminated. Only certain cardholder data elements may be stored after authorization under defined controls, and never the sensitive authentication data elements.
How do we find cardholder data that may have accumulated in logs, backups, and other non-primary locations?
Use data discovery methods appropriate to your environment, such as pattern-based scanning for candidate PAN structures across file systems, log repositories, backup media, database exports, and temporary directories, combined with review of application logging and error-handling behavior. Discovery tools produce false positives and false negatives, so results should be validated. The goal is to confirm all locations where in-scope data exists so they can be brought under the applicable protection, retention, and deletion controls, or the data can be removed where it should not be present.
How should retention and secure deletion be handled for cardholder data in backups and archives?
Apply your defined data retention and disposal policy consistently to non-primary storage. Retain cardholder data only as long as there is a documented business, legal, or regulatory need, and securely delete or render unrecoverable data that exceeds that need. Backups and archives can complicate deletion because data may persist across multiple media generations or off-site copies. Account for these in the disposal process so that expired data does not survive indefinitely in secondary stores. Confirm specific control expectations against the current published PCI DSS, since requirement wording and numbering differ between versions.
What protections apply to cardholder data stored in non-primary storage?
The same protection expectations that apply to primary storage apply here. Stored PAN must be rendered unreadable using an approved method such as strong cryptography with associated key management, truncation, one-way hashing of the entire PAN, or tokenization, depending on implementation and validation. Access should be restricted on a need-to-know basis, and the storage should be covered by monitoring and logging controls. Note that truncation, masking, hashing, tokenization, and encryption transform data differently and their effect on scope depends on how each is implemented and validated, not on the label alone.
How can we prevent cardholder data and sensitive authentication data from ending up in logs and other non-primary stores in the first place?
Address this at the application and infrastructure layers. Configure logging, debugging, and error handling so that PAN is masked or omitted and sensitive authentication data is never written, including in verbose or diagnostic modes. Review code paths that capture request or response payloads, exception details, and memory contents. Establish controls over temporary files and caches, and include log and backup content in periodic data discovery reviews so that inadvertent capture is detected and corrected. This is a prevention-focused control that reduces, but does not by itself guarantee elimination of, unintended data retention.

Common misconceptions

Data stored outside the primary production database is out of PCI DSS scope.
Scope is determined by where cardholder data is stored, processed, or transmitted, not by whether the location is primary or secondary. Backups, archives, logs, temporary files, and removable media that contain cardholder data are in scope and require the same protection expectations. Confirm applicable requirements against the current published PCI DSS.
It is acceptable to keep sensitive authentication data in non-primary storage such as logs or backups as long as it is encrypted.
Sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks) must not be stored after authorization, even when encrypted. Encryption does not create an exception. Only certain cardholder data elements may be retained under defined controls and documented retention justification.
Encrypting or truncating data in secondary storage automatically removes it from scope.
Tokenization, encryption, truncation, masking, and hashing transform or reduce data differently, and their effect on scope depends on the specific implementation and how it is validated, not on the label alone. Whether a non-primary store is descoped must be assessed rather than assumed.

Best practices

Maintain a complete data flow map and inventory that explicitly includes backups, archives, logs, caches, temporary files, and removable media, so no location holding cardholder data is overlooked when defining scope.
Configure applications and systems so that sensitive authentication data is never written to logs, debug output, temporary files, or backups after authorization, and periodically search these locations to confirm it is absent.
Define and enforce documented retention and secure disposal schedules for any cardholder data held in non-primary storage, keeping only what has a stated business, legal, or regulatory justification.
Apply the same access controls, encryption where applicable, and monitoring to secondary storage as to primary systems, since scope follows the data rather than the system tier.
Before treating any non-primary store as out of scope through tokenization, encryption, truncation, or masking, validate the specific implementation against the current published PCI DSS rather than relying on the technique's label.
Track and physically secure removable and portable media that may contain cardholder data, and confirm the controls you rely on against the current version of the applicable standard, since requirement numbering and wording change between versions.