One of the most persistent misunderstandings I see during PCI DSS assessments is the belief that cardholder data (CHD) that is stored in memory only is not considered stored. Even seasoned QSAs sometimes get this wrong.
The truth is: volatile memory counts as storage under PCI DSS, even if the data exists for just a fraction of a second. Misunderstanding this can lead to inaccurate scoping, failed assessments, and missed controls.
Understanding CHD and SAD in Memory
PCI DSS defines cardholder data (CHD) as:
- Primary Account Number (PAN)
- Cardholder name
- Expiration date
- Service code
Sensitive Authentication Data (SAD) is:
- Full magnetic stripe data (Track data)
- CAV2/CVC2/CVV2/CID
- PINs or PIN blocks
SAD must never be stored post-authorization, but both CHD and SAD can exist temporarily in system memory during processing.
Even if the data is in RAM for milliseconds, it is:
- Still considered stored
- Still in scope for PCI DSS
- Subject to encryption, access control, and logging requirements
Speak to a Compliance Specialist.
Why Memory-Only CHD Matters
Many organizations assume that because the PAN or CVV is only present in memory and never written to disk, it is “out of scope.” This is false.
- Applications often handle CHD in memory buffers, caches, or process heaps.
- Logging, crash dumps, and swap files can inadvertently persist in memory.
- Attackers who compromise a system can capture memory to steal CHD (memory scraping).
From a PCI DSS perspective, any environment that processes CHD—even in volatile memory—is part of the Cardholder Data Environment (CDE).
Key Implications for Assessments
- Volatile memory is storage
PCI DSS treats CHD/SAD in memory as “stored”, so:
- You cannot ignore memory-only data when scoping
- Memory processing systems require controls just like disk storage systems
- Encryption, access restrictions, and monitoring apply even if data only exists for a millisecond
- Processing-only systems are in scope
Even systems that never persist CHD to disk, but process it in memory, are part of the CDE. Examples:
- Payment authorization applications
- In-memory tokenization processes
- APIs that handle PANs or SAD in request payloads
- Sensitive Authentication Data (SAD) is ephemeral
SAD must be purged immediately after authorization, but if it exists in memory, controls are required while it exists. This includes:
- Preventing logging or memory dumps
- Restricting access to authorized processes/users
Securing memory buffers against unauthorized access
Practical Guidance for Scoping
- Map memory flows: Identify every process where PAN, SAD, or CHD exists—even temporarily.
- Include memory-only systems in the CDE: Do not exclude systems that never persist data.
- Implement appropriate controls: Encryption, access control, and monitoring for memory-processing systems.
- Document assumptions clearly: If data exists only in memory, explain processing duration, safeguards, and purging procedures.
- Validate with testing: Confirm that no memory dumps, swap files, or logs persist CHD/SAD.
Common Misconceptions
❌ “We don’t store card data because it’s only in memory.” → False
❌ “Memory-only CHD doesn’t need to be encrypted.” → False
❌ “SAD in memory is fine as long as we don’t log it.” → False
Memory is just another form of storage, and PCI DSS expects it to be treated as such.
Final Thoughts
If your organization processes cardholder data—even for a millisecond in memory—it is in scope for PCI DSS. Failing to recognize this can lead to critical gaps in controls, assessment findings, and security risk.
Remember: volatile does not mean invisible. PCI DSS sees it as stored.
About the Author
Carla Brinker
Carla is a Senior Manager at Auditwerx and leads our PCI DSS service line. With over 20 years of security compliance experience, Carla is a QSA your business can count on.
Related Content
Gain Deeper Insights
