3.5 Securing stored PAN: requirements and evidence

What 3.5 securing stored PAN requires in plain terms

Requirement 3.5 asks one question of any system that keeps a primary account number: can someone who gets hold of this data read the card number? If the answer is yes, the PAN must be rendered unreadable wherever it sits. The standard accepts four methods: a keyed cryptographic hash of the entire PAN, truncation, index tokens that point to a value held elsewhere, or strong cryptography with proper key management. Your team picks one or combines them, but the choice has to hold for every copy, not only the main database. Since v4.0.1 is the only active version of PCI DSS, confirm the wording of 3.5.1.1 and 3.5.1.2 against the current standard and your assessor's expectations before you design around them. Disk-level encryption alone is accepted only for removable electronic media, so a server volume that is encrypted at the operating system level does not, by itself, satisfy this requirement.

The hard part is finding every copy. PAN ends up in database backups, replicas, data warehouse extracts, application and troubleshooting logs, error traces, message queues, spreadsheets exported for finance and support tickets. Requirement 3.5 reaches these non-primary stores too, so a clean production database can still fail when an old backup or debug log contains plaintext numbers. Start with a data discovery exercise that searches file systems, backup catalogs and log pipelines, then record where each copy lives and which method protects it. Ask your team to confirm whether each store is in the cardholder data environment and whether its keys are managed under Requirements 3.6 and 3.7. Plan for the cost of this discovery and cleanup as a one-time effort, then budget for recurring checks, because new logs and exports appear as the application changes.

Choosing between methods has consequences for the rest of the program. Hashes and tokens can reduce the systems that need strong key management, but a hash of a card number is only protective when it is keyed, and the SSC's FAQs on hashing and on correlating hashed and truncated values explain when hashed data may fall out of scope. Encryption keeps the full PAN available for business use but brings key custody obligations into scope. Open-source components can help produce the evidence: Nextcloud server-side encryption protects file contents at rest but does not hide file names or folder structure, so PAN must not appear in names. OpenBao's transit engine can encrypt application data with versioned keys and rotation, and GitLab pipeline secret detection can flag credentials committed to code. Confirm what each tool does in your environment before you rely on it, and ask your QSA which evidence they will sample.

Which stored PAN locations and teams fall under 3.5

Requirement 3.5 applies to every place stored PAN lives, not only the primary database. The cards below cover the storage locations and owning teams that most often surprise assessors, along with the scoping decisions that change how much work each one creates.

Primary databases and application stores

These hold the PAN that the business actually uses, such as order, subscription and customer records. Check every column, table and document field that can contain a full PAN, including fields added by developers for convenience. Confirm which protection method (hash, truncation, index token or strong encryption) applies to each field and who holds the keys. Application teams and database administrators usually own this work, and a column inventory is the fastest way to start.

File shares, exports and reports

Spreadsheets, CSV exports, dispute files and reconciliation reports often carry full PAN because someone needed it once. Search shared drives, ticketing attachments and email archives for card number patterns. Each copy either gets protected under 3.5 or is removed. Finance, operations and support teams are common sources, so the cleanup needs their participation, not only the security team's scan.

Backups and disaster recovery copies

Requirement 3.5 covers non-primary storage, so backup sets, snapshots and replicated volumes count as stored PAN. A backup encrypted at the disk level does not automatically meet 3.5.1.2, which limits that method to removable media. Confirm that backup copies use an approved method, that restore procedures keep the same protection, and that the infrastructure or backup team knows which sets contain PAN.

Audit, troubleshooting and application logs

Debug output, exception traces and audit trails are a frequent source of unprotected PAN because they capture requests as they pass through the system. Review logging configuration in each service and sample recent log files for card number patterns. Engineering and operations teams own the fix, which usually means masking at the source. Log retention periods also determine how long any leaked PAN remains in place.

Analytics stores and data pipelines

