PCI DSS Mapping Is Live, and It Fits What We Already Find Better Than Any Framework Yet
Compliance mapping now covers six frameworks, SOC 2, ISO 27001, NIS2, DORA, LGPD, and, newly, PCI DSS v4.0. Of all of them, PCI DSS is the one that fits what Decloak already finds most precisely, and there's a specific reason why.
The part worth leading with
PCI DSS v4.0 introduced two requirements that didn't really exist in earlier versions of the standard:
- Requirement 6.4.3 - every script that runs on a payment page has to be inventoried, authorized, and justified as necessary.
- Requirement 11.6.1 - a change-and-tamper-detection mechanism has to be deployed on payment pages, alerting on unauthorized changes to scripts and HTTP headers.
Both were added in direct response to Magecart-style e-skimming attacks, where an attacker compromises or slips an unauthorized third-party script onto a payment page, often through a hacked ad-tech vendor, a compromised tag manager container, or a supply-chain attack on a JS library, and quietly captures card numbers as a shopper types them in before exfiltrating them. It's one of the most consequential and hardest-to-detect classes of web attack in e-commerce, and it's exactly the blind spot most infrastructure-focused security scanners miss entirely, they check your servers, not the third-party JavaScript your own site is loading on top of them.
That happens to be exactly what Decloak has always been built around. Long before PCI DSS v4.0 existed, Decloak was already fetching and parsing full Google Tag Manager container configurations, flagging scripts firing to newly-registered or suspicious domains, checking Subresource Integrity on cross-origin scripts, and tracking dynamically-injected scripts against a trusted-injector allowlist. Under the new mapping, all of that, the Malicious Domain, Suspicious Domain, Unknown Third-Party Domain, Tracking Pixel, GTM Custom Tag, Tag Manager, Dynamic Script Injection, and Subresource Integrity finding categories, now maps directly onto PCI DSS 6.4.3 and 11.6.1.
That's a materially stronger, more specific fit than these same findings get under any of the other five frameworks, where they only reach a generic third-party or supply-chain security control. Put plainly: Decloak was already built to catch the exact attack PCI DSS's newest rules exist to prevent.
Why now
Compliance mapping has grown one framework at a time: ISO 27001 and SOC 2 first, then NIS2 and DORA ahead of NIS2's October 2026 EU deadline, then LGPD, Brazil's data protection law, added after direct demand from a Brazilian compliance buyer. PCI DSS had been flagged as a strong future candidate as far back as the NIS2/DORA work, but it took a competitive review, a competitor marketing SOC2/ISO27001/PCI DSS/NIS2 mapping as a bundle, to turn "obvious next framework" into a scoped, shipped feature.
It's also the one framework here that isn't a law or a self-assessed standard. PCI DSS is contractual, required by the card networks (Visa, Mastercard, and others) of anyone who handles payment card data, which makes it relevant to almost every online business selling anything, regardless of jurisdiction.
How it was built
No new scanning logic. Every finding Decloak's scanners already produce carries a category field, "Missing Header," "JavaScript CVE," "Malicious Domain," and a lookup table maps each category to the specific control it's relevant to, per framework. Adding PCI DSS meant widening that table with one PCI requirement number per existing category, 40 finding categories in total, spanning the free-tier core scan, the paid-tier agent investigation, DNS/TLS checks, and Enterprise-only Active Testing and API Scanning.
The rest of the mapping follows more conventional lines: transport security and certificate findings map to Requirement 4.2.1 (strong cryptography for public network transmission), header and configuration findings to Requirement 2.2 (secure configuration), JS and server CVEs to Requirement 6.3.3 (patching vulnerable components), injection and code-pattern findings to Requirement 6.2 (secure coding), exposed secrets and source findings to Requirement 6.3.2, access control and API findings to Requirements 7.2/8.3, and network-level findings like subdomain takeover to Requirement 1.
Because every part of the product, the report page, the scoreboard, CSV and PDF exports, the AI assistant, evidence packages, already reads from that single lookup table rather than hardcoding a framework list anywhere, PCI DSS mapping appeared everywhere the other five already did the moment the table was updated. No framework-by-framework UI work required.
Where you'll see it
- The report page's Compliance Mapping section now shows six framework tabs instead of five, each showing which controls a scan's findings are evidence for, which Active Testing checks came back verified-clean, and a CSV export for handing straight to an auditor.
- The Scoreboard's Compliance Controls tile, account-wide and per-domain, now counts evidenced controls across all six frameworks, with PCI DSS as its own bar in the breakdown.
- PDF evidence exports, the main report, the DAST report, the Pentest report, all pick up PCI control badges automatically.
- The AI Assistant can now correctly answer "does this map to PCI DSS?" questions, pulling from the same authoritative table rather than guessing at requirement numbers from general knowledge.
- Every public page that names frameworks explicitly, the homepage, pricing, features, the dedicated /for-compliance page, account plan descriptions, onboarding, and the compliance mapping help guide (which also picked up a new glossary entry explaining what Magecart is and why 6.4.3/11.6.1 exist), now lists PCI DSS alongside the rest.
Worth being honest about
PCI DSS is audited by Qualified Security Assessors considerably more rigorously than the self-assessment approach most companies use for the other frameworks in practice. The same disclaimer that's applied to every framework we map still applies here: this is indicative mapping to help you understand where a finding sits and prepare evidence, not a certified audit, and not a substitute for a QSA's actual assessment. The requirement numbers are a strong starting point for that conversation, not the final word in it.
Availability
PCI DSS control mapping is live now on Decloak Pro, alongside SOC 2, ISO 27001, NIS2, DORA, and LGPD, and works retroactively on scans you've already run.
Compliance mapping across six frameworks is available on Decloak Pro. See plans →