Start with payment flows and the assessment boundary
PCI DSS applies to entities that handle cardholder data or sensitive authentication data, and to entities that can affect the security of the cardholder data environment. Confirm the payment flow, service-provider responsibilities and validation approach with the party receiving the assessment. Discovery results help scope discussions but do not independently settle scope.
Sources: [1]
Distinguish cardholder data from authentication secrets
Account data includes cardholder data and sensitive authentication data. PCI SSC explains that Requirement 3.3.1 prohibits retaining sensitive authentication data after authorisation, even when encrypted. Issuer-specific applicability needs to be assessed against the full standard. A discovery policy must not make prohibited retention acceptable by moving a finding into a new archive.
Sources: [2]
Search the locations where copies accumulate
Choose a controlled discovery scope based on the payment flow. Review shared work areas, approved exports and support workflows where people might copy payment information. Use safe test records to evaluate detection before running a production scan.
When a candidate finding appears, validate the result and identify the owner. Document the location and the business process without unnecessarily exposing the full payment data. Work with the payment-security team to decide whether removal, tokenisation, a workflow change or another measure is appropriate. These are practical response options, not an automatic PCI scope reduction.
Avoid turning incident evidence into another data store
Decide what event details are necessary for review. Where possible, keep masked context, a policy reference and a controlled pointer to the source rather than copying payment content into email or tickets. Restrict evidence access and test the retention process.
After remediation, repeat the discovery test and verify the underlying workflow. A deleted spreadsheet may return if a scheduled export or support procedure continues to recreate it. Assign the root-cause action to a named owner.
Use current assessment documents
Use the v4.0.1 documents and the correct assessment form from PCI SSC. The limited v4.0.1 revision clarified the standard rather than adding or deleting requirements. The 31 March 2025 effective date for future-dated requirements has already passed.
Practical checklist
- Confirm payment flows, owners and the intended validation method.
- Test discovery with safe payment-data samples and review false positives.
- Keep sensitive authentication data out of investigation copies and ordinary tickets.
- Verify remediation, evidence access and the process that produced the original copy.
Applying this with TRIAS
Use a TRIAS proof of concept to evaluate payment-data discovery and supported DLP channels in your environment. Confirm which data elements and file types are detected, how findings are reviewed and what evidence is retained. DLP is one control within the wider PCI DSS assessment.
Official sources
Last checked: . Practical examples are editorial implementation suggestions. Applicability depends on your organisation and jurisdiction.
- PCI SSC — PCI DSS scope and intended audience (opens in a new tab)
- PCI SSC — FAQ 1154, sensitive authentication data (opens in a new tab)
- PCI SSC — Document Library (opens in a new tab)
- PCI SSC — Publication of PCI DSS v4.0.1 (opens in a new tab)
- PCI SSC — Future-dated v4.x requirements (opens in a new tab)