Data warehouses, reporting replicas and event streams often copy whole tables for reporting or fraud models. Trace each pipeline from its source to its destination and record where PAN is copied or transformed. A hashed PAN may be out of scope under FAQ 1089, but FAQ 1308 notes that a hashed and a truncated version of the same PAN can be correlated, so keep both forms apart or protect them together. Data engineering and analytics teams should own the pipeline inventory.

Removable media and developer repositories

USB drives, tapes and external disks may carry PAN in plain form or under disk-level encryption, which 3.5.1.2 permits only for removable media. Source code repositories and CI pipelines can also hold test data copied from production. Check removable media inventories, and scan repositories for committed card data. Pipeline secret detection tools can help with secrets but must be configured and reviewed for card number patterns.

How a QSA tests stored PAN unreadability

This table shows what a QSA typically checks for each accepted way of rendering stored PAN unreadable, the evidence requested and where assessments usually find gaps. Read each row as a test an assessor runs on the systems in scope, from the data discovery results through to the key records and storage locations.

Method or rule	What the assessor tests	Evidence requested	Common findings
Keyed hash of the entire PAN (3.5.1, 3.5.1.1)	The hash is a keyed cryptographic hash of the full PAN, the key is managed under 3.6 and 3.7, and hashed values cannot be reversed by a brute-force lookup of PAN space.	Hashing algorithm and key configuration, key custodian and rotation records, sample of hashed records from each store.	Unkeyed hashes of PAN, hashes that are truncated or salted inconsistently, and keys stored beside the hashed data.
Truncation (3.5.1)	Only the permitted digits remain, and the truncated value cannot be combined with other stored data to rebuild the full PAN.	Truncation logic in code or database schema, sample records, and the data flow showing where full PAN is still written.	Truncated and full PAN stored in the same table, or in logs, backups and exports that bypass the truncation step.
Index tokens (3.5.1)	The index is stored separately from the PAN it points to, and the mapping cannot be reproduced without the protected store.	Token index design, access rights to the index store, and the separation evidence between the two stores.	Index and PAN kept in the same database or backup set, which weakens the separation the method relies on.
Strong cryptography with key management (3.5.1)	The cipher is strong, keys are generated, stored and rotated under 3.6 and 3.7, and decryption is limited to authorized processes.	Cipher and mode configuration, key inventory, rotation and custodian records, and access logs for decryption services.	Keys held in application configuration files, shared keys across environments, or no record of key rotation.
Disk or partition encryption (3.5.1.2)	Assessor confirms the encryption is applied only to removable electronic media, or that PAN is also protected by another accepted method on any other system.	Inventory of storage types, encryption settings per host, and the second protection method where disk encryption is used.	Server volumes encrypted at disk level as the sole protection, and encrypted volumes that are mounted and readable to any logged-in process.
Non-primary storage (3.5 scope notes)	Backups, audit logs, troubleshooting logs and exports are sampled and checked for readable PAN in the same way as the primary database.	Backup policy and job configuration, log samples, and data discovery results for each location.	PAN in debug logs, crash dumps, support exports or replicated backups that were never added to the inventory.
Data discovery and sampling	Assessor reviews how the entity found PAN across systems and samples locations to confirm the results.	Discovery tool scope, scan reports, the list of locations sampled, and any exclusions with their justification.	Discovery run only against the primary database, or exclusions without a documented reason.
Hashed data scope (FAQ 1089, FAQ 1308)	Assessor decides whether hashed values are in scope and checks that hashed and truncated versions of one PAN cannot be correlated.	Scope documentation, the correlation analysis, and the controls that keep the two forms apart.	Hashed and truncated copies of the same PAN stored together, allowing correlation to rebuild the number.

Implementing unreadable PAN step by step

This sequence takes stored PAN from unknown locations to a documented, tested state where every copy is unreadable under Requirement 3.5.1 or is removed. Each step closes with an artifact an assessor can inspect.

