Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Learn how to make your website HIPAA compliant in 2025 with 30+ checklist items, from BAAs and access controls to client-side monitoring and audit-ready evidence.

PCI DSS 4.0.1 compliance becomes manageable once you recognize that each tool protects a different layer, and the strongest programs combine them thoughtfully. With Requirements 6.4.3 and 11.6.1 now bringing the browser into focus, organizations can finally see the complete picture they need.

Most organizations begin their PCI DSS planning with what’s easiest to define: the Qualified Security Assessor (QSA) fee. As the process unfolds, other costs come into view, from mapping data flows to preparing evidence. Seeing the full picture early helps teams plan with confidence.

Modern checkout pages have evolved from static forms into dynamic ecosystems where dozens of third-party scripts run alongside first-party code. This complexity expands the attack surface and challenges traditional defenses designed for fixed perimeters. PCI DSS 6.4.3 was introduced to address that shift, emphasizing continuous oversight of browser-executed scripts and the integrity of client-side behavior.

Most modern sites run significant third-party code in the user’s browser. The Web Almanac 2022 reports that the top 1,000 sites load an average of 43 third-party domains on mobile and 53 on desktop, expanding the surface for JavaScript injection attacks and supply-chain tampering. In parallel, real e-commerce compromises continue to surface. Sansec has identified more than 70,000 websites that suffered Magecart e-skimming over time.

Preparing for PCI DSS 4.0.1 can feel complex, especially when so much of compliance now lives in the browser. Your assessor’s main goal is simple: to confirm that your controls are not only in place but also working as intended. Two requirements matter most for e-commerce environments. Many organizations start with Content Security Policy (CSP). It’s a sensible place to begin because CSP gives browsers a set of rules about what content to load.

According to Web Almanac, the top 1,000 websites load an average of 43 third-party domains on mobile and 53 on desktop, each a potential entry point for supply-chain tampering. A separate analysis found that most enterprise sites include 12 third-party and 3 fourth-party scripts in sensitive user journeys. That’s 15 external execution paths per transaction, and every one of them runs in the same browser as your checkout.

Many teams believe that cross-site scripting, or XSS, is a problem of the past. Modern frameworks promise built-in protections, and developers often assume the browser will handle the rest. The reasoning sounds logical: if React auto-encodes output, XSS can’t happen. However, XSS prevention doesn’t work on assumptions; it works on visibility. We’ve learned that XSS prevention is about maintaining continuous control over the browser environment where your application runs.

Many teams assume that embedding payment forms in an iframe keeps them compliant with PCI DSS 4.0.1, Requirement 6.4.3. The reasoning sounds logical – compliance seems guaranteed if card data never reaches your infrastructure. However, iframe payment security PCI DSS 6.4.3 doesn’t work on assumptions; it works on control. The responsibility shifts to new layers of your website’s supply chain.

PCI DSS 4.0.1 became mandatory on March 31, 2025, bringing in 47 new requirements that fundamentally changed how compliance works. Organizations that treated PCI as an annual audit exercise now face a standard that expects real-time visibility into payment pages. Requirements 6.4.3 and 11.6.1 are the most impactful additions, which require real-time visibility into scripts and payment page changes. A spreadsheet updated quarterly can’t deliver that.