Does encryption remove cardholder data from PCI DSS scope

Does encryption take cardholder data out of PCI DSS scope, and why it usually does not

Encrypting cardholder data with strong cryptography meets Requirement 3.5.1, but it does not by itself take that data out of PCI DSS scope. PCI SSC FAQ 1086 makes this point directly, and FAQ 1233 covers the same question for service providers. If a customer, acquirer or contract asks you to shrink scope, the first step is to separate two questions: whether the stored or transmitted data is protected, and whether the systems that touch it still fall under the standard. Encryption answers the first question. The second depends on the architecture around it. The answer turns on four things. The first is who holds the keys and where they are kept, since key-management systems that generate, store or use the keys often remain in scope, and Requirement 3.6.1.2 sets specific rules for how secret and private keys are stored. The second is where decryption happens, because any system that can decrypt PAN usually remains part of the cardholder data environment. The third is which Self-Assessment Questionnaire applies. Encrypted cardholder data still counts as cardholder data for SAQ eligibility, and the merchant attestation that it does not store cardholder data electronically is the trigger that can push a merchant to SAQ D. The fourth is whether the encrypted data is still stored electronically at all.

Your organization owns the scope decision. Your QSA, or the acquirer and payment brands where they require it, confirms it. DeployOpen can help prepare the data-flow diagrams, the key-management design, the decryption boundaries and the evidence that shows where cardholder data sits before and after the change. DeployOpen does not validate scope, issue a Report on Compliance or sign an Attestation of Compliance. Before you commit to a design, ask your assessor to document the systems that hold keys, perform decryption, or can reach either, and confirm in writing which SAQ or ROC applies to the revised environment. If the goal is a meaningful reduction, the routes to examine are the ones the standard treats differently: hashing or truncation of the PAN under Requirement 3.5.1, tokenization, or a PCI-listed point-to-point encryption solution. Hashing removes data from a separate environment only where the hashed value is transferred and stored there, while the systems that perform the hashing stay in scope (PCI SSC FAQ 1089). Each route has its own conditions, so the decision should be made against the specific architecture rather than against the label of the technology.

Which systems stay in scope after you encrypt PAN

Encrypting PAN changes what an assessor tests, not whether the systems around it are in scope. The components below hold, use or control the keys that make the ciphertext readable, so they stay inside the cardholder data environment and need evidence of their own.

Application and database holding encrypted PAN

The application or database that stores the ciphertext remains in scope because encrypted PAN is still cardholder data. Its scope status does not change until the data is rendered unreadable by an accepted method. Check which fields hold encrypted PAN, which services read them, and whether any copies, logs or exports hold the same ciphertext. Assessors will ask for data-flow diagrams and an inventory that shows every location where encrypted PAN is stored.

Key management system and HSMs

The key management system and any hardware security modules hold the keys that decrypt PAN, so they are in scope for the whole key lifecycle. Confirm where keys are generated, stored, rotated and destroyed, and who can invoke them. Assessors typically ask for key inventories, key-custodian records, rotation logs and configuration exports from the HSM or key service that show the controls in operation.

Key storage under Requirement 3.6.1.2

Requirement 3.6.1.2 governs how secret and private keys are stored at all times. Keys must be encrypted under a separate key-encrypting key, held inside a secure cryptographic device such as an HSM, or kept as at least two full-length components or shares. Each option needs documented procedures and evidence. Confirm which option applies to each key class before you choose a design, because a key stored in plaintext next to the data it protects removes the protection.

Decryption service

The decryption service calls the key store and returns clear PAN to authorized callers, so it sits inside the cardholder data environment. Its code, configuration, authentication and network paths all need the controls that apply to other in-scope systems. Ask for an inventory of callers, the authorization rules that gate each decrypt request, and logs that record decryption events for review.

Systems that handle key components

Where keys are split into components or shares, every system and person that handles a component is in scope for that step. Key-component custodians, the workstations used to load components and any media that carry them must be controlled and logged. Confirm the custodian list, the split and recombination procedure, and the records that show each component stayed separated from the others.

Administrators with access to keys

Administrators who can read, export, rotate or disable keys are in scope even if they never see clear PAN. Their accounts can enable decryption indirectly, so they need strong authentication, least-privilege roles and logged activity. Assessors commonly ask for role assignments, access reviews and a sample of key-management audit logs that show who changed what and when.