Discover every location holding PAN
Search databases, file shares, object storage, application logs, support exports, message queues, backups, snapshots, developer workstations and analytics stores for primary account numbers. Use data discovery tooling where it fits your estate, and check repositories and CI/CD artifacts too, since credentials and card data both leak into them. The output is a location inventory that lists each store, its owner, the data elements found and whether the store sits inside the cardholder data environment. Treat the inventory as incomplete until a second method, such as a sample review or a manual walk through the application flows, confirms it.
Classify each store and choose a method
For each location, decide which accepted method renders PAN unreadable: a keyed cryptographic hash of the entire PAN, truncation, index tokens, or strong cryptography with key management. Record why the method fits the store's access pattern, for example whether the application must retrieve the full number later, which rules out hashing alone. Confirm with your QSA or internal assessor whether a store can be removed from scope instead. The output is a per-store decision record that names the method and the reason for it.
Deploy keyed hashing or encryption with key management
Implement the chosen method using vetted cryptographic libraries or a managed secrets and encryption service. For example, an application can call an encryption transit engine such as OpenBao's transit secrets engine so that the application never holds long-term keys, while the engine supports versioned keys and rotation. Where keyed hashes are used, the key must be managed under Requirements 3.6 and 3.7. Disk-level encryption alone does not satisfy 3.5.1 for stored PAN on servers, and is limited to removable electronic media. The output is a change record, a tested decrypt or lookup path, and key custody records.
Migrate or purge existing clear PAN
Re-encrypt or re-hash historical records, then remove clear-text copies from the old location. Where the data is no longer needed, delete it under the retention rules in Requirement 3.2 rather than migrating it. Verify the migration with row counts, sample reconciliation and a search for residual clear PAN across the inventoried stores. The output is a migration report and a re-run of the discovery search showing no unprotected PAN remains in the stores you inventoried.
Verify backups, logs and non-primary storage
Requirement 3.5 covers non-primary storage such as backups, audit logs and troubleshooting logs. Confirm that backup sets, snapshots, replicas and log pipelines either hold only protected PAN or are excluded from receiving PAN at all. Check that restore procedures return data that stays protected, and that old backup generations are handled under your retention schedule. Logging frameworks often capture request bodies, so test them with a known test PAN. The output is a verification record for each backup and log destination, including the test results.
Confirm hashed and truncated copies cannot be correlated
If you keep hashed and truncated versions of the same PAN, check that an attacker or an internal user cannot link them to recover the full number. Review how the hash input, salt or key, and the truncation pattern interact, and document the analysis. Apply the scope questions in the relevant PCI SSC FAQs before concluding that a hashed PAN sits outside scope. The output is a correlation analysis signed off by the security owner and reviewed with your assessor.
Document decisions and retain assessor evidence
Bring the inventory, method decisions, key management records, test results and verification records into one evidence pack that maps each store to the requirement it satisfies. Keep the procedures current and assign owners for ongoing discovery, since new stores appear with every new integration. Your organization owns these controls, and an independent QSA decides whether the evidence meets the requirement. The output is a controlled evidence folder with a named owner and a review date on each record.

Why disk encryption alone does not protect stored PAN

Full-disk or partition encryption on a server is not, by itself, a way to protect stored PAN under Requirement 3.5. Requirement 3.5.1.2 allows disk-level or partition-level encryption as the only PAN protection only on removable electronic media, and that limit became mandatory on 31 March 2025. A database volume, file share, backup target or log directory on a fixed server does not qualify simply because the underlying disk is encrypted. Your team needs to decide, for each location where PAN lands, whether it is protected by one of the accepted methods in 3.5.1 (keyed hashing, truncation, index tokens or strong cryptography with key management) or whether it is removable media covered by 3.5.1.2.

