Table of Contents
The world of digital payments is evolving at a remarkable pace, and with it, the demands for cardholder data security are increasing. The PCI DSS (Payment Card Industry Data Security Standard) forms the bedrock of this security, yet its proper understanding and implementation continue to pose challenges for many organisations. Even seasoned professionals frequently fall into interpretative traps, which can cost a company not only substantial penalties but also a loss of reputation.
In this article, we shall examine the most common misconceptions regarding the scope of PCI DSS and discuss the key new controls introduced in version 4.0.1 of the standard. Our aim is to help you avoid costly mistakes and ensure an appropriate approach to compliance with security requirements.
Pitfall One: ‘We do not store cardholder data, so we are not in scope for PCI DSS’
This is one of the most common and dangerous assumptions. Many organisations misinterpret the scope of PCI DSS, focusing exclusively on the storage of full payment card numbers.
In reality, according to the definition of certification scope, all organisations that transmit, store, or process cardholder data, as well as those that impact its security, fall within the remit of PCI DSS. This means that even if your company does not directly store card numbers, but, for example:
- Manages network infrastructure through which cardholder data flows
- Provides hosting services for payment applications
- Oversees physical security at locations where payments are processed
- Supplies system components supporting the payment environment
Your organisation may still be in scope for PCI DSS certification.
The scope of certification encompasses four key areas: Technologies (Product), People, Partners (Subcontractors), and Management Processes. Any element with access to the cardholder environment, or which may influence its security, must be included in the certification.
Pitfall Two: ‘My vendor is certified, so I do not need to be’
Another frequent pitfall is the belief that engaging a certified service provider automatically absolves one of responsibility for PCI DSS compliance.
A vendor’s compliance confirms only the security of the vendor’s environment, not your own environment or the manner in which you utilise the vendor’s services. While using a PCI DSS-compliant provider assists in achieving compliance, it does not remove your obligations.
According to PCI DSS guidelines, organisations are responsible for controlling and monitoring all third-party scripts on their websites, even if those scripts originate from certified providers. This means that:
- You must conduct due diligence on your suppliers
- You are required to monitor how their solutions are implemented within your environment
- Regular checks of supply chain compliance are necessary
- Outsourcing may, at times, broaden the scope of compliance rather than reduce it
Pitfall Three: ‘We use network tokens, so we are outside PCI DSS scope’
This is a relatively recent misconception, which has gained traction with the development of tokenisation technologies. Many organisations mistakenly assume that the use of network tokens automatically excludes them from PCI DSS requirements.
According to Visa regulations, all payment credentials (not just cardholder data) fall within the scope of PCI DSS, and the definition of payment credentials includes both tokens and network tokens. This crucial distinction demonstrates that tokenisation does not eliminate the need for PCI DSS compliance.
The purpose of PCI DSS is to protect against fraud; therefore, any instrument that could facilitate fraud remains within its scope. Network tokens, whilst significantly more secure than traditional card numbers, can still be used to conduct transactions and thus require appropriate protection.
Tokenization may simplify compliance validation efforts by reducing the number of system components subject to PCI DSS requirements, but it does not entirely remove the need for certification.
Key New Controls in PCI DSS 4.0.1
PCI DSS 4.0.1 has introduced significant changes aimed at strengthening security and adapting requirements to contemporary cyber threats. From our experience, these present both challenges and difficulties for many organisations.
Control One: Obligation to Document PCI DSS Scope (Requirement 12.5)
A new requirement for every organisation is the obligation to document the scope. In accordance with requirement 12.5.2 of PCI DSS v4.0.1, the scope must be documented and reviewed and updated at least annually.
This control requires organisations to:
- Create formal documentation describing all elements of the cardholder environment
- Regularly review and update this documentation
- Include all four areas of scope (the 4Ps of certification)
Scope documentation is the foundation of effective PCI DSS certification. If you are unsure how to prepare such a document, it is advisable to utilise expert templates available in our newsletter.
Control Two: Obligation for Quarterly Internal Audits (Requirement 12.4.2)
This requirement applies solely to Service Providers and is intended to implement a continuous compliance approach. The control introduces five key areas of inspection:
- Daily log reviews – inspections conducted every three months using automated mechanisms
- Reviews of network security control configurations – verification of firewall rules every six months
- Application of configuration standards to new systems – quarterly inspections of newly added devices
- Response to security alerts – in accordance with established incident response procedures
- Change management procedures – oversight of system change processes
The aim of this requirement is to transform PCI DSS into a method of managing the IT environment, rather than a one-off project. This enables the cyclical and prompt identification of vulnerabilities and the implementation of corrective actions.
Control Three: Authenticated Internal Scanning (Requirement 11.3.1.2)
This is one of the most demanding new controls, which became mandatory as of 1 April 2025. Requirement 11.3.1.2 stipulates that internal vulnerability scans must be conducted using authenticated access to the system (previously, this was not obligatory).
Authenticated scanning means that:
- The scanner must possess login credentials for the systems being scanned
- Systems unable to accept credentials must be documented
- Accounts used for scanning must have sufficient privileges
- If accounts may be used for interactive logins, they must be managed in accordance with requirement 8.2.2
Authenticated scanning provides deep insight into systems and their configurations, offering far greater capability to identify vulnerabilities. Compared with traditional unauthenticated scanning, this method uncovers significantly more security issues.
Summary and Recommendations
PCI DSS 4.0.1 introduces significant changes that require a considered approach and thorough preparation. The keys to success are:
- Proper understanding of certification scope – do not limit yourself solely to the storage of cardholder data
- Realistic assessment of responsibilities – the presence of certified vendors does not absolve you of your own obligations
- Preparation for new requirements – particularly authenticated vulnerability scanning
Patronusec, with over 15 years’ experience working with the PCI DSS standard and the completion of more than 1,000 certification audits in over 60 countries, understands the complexity of these challenges. Our team is authorised to conduct PCI certification audits across a wide spectrum and collaborates with leading technology providers, enabling us to offer competitive solutions.
If your organisation is approaching PCI DSS certification for the first time, or is planning an upgrade to version 4.0, we recommend beginning with a gap analysis. This service enables a comprehensive understanding of the requirements, identification of areas needing improvement, and the preparation of an implementation strategy. Alternatively, our consulting services can assist you in navigating the complexities of the standard and ensuring an effective path to compliance.
Remember, cardholder data security is a process that should be straightforward and seamlessly embedded within your organisation’s operations. With the right expert support, PCI DSS certification can become not merely a regulatory obligation, but an investment in long-term security and customer trust.
