PCI DSS v4.0.1 is built around continuous compliance, not an annual event.
The standard expects security controls to operate and be demonstrated year-round, with real-time monitoring, ongoing evidence collection, and documented business-as-usual processes built into the requirements themselves.
An assessment is still the formal checkpoint, but it’s meant to confirm what’s already been running continuously, not reconstruct a security posture from scratch once a year.
The PCI Security Standards Council built v4.0.1 around a different assumption: that security controls should operate continuously, not get reconstructed once a year for an auditor. Real-time monitoring, ongoing evidence collection, and documented business-as-usual processes are now built into the requirements themselves. Organizations that treat PCI DSS as a once-a-year event will increasingly find that approach doesn’t hold up under assessment. The standard changed to match how continuous risk platforms like FortifyData already work, not the other way around.
Before any of that continuous-monitoring conversation is useful, it helps to know where your organization sits. PCI DSS applies to every business that stores, processes, or transmits cardholder data, but how you validate compliance depends on how much you process and how you handle it.
Transaction volume determines your merchant level. Card brands set the thresholds, and they’re broadly similar across brands.
Separately, which SAQ applies depends on how you handle card data, not your transaction count. An e-commerce merchant that fully outsources payment processing to a compliant third party (a hosted redirect or embedded payment form) typically qualifies for the shortest questionnaire, SAQ A. A merchant whose own website can still influence the security of that payment page usually lands in SAQ A-EP instead, a meaningfully longer questionnaire with real infrastructure obligations attached. Organizations that store, process, or transmit cardholder data more directly move into SAQ C or SAQ D, and most Level 1 merchants and larger service providers go through the full ROC rather than any SAQ at all.
Knowing which path applies to your organization is the first real decision in a PCI DSS program. Everything from scan cadence to how much documentation an assessor expects flows from it.
| PCI DSS v4.0.1 Requirement Area | What It Requires | How FortifyData Addresses It |
|---|---|---|
| Requirement 6 — Vulnerability identification and remediation | Identify vulnerabilities in systems and software, prioritize and remediate them over time, not just at a single scan | Internal and external vulnerability scanning with findings prioritized by actual exploitability and business risk, plus tracking of whether identified vulnerabilities actually get closed over time |
| Requirement 11.3.1 — Internal vulnerability scanning | Quarterly internal vulnerability scans | Continuous internal scanning that satisfies and exceeds the quarterly minimum |
| Requirement 11.3.2 — External vulnerability scanning | External scan of internet-facing systems at least once every three months | Continuous external scanning that runs alongside your approved scanning vendor's quarterly assessment, supplementing coverage between scan cycles and keeping visibility current in between |
| Standard-wide theme — Continuous compliance / business-as-usual | Evidence that controls operate continuously, not just at assessment time | This is the core of FortifyData's approach across every module: always-on assessment in place of a once-a-year reconstruction of your posture |
| Requirement 12.8 — Managing PCI DSS compliance of Third-Party Service Providers | Due diligence and ongoing monitoring of TPSPs' PCI DSS compliance status | Vendor questionnaire responses auto-validated against live technical assessment data, in a single vendor-evidence repository, instead of a folder of PDFs collected once a year |
| Requirement 12.3.1 / 12.3.2 — Targeted Risk Analysis and Customized Approach (verify exact numbering against your licensed copy of the standard) | A documented, defensible risk analysis behind any chosen control frequency or Customized Approach control | FortifyData can scope multiple, customer-specific Targeted Risk Analyses, giving teams a structured way to justify chosen frequencies and alternative controls rather than building that justification from scratch |
| Requirement 8.4 — Multi-factor authentication | MFA enforced on all access into the cardholder data environment | Documentation and evidence can be centrally housed in the Controls and Compliance module |
| Requirements 12.1 / 12.7 — Security policy and personnel screening documentation | Documented policies and background-check records | Centralized storage and organization of this evidence alongside everything FortifyData generates directly |
| Cross-framework — Risk Register | Consolidated visibility across compliance obligations | Findings from PCI-related assessments land in the same Risk Register as third-party risk and attack surface findings, rather than a PCI-only silo |
A passing quarterly scan tells you your environment was clean on the day it ran.
It does not tell you what changed on day 46 of that quarter. That gap is exactly where the industry’s oldest lesson lives: compliance and security are related, but they are not the same thing, and a program built only to satisfy the compliance calendar will always have blind spots the calendar can’t see.
FortifyData’s continuous scanning is built to close that gap, not to replace the quarterly requirement itself. Running vulnerability assessments continuously, rather than once every ninety days, means new exposures get caught closer to when they appear instead of whenever the next scan window happens to fall. Some organizations already run their approved scanning vendor continuously and only formally submit the quarterly report; others use FortifyData for continuous visibility and their ASV strictly for the required quarterly attestation. Either approach satisfies the letter of Requirement 11.3.2. The point of continuous scanning is what happens in the ninety days in between.
PCI DSS is one piece of a larger compliance and risk picture.
Most FortifyData customers are managing it alongside frameworks like SOC 2, HIPAA, ISO 27001, GLBA, or NIST CSF, and alongside third-party and attack surface risk.
See how FortifyData’s Cyber GRC platform brings PCI DSS findings into the same Risk Register as every other framework and vendor you’re accountable for. Schedule a demo or a PCI-DSS Compliance consultation to learn how we can help with compliance management.
PCI DSS v4.0.1 is the current, fully mandatory standard. The prior version, v3.2.1, was retired in March 2024, and the last set of transition allowances under v4.0.1 became fully required in March 2025. There is no remaining grace period for any PCI DSS v4.0.1 requirement.
A Self-Assessment Questionnaire, or SAQ, is a self-validation tool completed by eligible smaller merchants, with the specific SAQ type determined by how you handle card data rather than your transaction volume. A Report on Compliance, or ROC, is a full assessment conducted by a Qualified Security Assessor and is required for Level 1 merchants and most service providers, covering the entire standard rather than a scoped subset of it.
FortifyData’s continuous scanning runs alongside your approved scanning vendor’s quarterly assessment rather than in place of it. Continuous scanning closes the visibility gap between quarterly scan cycles, which matters because compliance and security are not the same thing. A clean scan on day one tells you nothing about day forty-six. Many organizations use FortifyData for continuous visibility and their approved scanning vendor specifically for the required quarterly report.
FortifyData supports vulnerability scanning and risk-based prioritization, internal and external scan cadence, patch and remediation tracking, third-party and service provider PCI status monitoring, Targeted Risk Analysis scoping for the Customized Approach, and centralized evidence housing for controls like MFA documentation and policy records. Findings from all of these feed into a single Risk Register alongside your other compliance and vendor risk data.
FortifyData supports NIST CSF, ISO 27001, SOC 2, HIPAA, GLBA, DORA, HITRUST, and other major frameworks, with control mappings that carry forward as you add new frameworks, so work done for one doesn’t have to be redone from scratch when the next one comes up.
No. Requirement 11.3.2 specifically calls for a scan performed by an approved scanning vendor at least once every three months. Continuous scanning is a security practice that supplements that requirement by catching new exposures in the time between quarterly scans, not a substitute for the quarterly scan itself.
