Most organizations operate under a straightforward assumption: if you don’t directly process payment cards, PCI DSS compliance isn’t your responsibility. The logic seems sound. A customer enters card data somewhere. It goesto a payment processor. Your systems touch it minimally, if at all. And if you’re using tokenization, you’re plainly avoiding card data handling entirely.
But here’s what happens: card numbers are being logged by your systems without you knowing it.
Your webhooks receive payment notifications you didn’t realize were payment notifications. Your test databases contain copies of production data developers needed for debugging. And you’ve never checked any of it.
Many organizations discover this during a breach or audit, when they trace the actual data flows and realize cardholder data has been flowing through systems they thought were isolated. Now they’re retrofitting controls they didn’t budget for, issuing breach notifications to millions of cardholders, and explaining to leadership why this conversation should have happened months earlier.
The cost is steep. Fines range from $5,000 to $100,000 per month, depending on the acquiring bank, payment card brands, and severity. But no matter the cost, the reputational damage from breach is what breaks organizations.
As a result, the question shouldn’t be whether your system touches card data. It’s whether card data touches your system.
Understanding where that data goes is where most organizations discover they’ve been wrong.
The Systems You Didn’t Know Were in Scope
Here’s the principle: scope isn’t determined by intent. It’s determined by whether cardholder data touches your systems.
A customer enters a card number at checkout. That data moves from their browser to your system, from your system to a payment processor, from the processor to an issuing bank, then back through networks. But the journey doesn’t end at the processor.
Along the way, that data passes through an API integration you wrote. It gets captured in application logs, web server logs, and database query logs before it goes anywhere. Your logging infrastructure is now in scope. It might be cached in memory for performance. Your caching layer is in scope. It appears in settlement reports and backups. Your archival systems are in scope.
Most organizations don’t recognize that all these seemingly small interactions with card data qualify for PCI compliance. Not because they were careless when they built their systems, but because cardholder data moves through infrastructure in ways that aren’tobvious from the outside.
The question then becomes straightforward: where is cardholder data flowing through your infrastructure right now? The only way to answer that honestly is to ask yourself the following questions.
How to Know If PCI Applies to You
Are card numbers being logged in your systems?
Logging is where card numbers live unintentionally. If cardholder data ever flows through your system, it often appears in application logs, web server logs, database query logs, and API logs. Unless you’ve explicitly prevented it, it’s there.
Can your staff see full card numbers, even in logs? If employees can access logs, databases, or reports that display full Primary Account Numbers, you’re in scope.
Is encryption giving you false confidence?
Encrypted cardholder data still triggers PCI DSS requirements. The decryption keys often live in the same environment as the encrypted data. If someone gains access to your systems, they can decrypt it. PCI doesn’t care that the data is encrypted if the keys aren’t separated from the ciphertext.
Does your system store, cache, or transmit card data in any form? Caching payments in memory. Storing tokens in your database. Transmitting card numbers between systems. Archiving transaction data. All in scope.
Does tokenization actually eliminate your responsibility?
Tokenization reduces what you have to secure. It doesn’t eliminate PCI scope or requirements. Tokens and network tokens are payment credentials covered by PCI DSS. You still need to secure the tokens, manage the APIs that use them, and ensure your infrastructure can’t be compromised to extract them.
Do you integrate with payment gateways, processors, or payment APIs? If you’ve written code to call a payment processor’s API, written webhooks to receive callbacks, or built integrations to payment platforms, integration security is your responsibility, not the processor’s.
Does your transaction volume determine applicability?
You can process 100 transactions a year or a million. If you process cardholder data, you’re in scope. Small businesses are specifically targeted by attackers because they’re presumed fragile.
Does submitting an SAQ mean you’re compliant?
Many organizations complete a Self-Assessment Questionnaire, check every box yes, submit it, and stop. They’ve now documented non-compliance as “yes, we are compliant.” PCI DSS requires you to comply with the standard in its entirety.
Completing an SAQ Type C covers 123 specific requirements, but it’s not the full standard. Many PCI requirements exist outside the SAQ questionnaire. Checking every box means you’ve answered the questions, but it does not mean that you’re compliant with PCI DSS in its entirety.
Where else is cardholder data hiding?
Backup systems, disaster recovery environments, and archived data are consistently forgotten. If your backups contain cardholder data, they’re in scope. If you replicate production data to a disaster recovery environment, that environment is in scope.
Does cardholder data exist anywhere outside your primary payment-handling systems? In backups. In test environments. In deployment systems. In disaster recovery. If yes, those systems are in scope.
Same applies to your deployment infrastructure. If cardholder data flows through your CI/CD pipeline, git repositories, artifact repositories, or build systems, those systems are in scope. Developers often commit test data to version control. That version control system is now in scope and needs controls.
How much does scope expand through integration?
Your payment processor is PCI compliant. Your API integration with that processor is your responsibility.
Does payment card data pass through your system in any form? Direct payment processing. Integration with payment gateways. Hosting payment collection forms or iFrames. Receiving card data in API calls. Logging transaction data. Storing tokens. Handling encrypted card numbers. If payment data flows into your infrastructure at any point, you need to know where it goes.
If your API endpoints receiving payment confirmations are vulnerable, if your webhooks aren’t validated, if you’re caching tokens, if you’ve connected development systems to payment infrastructure, if your cloud environment hasn’t been segmented to isolate cardholder data, all of these expand scope. Third-party compliance doesn’t reduce your integration responsibility.
Can systems outside cardholder data reach systems inside?
Systems that don’t directly touch cardholder data can still be in scope if they can reach systems that do (shared databases or shared network infrastructure).
If an attacker can compromise one system and move laterally to systems handling cardholder data, that lateral-movement path is in scope. This is why segmentation matters. Not just having different VLANs or firewall rules, but verifying that systems can’t reach each other. Organizations often assume segmentation is effective because it’s documented, only to discover during assessment that the actual controls still allow easy lateral movement between network segments.
Are your dev and test environments really isolated?
Do you host payment forms, iFrames, or JavaScript that handles card data? If your servers deliver the code that collects card numbers from customers, even if that code immediately sends the data to a payment processor, you’re in scope. You control the trust chain.
Are your dev and test environments isolated from production card data? If you copy card data to test systems, if developers can access production payment data, if test environments aren’t separated from production by network controls, those test systems are in scope. And they need the same controls as production.
IF YOU ANSWERED YES TO ANY OF THESE QUESTIONS, PCI DSS COULD APPLY TO YOU.
What Happens Next
Determining your actual scope is straightforward and practical. You identify every system cardholder data touches. You implement controls appropriate to that data flow. You verify that you’re implementing what your acquiring bank will require, not what you guessed they’d require. No surprises during assessment. No discoveries of scope gaps during breaches.
This is where experienced assessors matter. Not to audit you. To bring pattern recognition from dozens of scope determinations. To know which systems your specific acquiring bank will flag. To identify gaps before you’ve built controls around the wrong scope. Organizations that bring assessors in early avoid retrofitting, avoid assessment delays, and avoid the expensive discovery that they built their compliance program against incomplete scope.
Drummond is one of the longest-running Qualified Security Assessors (QSA) in the industry. We know the patterns. We know where cardholder data hides. We know which scope interpretations different acquiring banks enforce. A readiness assessment shows you exactly where cardholder data lives in your infrastructure, which PCI requirements apply to your situation, and how your acquiring bank will assess you. The clarity matters far more than it appears.