Server-side disk encryption does useful work, but its protection is narrower than many teams assume. It guards data at rest against someone who removes the drive or copies the raw volume without the keys, which matters for decommissioning and physical loss. It does not stop an authenticated user, a compromised service account or a process running on the host from reading PAN through the normal file system, because the operating system decrypts the data for every legitimate reader. Some server-side encryption features also leave file names, folder structure and metadata visible. The open-source Nextcloud server, for example, documents that its server-side encryption protects file contents but not file names or folder structure, so a PAN embedded in a file name would remain readable.

Before relying on disk encryption for any location holding PAN, confirm the position with your QSA or assessor in writing. Ask which storage locations they will treat as removable media, whether they accept volume encryption as a control for non-primary stores such as backups, audit logs and troubleshooting logs, and how they will test that PAN is unreadable in those places. Document the decision in your data inventory, and record the key custody and access paths that make the encryption meaningful. Where the answer is no, plan to apply application-level strong cryptography with key management, a keyed hash or truncation to the PAN itself, and then test that stray copies cannot be reconstructed from the remaining data.

Evidence that shows stored PAN is unreadable

An assessor testing 3.5 Securing stored PAN wants to see where account data lives, how each copy was made unreadable, and proof that the method still works. The cards below cover the records that connect those answers, and each one needs a named owner and a refresh trigger so it stays accurate between assessments.

Data discovery reports

A discovery report lists every location where PAN was found, including databases, file shares, log files, backups, ticket attachments and developer workstations. Run discovery on a defined schedule and after major application or migration changes, because a scan that is months old will not show new stores. Check that the report covers non-primary storage such as backups, audit logs and troubleshooting logs, since 3.5 applies to those as well. Record how each finding was resolved, whether by deletion, truncation or a protection method.

Method decision records per store

For each store that keeps PAN, record which accepted method renders it unreadable: keyed hash of the full PAN, truncation, index token, or strong cryptography with key management. Explain why that method suits the store and who approved it. Where a hashed value and a truncated value of the same PAN exist, document how they are kept from being correlated, and confirm the approach against the PCI SSC FAQ on that question before relying on it. Review the record whenever the store's purpose or data flow changes.

Key management records tied to 3.6 and 3.7

Any store protected by encryption or keyed hashing depends on keys, so the assessor will trace each key back to its management records. Keep an inventory of keys that map each key to the stores it protects, its custodians, its cryptoperiod, and its rotation history. Link these records to the key lifecycle and key custodian evidence defined under 3.6 and 3.7. Confirm the rotation and re-encryption steps have been performed and logged, not only planned.

Configuration exports

Configuration exports show the protection is switched on in the running system. Capture the relevant settings from each platform, such as the server-side encryption state of a file store, the transit encryption engine configuration in a secrets service, or the database column protection settings. Store exports with timestamps and the person who took them, and compare them against the approved configuration baseline. Ask the platform owner which settings change behavior silently, because a passing export today does not prove a later upgrade kept it.

Sample verification outputs

Sample verification shows that a protected value cannot be read back in clear text by unauthorized users or processes. Pick a sample of records from each store, attempt retrieval through normal application paths and direct access, and keep the outputs showing that only the expected components can decrypt or match a hash. Include negative tests such as reading a truncated field to confirm the full PAN is absent. Repeat the sample on a fixed cadence and after any change to the store.

Backup and log coverage records

Backups, audit logs and troubleshooting logs are frequent places where unprotected PAN survives, so the assessor will ask for coverage records for each. Document which backup sets and log pipelines exist, the protection applied to each, and how restored copies inherit the same protection. Confirm that debug output and crash dumps are either excluded or masked. Recheck coverage after each new backup target or logging change, since a new collector can capture data the earlier review never saw.

What meeting 3.5 costs in money and effort

This table lists the cost components of meeting Requirement 3.5, who is typically paid for each, whether the cost is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to see where self-hosted open source can remove license spend. No fees or durations are given because none were supplied for this topic.

