Braintree PCI Compliance: Which SAQ Applies and When You Need an ASV Scan
Braintree PCI compliance explained: see which SAQ fits Hosted Fields, Drop-in or custom builds, and when quarterly ASV scans apply. Book an ASV scan today.
• PCI DSS 11.3.2 requires an external vulnerability scan at least every three months, run by a PCI SSC Approved Scanning Vendor, resolved to a passing result with rescans as needed.
• A scan passes only when no vulnerability is scored CVSS 4.0 or higher and no automatic-fail condition is present.
• PCI DSS 11.3.2.1 adds a separate external scan after any significant change. Qualified, independent personnel can run it, so it does not have to be an ASV.
• SAQ A merchants have 11.3.2 and 11.3.2.1 on their form under v4.0 and v4.0.1. Check your SAQ and your acquirer.
• Auditors look for a complete trail: quarterly reports, scope records, rescans and change tickets.
PCI DSS 11.3.2 is the requirement behind every quarterly ASV scan, and assessors check it in almost every PCI assessment. If you searched for the requirement number, you probably want to know what it says, whether it applies to you, and what to show an auditor. The requirement exists because internet-facing systems are the most exposed layer of a cardholder data environment. This guide explains 11.3.2 and its companion 11.3.2.1 in plain English, covers rescans, and ends with an evidence checklist. PCI DSS v4.0.1, published in June 2024, is a limited revision of v4.0 that clarified wording. It did not change the quarterly ASV scan rule. For the wider v4 picture, see our guides to PCI DSS v4.0 ASV scanning and the PCI DSS 4.0.1 deadline.
A disclosure: we are Secusy, an ASV vendor. This guide paraphrases the standard rather than quoting it, and it is not a QSA opinion. Confirm details against the current PCI DSS and with your acquirer.
PCI DSS 11.3.2: the requirement for external vulnerability scans at least every three months by a PCI SSC Approved Scanning Vendor.
PCI DSS 11.3.2.1: the requirement for an external vulnerability scan after any significant change.
ASV (Approved Scanning Vendor): a company approved by the PCI Security Standards Council to run external scans. See what an ASV is.
Cardholder data environment (CDE): the people, processes and technology that store, process or transmit cardholder data or sensitive authentication data, plus any connected or security-impacting systems.
Passing scan: under the ASV Program Guide, a scan with no vulnerability scored CVSS 4.0 or higher and no automatic-fail condition.
Significant change: a change to the environment that PCI DSS treats as needing re-verification, such as new or replaced systems, changed data flows or a changed CDE boundary.
Attestation of Scan Compliance (ASC): the cover document an ASV issues stating whether the scan passed. See what an ASV report contains.
PCI DSS 11.3.2 requires external vulnerability scans at least once every three months, performed by an ASV, with vulnerabilities fixed to a passing result and rescans run as needed to confirm the fix.
The requirement has four parts:
1. Frequency: at least once every three months.
2. Who scans: a PCI SSC-approved scanning vendor. An internal scanner or a general-purpose tool does not satisfy it.
3. Outcome: vulnerabilities are resolved, and the ASV Program Guide requirements for a passing scan are met.
4. Rescans: repeat scans as needed to confirm vulnerabilities are resolved.
A passing scan has no finding scored CVSS 4.0 or higher and no automatic-fail condition, such as an unsupported operating system. The merchant defines the scope. The ASV Program Guide expects every public IP address routed to the in-scope environment and every URL that points to those addresses to be included.
What must be scanned. Every internet-facing IP address and system within or connected to the CDE: web and application servers, remote access points and any other internet-accessible system. This is not limited to systems that handle card data. Systems that can affect CDE security through network connectivity are in scope too, and leaving one out is a gap an assessor will find quickly.
First-year exception. For initial PCI DSS compliance, four passing scans in the first 12 months are not required if an assessor verifies three things: the most recent scan passed, you have documented policies requiring scans at least every three months, and any vulnerabilities were corrected as shown by a rescan. In later years, you need passing scans at least every three months.
11.3.2 covers external scanning only. Internal scans fall under a separate requirement, 11.3.1. For how often scans fall due in practice, see how often ASV scans are required, and for the program rules, see the ASV Program Guide explained.
Start a scan that produces the full report package your assessor expects.
Any merchant or service provider whose validation includes 11.3.2 and who has internet-facing systems in scope. Your SAQ type or Report on Compliance decides whether it appears on your form.
Validation type | 11.3.2 on the form? | Note |
|---|---|---|
SAQ A | Yes | Added in v4.0 and still listed after the January 2025 revision, which removed the script requirements but not scanning |
SAQ A-EP | Yes | Has always required quarterly ASV scans |
SAQ B-IP | Listed by several sources | Confirm on your form, and verify scope |
SAQ C | SAQ C | |
SAQ D (merchant) | Yes | |
SAQ D (service provider) | Yes | |
Report on Compliance | Yes, where internet-facing systems are in scope | Level 1 merchants and most service providers |
SAQ P2PE | Generally not | Confirm on your form |
The SAQ A change surprises many merchants who validated under v3.2.1, when SAQ A carried no scanning requirement. If your checkout redirects to or embeds a third-party payment form, check your SAQ A and ask your acquirer before assuming you are exempt. More detail is in the PCI ASV scan requirements.
The SAQ determines whether the requirement is on your form. Your environment determines what gets scanned. If a public IP or domain routes to systems in scope, it belongs in the scan scope.
Two events trigger extra external scans: a failing result, which needs rescans until it passes, and any significant change, which needs its own scan under 11.3.2.1. Both come on top of the quarterly scan.
If a scan fails, fix the findings and rescan until the ASV issues a passing result. Keep both the failing and the passing reports, because together they show the remediation loop worked. A failed scan followed by a documented fix and a pass is normal. A failed scan with no follow-up is an audit finding. If a finding looks wrong, use the false positive dispute process rather than ignoring it. For what to do after a fail, see why an ASV scan fails, and check your vendor's rescan policy.
PCI DSS 11.3.2.1 requires an external vulnerability scan after any significant change. Three details matter:
• Findings: vulnerabilities scored CVSS 4.0 or higher must be resolved, with rescans as needed.
• Who can scan: qualified personnel with organisational independence from the people who made the change. The scan does not have to come from an ASV or a QSA.
• It is additional: a significant-change scan does not replace the quarterly ASV scan.
Typical triggers include new or replaced servers, firewalls or load balancers, changed data flows, a moved or resized CDE boundary, and changes to supporting infrastructure or third-party providers. Use the standard's own definition and your change policy to decide what counts. The practical fix is a process. Add a field to your change ticket that flags significant changes, and make the external scan a required step before the ticket closes. Many teams simply use their ASV for this scan to keep one toolset and one evidence format.
Learn the three parts of an ASV report and what each one proves.
Keep the full ASV report for each quarter, your scope records, every rescan, remediation proof, and change tickets with their post-change scans. An assessor wants to follow the trail from scope to passing result.
Evidence | What it shows | Tip |
|---|---|---|
Four most recent quarterly ASV reports, each in full | Scans happened at least every three months and passed | Keep the three-part report: ASC, summary and vulnerability details |
Scope record: every public IP, domain and URL submitted | The scan covered the environment | Reconcile against your asset inventory, DNS and network diagrams each quarter |
Scan customer attestation and any special-note declarations | You confirmed scope and addressed flagged items | You must complete the scan customer attestation yourself |
Failed reports plus the rescans that followed | Findings were fixed and verified | Keep the pair together, with dates |
Remediation records | What was changed and when | Tie each ticket to a finding ID |
Dispute, exception or compensating-control records | Contested findings were handled formally | Keep the ASV’s written decision |
Scanning policy | Scans are required at least every three months | Needed for the first-year exception |
ASV listing proof | Your vendor was on the PCI SSC list at scan time | Save a dated screenshot or note |
Change tickets with post-change scans (11.3.2.1) | Significant changes were scanned | Record who scanned and why they qualify as independent |
Scan interference notes | IPS or WAF rules did not block the scanner | Document any allowlisting you applied for |
Retain the formal reports your ASV issues, not raw scan data or informal summaries. Each should identify the ASV, the scan date, the systems covered, the findings and the pass or fail result. Keep event-driven scans after significant changes separate from the routine quarterly scans, so the trail shows your programme responds to change and is not only calendar-driven. Keep reports for the whole assessment period at minimum, and longer if your retention policy or acquirer requires it. For a wider preparation routine, use the PCI ASV scanning checklist and how to pass an ASV scan the first time.
Most findings are process gaps, not technical ones: a missed quarter, an incomplete scope, a failing scan with no rescan, or a significant change with no scan.
• A gap longer than three months. One late scan breaks the quarterly pattern. Put the next scan date on a shared calendar with an owner.
• Incomplete scope. New cloud IPs, load balancers, CDN origins and forgotten subdomains are missed. Reconcile the scope against DNS and the asset inventory each quarter.
• A report that is not from an ASV. Internal scanner output does not satisfy 11.3.2. Confirm your vendor is on the PCI SSC list.
• A failed scan with no rescan on file. Always keep the passing report that closed the loop.
• No scan after a significant change. Link change management to scanning so 11.3.2.1 is not left to memory.
• Missing attestation or declarations. The scan customer attestation and special-note declarations must be on file.
• Scan interference. An IPS or WAF that blocks the scanner can invalidate results. Allowlist the ASV and document it.
• Unresolved TLS and certificate findings. These are among the most common failing items. See ASV scan for TLS failures, open ports and ASV failures.
Turn the findings into a fix list and get back to a passing result.
Binoy Koonammavu, is the Founder and CEO of Secusy ASV, where he helps SMBs and fintech companies meet PCI DSS scanning requirements without the complexity of enterprise-grade tools. His writing focuses on making ASV compliance straightforward for growing businesses.