How each Requirement 3.5.1 method changes what is in scope

This table compares the accepted ways to render stored PAN unreadable under Requirement 3.5.1 and shows what each one does to scope. Read the middle column for what changes in the environment where the data lands, and the last column for the systems that remain in scope regardless of method.

Method	Scope effect	What stays in scope
Strong encryption of PAN	Meets Requirement 3.5.1, but the encrypted data is still cardholder data and the environment stays in scope (FAQ 1086)	Storage systems, decryption paths, applications that read the PAN, and the key management system
One-way hash of entire PAN	Hashed PAN moved to and stored in a separate environment is no longer cardholder data there (FAQ 1089)	Systems performing the hashing, and the source systems where the full PAN exists before hashing
Truncation	Truncated PAN is not cardholder data in the receiving environment, but the truncation process runs where the full PAN is present	Any system that handles the full PAN before truncation, plus the logic that truncates it
Index tokens	Stored index tokens with the PAN held in a separate, secured location can reduce the scope of the systems holding the tokens	The secured location holding the PAN and the index mapping, and any process that correlates them
Strong cryptography with key management	Data remains cardholder data, so encryption alone does not remove scope and SAQ eligibility is still affected (FAQ 1314)	Key management processes, key storage under Requirement 3.6.1.2, and all systems with decryption access
Hashed or truncated PAN correlated across environments	Correlation can restore a link to the original PAN, which can bring the separate environment back into scope (FAQ 1308)	Any environment where hashed or truncated values can be matched to full PANs, so confirm correlation risk before relying on scope change

Which SAQ applies when you store only encrypted PAN

A merchant that never stores PAN electronically is the simplest case. Card data may pass through the business during a transaction, but it is not kept in any file, database, log or backup after authorization. The SAQ attestations in the questionnaires other than SAQ D describe this condition, so a merchant that can truthfully make it may be eligible for a shorter SAQ, depending on how it accepts payments.

Confirm the storage claim: Search for PAN in databases, spreadsheets, email, ticketing systems and shared drives before you accept the attestation.
Check the channel: The payment channel, such as e-commerce redirect, terminal or call center, determines which SAQ type fits.
Watch for incidental copies: Card numbers written on paper, saved in screenshots or forwarded by email count as storage.
Record the basis: Keep the scoping evidence that supports the statement you sign.
Ask your acquirer: Acquirers and payment brands decide which validation type applies to your business.

Before relying on this tab, check that your storage claim holds across every system, because a single stored PAN file can change your SAQ.

When P2PE is the exception route

A PCI-listed point-to-point encryption (P2PE) solution is the one encryption route the Council describes as able to significantly reduce the number of PCI DSS requirements that apply to a merchant. The key word is reduce. A listed P2PE solution does not remove PCI DSS from the merchant's environment, so the merchant still has obligations for the systems that remain, such as the point-of-interaction devices it manages, the store network and the processes that handle payment changes, returns and staff access. Before relying on P2PE to lower validation effort, confirm that the specific solution and its components appear on the Council's current listings, because the benefit depends on the listed scope matching how the merchant actually deploys it.

Encryption that is not PCI-listed follows different rules. The Council allows merchants to use such solutions to reduce validation effort, but it does not validate them and recommends listed P2PE solutions instead. If a merchant chooses a non-listed encryption product, its next step is to ask the acquirer or the payment brands how that product will be treated for validation. Ask for the answer in writing, including which requirements remain in scope, which SAQ or ROC applies and what evidence the assessor will expect. Do not assume that deploying an encryption product reduces scope until that answer is on file.

Whether a P2PE deployment qualifies for the SAQ P2PE questionnaire depends on conditions that are covered on the sibling page on P2PE solutions and SAQ P2PE, including the requirement to follow the P2PE Instruction Manual and the status of the listing. Treat that page as the next step once you have confirmed that P2PE fits your payment channel. Your own team owns the store-side controls, and any outside help should be scoped in writing around the evidence the acquirer will accept.

How to test whether encryption reduces your scope

