Threat Modeling for
PCI DSS 4.0.1 Compliance

PCI DSS 4.0.1 — the version PCI SSC published on June 11, 2024, and the only version of the standard currently in effect moved Requirement 6 away from a static list of coding rules and toward a process obligation. Requirement 6.2.4 states that “software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software,” and lists categories including injection attacks, attacks on data structures, and attacks on cryptography usage.

The standard doesn’t name “threat modeling” in the requirement text itself. But the requirement asks for exactly what threat modeling produces: a defined method, applied by development personnel, that identifies which attack categories apply to a given piece of software and drives mitigations for them. An organization that can point to a repeatable threat-modeling process not a one-time diagram, a recurring one, tied to the SDLC has a direct answer to 6.2.4.

Two adjacent requirements extend the same connection:

• Requirement 6.3.1 requires that security vulnerabilities be identified using a defined methodology, ranked according to risk, and kept current — the output of a threat model’s risk-ranking stage.
• Requirement 6.3.2 requires an inventory of bespoke and custom software and the third-party components inside it, maintained to support vulnerability and patch management — a byproduct of the decomposition stage most threat-modeling methodologies perform before threat enumeration.

None of this makes threat modeling a checkbox PCI DSS requires by name. It means an assessor asking “how do you address 6.2.4” gets a stronger answer from “here’s our threat model for this application, updated last release” than from a static secure-coding checklist reviewed once a year.

PASTA (Process for Attack Simulation and Threat Analysis) was built around exactly the progression 6.2.4 implies: understand the application (decomposition), understand what attacks are plausible against it (threat analysis, attack modeling), and understand which vulnerabilities matter most given those attacks (vulnerability and risk analysis) — before mitigation is prioritized. That order matters for PCI DSS specifically, because 6.3.1’s risk-ranking requirement depends on already knowing which attacks are realistic for the environment, not just which CVEs exist in a scanner’s database.

For a cardholder data environment, that means the threat model accounts for the CDE’s actual boundaries — network segmentation, third-party payment gateways, POS integrations — rather than treating the application as generic software. A PASTA-based model for a payment application produces threat and mitigation documentation that maps directly onto 6.2.4’s attack categories and 6.3.1’s ranking requirement, because the methodology was built to produce risk-ranked, business-context-aware output rather than a flat list of theoretical threats.

PCI DSS 4.0.1 assessments happen annually, but Requirement 6 applies to software that changes far more often than once a year. A threat model produced once, for a point-in-time assessment, ages out of relevance the first time the application’s attack surface changes — a new API endpoint, a new third-party integration, a new deployment topology.

Fork (VerSprite’s Threat Modeling as a Service platform) and TMaaS are built around that gap: rather than a single engagement producing a document, threat models are maintained as living artifacts tied to the application’s actual architecture, updated as the system changes. For a merchant or service provider under continuous 6.2.4 obligations, that means the threat model an assessor reviews reflects the CDE as it exists today, not as it existed at the last audit.

Threat modeling is not a substitute for the rest of Requirement 6 — code review (6.2.3), vulnerability scanning, or the SBOM-adjacent inventory work in 6.3.2 still have to happen. And no vendor, VerSprite included, can represent that a threat model guarantees a passing PCI DSS assessment; that determination belongs to a Qualified Security Assessor (QSA) reviewing the full control set. What a threat model does is give an assessor documented evidence that 6.2.4’s “defined and in use” language is being met by an actual process, not an annual checklist exercise.