PCI-DSS 4.0 and licensing — scope, evidence, assessment.

PCI-DSS in the software estate.

The Payment Card Industry Data Security Standard (PCI-DSS) is the global standard for any entity that stores, processes or transmits cardholder data. Version 4.0, with full enforcement effective 31 March 2025, restructured the standard into 12 requirements and introduced a new "customised approach" alongside the traditional "defined approach". The licensing intersection is that any software touching the cardholder data environment (CDE) creates compliance obligations that the buyer must evidence under audit by a Qualified Security Assessor (QSA) or in a self-assessment questionnaire (SAQ).

The most common PCI-licensing failure we see is scope creep: the cardholder data environment was carefully scoped at certification, but new software deployed since then has connected to that environment without re-scoping. A SaaS analytics platform connected to the payment gateway, a Salesforce installation receiving payment data, a Microsoft Power BI report pulling from a transaction database — each of these may pull the connected system into PCI scope and create both a compliance and a licensing exposure. A scoped software license compliance assessment maps every system connected to the cardholder data environment back to its entitlement, so PCI scope and licence scope stay aligned.

Where licensing intersects each requirement.

PCI-DSS 4.0 organises controls into 12 requirements grouped under six control objectives. The licensing-relevant intersections:

Req 1 – Install and maintain network security controls

Firewall and segmentation software is licensed and inventoried; the inventory has to match the network diagrams used in the assessment.

Req 2 – Apply secure configurations

Configuration management software (Chef, Puppet, Ansible Tower) and the licence terms governing its use are PCI-relevant. Inventory of system components has to align with the entitlement record.

Req 5 – Protect all systems and networks from malicious software

Anti-malware product licensing and the scope of coverage; the coverage report has to demonstrate that every in-scope system is licensed.

Req 6 – Develop and maintain secure systems and software

Software development tools, container security platforms, and code-scanning licences. The licence has to permit use in production CDE workloads.

Req 10 – Log and monitor all access

Logging platform licensing — Splunk, Elastic, Sumo Logic. Volume-based licences need to be sized to cover the full one-year log retention requirement, not just current rate.

Req 11 – Test security of systems and networks regularly

Vulnerability scanning, penetration testing tools, and the ASV-scan services. The licence model has to match the testing cadence (quarterly ASV, semi-annual internal).

Req 12 – Support information security with organisational policies and programs

Documented policies for software acceptable use, supplier risk and incident response. The policies need to reflect the licensing reality.

The scope question that decides everything.

PCI scope is the set of systems, networks, applications and people that interact with the CDE. The smaller the scope, the smaller the compliance burden and the lower the cost. Scope is the single most consequential decision in PCI compliance, and it is a decision that the licensing record materially affects. Three patterns we see consistently:

First, segmentation that is not contractually evidenced. A vendor will assert that their product can be segmented from the CDE, but the contract has no representation to that effect. The QSA reads contractual representations; verbal assurances do not appear in the assessment report. Require written segmentation representations from any vendor whose product is "in but isolated".

Second, SaaS sprawl pulling systems back into scope. A team subscribed to a new analytics tool, connected it to the transaction database, and silently pulled the analytics tool (and its administrators) into PCI scope. The fix is upfront: SaaS-procurement intake should include a PCI-scope question and route any positive answer to the security team for scoping.

Third, tokenisation gaps. Tokenisation reduces scope when implemented properly. When the tokenisation vendor retains the ability to detokenise (most do), the tokenisation vendor itself is in scope. Read the tokenisation contract carefully and understand exactly what the vendor can see.

What the QSA actually asks for.

A QSA assessment for a Level 1 merchant or Level 1 service provider is typically a six-to-twelve-week engagement involving documentation review, system testing, and process walkthroughs. The evidence requests touch licensing in three areas: the asset inventory (full list of in-scope assets with software and version), the entitlement evidence for each in-scope asset, and the configuration evidence demonstrating that the software is implemented according to vendor-recommended baselines. Buyers who maintain a unified asset register integrating discovery and entitlement consistently complete QSA assessments in 30–40% less time than buyers who reconstruct the evidence under audit pressure.

What changed in 4.0 that affects licensing.

PCI-DSS 4.0 introduced several changes that pull on licensing. The customised approach permits organisations to design alternative controls, but requires more sophisticated risk-analysis documentation — which has to align with vendor product capability statements. Multi-factor authentication is now required for all access to the CDE, increasing the licensing footprint for MFA tools across the enterprise. Targeted risk analyses are required for certain controls, including frequency of activities, and these analyses pull on consumption telemetry that licensed tools provide. Continuous PCI monitoring (real-time rather than point-in-time) increases the licensing of SIEM and posture-management tools.