Cost component	Who is paid	One-time or recurring	What drives the cost
Discovery of stored PAN	Internal team or a scanning tool vendor, plus any consultant running the search	One-time, then recurring with each scan cycle	Number of systems, backups, audit logs and troubleshooting logs in scope, and how much unstructured data exists
Re-architecting stores to unreadable forms	Internal engineers or an implementation partner building keyed hashes, truncation, index tokens or encryption	One-time for most work, with ongoing change effort	Number of databases and file stores holding PAN, schema changes needed, and application dependencies
Key management licenses or hosting	Commercial key management vendor, cloud provider, or your own hosting team	Recurring license or hosting, plus one-time setup	Number of keys, rotation frequency, high availability, and whether keys are held on premises or in the cloud
Self-hosted open-source key management	Your team or an implementation partner for installation, hardening and operation	One-time build, recurring operations staff time	Staff skills, backup and recovery design, and the depth of documentation your assessor will expect
Evidence upkeep	Internal compliance staff, with time from engineers for configuration records	Recurring, tied to each assessment cycle	Number of stores in scope, how often keys rotate, and whether evidence is generated automatically or collected by hand
External testing or review	Independent testers or reviewers, chosen by you and separate from the assessor	Recurring, usually tied to change or assessment dates	Scope of the review, number of changes to PAN stores, and whether previous findings remain open
Assessor sampling and testing time	Qualified Security Assessor, paid by you under the engagement agreement	Recurring each assessment cycle	Number of stores and keys the assessor samples, and how well your evidence is organized before fieldwork
Keeping hashed and truncated copies separate	Internal engineers and, if needed, legal or compliance review	One-time design, with recurring checks on new data flows	Whether hashed and truncated versions of the same PAN can be correlated, a question covered by PCI SSC FAQ 1308

Open-source tools that support unreadable PAN

OpenBao is an open-source fork of HashiCorp Vault distributed under the MPL-2.0 license. Its transit secrets engine lets an application send data to the server for encryption or decryption, so the application does not hold the encryption key itself. The engine also signs and verifies data and supports versioned encryption keys with key rotation, which helps when PAN ciphertext must be re-encrypted under a newer key version.

Application-level encryption: The service encrypts PAN before it reaches the database, and the transit engine returns ciphertext that is unreadable without access to the key.
Versioned keys: Ciphertext records the key version used, so older data can still be decrypted while new writes use the current version.
Key rotation: Operators can rotate the key and plan re-encryption of stored values as a scheduled task.
Access policies: Only named applications or roles can call encrypt or decrypt, and those calls can be logged for review.
Limits: The engine does not decide which fields hold PAN, whether a keyed hash or truncation is a better fit for a given store, or how backups and logs are handled.

Confirm with the OpenBao documentation how key material is protected, how the engine is deployed in high availability, and whether your version supports the rotation workflow you intend to use. Document the key hierarchy and access model as evidence, because the tool alone does not satisfy Requirement 3.5.

GitLab Community Edition is licensed under MIT. Its pipeline secret detection runs as a CI/CD job that scans files committed and pushed to the repository, and writes detected secrets to a gl-secret-detection-report.json job artifact. The feature is available in every tier, which makes it a practical way to check that encryption keys, database credentials and key-management tokens are not stored in code, where they would undermine the protection of stored PAN.

Pipeline job: Detection runs on pushed changes, so the result is tied to a specific commit and pipeline run.
Report artifact: The JSON report can be retained as evidence that the check ran and what it found.
Key hygiene: Finding hard-coded keys early supports the governance expected under Requirements 3.6 and 3.7.
Coverage gaps: Scanning covers committed and pushed files, so secrets already in history, in configuration managers or in runtime environments need separate handling.
Remediation records: The tool does not rotate a leaked key. Teams must record revocation, rotation and the review of any access the key allowed.

Confirm the scanner rules and the report retention period with the GitLab secret detection documentation, and decide who triages findings. A passing pipeline shows one control operating, not that stored PAN is unreadable across the environment.

