PCI DSS 4.0 Is Fully Enforced: What Texas Businesses Need to Fix Now

PCI DSS 4.0’s “future-dated” requirements became mandatory on March 31, 2025. If your business accepts credit cards, your 2026 assessment is the first one where every v4.0.1 requirement must be fully met. Many Texas retailers, restaurants, medical offices, and professional services firms treated those requirements as optional best practices while they were in the grace period. That grace period is over.

What Changed on March 31, 2025

When the PCI Security Standards Council released PCI DSS 4.0 in March 2022, it included 51 requirements labeled as “best practices” with a future effective date of March 31, 2025. Organizations had three years to implement them. Under PCI DSS v4.0.1, those 51 requirements are now mandatory for every business that stores, processes, or transmits cardholder data.

For businesses that kept pace with the changes as they were announced, the transition should be smooth. For the many SMBs that deferred implementation, 2026 assessments will surface gaps. Your Qualified Security Assessor (QSA) or Internal Security Assessor will evaluate your environment against the full v4.0.1 standard, and the “we’ll get to it next year” option for formerly future-dated controls no longer exists.

Five Requirements That Catch SMBs Off Guard

These are the v4.0.1 changes that generate the most remediation work for small and mid-sized businesses. If you haven’t addressed them, prioritize these before your next Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC).

1. MFA for All Cardholder Data Environment Access (Requirement 8.4.2)

Multi-factor authentication is now required for every user who accesses the cardholder data environment (CDE), not just remote access or admin accounts. If a cashier, bookkeeper, or office manager logs into a system that touches payment card data, they need MFA.

This is the requirement that generates the most surprise. Many businesses had MFA on VPN and remote desktop but assumed in-office access was excluded. It isn’t. Every access path into the CDE needs MFA, whether the user is sitting at a desk or connecting from home.

If your business already enforces MFA across all accounts as part of your cyber insurance compliance requirements, you may already meet this requirement. Verify that MFA coverage extends specifically to CDE access, including point-of-sale admin consoles and payment processing portals.

2. 12-Character Minimum Passwords (Requirement 8.3.6)

The minimum password length increased from 7 characters to 12 (or 8 if your system can’t support 12). Password policies must also require a mix of numeric and alphabetic characters. If you’re still running systems with 8-character minimums, this needs to change before your assessment.

For businesses using Active Directory or Microsoft 365, updating password policies is straightforward through Group Policy or Entra ID. The harder part is legacy systems, POS terminals, and payment applications that may have their own password requirements built in. Identify every system in your CDE and verify each one supports and enforces the new minimum.

3. Payment Page Script Inventory and Integrity Monitoring (Requirement 6.4.3)

If your business runs an e-commerce site that accepts payments, you must now maintain an inventory of all JavaScript and other scripts running on your payment pages. Each script must be authorized, and you need a mechanism to detect unauthorized changes.

This requirement targets supply chain attacks like Magecart, where attackers inject malicious scripts into payment pages to skim credit card numbers. It’s particularly relevant for businesses running WordPress, Shopify, or custom e-commerce platforms that rely on third-party plugins.

Implementation involves identifying every script that loads on pages where customers enter payment information, documenting the business justification for each one, and deploying integrity monitoring that alerts you when a script changes. Content Security Policy (CSP) headers and Subresource Integrity (SRI) attributes are common technical approaches, but the specific method depends on your platform.

4. Web Application Firewall for Public-Facing Payment Apps (Requirement 6.4.2)

Every public-facing web application involved in payment processing must be protected by a web application firewall (WAF). For most SMBs with e-commerce sites, a cloud-based WAF from providers like Cloudflare, AWS WAF, or Azure Front Door is the most practical option.

If you already work with a managed security provider for your infrastructure, ask whether your current setup includes WAF coverage for payment-facing applications. Many businesses discover they have a WAF protecting their corporate website but not their payment portal, or that the WAF is deployed but not configured with rules specific to payment page attacks.

5. Targeted Risk Analysis for Security Activities (Requirement 12.3.1)

