PCI DSS covers any organisation that stores, processes or transmits cardholder data, or that can affect the security of the cardholder data environment. The biggest lever a CTO has is scope: keep card numbers out of your systems, and the number of requirements and systems you must prove falls sharply.
Who does PCI DSS apply to?
The PCI Security Standards Council says the standard is for entities that store, process or transmit cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment. That includes merchants, processors, acquirers, issuers and service providers. Which validation path you follow, such as a self assessment questionnaire or an assessment by a Qualified Security Assessor, depends on your role and what your acquirer or card brands require. Ask your acquirer.
Why does scope matter so much?
Every system that stores, processes or transmits card data is in scope. So are systems connected to those, and systems that provide security services to them. A flat network with a payments database in it can turn a whole company into the assessment. A narrow segment with a few systems turns the same company into a small exercise.
How do you reduce scope?
Three design choices do most of the work:
- Hosted fields or redirect. The payment provider collects the card number in its own frame or page, so the number never reaches your servers. Your page still affects security, so script control remains important.
- Tokenisation. Store a token from the provider, not the card number, and keep the vault outside your estate.
- Segmentation. Isolate the systems that must touch card data with network controls, separate identity and tight administrative access, then test that the isolation holds.
A constructed example: a subscription app takes card numbers in its own checkout form, passes them through its API and logs requests for debugging. Card numbers end up in logs, backups and a data warehouse, so each of those is in scope. Switching to hosted fields and scrubbing logs removes them from the picture.
What do the 12 requirement areas ask of engineering?
The standard groups requirements into twelve principal areas: network security controls, secure configurations, protecting stored account data, encrypting data in transit, malware protection, secure systems and software, restricting access by need to know, identifying and authenticating users, physical access, logging and monitoring, regular testing, and policies. For engineers, the software area means a vulnerability process and secure development practice, and the testing area means scans and penetration tests.
What about third parties?
Service providers that touch your cardholder data environment are part of your compliance story. Keep a list of which requirements each provider covers and which you cover, and get their evidence of compliance each year. Open source dependencies in payment code are part of your software inventory, so scan them and track fixes.
What to do
- Find every place card data appears, including logs, backups and exports.
- Move to hosted fields or redirects and tokens where you can.
- Segment what remains and document the boundary with a diagram.
- Confirm your validation path and assessor needs with your acquirer.
- Keep an inventory of third party services and dependencies in scope, and scan them.
- Control scripts on payment pages.
- Review scope whenever a new integration or data store is proposed.
Quick check
If we use a payment provider, are we out of scope?
Not automatically. Using hosted fields reduces scope a lot, but your site and your obligations toward the provider remain. Confirm your validation path with your acquirer.
Does PCI DSS apply to small businesses?
It applies to any entity that handles cardholder data. The way you validate varies with size, volume and what your acquirer asks for.
Sources
Last reviewed: 18 October 2026.