Where stored PAN programs usually fall short

Most stored PAN failures are not missing encryption products. They are gaps in where PAN is kept, how it is protected in each location, and whether the protection is tied to key management. The cards below cover six gaps assessors often find, each paired with a check you can run before the next assessment.

Unkeyed hashes of PAN

Requirement 3.5.1.1 expects hashes used to protect PAN to be keyed cryptographic hashes of the entire PAN, with the keys managed under 3.6 and 3.7. Teams often hash card numbers with a plain algorithm, which an attacker with the full PAN space can reverse. Check each hashing routine in your code and data pipelines, confirm a secret key is involved, and confirm that key sits under your key management controls.

PAN in backups and logs

Requirement 3.5 applies to non-primary storage, including backups, audit logs and troubleshooting logs, not only the production database. A correctly encrypted primary store can still leak PAN through a nightly backup copy or an application log that recorded a request body. Inventory backup sets, log sinks and replicas, then search them for unprotected PAN patterns and confirm each copy is covered by one of the accepted methods.

Forgotten troubleshooting exports

Support engineers often export transaction records to spreadsheets, CSV files or ticket attachments to diagnose a failed payment. These copies sit outside the systems that teams manage and are rarely listed in any inventory. Ask your support and operations leads for their export habits, search shared drives and ticketing systems for card-like strings, and set a rule that exports must mask or tokenize PAN before they leave the system.

Disk encryption as the only control

Requirement 3.5.1.2 allows disk-level or partition-level encryption as the sole protection for PAN only on removable electronic media. Many server and virtual machine builds rely on full-disk encryption alone, which protects data at rest from a stolen drive but not from anyone who logs in to the running system. Review each server build for PAN storage, and where PAN sits on a fixed disk, add one of the accepted methods such as keyed hashing, truncation, index tokens or application-level encryption.

Encryption keys without a 3.6 and 3.7 link

Strong encryption or keyed hashing only protects PAN if the keys are managed properly. Teams sometimes store the encryption key in the same configuration file or database as the encrypted data, or rotate data without any key lifecycle record. Trace each protection method to the key that supports it, then confirm the key has a named custodian, storage location and rotation record that match the controls in Requirements 3.6 and 3.7.

No current discovery report

A PAN protection design is only as good as the inventory it is built on. Without a dated discovery report that lists every location where PAN was found, assessors cannot confirm that the accepted methods cover all of them, and teams cannot tell whether a new system has added card data. Run a discovery scan across databases, file shares, logs and backups, record each finding with its protection method and owner, and repeat the scan on a schedule and after major system changes.

Questions buyers ask about 3.5 cost, effort and evidence

What drives the cost of meeting requirement 3.5 for stored PAN?

The cost depends mainly on how many places PAN is stored and how many systems must be changed to protect it. Buyers should expect costs in three groups: internal staff time for discovery and data-flow mapping, engineering work to implement keyed hashing, truncation, tokenization or encryption, and assessor fees for validating the result. Recurring costs include key management operation, log and backup handling, and re-validation each year. Ask any provider to price discovery, implementation and evidence collection as separate line items so you can see which parts are one-time and which recur. No figure is given here because the source material does not supply one; confirm costs against your own environment and written scope.

How long does it take to secure stored PAN and who needs to be involved?

Duration depends on the number of data stores, the age of the code that writes PAN, and how quickly the key management design is agreed. Work usually involves developers, database and backup administrators, the team that owns log pipelines, and the people who approve cryptographic decisions. Because requirement 3.5 also reaches backups, audit logs and troubleshooting logs, those owners must be included early or the schedule slips. No duration is supplied for this work, so ask any partner for a timeline tied to a written list of stores and systems in scope.

Can an in-house team secure stored PAN without outside help?

