PCI DSS 4.0, Requirement 11 scans handled.
PCI DSS 4.0 is the payment card industry's security standard for any organisation that stores, processes, or transmits cardholder data — 6 Goals and 12 Requirements covering network security, data protection, vulnerability management, access control, monitoring, and policy. grComply seeds the real v4.0 structure, and Requirement 11's ASV and internal vulnerability scans run directly on grComply's own external and internal scanning pipeline — not a manually uploaded quarterly report.
What is PCI DSS? The Payment Card Industry Data Security Standard (PCI DSS) is a security standard maintained by the PCI Security Standards Council for any organisation that stores, processes, or transmits cardholder data — version 4.0 organises requirements into 6 Goals and 12 numbered Requirements, validated through self-assessment or a Qualified Security Assessor (QSA).
How grComply benefits your PCI DSS programme
All 6 Goals and Requirements 1–12, real structure
Build & Maintain, Protect Account Data, Vulnerability Management, Access Control, Monitor & Test, and Policy — seeded as the actual v4.0 hierarchy.
Requirement 11 scanning is grComply's own scanning
ASV and internal vulnerability scan evidence comes directly from the platform's scanning pipeline, CVE-enriched.
Requirement 10 logging ties to real SIEM evidence
CDE authentication/access log samples map straight to Requirement 10, not a manual export.
MFA for CDE access tracked as its own sub-control
Granular enough to evidence multi-factor authentication specifically, not bundled into a generic access-control line.
Cross-maps to ISO 27001 and SOC 2 for shared merchants
A control satisfying account-data protection can simultaneously credit an equivalent ISO 27001 A.8 control.
Audit-ready reporting for QSA engagements
Versioned report packages and an auditor-engagement workflow built for exactly this kind of formal assessment.
Six Goals, twelve Requirements, seeded with real v4.0 structure
Seeded exactly as the PCI Security Standards Council structures v4.0 — Goals as domains, Requirements 1–12 underneath.
Build and Maintain a Secure Network and Systems
Requirement 1 — install and maintain network security controls — and Requirement 2 — apply secure configurations to all system components.
Protect Account Data
Requirement 3 — protect stored account data — and Requirement 4 — protect cardholder data with strong cryptography during transmission.
Maintain a Vulnerability Management Program
Requirement 5 — protect systems from malicious software — and Requirement 6 — develop and maintain secure systems and software.
Implement Strong Access Control Measures
Requirement 7 — restrict access by business need to know — Requirement 8 — identify and authenticate access, including MFA for CDE access — and Requirement 9 — restrict physical access to cardholder data.
Regularly Monitor and Test Networks
Requirement 10 — log and monitor all access — and Requirement 11 — test security of systems and networks regularly, fed by grComply's own external and internal scanning.
Maintain an Information Security Policy
Requirement 12 — support information security with organisational policies and programs.
Evidence grComply already models for PCI DSS
Real evidence-requirement examples from the seeded control library — the same evidence types every other framework in grComply uses, not a bespoke process for this one.
| Control | Evidence type | Example |
|---|---|---|
| REQ-1 — Network security controls | Architecture diagram | Network diagram and NSC configuration evidence |
| REQ-3 — Protect stored account data | Inventory document | Data retention / CHD storage inventory |
| REQ-11 — Vulnerability testing | Vulnerability scan report | ASV / internal vulnerability scan reports, from grComply's own scanning |
| REQ-10 — Log and monitor access | SIEM log sample | CDE authentication and access log sample |
| REQ-12 — Security policy | Attestation | Security policy acknowledgement |
Why this matters: Requirement 11's quarterly ASV scans and regular internal vulnerability scans are exactly what grComply's scanning module already produces on a schedule — for a merchant already using the platform for another framework, PCI DSS's most operationally demanding requirement is largely already running.
PCI DSS, in the live workspace
The same grComply workspace shown across the platform — control browser, mapping, evidence, and AI assist apply identically to PCI DSS.
PCI DSS in grComply
What is PCI DSS?
PCI DSS is the Payment Card Industry Data Security Standard, a security standard for any organisation that stores, processes, or transmits cardholder data, organised in version 4.0 into 6 Goals and 12 Requirements.
Who needs to comply with PCI DSS?
Any merchant or service provider that stores, processes, or transmits cardholder data, validated via a Self-Assessment Questionnaire (SAQ) or, for larger merchants, a Report on Compliance from a Qualified Security Assessor.
Does grComply support the full PCI DSS 4.0 structure?
Yes — all 6 Goals and Requirements 1–12 are seeded with real v4.0 requirement language, including sub-controls like MFA for CDE access (REQ-8.3).
How does Requirement 11 scanning work in grComply?
grComply's own external (ASV-equivalent) and internal vulnerability scanning generates CVE-enriched findings that serve directly as Requirement 11 evidence, run on a schedule rather than a manual quarterly upload.
Can PCI DSS evidence also satisfy ISO 27001 or SOC 2?
Where controls are genuinely equivalent, yes — cross-framework mapping lets a control like REQ-3 account-data protection credit an equivalent ISO 27001 A.8 technological control.
Does grComply support QSA-style audit engagements?
Yes — the auditor-observation workflow, peer review, and versioned report packages match how a formal PCI assessment or Report on Compliance engagement runs.
What's the difference between an SAQ and a full assessment?
An SAQ is a self-assessment for smaller merchants; larger merchants or those meeting certain thresholds need a Report on Compliance from a QSA — grComply's evidence and control structure support either validation path.
Can PCI DSS run alongside a regional framework?
Yes — a tenant can run PCI DSS alongside any other seeded or imported framework, each tracked to its own completion status. See the full catalog on the Compliance Frameworks page.
See PCI DSS mapped into your control library
Powered by Mutex Systems. Back to Compliance Frameworks → · grComply overview → · Security Awareness Training →
Talk to us about PCI DSS
Tell us where your PCI DSS programme stands today, and we'll route it to the right product specialist.
- A product specialist replies personally — not a bot
- No obligation after the first conversation
- WhatsApp support also available 24/7
By submitting, you agree to be contacted about your enquiry. We respect your privacy.
Book a meeting directly
Pick a time that works for you — 30 minutes with a product specialist, no sales script.
Ready to bring PCI DSS into one control library?
We respond within one working day — or reach us instantly on WhatsApp.