This sequence shows whether encrypting stored card data changes your validation scope, by tracing every place the PAN lives, who holds the keys and which systems can decrypt it. It ends with a scope decision that the acquirer or QSA has agreed and that you have recorded.

Map every location where PAN appears
Your payments or data team lists every system, database, file share, backup, log, export, report and paper record where a primary account number appears, whether encrypted or not. Include copies created by batch jobs, support tooling, analytics pipelines and disaster recovery stores. The output is a PAN location register with an owner and a data flow for each entry. The step is done when the team can show a source for each location and no known store is missing from the register.
Document the encryption method and its strength
Your security engineers record which algorithm and key length protect each stored PAN location, how the encryption is applied (column, file, volume or application level) and whether the method uses strong cryptography as Requirement 3.5.1 expects. Confirm this against the current standard and the cryptographic guidance you rely on. The output is an encryption register that pairs each PAN location with its method. The step is done when every entry in the location register has a matching encryption record.
Record key custody and key management processes
Your key custodians document where each data encryption key and key-encrypting key is generated, stored and rotated, and who can access them. Check that secret and private keys are protected as Requirement 3.6.1.2 describes, either wrapped by a separate key-encrypting key, held in a secure cryptographic device or split into key components. Key management systems that can decrypt PAN stay in scope, so list them as in-scope components. The output is a key custody map. The step is done when each key has a named custodian and a storage method.
Confirm every decryption path
Your engineers trace each route that can turn encrypted PAN back into readable data, including application services, administrative consoles, reporting queries, database administrators, backup restores and support access. For each path, record the system, the identity or role that can invoke it and the logs it produces. A path that returns readable PAN keeps the system that exposes it in scope. The output is a decryption path inventory. The step is done when no decryption path is undocumented and every path has an owner.
Determine SAQ eligibility from the findings
Your team works out whether the encrypted storage still counts as cardholder data for the validation type you expect to use. Encrypted cardholder data still counts for SAQ eligibility, and a merchant that stores only encrypted cardholder data may fall to SAQ D. Compare this against the payment channel and the decryption paths you recorded. The output is a provisional validation type with a written reason. The step is done when the team can explain how each stored location affects that choice.
Agree the scope with the acquirer or QSA
You send the location register, encryption register, key custody map and decryption path inventory to your acquirer or payment brand contact, and to your QSA if you use one for a ROC. Ask them to confirm which systems are in scope and which validation type applies. Record their written response, including any conditions. Independent assessors make the final determination, and your team does not issue its own validation. The output is a written scope position from the acquirer or QSA. The step is done when that position is on file.
Record the result in the scope confirmation
Your compliance lead writes the agreed scope into the annual scope confirmation, listing in-scope systems, out-of-scope systems with the reasons they are out, the key management components and the agreed validation type. Attach the registers and the acquirer or QSA response. Schedule a re-check when the encryption design, key arrangements or data flows change. The output is a dated scope record that the assessor can trace back to the evidence. The step is done when the record is approved and stored with the other PCI DSS documentation.

What to have in place before the scope conversation

Encryption protects card data, but the scope decision depends on what can read it and how the keys are handled. The five items below are the evidence a QSA or acquirer will ask for before accepting that encrypted PAN has left the cardholder data environment. Each one has a clear owner inside your organization.

Data flow diagram for encrypted PAN

Map every path the encrypted PAN takes, from the point of capture through storage, backups, logs, analytics exports and third-party transfers. Mark each hop where the data is encrypted, where it is decrypted, and which network segment it crosses. Check the diagram against live traffic and storage locations, not the design document alone. The payments or platform architecture lead owns this map and must refresh it after each significant change.

Key inventory with custodians

List every secret and private key that protects stored PAN, with its purpose, algorithm, creation date, rotation schedule and named custodians. Requirement 3.6.1.2 expects each key to be stored encrypted under a separate key-encrypting key, inside a secure cryptographic device such as an HSM, or as at least two full-length components. Confirm the storage method for every key, including backup copies. Security operations owns the inventory, and each custodian should be named and recorded.

Strong cryptography selection records

Keep a record of which algorithms, key lengths and modes protect stored PAN, and why each was chosen. Assessors look for current strong cryptography, documented key-management processes and no reliance on deprecated ciphers or home-grown schemes. Ask the security architect to justify each choice against the standard's definition of strong cryptography, and confirm that the library versions in production match the approved configuration.

