The Payment Card Industry Data Security Standard is the measuring stick for protecting cardholder data, and in its current version it asks more of API teams than any version before it. Here is where the standard stands today, which requirements put the most weight on your APIs, and how Salt helps you meet them.
Where the standard stands
PCI DSS v4.0.1 is the current published version. The Council released it on 11 June 2024 as a limited revision that clarified existing requirements without adding or deleting any, and v4.0 was retired on 31 December 2024.
The more consequential change is timing. Version 4.x introduced 64 new requirements, and 51 of them were future-dated and became effective on 31 March 2025. In any applicable assessment today, they are requirements rather than roadmap items. If your API security program was scoped against the transition period, this is the moment to revisit it.
The Council ran a Request for Comments on v4.0.1 through July 2026 to shape the next iteration. No successor version has been published, so v4.0.1 is what you will be assessed against.
Salt's PCI control chain
APIs touch PCI DSS at every stage of the software lifecycle, which is why Salt covers the whole chain rather than a single control point. The Agentic Security Platform runs from outside your perimeter through your code to your live traffic:
- Salt Surface scans from the internet inward with no deployment, finding externally exposed APIs and agentic endpoints reachable from outside. Ideal for scope discovery and for surfacing public-facing endpoints nobody documented.
- Salt Connect works inside-out through agentless integrations with cloud providers, API and AI gateways, databases, and hosting platforms, producing configuration-level inventory and posture without intercepting traffic.
- Continuous API discovery maintains a live picture of internal, external, third-party, shadow, and zombie APIs, with endpoint metadata, authentication method, data classification, and traffic patterns attached.
- Sensitive data discovery classifies APIs handling PCI and other regulated data, maps access paths, flags sensitive data on public or unauthenticated endpoints, and validates transport-layer protection.
- Salt Code applies security and compliance policy inside AI coding assistants, pull requests, and CI/CD, and reviews existing repositories for missing authentication, unprotected sensitive data, hard-coded secrets, and risky logging patterns.
- Posture Governance and the Policy Hub define posture standards with out-of-the-box PCI DSS framework support, detect drift, surface violations, and export evidence for audit workflows.
- Salt Collect observes live traffic across 70+ technologies, providing runtime behavioral data that configuration and code review cannot produce on their own.
- Salt Protect detects API abuse and business-logic attacks through behavioral baselining and supports targeted blocking.
- Salt Managed Rules for AWS WAF attach to AWS WAF web ACLs for inline blocking of API attack classes.
- The Agentic Security Graph correlates external exposure, configuration, code, and runtime, so you can tell which payment API risk actually matters.
That chain is what makes the requirement mapping below hold up under assessment.
Requirement by requirement
6.2.1 and 6.2.3: secure development and code review
6.2.1 requires bespoke and custom software to be developed securely using industry standards and secure development practices. 6.2.3 requires code review appropriate to the code being written, and 6.2.3.1 adds independence, knowledge, and approval controls when those reviews are performed manually.
Salt Code is built for exactly this. It enforces your policy at the moment code is written, inside the AI coding assistants your developers already use, and reviews existing repositories against the same policy. Findings come back with file and line references, a category, and remediation guidance, which is a form engineers can act on and assessors can read.
Your own review process supplies the reviewer independence and management approval that 6.2.3.1 calls for, along with the training and approval steps in your SDLC. Salt Code gives those reviewers far better raw material to work from.
6.2.4: common software attacks, including business logic abuse
This is the closest thing to a purpose-built API security requirement in the standard. 6.2.4 asks for software engineering techniques that prevent or mitigate common software attacks, and it explicitly names business logic abuse through manipulation of APIs, protocols, and client-side functionality, alongside attacks on access-control mechanisms.
Business logic flaws are the reason API security needs its own approach. There is no CVE for an endpoint that lets one authenticated user retrieve another user's card data by changing an identifier. The request is well-formed, the credentials are valid, the channel is encrypted. What makes it an attack is the behavior, and behavior is what Salt was designed to see.
Salt covers this requirement from both ends of the lifecycle. Before production, Salt Code enforces authentication, authorization, sensitive-data, and secure-design policy. After deployment, Collect and Protect baseline normal behavior across API and user attributes to surface account takeover, data exfiltration, session abuse, access-control abuse, and low-and-slow attacks. Few controls in your stack address both sides of 6.2.4 the way this pairing does.
6.3.1 and 6.3.2: vulnerabilities and inventory
6.3.1 requires identifying and managing vulnerabilities with assigned risk rankings across bespoke, custom, and third-party software. 6.3.2 requires an inventory of bespoke and custom software plus the third-party software components incorporated into it, maintained to support vulnerability and patch management.
Salt Code, Posture Governance, and runtime context identify API and application risks and prioritize them using exposure, sensitive data, and observed behavior. Surface, Connect, and continuous discovery give you a picture of your custom application surface that stays current as systems change, rather than one that goes stale the moment the next deploy lands.
For complete 6.3.2 coverage, pair your Salt API inventory with your software component inventory or SBOM. The two are complementary: yours catalogs the components, Salt catalogs the interfaces those components actually expose, including the ones that never made it into documentation.
6.4.2: automated detection and prevention for public-facing applications
Worth recalibrating if you are working from older guidance. Per the Council, after 31 March 2025, 6.4.2 is the effective requirement and 6.4.1 is superseded and reported as not applicable. The manual vulnerability review path is gone. Public-facing web applications need an automated technical solution that continuously detects and prevents web-based attacks.
Salt supports this requirement across your API attack surface. Salt Protect detects API-specific attacks at runtime and supports targeted blocking. Salt Managed Rules for AWS WAF go further, blocking inline inside AWS WAF against credential brute force, SSRF, prototype pollution, excessive GraphQL queries, and JWT anomalies. For API-driven applications, this is a materially stronger answer to 6.4.2 than a general-purpose WAF ruleset provides on its own, since those rulesets were not written with API attack classes in mind.
Coverage for non-API web attack classes comes from your broader web application controls, and as always your assessor confirms sufficiency against your architecture.
6.4.3 and 11.6.1: payment page scripts
These requirements also became effective on 31 March 2025, and they are the part of v4.x most often underestimated by e-commerce merchants. The Council published dedicated guidance on payment page security and e-skimming in March 2025.
6.4.3 requires that scripts loaded and executed on the payment page are managed: each one authorized, its integrity assured, and an inventory maintained with written business or technical justification. 11.6.1 requires a mechanism that detects and alerts on unauthorized modification to security-impacting HTTP headers and to payment page content as received by the consumer browser.
These are browser-layer controls, and meeting them calls for dedicated script-integrity tooling that observes the page as the consumer's browser receives it. Salt operates the layer beneath, which is where the cardholder data actually lives, and the two fit together well.
A script-integrity control tells you that a script on your payment page changed. Salt tells you what that change can reach: which APIs the script invokes, whether those APIs handle cardholder data, whether their authentication posture is sound, and whether their runtime behavior shifted after the change. E-skimming is only consequential because of the data at the other end of the call, and that end is Salt's. Merchants running both controls get the full path from payment page to script to API to cardholder data.
One clarification worth having, since it causes real confusion: the 2025 revisions to SAQ A removed 6.4.3 and 11.6.1 from that questionnaire and added an eligibility criterion requiring the merchant to confirm its site is not susceptible to script attacks affecting its e-commerce systems. The requirements were not removed from the standard itself, so this is not a general exemption from script security.
6.5.1 and 6.5.2: secure change management
6.5.1 requires production changes to be managed with a documented reason, security impact analysis, approval, testing, and secure rollback. 6.5.2 requires confirmation after significant change that applicable PCI controls remain in place and documentation is updated.
Salt Code tests code against policy before deployment. Posture Governance detects drift afterward and exports the evidence. Connect and continuous discovery reveal newly exposed APIs that a change introduced. Together they give you a documented answer to "did this change affect our security posture," which is the question 6.5.2 is really asking, and one that is difficult to answer credibly without continuous monitoring.
Your change management workflow supplies the approval, business justification, and rollback procedure. Salt supplies the security evidence that workflow needs.
4.2.1: cardholder data in transit
4.2.1 requires strong cryptography and security protocols to safeguard cardholder data transmitted over open, public networks.
Salt's contribution here is finding the paths you did not know about. Sensitive data discovery classifies APIs carrying PCI data, maps their access paths, flags sensitive data reachable on public or unauthenticated endpoints, and validates transport-layer protection. That is how teams find the weakly protected transmission path nobody documented, and Salt Code can enforce secure API patterns before the next one ships.
Once Salt surfaces a weak or missing transport protection, your platform team makes the TLS and certificate configuration change.
12.5.1 and 12.5.2: scope and inventory
12.5.1 requires a current inventory of in-scope system components. 12.5.2 requires you to document and confirm PCI scope at least annually and after significant change, including payment data flows.
Scope is where API sprawl does its real damage. An undocumented endpoint handling card data, reachable from the internet, is a scoping failure before it is a security failure, and it is exactly the kind of thing a point-in-time review misses.
Surface, Connect, continuous discovery, and sensitive-data mapping together give you exposed and internal APIs, shadow and zombie endpoints, ownership, posture, and cardholder-data flows. Salt covers the API and agentic portion of your in-scope inventory in depth; your CDE scoping documentation brings in the rest of the environment and the network and data-flow diagrams PCI requires.
How Salt fits alongside your other PCI controls
PCI DSS is a framework covering people, process, and technology, and a strong program layers controls rather than relying on any one of them. Salt is the API and agentic layer of that program. Here is how it sits next to the rest:
- Your assessor determines compliance. Salt provides the technical controls and the continuous evidence that make the assessment go smoothly.
- Your ASV and vulnerability scanning satisfy the scanning requirements in 11.3. Salt posture and code findings help you prioritize what to remediate first, using exposure and cardholder-data context those scans do not have.
- Your identity systems own authentication, MFA, and privileged access. Salt identifies authentication and authorization posture gaps across your APIs and detects abuse of credentials that are technically valid.
- Dedicated script-integrity tooling covers 6.4.3 and 11.6.1 at the browser. Salt covers the APIs and cardholder data those scripts reach.
- Your patch and vulnerability management program tracks industry-recognized vulnerability sources. Salt adds the API-layer risks that never appear in a CVE feed.
- Your logging platform carries Requirement 10 across all in-scope systems. Salt runtime telemetry and attack timelines feed it the API security evidence it would otherwise lack, through your SIEM and SOAR workflows.
- Your data platform enforces retention and secure deletion under 3.2.1. Salt shows you where regulated data is actually flowing through APIs, which is often the part nobody has mapped.
Taking the next step
APIs carry a larger share of PCI DSS weight in v4.x than in any previous version, and the requirements that matter most are the ones traditional application security tooling handles least well: business logic abuse, access-control manipulation, continuously current inventory, and cardholder data moving through interfaces nobody documented. Those are the problems Salt was built for, across discovery, code, configuration, data exposure, runtime behavior, and enforcement, with continuous technical evidence instead of annual screenshots.
If you want to see which of your APIs handle cardholder data and where the technical gaps are, request an API Attack Surface Assessment, or request a demo and our team can walk your PCI scope with you.
PCI DSS v4.0.1 is the current published standard as of September 2026. Salt provides technical controls, visibility, and evidence that support PCI DSS requirements. Salt does not certify an entity as PCI compliant. Applicability and sufficiency depend on your architecture and must be validated by your acquirer, payment brand, ISA, or QSA.
Originally published by Amanda Fitzsimmons on June 21, 2024. Updated September 18, 2026 by Nika Engberg, Head of Legal.