Yes, an in-house team can meet requirement 3.5 if it has engineers who understand strong cryptography, key lifecycle controls and the payment data flows. The usual gaps are complete discovery of stray PAN in logs, backups and exports, and a clear record of why each protection method was chosen. Teams often find that the hardest part is not the cipher but proving that every copy has been found. An outside implementation partner can help with discovery and build work, while the organization keeps ownership of the controls. The independent assessor still decides whether the evidence is sufficient.

Can a partner run PAN discovery across our systems?

A partner can run discovery as part of a fixed-scope engagement, covering databases, file shares, backups, audit logs, troubleshooting logs and exports. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so discovery results and remediation sit in your environment. The scope, deliverables and timeline are agreed in writing before work starts. Ask the partner which search methods it uses, how it handles false positives, and how it records the systems it searched so the assessor can follow the trail.

What does the client need to provide before work on requirement 3.5 starts?

The client needs to provide a current inventory of systems and data stores, network and data-flow diagrams, access to representative environments, and named owners for each system. Access to key management decisions and the policies that govern key custody is also required. Without an accurate list of where PAN lives, any design will miss copies. Ask your partner for a written list of required inputs at the start of the engagement so that delays are visible early.

How does the customized approach apply to requirement 3.5?

The customized approach lets an entity meet the stated objective of a requirement in a different way, and PCI SSC describes it as available to entities with robust security and risk management. It is not a shortcut. For requirement 3.5, the objective is that stored PAN is unreadable, so a customized design must still show that PAN cannot be recovered, with documented risk analysis and evidence. Confirm with your assessor whether they will accept a customized approach before you design around it. Compensating controls are a separate route for requirements that cannot be met at all, and the two should not be confused.

What evidence does the assessor need to accept PAN protection?

The assessor will look for a documented list of the accepted methods, proof that each stored PAN is rendered unreadable, and records of the key management processes behind any encryption or keyed hashing. For each data store, expect to show configuration, a test that the data cannot be read in clear form, and a discovery result that covers backups and logs. Evidence should be dated and repeatable. Ask your assessor early which artifacts they expect, because the format of acceptable evidence is set by their review, not by the vendor.

Which tools can produce evidence for PAN protection?

Open-source platforms can produce useful evidence. Nextcloud server-side encryption protects file contents at rest, but it does not encrypt file names or folder structure, so PAN in names still needs separate handling. OpenBao's transit secrets engine encrypts application data without storing it and supports versioned keys with rotation, which produces key lifecycle records. GitLab pipeline secret detection writes findings to a report artifact, which helps find credentials but is not a PAN scanner. Confirm each tool's fit against your data flows before relying on it.

How DeployOpen works on this

DeployOpen works on 3.5 Securing stored PAN inside your own infrastructure, starting with a written scope that identifies every location where stored PAN lives. We prepare the systems, controls and evidence that an independent QSA will examine, while your organization keeps ownership of the controls and the assessment decision.

How we scope

Map every store of PAN, including databases, file shares, backups, audit logs and troubleshooting logs.
Confirm which PAN protection method applies to each store: keyed hash, truncation, index token or strong encryption.
Agree the written scope, deliverables and timeline with you before any work starts, as most engagements are fixed-scope.

How we build

Configure keyed hashing or encryption for PAN fields, with key handling aligned to Requirements 3.6 and 3.7.
Restrict disk-level encryption to removable electronic media, or pair it with another documented PAN protection method.
Test that PAN is unreadable in each store by inspecting stored data, not only configuration files.

How we hand over

Document each PAN store, its protection method, key owner and the test that proves unreadability.
Deliver evidence packs such as configuration exports, test results and change records that your assessor can sample.
Walk your team through the runbooks so your staff can operate and explain the controls during assessment.

How we support

Offer ongoing support, upgrades and continuous testing for the systems we built, available as a retainer.
Re-check PAN stores after changes to backups, logging pipelines or new integrations that touch cardholder data.
Confirm with your QSA which evidence format and sampling they expect before the assessment begins.