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

Non-Persistent Memory

Also known as: Volatile Memory
Simply put

Non-persistent memory is a type of computer storage that only holds data while it has power, losing its contents when power is removed. This contrasts with non-volatile (persistent) memory, which retains information even after power is turned off. Because data does not survive a loss of power, non-persistent memory is used for fast, temporary storage of active data rather than for long-term retention.

Formal definition

Non-persistent (volatile) memory is computer memory that requires continuous power to retain its stored contents; when power is removed, the data is lost. It provides fast, temporary storage for actively processed data, in contrast to non-volatile memory (NVM), which retains information after power is removed and is used for long-term storage and retrieval. In a payment security context, the persistence characteristics of a memory tier are relevant to how data is retained and cleared: sensitive authentication data (for example, full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks) must not be stored after authorization, even when encrypted, so processing such data transiently in non-persistent memory differs materially from writing it to persistent storage. Whether any given implementation actually avoids persistence, and its effect on PCI DSS scope, depends on the specific architecture and validation rather than on the memory type label alone; the emergence of persistent (Storage Class Memory) technologies further blurs the traditional volatile/non-volatile boundary.

Why it matters

In payment environments, the distinction between non-persistent and persistent memory is directly relevant to how sensitive data is retained and cleared. Sensitive authentication data (for example, full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks) must not be stored after authorization, even when encrypted. Because non-persistent memory loses its contents when power is removed, processing such data transiently in this memory tier differs materially from writing it to persistent storage, where data would survive a reboot or power loss and could remain recoverable long after a transaction completes.

However, the memory type label alone does not determine compliance or safety. Whether a given implementation actually avoids persistence, and how that affects PCI DSS scope, depends on the specific architecture and its validation rather than on whether memory is nominally described as volatile. Data held in non-persistent memory can still be exposed while power is present through memory-scraping malware or improper handling, and residual data may persist longer than assumed depending on hardware behavior. Teams should confirm requirements against the current published PCI DSS rather than assuming a memory characteristic satisfies a control.

The traditional volatile/non-volatile boundary is also becoming less clear. Emerging Storage Class Memory (SCM) technologies are non-volatile, meaning data does not disappear when power is removed, yet may be used in roles historically associated with faster, temporary storage. This blurring means that assumptions about whether data survives a power loss cannot be based on a memory tier's conventional role, and must instead be verified against the actual technology in use.

Who it's relevant to

Security Engineers and Architects
Those designing payment systems must account for whether a memory tier is persistent when deciding where sensitive authentication data is processed. Because sensitive authentication data must not be stored after authorization, transient handling in non-persistent memory differs materially from writing to persistent storage. Architects should verify the actual persistence behavior of the hardware in use, particularly where Storage Class Memory blurs the volatile/non-volatile boundary.
Compliance Officers and QSAs
Whether an implementation using non-persistent memory affects PCI DSS scope depends on the specific architecture and its validation, not on the memory type label. Compliance teams should confirm applicable requirements against the current published PCI DSS and validate claims that data does not persist, rather than accepting the classification of memory as volatile as sufficient evidence.
Payment System Developers
Developers handling full track data, card verification values, and PINs/PIN blocks during authorization need to understand that these must not be retained after authorization, even when encrypted. Understanding the persistence characteristics of the memory their code uses helps them avoid inadvertently writing sensitive authentication data to storage that survives a power loss.

Inside Non-Persistent Memory

Volatile Storage
Memory such as RAM whose contents are lost when power is removed or the process terminates. Non-persistent memory refers to data held only in this transient state rather than written to disk or other durable media.
Transient Sensitive Authentication Data
Full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks may pass through non-persistent memory during authorization. This is distinct from persistent storage; sensitive authentication data must not be stored after authorization even when encrypted, but its momentary presence in memory during processing is a different matter that must still be protected.
In-Process Cardholder Data
PAN, cardholder name, expiration date, and service code that may reside temporarily in application memory during transaction handling. While some cardholder data may be stored persistently under defined controls, its handling in non-persistent memory still requires protection against exposure.
Memory Lifecycle Boundaries
The points at which data enters memory, is used, and should be cleared. Non-persistent memory is characterized by the expectation that data is removed once no longer needed rather than retained.
Memory Exposure Vectors
Mechanisms by which data intended to be non-persistent can nonetheless leak, including memory dumps, swap or paging to disk, crash artifacts, hibernation files, and core files that may inadvertently create a persistent copy.

Common questions

Answers to the questions practitioners most commonly ask about Non-Persistent Memory.