Register of components that can decrypt

List every system, service account, application and person able to call a decryption function or reach the key material. This list usually includes application servers, batch jobs, reporting tools, support consoles and administrators with key access. Each entry that can decrypt PAN belongs inside the scope boundary, so the list directly determines how large the scope becomes. The identity and access team should reconcile it against actual IAM policies and key access logs.

Written scope statement

Write a short statement that names the systems in scope, the systems you believe are out of scope, the reasoning for each boundary and the evidence behind it. Include the encryption position, the decrypting components and the data flow reference. Have the compliance lead approve it, and bring it to the acquirer or QSA before relying on it. Record the review date, because the statement must be revisited whenever architecture or key handling changes.

Who owns the scope decision and who prepares the evidence

The organization owns the scope decision. It must define which systems store, process or transmit cardholder data, which systems could affect their security, and whether encryption actually changes that picture. Encryption alone does not remove a system from scope, so the organization has to document where clear text PAN exists, who can reach the keys and how each system is treated.

Scope decision: Decide which systems remain in the cardholder data environment after encryption and document the reasoning, including key management systems and any decryption path.
Policies and ownership: Assign named owners for key management, access to decryption and the annual scope confirmation.
Architecture review input: Provide current data flow and network diagrams, because the assessor and any partner will work from them.
Evidence it runs daily: Keep operational records such as key rotation logs and access reviews, since these are produced by the organization's own processes.
Vendor oversight: Hold written agreements with any provider and monitor their attestation dates.

Before relying on the scope decision, check that it has been signed off by the people accountable for it and that it matches the diagrams the assessor will receive.

Why encryption projects fail to reduce scope

Encryption protects card data, but a project that encrypts PAN and stops there usually leaves the systems around it in scope. The cards below cover the failure points assessors see most often, and each one pairs the mistake with the check that catches it before the assessment.

Keys stored beside the encrypted data

If the decryption key sits in the same database, configuration file or container image as the ciphertext, the encryption adds little protection and the key store becomes part of the cardholder data environment. Requirement 3.6.1.2 expects secret and private keys to be stored encrypted under a separate key-encrypting key, inside a secure cryptographic device such as an HSM, or split into at least two full-length components. Check where every key lives and who can read it, and treat the key management system as in scope.

Decryption rights granted to broad admin groups

Teams often grant decryption to every database administrator, backup operator and cloud administrator because it is convenient. Each account that can decrypt PAN keeps those systems in scope and widens the access reviews that Requirement 7 and Requirement 8 require. Limit decryption to a named service identity, log every decrypt call, and confirm that general administrators can run queries without seeing clear PAN.

Clear PAN left in backups and logs

Encrypting the production database does not help if application logs, debug dumps, exported reports or nightly backups still carry card numbers in clear text. A scope review can miss these copies because they sit outside the main data flow. Search logs and backup sets for PAN patterns, mask card numbers at the point of logging, and confirm that every backup copy is encrypted with the same controls as the source.

Hashing that correlation can reverse

A plain hash of the PAN can be reversed by anyone who can enumerate the small space of card numbers, and a hashed value that is stored next to a truncated or tokenized PAN can be matched back to the original. PCI SSC FAQ 1308 addresses how correlating hashed and truncated PANs affects the treatment of the data. Use a keyed one-way hash based on strong cryptography, keep the key outside the hashed environment, and confirm with the assessor which other data sets could be correlated with the output.

Assuming encryption alone ends scope

PCI SSC FAQ 1086 states that encrypting cardholder data with strong cryptography meets Requirement 3.5.1 but does not take the data out of scope. Systems that encrypt, decrypt, route or can reach the keys remain in the CDE, and so do the components that connect them. Before the project closes, document a data-flow diagram that shows every place encrypted PAN moves, and ask your QSA which systems remain in scope after the change.

Questions buyers ask about encryption and PCI DSS scope

Does encryption alone take cardholder data out of PCI DSS scope?