PCI DSS 4.0 introduces “targeted risk analysis” as the method for determining how often you perform periodic security tasks like log reviews, vulnerability scans, and access reviews. Instead of the standard prescribing a fixed frequency for every activity, your organization must now conduct a documented risk analysis to justify the frequency you choose.

This is more work than it sounds. You need to document the assets involved, the threats they face, and the reasoning behind your chosen review frequency for each activity. A boilerplate statement like “we review logs weekly because that’s industry standard” won’t pass assessment. The analysis must be specific to your environment, and your QSA will ask for this documentation.

Which SAQ Applies to Your Business

Many business owners aren’t sure which Self-Assessment Questionnaire they need to complete. The SAQ type depends on how your business handles cardholder data:

• SAQ A: You never touch cardholder data. All payment processing is handled by a PCI-compliant third party (Stripe, Square hosted checkout, or a similar fully hosted payment page). This is the shortest SAQ.
• SAQ A-EP: Your website affects the security of the payment transaction (redirects, iframes) but you don’t directly process card data on your servers.
• SAQ B: You use imprint machines or standalone dial-out terminals with no electronic storage of cardholder data.
• SAQ C: You process cards through payment application systems connected to the internet but don’t store cardholder data electronically.
• SAQ D: You store cardholder data electronically, or nothing else fits. This is the most comprehensive questionnaire and covers the full PCI DSS requirement set.

For most Texas SMBs, the answer is SAQ A (if you use a fully hosted payment page) or SAQ C (if your POS system connects to the internet). Your payment processor or acquiring bank can confirm which SAQ applies if you’re unsure. Getting the SAQ type wrong means either over-investing in controls you don’t need or missing requirements you do.

What Happens If Your 2026 Assessment Finds Gaps

A failed PCI assessment doesn’t trigger an immediate fine, but the consequences compound quickly.

Your acquiring bank (the bank that processes your credit card transactions) is ultimately responsible for your compliance. When you report gaps or fail an assessment, the bank’s options include increased transaction fees, mandatory remediation plans with deadlines, restrictions on the types of transactions you can process, or termination of your merchant account.

The PCI Security Standards Council doesn’t levy fines directly. Card brands (Visa, Mastercard, Discover, American Express) impose fines on acquiring banks, which pass those costs to non-compliant merchants. According to published card brand enforcement guidelines, fines range from $5,000 to $100,000 per month of non-compliance, depending on the severity and duration of the gap. For an SMB, even the lower end of that range represents a serious hit.

Beyond fines, a breach that occurs while you’re out of compliance creates significant liability. If cardholder data is compromised and your most recent assessment showed unresolved gaps, expect the card brands to hold your business responsible for fraud losses, forensic investigation costs, and card reissuance fees. These costs routinely reach six figures for businesses of any size.

The practical approach: treat your next assessment as a hard deadline, not a test you can retake. Identify gaps now, build a remediation plan with specific timelines, and close the issues before your QSA arrives.

How to Prepare Before Your Next Assessment

Audit your MFA deployment. Verify that every user who accesses the cardholder data environment has MFA enabled. Check POS admin consoles, payment processing portals, and any remote access paths. Document exceptions with compensating controls.

Update password policies. Set the minimum length to 12 characters across all CDE systems. Test that legacy systems and POS terminals enforce the new policy correctly. Update employee documentation and provide advance notice before the change takes effect.

Inventory your payment page scripts. List every script that loads on pages where customers enter payment data. Remove anything unnecessary. Deploy integrity monitoring to detect unauthorized additions or modifications.

Deploy or verify WAF protection. Confirm that a web application firewall protects every public-facing payment application. If you don’t have one, evaluate cloud-based WAF options that can be deployed without major infrastructure changes.

Document your targeted risk analyses. For every periodic security activity (log review, access review, vulnerability scanning), write a risk analysis that justifies your chosen frequency. Include the assets, threats, and rationale. Your QSA will ask for this documentation.

Schedule a cybersecurity risk assessment. A formal assessment maps your current controls against PCI DSS 4.0.1 requirements and identifies gaps before your assessor does. This gives you time to remediate on your own schedule rather than under pressure from your acquiring bank.