Does storing sensitive authentication data in non-persistent memory mean I am not storing it under PCI DSS?
No. The prohibition on retaining sensitive authentication data after authorization applies regardless of the storage medium, and it applies even when the data is encrypted. Non-persistent memory such as RAM is a legitimate place for sensitive authentication data to exist transiently during processing, but you must ensure it is not persisted, written to logs, captured in crash dumps or debug traces, swapped to disk, or otherwise retained after authorization completes. Treating volatile memory as an automatic exemption is a common misreading; the control is about not retaining the data, not about which medium it briefly occupies.
Is data in non-persistent memory automatically out of PCI DSS scope?
No. Cardholder data and sensitive authentication data present in memory, even transiently, are within the assessment's concern because that memory sits on in-scope systems that process the data. Whether a given component is in scope depends on your environment, segmentation, and how the data flows, not on the volatility of the medium. Memory being non-persistent affects retention obligations, but it does not by itself remove a system from scope. Confirm scope determination against the current published standard and your assessor's guidance.
How can I confirm that sensitive authentication data is not accidentally persisted from memory?
Review the full data lifecycle for paths that can move volatile data to durable storage. Common leakage points include application and debug logs, exception traces, core or crash dumps, memory swapped to disk by the operating system, temporary files, and caching layers. Testing typically combines code review, configuration review of logging and dump settings, and forensic-style searches of disk and log stores for data patterns after authorization. The goal is to demonstrate that data expected to be transient does not appear in any persistent location.
What controls help limit exposure of cardholder data while it resides in memory?
Practical measures may include minimizing how long data stays in memory, overwriting or clearing buffers when processing completes rather than relying solely on garbage collection, restricting who and what processes can read process memory, disabling or securing memory dumps in production, and preventing sensitive regions from being swapped to disk. These help reduce the window and surface for exposure but do not eliminate risk on a compromised host, so they should be combined with broader system hardening and access controls.
How does non-persistent memory relate to tokenization, encryption, and truncation?
Those techniques transform or replace data to reduce what is stored persistently, whereas non-persistent memory concerns data that is only present transiently during processing. They address different questions: tokenization, encryption, truncation, masking, and hashing change the form of retained data, while memory volatility concerns whether data is retained at all. A system may hold cleartext data briefly in memory during processing even in an environment that tokenizes or truncates before writing to storage. Their effect on scope depends on implementation and validation, not on the label.
Should I rely on non-persistent memory as a substitute for meeting storage requirements?
No. Using volatile memory for transient processing is appropriate, but it is not a compliance strategy on its own. You still need to prevent inadvertent persistence, protect data in memory to the extent feasible, and meet the applicable retention, protection, and access requirements for any cardholder data you do store. Verify the current requirement wording against the published standard, since numbering and phrasing differ between PCI DSS versions.

Common misconceptions

Data in non-persistent memory is automatically out of PCI DSS scope because it is never stored.
Cardholder data and sensitive authentication data present in memory are still within scope while being processed. Scope depends on how data is handled, transmitted, and protected, not solely on whether it touches durable media. Systems processing this data can bring the environment into scope.
Because sensitive authentication data is only in RAM, storing it there after authorization is acceptable.
The prohibition is on storing sensitive authentication data after authorization. Retaining such data in memory beyond the authorization it supports can constitute storage of prohibited data. Data should be cleared once it is no longer needed for the authorization.
Non-persistent memory cannot inadvertently become persistent.
Memory contents can be written to durable media through swap files, paging, hibernation, crash dumps, or core files, potentially creating an unintended persistent copy that must be prevented or protected.

Best practices

Clear or overwrite sensitive authentication data and cardholder data from memory as soon as it is no longer needed for the authorization it supports, rather than relying on process termination alone.
Configure systems to prevent memory contents from being written to durable media by disabling or protecting swap, paging, hibernation, and crash/core dump files where sensitive data may be processed.
Treat systems that process cardholder or sensitive authentication data in memory as in-scope and apply relevant PCI DSS controls, confirming exact requirement wording against the current published standard.
Do not retain sensitive authentication data in memory beyond the authorization stage, since prolonged retention may amount to prohibited storage of that data.
Restrict and monitor access to process memory and memory-inspection tooling to help reduce the risk of unauthorized memory scraping or dumping, recognizing that monitoring may produce false positives or negatives.
Consider transforming or reducing data exposure through techniques such as tokenization, encryption, truncation, or masking where appropriate, validating the actual scope effect of each approach rather than assuming it based on the label.