No. Encrypting cardholder data with strong cryptography helps you meet Requirement 3.5.1, but the PCI SSC states that encryption alone does not remove the data from PCI DSS scope. The systems that store, process or transmit the encrypted data, and the systems that can affect its security, generally remain in scope. The practical effect is that encryption often reduces risk and some technical effort, while the scope boundary stays where it was. Scope is removed only through a route the standard recognizes, such as a PCI-listed P2PE solution, a qualifying tokenization design, or removing the data entirely. Confirm the boundary with your acquirer and QSA before you rely on any design.

If we store only encrypted PAN, do we have to complete SAQ D?

It can. Encrypted cardholder data still counts as cardholder data for SAQ eligibility. Every SAQ except SAQ D includes an attestation that the merchant does not store cardholder data electronically, so a merchant that stores encrypted PAN electronically generally cannot use those shorter questionnaires. Whether SAQ D applies depends on your channel, your processing model and your acquirer's rules, so ask your acquirer which SAQ or validation level they expect. Storing fewer copies of PAN, or removing stored PAN altogether, can change which questionnaire fits. Your QSA or acquirer makes the final call on eligibility.

Do we need an HSM to manage encryption keys for card data?

The standard does not name a product, but Requirement 3.6.1.2 sets the rules for how secret and private keys must be stored at all times. Keys must be encrypted with a separate key-encrypting key, held inside a secure cryptographic device such as an HSM, or split into at least two full-length key components or shares. A hardware HSM is one way to meet this, and many organizations choose it because it keeps key material out of general-purpose systems. A key-management design that meets the requirement without an HSM is possible, so ask your QSA to confirm the design. Budget for the key management system itself, because it stays in scope wherever it sits.

Can our own engineers run a PCI DSS scope review without outside help?

Your team can run the scope review, and many do. The work includes listing every system that stores, processes or transmits card data, mapping data flows, and checking that connected systems cannot reach the cardholder data environment without controls. Internal staff usually need a clear written method, current network and data-flow diagrams, and a second pair of eyes on segmentation. Assessment decisions still belong to your acquirer and QSA, who confirm the scope and any reduction you claim. An implementation partner can help prepare systems, diagrams and evidence, but the organization owns the scope decision and an independent assessor validates it.

How long does a PCI DSS encryption scope review usually take?

The duration depends on how many systems touch card data, how well the environment is documented, and how many payment channels and third parties are involved. Reviews take longer when data flows are undocumented, when card data turns up in unexpected places, or when a design change is still being decided. Your acquirer or QSA can tell you what their process requires and whether a formal review is needed before any change goes live. Ask any provider for a written scope and milestone plan, because a timeline without defined deliverables tells you little. Treat the timing as something to agree in writing, not a fixed figure.

What should we ask a partner before signing for encryption and scope work?

Ask a partner to state in writing which systems are in scope before and after the work, and which deliverables they will produce. Confirm that they prepare evidence but do not issue reports or attestations, and that an independent QSA or acquirer will validate the result. Ask how they handle key management, whether they have a plan for PAN discovery in backups and logs, and how changes are documented for the annual scope confirmation. Request the fee basis, the included deliverables and what is excluded. Ask who owns the controls after the engagement ends and what ongoing support is available under a separate retainer.

How DeployOpen scopes encryption and prepares the evidence

DeployOpen helps organizations map where encrypted card data sits, which systems still touch it, and what evidence an assessor will need. We plan, build and document the self-hosted open-source platforms in your own infrastructure, while your organization owns its controls and an independent QSA or assessor issues any report or attestation.

How we scope

Written scope lists every system that stores, processes or transmits encrypted PAN, including key management components
We map where decryption keys live and who can use them, so key systems are scoped correctly
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts

How we build

We implement key management with separate key-encrypting keys, HSM-backed storage or split key components as the scope requires
We configure hashing, truncation or index tokens where they replace stored PAN, with systems that perform the hashing kept in scope
We harden and test the in-scope systems so the controls described in the design are the ones that run in production

How we hand over

Scope documentation, data-flow diagrams and key custody records delivered for your assessor's review
Configuration baselines, test results and change records that show each control operating as documented
Clear notes on which parts of the design your organization must own and maintain after handover

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Scope is revisited when systems or payment flows change, so the written scope stays accurate
Ask us to confirm in writing which assessor, QSA or acquirer decisions remain with your organization