A lot of small businesses in South and Central Florida take card payments online without ever touching a card number. A dental group in Boca Raton collects copays through a patient portal. A law firm in Orlando takes retainers through a payment form on its website. A boutique in Naples runs a small online store. In most of these setups, the payment processor hosts the actual card fields, and the business fills out the shortest PCI DSS questionnaire there is, the SAQ A, once a year.
That part has not changed. What changed is the fine print about how the payment form sits on your page, and many owners who renewed their SAQ A this year signed an eligibility statement without knowing what it asked them to confirm.
When PCI DSS version 4 took full effect on March 31, 2025, two requirements aimed at payment page scripts became mandatory. Requirement 6.4.3 asks you to inventory and authorize every script that runs on the payment page. Requirement 11.6.1 asks you to detect unauthorized changes to that page. These controls exist because attackers who get a malicious script onto a checkout page can skim card numbers as customers type them, even when the card fields belong to someone else.
Early drafts of the SAQ A included both requirements, and small merchants pushed back hard. In January 2025 the PCI Security Standards Council published a revised SAQ A that removed 6.4.3 and 11.6.1 and added a new eligibility criterion instead. To use SAQ A, you now confirm that your site is not susceptible to attacks from scripts that could affect your e-commerce system. The Council later issued FAQ 1588 to explain how a merchant can back that statement up.
The key detail is which setups this touches. According to the Council's guidance, the criterion applies to merchant pages that embed the processor's payment form, usually through an iframe. If your customers are sent away to the processor's own hosted page through a full redirect, or your whole store is run by a third party, this particular criterion is not aimed at you.
FAQ 1588 gives merchants two main paths. The first is to implement the script controls from 6.4.3 and 11.6.1 yourself on the page that hosts the payment form. The second is to get written confirmation from your payment provider that its embedded solution includes protection against script attacks when it is set up according to its instructions. Some assessors will also accept other evidence, such as web application testing or a properly configured web application firewall, so ask your acquiring bank or assessor what they expect before you pick a path.
Here is the catch. The provider's letter only covers you if you actually followed the provider's instructions. We regularly see marketing tags, chat widgets, analytics code and plugin updates added to the same page as the payment form by whoever manages the website. Nobody told compliance, and nobody checked whether that changes anything. If a breach happens, "our processor handles PCI" is not going to be a satisfying answer to your bank.
For most small businesses the practical steps are simple. Find out whether your checkout is a redirect or an embedded form. If it is embedded, request the provider's written statement and keep it with your SAQ. Make a list of the scripts that load on that page and who approved them. Then tell whoever runs your website that nothing new goes on that page without a quick review.
Florida has a lot of the kinds of businesses that fit this profile: medical and dental practices, professional services firms, hospitality, and small online retailers. Many of them rely on an outside web developer or agency, so the person who adds scripts to the site is often not the person who signs the SAQ. That gap is where these problems start. On top of card brand and bank consequences, a skimming incident that exposes customer data can also bring notification duties under the Florida Information Protection Act.
CMBNetworks helps South and Central Florida businesses with PCI-DSS compliance, from confirming which SAQ fits your payment setup to documenting the evidence that holds up when your bank or an assessor asks. The practice is led by a former CISO of WMATA, the 2nd largest transportation organization in the United States, who has signed off on payment security from the business side. Start a conversation.