PCI DSS v4.0.1 evidence at the sub-requirement level — the way QSAs actually walk the RoC.
NSAuditor AI EE generates PCI DSS v4.0.1 (PCI SSC, June 2024 errata) pre-audit gap reports mapped at the auditor-canonical sub-requirement level. Signed artifacts, RFC 3161 trusted timestamps, SHA-256 chain-of-custody, suppression workflow, honest OOS framing on Req 5 (anti-malware EDR) + Req 9 (physical) + Req 12 (governance) — and Zero Data Exfiltration, so payment-processing and PCI-scoped customers can scan inside their own boundary without sending Cardholder Data to a third-party scanner.
Sub-requirement-level mapping (auditor-canonical): PCI DSS v4.0.1 has 12 Requirements × ~250 sub-requirements. QSAs attach evidence at the sub-requirement level per the PCI SSC RoC Reporting Template Appendix B — Requirements are navigational headers. Requirement-level claims (e.g., "we cover Req 1") don't pass QSA review. NSAuditor ships MVP-67 density (20 covered + 8 partial + 39 OOS) — density expansion deferred to 0.11.1 per the EE 0.10.0 NIST CSF MVP-23 → density-expansion precedent.
Honest OOS framing — four architectural limits named upfront:
· Req 12 OOS-by-design entirely — 14 sub-requirements explicitly OOS (policy / Targeted Risk Analysis Req 12.3.1 / Customized Approach Documentation Req 12.3.2 / TPSP Responsibility Matrix Req 12.8.5 / IR Plan Req 12.10.x / training Req 12.6.x).
· Req 5 OOS-entirely — 3 sub-requirements (anti-malware deployed/active/monitored 5.2-5.3 + anti-phishing 5.4 NEW v4.0). Pair with endpoint EDR (CrowdStrike Falcon, SentinelOne, MS Defender for Endpoint) + email-security gateway (Proofpoint, Mimecast).
· Req 9 OOS-entirely — 5 sub-requirements (facility access / media handling / point-of-interaction devices). Inherit cloud-provider's PCI DSS Service Provider AOC.
· Req 3 OOS-by-design at technical-control layer — 6 sub-requirements (stored CHD discipline; CDE-attestation gated). Engine evidences encryption-at-rest substrate (Req 3.5.1 partial) but cannot determine which storage holds PAN.
Defined-vs-Customized Approach discipline: 15 sub-requirements are Defined-only per PCI DSS v4.0.1 Appendix E (cannot use Customized Approach). The schema enforces this via approachEligibility: 'defined-only' + customizedApproachObjective: null — misclassifying as Customized-eligible is the PCI analog of HIPAA's "Addressable as Required" overclaim that auditors specifically test for.
4-framework evidence pack from one scan:--compliance soc2,hipaa,nist-csf,pci-dss produces four complete auditor-ready evidence packs. SOC 2 reports cite CC IDs; HIPAA reports cite §164.312 specs; NIST reports cite Subcategory IDs; PCI reports cite Req-x.y.z sub-requirements. Cross-framework citation-leak defense in all 6 pair-directions (88 new tests).
PCI DSS v4.0.1 errata published June 2024 by PCI Security Standards Council (supersedes v4.0 March 2022; v3.2.1 retired March 31, 2024). Structure: 12 Requirements + Appendices A1/A2/A3 (multi-tenant service providers / legacy SSL/TLS / Designated Entities Supplemental Validation). Most-requested next framework after SOC 2 + HIPAA + NIST CSF 2.0 for merchants + service providers + payment processors. NSAuditor's engine is framework-agnostic — see the SOC 2 coverage matrix, HIPAA §164.312 coverage matrix, and NIST CSF 2.0 coverage matrix for the companion frameworks.
NSAuditor AI EE generates PCI DSS v4.0.1 sub-requirement-level evidence — at the same institutional grade as SOC 2, HIPAA, and NIST CSF 2.0.
It maps cloud infrastructure findings (AWS, Azure, GCP) and network scan results to specific PCI sub-requirement IDs (1.2.1, 8.4.1, 10.2.1, etc.), produces signed evidence artifacts (cover-page Scope Attestation, SHA-256 chain-of-custody sidecars, RFC 3161 trusted-timestamps, cryptographic suppression signing), and ships PCI reports in machine-readable form suitable for PCI-aware GRC platform ingestion + QSA RoC workflow.
It is not a complete PCI DSS v4.0.1 RoC attestation (Req 5 anti-malware + Req 9 physical access are OOS-entirely; Req 12 Information Security Program is OOS-by-design entirely; Req 3 stored CHD discipline is OOS-by-design at the technical-control layer pending operator CDE-scope attestation). It is not a Customized Approach validation engine (engine evidences Defined-Approach configuration substrate; if operator implements a Customized Approach, the QSA cross-references operator's Customized Approach Documentation per Req 12.3.2). It is not a CDE scope determination tool (CHD scope is operator-attested via CDE Data Flow Diagram per Req 1.2.4 + Req 12.5.1). It is not a PCI SSC-Approved Scanning Vendor (Req 11.3.2 external ASV scans Defined-only per Appendix E — operator must contract a PCI SSC-listed ASV). It is not a pen-test platform (Req 11.4.1 internal/external pen test requires qualified pen-tester).
What it IS: the sub-requirement-level technical-evidence layer covering Req 1 (Network Security Controls), Req 2 (Apply Secure Configurations), Req 4 (TLS for CHD in transit — partial gated on CDE attestation), Req 6 (Develop and Maintain Secure Systems), Req 7 (Restrict Access by Need-to-Know), Req 8 (Identify Users + Authenticate Access), Req 10 (Log and Monitor All Access), Req 11.3.1 (Internal vulnerability scans) — complete and QSA-ready. Compatible with operator-side PCI DSS RoC preparation, ASV-scan ingestion, pen-test report integration, and merchant + service-provider acquirer questionnaire response. Honest about what infrastructure scanning fundamentally cannot evidence (Req 5 EDR + Req 9 facility + Req 12 governance + Customized Approach + CDE scope) — saves you from the textbook QSA-auditor overclaim findings.
The market split: PCI-aware GRC platforms (Drata PCI, Vanta PCI, AuditBoard PCI, OneTrust GRC) automate policy library + Targeted Risk Analysis + Customized Approach Documentation + TPSP Responsibility Matrix + security-awareness training workflows but lack deep cloud-infrastructure scanning at the sub-requirement-evidence level. Legacy PCI scanners (Qualys PCI, Tenable PCI) produce voluminous CVE reports but don't map findings to PCI sub-requirements at the auditor-canonical level. NSAuditor's wedge is the bridge — deep cloud + network scanning + PCI DSS v4.0.1 sub-requirement-mapped output + same Zero Data Exfiltration architecture used for SOC 2 + HIPAA + NIST CSF (CHD never leaves customer infrastructure; air-gapped deployment for PCI-CDE-isolation operator threat models).
Why sub-requirement-level mapping
PCI DSS v4.0.1 has a 2-level hierarchy:
Requirement (12 + Appendices A1/A2/A3 — Reqs 1–12 spanning network security through information-security program) — the top-level navigational grouping.
Sub-requirement (~250 — e.g., 1.2.1 NSC configuration standards, 8.4.1 MFA on non-console admin, 10.2.1 audit logs enabled) — the testing-procedure granularity QSAs attach evidence to in the RoC Reporting Template Appendix B.
QSAs walk the PCI DSS RoC sub-requirement-by-sub-requirement against testing procedures published in the PCI DSS v4.0.1 quick reference guide. Auditor-canonical evidence is per-sub-requirement. Requirement-level claims (e.g., "we cover Req 1") don't survive institutional QSA review — Req 1 alone spans ~30 sub-requirements; the auditor will ask which sub-requirements with what evidence.
NSAuditor maps at the sub-requirement level. Per-sub-requirement fields in data/compliance/pci-dss.json:
Field
Type
Purpose
id
string
Sub-requirement ID in canonical PCI form: REQ.SUB.LEAF (e.g., 8.4.1, 10.2.1).
requirement
enum
One of 1…12 — the parent Requirement group.
subRequirement
string
Full dotted ID (e.g., 1.2.1, 11.3.1).
requirementText
string
PCI SSC's verbatim testing-procedure outcome statement (the auditor-citation-source-of-truth).
customizedApproachObjective
string|null
PCI SSC-published CAO text from Appendix D where applicable; null for Defined-only sub-requirements + MVP-deferred to 0.11.1 for Customized-eligible sub-requirements.
approachEligibility
enum
Either defined-only (per Appendix E — Customized Approach NOT permitted) or customized-eligible (operator may implement alternative meeting the CAO).
controlType
enum
Either preventive, detective, or hybrid — defends against SOC 2 Class L preventive-overclaim (configuration-state evidence ≠ prevention-exercised evidence).
cloudProviderAttestation
object
Per-cloud-provider Service Provider AOC reference: {aws, azure, gcp}. Cited names current as of 2026-05-23 (AWS PCI DSS Service Provider AOC v4.0, etc.). Annual currency-review cadence institutionalized.
cdeScope
enum
Either always-in-scope, cde-only, or cde-conditional — per-control CDE-scope discipline gating which findings touch in-scope CDE per operator's CDE DFD attestation per Req 1.2.4 + Req 12.5.1.
The 4 load-bearing schema enrichments (controlType + approachEligibility + cloudProviderAttestation + cdeScope) defend against 13 ship-blocker classes surfaced by the EE 0.11.0 skill-research synthesis (SOC 2 evidence-sufficiency + HIPAA OCR R-vs-A discipline + PCI DSS QSA perspective audit-skill lenses). A schema-additive-fields propagation test enforces these fields reach the rendered report.
Defined Approach vs Customized Approach (PCI DSS v4.0.1 Appendix E)
PCI DSS v4.0 introduced the Customized Approach as a peer of the Defined Approach. Operators have three implementation paths per controlled sub-requirement:
Defined Approach — implement the control as the standard defines it. Substrate evidence: configuration state matching the testing procedures listed in the PCI DSS v4.0.1 quick reference guide. NSAuditor evidences this dimension.
Customized Approach — implement an alternative control meeting the published Customized Approach Objective (CAO) for that sub-requirement, with documented risk-acceptance signoff per Req 12.3.2 and supporting Targeted Risk Analysis per Req 12.3.1. The QSA cross-references the operator's Customized Approach Documentation; NSAuditor does not validate Customized Approach implementations.
Compensating Controls (legacy v3.2.1 path) — Appendix B retains compensating controls for sub-requirements where the operator cannot meet the Defined Approach AND the Customized Approach is not eligible. NSAuditor does not validate compensating controls.
Defined-only invariant per Appendix E.15 sub-requirements explicitly disallow the Customized Approach:
Misclassifying a Defined-only sub-requirement as Customized-eligible is the PCI analog of HIPAA's "Addressable as Required" overclaim — QSAs specifically test for this. NSAuditor enforces the discipline at the schema layer: every Defined-only sub-requirement in pci-dss.json carries approachEligibility: 'defined-only' + customizedApproachObjective: null. The test suite (tests/pci_dss_mapping_anchor_drift.test.mjs) provides asymmetric defense — positive (every Appendix-E Defined-only ID enumerated somewhere in the framework JSON) + negative (no Defined-only entry carries a non-null CAO).
CAO text MVP-deferred to EE 0.11.1. Per the PCI DSS v4.0.1 Appendix D template, each Customized-eligible sub-requirement has a published CAO text (e.g., for Req 8.4.1 MFA: "Account access to systems and data is verified to be authentic before access is granted"). EE 0.11.0 ships customizedApproachObjective: null on every entry — the renderer surfaces an explicit CAO MVP-deferral disclaimer in the report's cover page directing operators to PCI DSS v4.0.1 Appendix D for the per-sub-requirement CAO text. Population of the schema field with verbatim CAO text is planned for EE 0.11.1 patch.
Cardholder Data Scope — operator-attested
PCI DSS v4.0.1 requires the operator to attest CDE scope via a Cardholder Data Data Flow Diagram (DFD) per Req 1.2.4 + Req 12.5.1. The DFD enumerates:
Every system that stores, processes, or transmits Cardholder Data (CHD) or Sensitive Authentication Data (SAD)
Every system connected to CHD-bearing systems (Connected-To systems — also in-scope per PCI SSC guidance)
Every system that can affect the security of the CDE (Security-Impacting systems — also in-scope)
The network segmentation controls separating in-scope from out-of-scope systems
The engine cannot produce the CDE DFD. Infrastructure scanning cannot determine which storage holds CHD (the data classification is operator-attested), which transmission paths carry CHD (the application traffic-shape is operator-attested), or which systems affect CDE security (the architectural relationship is operator-attested). NSAuditor evidences the technical-substrate state of in-scope CDE infrastructure; the operator declares which findings touch in-scope CDE.
cdeScope value
Applicability
Examples
always-in-scope
The control applies regardless of CDE scope
Req 1.4.1 (NSCs between trusted/untrusted), Req 7.2.1 (access-control model), Req 8.4.1 (MFA on non-console admin), Req 10.2.1 (audit logs enabled)
cde-only
The control applies only to in-scope CDE resources
Reqs gated on CHD scope (OOS-by-default at technical-control layer): Req 3 (Protect Stored Account Data) — engine cannot determine which storage holds PAN; Req 4 (TLS for CHD in Transit) — partial at Req 4.2.1; Req 5 (Anti-Malware) — OOS-entirely endpoint EDR; Req 9 (Physical Access) — OOS-entirely facility; Req 12 (Information Security Program) — OOS-entirely governance.
Coverage matrix by Requirement (MVP-67)
Source of truth is data/compliance/pci-dss.json; this matrix mirrors it. The anchor-drift defense test asserts every (source, titlePattern) pair in pci-dss.json exists in soc2.json (inheritance contract — closes the silent false-CLEAN class at the PCI mapping layer, parallel to HIPAA + NIST CSF inheritance defenses).
Requirement
Covered
Partial
OOS
Notes
Req 1
3
1
0
Network Security Controls — strong fit. Covered: 1.2.1 NSC config standards, 1.3.1 inbound CDE restriction, 1.4.1 NSCs between trusted/untrusted. Partial: 1.2.5 services/protocols allowed have business-need (substrate, needs operator approval records).
Test Security of Systems/Networks. Covered: 11.3.1 internal vuln scans (continuous). Partial: 11.4.1 pen test methodology. OOS: 11.3.2 external ASV scans (Defined-only — need PCI SSC-listed ASV), 11.4.2 segmentation-change pen test, 11.5.1 IDS/IPS, 11.5.2/11.6.1 Magecart detection (Defined-only).
Req 12
0
0
14
OOS-by-design entirely — Information Security Program. Policy library + Targeted Risk Analysis (12.3.1 Defined-only) + CAO Documentation (12.3.2 Defined-only) + TPSP Responsibility Matrix (12.8.5 Defined-only) + IR Plan execution (12.10.x) + IR training (12.10.4 Defined-only) + awareness training (12.6.x). Pair with Drata PCI / Vanta PCI / AuditBoard PCI / OneTrust GRC.
Total
20
8
39
67 of ~250 sub-requirements enumerated (MVP-67). Density expansion deferred to 0.11.1+ per the EE 0.10.0 NIST CSF MVP-23 → density-expansion precedent.
How to run a PCI DSS scan
Once EE is installed and licensed, PCI DSS v4.0.1 evidence generation is a one-flag operation:
The engine emits standard render targets (Markdown for QSA distribution, HTML for browser/GRC consumption, JSON for machine ingestion, CSV for spreadsheet review). PCI DSS reports include the Cardholder Data Scope OOS disclaimer section between the cover-page status and per-sub-requirement sections — surfaces upfront that infrastructure scanning does NOT determine CDE scope (operator-attested via CDE DFD per Req 1.2.4 + Req 12.5.1).
Quad-framework: SOC 2 + HIPAA + NIST CSF + PCI DSS in one scan
The engine is framework-agnostic. A single scan with four framework targets produces four complete evidence packs, each citing its own framework's control IDs:
Each report's per-framework citation map cites only its own framework's control IDs. SOC 2 reports never cite §164.312, PR.AA-01, or Req 1.2.1. HIPAA reports never cite CC IDs, PR.AA-01, or Req 1.2.1. NIST reports never cite CC IDs, §164.312, or Req 1.2.1. PCI reports never cite CC IDs, §164.312, or PR.AA-01. Cross-framework citation-leak defense is enforced in all 6 pair-directions (C(4,2)=6) by 88 net new PCI tests across 3 new test files (added in EE 0.11.0).
The same scan, same set of cloud-API calls, same findings — four frameworks. This is the institutional value prop for organizations preparing simultaneous SOC 2 + HIPAA + NIST CSF + PCI DSS audits (or selectively responding to RFP security questionnaires that cite different frameworks).
What you get — output artifacts
PCI DSS reports follow the same auditor-grade artifact pattern as SOC 2, HIPAA, and NIST CSF 2.0:
Markdown (scan_compliance_pci-dss.md) — primary QSA distribution format. Cover-page Scope Attestation, CHD Scope OOS disclaimer, CAO MVP-deferral framing, Card-brand AOC enforcement priority view, Preventive-control discipline caveat, per-sub-requirement sections with covered / partial / OOS framing, audit-canonical sub-requirement IDs as headings.
HTML (scan_compliance_pci-dss.html) — browser / GRC-platform render. Same content as markdown including the CHD-Scope OOS disclaimer section (markdown + HTML parity per EE 0.11.0 P2 renderer extension).
8 sub-requirements are partial — the engine evidences a substrate dimension but cannot evidence the full outcome (typically because part of the outcome requires operator-side documentation / HRIS correlation / business-justification records / pen-test execution). Every partial entry carries a partialReason field + a manualProcedure field >100 chars (audit-grade specificity enforced by test):
Business-justification records per allowed-port finding (change-management system: Jira, ServiceNow, etc.); approver identity per Req 7.2.4 access-control model; approval-cycle review per Req 12.4 scope review.
2.2.4
End-of-life service detection (substrate)
Operator hardening standard (CIS Benchmark, NIST SP 800-123, vendor STIG, custom-justified baseline) classifying each service as necessary OR unnecessary+disabled.
Operator CDE DFD per Req 1.2.4 + data-classification register confirming which encrypted storage holds CHD; tokenization platform integration (Spreedly, Stripe Issuing, Braintree) for the four Req 3.5.1 approaches (hash / truncation / tokenization / strong-crypto-with-key-mgmt).
4.2.1.1
KMS key aliases + ACM certificate inventory substrate — Defined-only per Appendix E
Formal inventory artifact (operator-maintained) tying each trusted key/certificate to its CHD-transmission use case per Req 4.2.1.1.
6.4.1
Perimeter substrate via SG ingress findings on public-facing resources
WAF deployment + rule-tuning records (AWS WAF, Cloudflare, Akamai, Imperva, F5) in front of public-facing web applications hosting CDE-scoped functionality.
8.2.6
Stale-key state via IAM access-key-age substrate
HRIS termination + role-change correlation closing the 90-day-inactivity dimension; operator HRIS termination CSV cross-referenced against stale-key findings.
10.5.1
CloudTrail retention configuration via S3 lifecycle policies
Verification that (a) total retention ≥12 months via S3 lifecycle, (b) most-recent 3 months in S3 Standard or S3 Intelligent-Tiering (not Glacier; immediately queryable).
Qualified pen-tester (internal team meeting Req 11.4.1 independence requirements OR external pen-tester) annual engagement + after significant change; pen-test methodology + report operator-side.
Req 12 Information Security Program — OOS-by-design entirely (14 sub-requirements)
Req 12 is the policy / strategy / governance dimension of PCI DSS v4.0.1: 12.1.x Information Security Policy, 12.2.x Acceptable Use Policy, 12.3.x Targeted Risk Analysis + Customized Approach Documentation (Defined-only), 12.4.x Scope Review, 12.5.x Scope Documentation, 12.6.x Security Awareness Training, 12.7.x Personnel Screening, 12.8.x TPSP Management (incl. 12.8.5 TPSP Responsibility Matrix Defined-only), 12.9.x TPSP Acknowledgment, 12.10.x Incident Response Plan execution (incl. 12.10.4 IR personnel training Defined-only). These are governance, board-level, training-records, supplier-relationship, and IR-runbook evidence streams.
All 14 enumerated Req 12 sub-requirements are OOS by architectural design. They require board minutes, signed information-security policy documents, Targeted Risk Analysis records, Customized Approach Documentation per Req 12.3.2 template, TPSP responsibility matrices, HRIS training records, and IR runbook execution logs — none of which infrastructure scanning can produce. Pair NSAuditor with a PCI-aware GRC platform (Drata PCI, Vanta PCI, AuditBoard PCI, OneTrust GRC) for Req 12 coverage.
This OOS-by-design framing is parallel to HIPAA §164.308 Administrative Safeguards entire + NIST CSF GV.* (Govern function ex GV.SC-04) + SOC 2 CC1.x–CC5.x (governance, communication, risk assessment, monitoring activities, control activities) OOS framing — the engine evidences technical substrate; operator-side governance evidence streams close the program-level dimension.
Req 5 (Anti-Malware) — 3 sub-requirements OOS-entirely. Req 5.2.x anti-malware solution deployed, Req 5.3.x anti-malware mechanisms active/maintained/monitored, Req 5.4.x anti-phishing mechanisms (NEW v4.0). All require endpoint EDR + email-security-gateway substrate that infrastructure scanning cannot produce. Pair with CrowdStrike Falcon / SentinelOne / Microsoft Defender for Endpoint (Req 5.2 + 5.3) + Proofpoint / MS Defender for Office 365 / Mimecast (Req 5.4 anti-phishing).
Req 9 (Physical Access) — 5 sub-requirements OOS-entirely. Req 9.1.1 physical access processes, 9.2.1 physical access controls, 9.3.1 visitors identified/authorized, 9.4.1 media storage + handling, 9.5.1 point-of-interaction devices. All are facility-tier — engine produces no facility-control substrate. Inherit cloud-provider's PCI DSS Service Provider AOC for the cloud-substrate portion (AWS PCI DSS Service Provider AOC v4.0 + Microsoft Azure PCI DSS v4.0 AOC + Google Cloud Platform PCI DSS v4.0 AOC all cover facility / hypervisor / network-infrastructure physical security); operator-maintained for on-prem CDE + badge-system logs + visitor logs.
This OOS-entirely framing is parallel to HIPAA §164.310 Physical Safeguards entire + NIST CSF PR.IR-02 (organization's technology assets protected from environmental threats — facilities) + SOC 2 CC6.4 (physical access to facilities) when claimed by cloud-tenant operators.
Customized Approach Objectives (CAOs) — MVP-deferred to EE 0.11.1
PCI DSS v4.0 introduces the Customized Approach Objective as the canonical reference for any Customized Approach implementation. Each Customized-eligible sub-requirement has a published CAO text in PCI DSS v4.0.1 Appendix D (e.g., for Req 8.4.1 MFA: "Account access to systems and data is verified to be authentic before access is granted"). The Customized Approach Documentation per Req 12.3.2 cites the CAO as the alternative-control evaluation target.
EE 0.11.0 ships customizedApproachObjective: null on every entry — verbatim CAO text per Customized-eligible sub-requirement is MVP-deferred to EE 0.11.1 patch (mirroring the EE 0.10.0 NIST CSF MVP-23 → density-expansion precedent). The renderer surfaces an explicit CAO MVP-deferral disclaimer in the report's cover page directing operators to PCI DSS v4.0.1 Appendix D for the per-sub-requirement CAO text.
Defined-only invariant enforced at the schema layer. Per PCI DSS v4.0.1 Appendix E, 15 sub-requirements explicitly disallow the Customized Approach — these MUST carry customizedApproachObjective: null perpetually (not as an MVP deferral; Defined-only sub-requirements cannot have a CAO under any circumstance). The test suite asymmetric defense ensures (a) every enumerated Defined-only ID is correctly classified, (b) every Appendix-E Defined-only ID appears somewhere in the framework JSON.
The honest framing is the institutional value prop. A vendor that claims Customized Approach validation from infrastructure scanning alone fails QSA scrutiny; a vendor that names the operator-side documentation surface upfront (CAO in Appendix D + Customized Approach Documentation per Req 12.3.2 + Targeted Risk Analysis per Req 12.3.1) passes.
The PCI Security Standards Council publishes the PCI DSS v4.0.1 standard + the QSA program; the four major payment card brands enforce it via individual Attestation of Compliance (AOC) programs:
Card brand
AOC program
Penalty mechanism
Visa
Cardholder Information Security Program (CISP)
$5K-$100K/month fines + post-breach Visa PFI forensic investigation + acquirer-relationship termination
Structured per-finding-to-category mapping is a planned EE 0.11.1+ improvement (R-MEDIUM-5 from the EE 0.11.0 QSA reviewer pass).
Cloud-provider PCI DSS Service Provider AOC inheritance
PCI DSS v4.0.1 explicitly recognizes the shared-responsibility model. Operators running workloads on AWS / Azure / GCP inherit the infrastructure-tier portion of certain controls from the cloud provider's PCI DSS Service Provider AOC. Every covered + partial control in pci-dss.json carries a cloudProviderAttestation: {aws, azure, gcp} schema field referencing the currently-named AOC for each provider (as of 2026-05-23):
Operator's TPSP Responsibility Matrix per Req 12.8.5 enumerates which controls the operator inherits from each cloud provider's AOC vs which the operator retains. NSAuditor's cloudProviderAttestation field is the substrate for this matrix — pair with the operator-maintained Req 12.8.5 Responsibility Matrix document for the full TPSP boundary.
AOC currency. Cloud-provider AOCs are reissued annually; the names cited above are current as of 2026-05-23. The cloudProviderAttestation strings in pci-dss.json are revisited annually to verify AOC currency — stale AOC references are a Class L finding per the audit-pci-dss-qsa-perspective audit skill.
Type-I vs Type-II for PCI DSS v4.0.1
PCI DSS does not formally use Type-I / Type-II terminology (that's SOC 2 / SSAE 18 convention). PCI DSS RoC submissions expect:
Point-in-time evidence — current state of sub-requirement-level technical posture. NSAuditor produces this directly with scan_compliance_pci-dss.* artifacts.
QSA sampling per PCI SSC RoC Reporting Template Appendix B — sub-requirement-by-sub-requirement testing procedures. NSAuditor's sub-requirement-level findings directly map to the QSA's testing-procedure walkthrough.
Operating effectiveness over the assessment period — does the configuration posture hold over the typically-12-month attestation window? NSAuditor's recurring-scan attestation + SLA/MTTR tracking provide the cadence proof; multi-period attestation reports cover Req 11.3.1 quarterly internal vuln scan cadence + Req 10.4.1 daily-log-review cadence + Req 8.2.4 90-day-credential-review cadence dimensions.
External ASV scans (Req 11.3.2 Defined-only) — operator MUST contract a PCI SSC-Approved Scanning Vendor (ASV) for the external-scan dimension. NSAuditor does NOT substitute for ASV scans; the engine produces internal-scan substrate (Req 11.3.1).
Annual pen test (Req 11.4.1 partial + Req 11.4.2 OOS) — operator MUST engage qualified pen-tester. NSAuditor produces perimeter substrate (SG/NSG findings) informing pen-test scope; the formal pen-test report is operator-side.
Zero Data Exfiltration — air-gapped CHD-safe deployment
The same architectural principle that makes NSAuditor AI EE a Zero-BAA tool for HIPAA applies to PCI DSS deployments: scan data never leaves customer infrastructure under any condition. Nsasoft does not see, store, or process customer cloud-API credentials, scan results, or evidence artifacts. The scanner is self-hosted; AI analysis runs locally (Ollama) or via the customer's own API keys (OpenAI, Anthropic); reports are written to the customer's local out/ directory.
This is the institutional differentiator for payment-processing customers with PCI DSS CDE isolation requirements. Sending scan data (including potentially CHD-adjacent metadata, network topology, IAM principal names) to a SaaS scanner is itself a potential CDE-isolation-boundary violation — PCI DSS Req 1.4.1 (NSCs between trusted/untrusted) + Req 12.5.1 (PCI DSS scope documented) framing applies to the scanner's network position. NSAuditor's air-gapped deployment is compatible with strict CDE-isolation threat models where outbound SaaS traffic from in-scope CDE infrastructure is prohibited.
PCI-aware GRC platforms (Drata PCI, Vanta PCI, AuditBoard PCI, OneTrust GRC) are SaaS and pair with NSAuditor for the OOS surfaces they specialize in — Req 12 governance, Req 12.3.1 Targeted Risk Analysis, Req 12.3.2 Customized Approach Documentation, Req 12.8.5 TPSP Responsibility Matrix, Req 12.6 awareness training — without ingesting the raw scan data or cloud credentials. The policy/workflow data they consume is sanitized governance data, not infrastructure substrate.
NSAuditor produces the sub-requirement-level technical substrate evidence GRC platforms cannot. Complement, not replacement.
Legacy PCI scanners
Qualys PCI, Tenable PCI, Rapid7
CVE detection at scale + ASV-scan substrate
NSAuditor produces PCI sub-requirement-mapped evidence (the format QSAs actually want) rather than raw CVE lists with no framework mapping. NSAuditor does NOT substitute for ASV scans (Req 11.3.2 Defined-only).
PCI consulting firms / QSAs
Coalfire, A-LIGN, Schellman, BlueVoyant
QSA RoC audit + advisory services
NSAuditor produces the pre-audit sub-requirement gap report the QSA builds the RoC on top of — reduces QSA billable hours + accelerates the RoC writing process.
CHD vaulting + PAN tokenization (Req 3.5.1 implementation path)
NSAuditor surfaces encryption-at-rest substrate (Req 3.5.1 partial); tokenization platforms close the PAN-render-unreadable dimension by removing CHD from operator's CDE entirely. Complement, not competition.
QSA-Auditor FAQ
Does NSAuditor map at the Requirement or sub-requirement level?
Sub-requirement level — the auditor-canonical granularity per PCI SSC RoC Reporting Template Appendix B. Requirements (Reqs 1–12) are navigational headers; sub-requirements (e.g., 1.2.1, 8.4.1, 10.2.1) are the testing-procedure granularity QSAs attach evidence to.
Why is Req 12 Information Security Program OOS-by-design entirely?
All 14 enumerated Req 12 sub-requirements require policy/governance/risk-assessment/IR-program/TPRM/training evidence streams that infrastructure scanning cannot produce. This includes the Defined-only Req 12.3.1 (Targeted Risk Analysis), Req 12.3.2 (Customized Approach Documentation), Req 12.8.5 (TPSP Responsibility Matrix), and Req 12.10.4 (IR personnel training). Pair with Drata PCI / Vanta PCI / AuditBoard PCI / OneTrust GRC.
Why are Req 5 anti-malware and Req 9 physical access OOS-entirely?
Req 5 requires endpoint EDR + email-security gateway substrate (operator-side: CrowdStrike Falcon, SentinelOne, MS Defender for Endpoint + Proofpoint, MS Defender for Office 365, Mimecast). Req 9 is facility-tier — inherit cloud-provider's PCI DSS Service Provider AOC (AWS PCI DSS Service Provider AOC v4.0, Microsoft Azure PCI DSS v4.0 AOC, Google Cloud Platform PCI DSS v4.0 AOC) for cloud-substrate portion; operator-maintained for on-prem CDE + badge-system logs.
How does NSAuditor handle the Customized Approach Objectives (CAOs) NEW in v4.0?
Engine evidences the Defined-Approach configuration substrate; Customized Approach implementations require operator-maintained Customized Approach Documentation per Req 12.3.2 — the QSA cross-references that document. Per-sub-requirement CAO text is MVP-deferred to EE 0.11.1 patch (every entry currently ships customizedApproachObjective: null); the renderer surfaces an explicit CAO MVP-deferral disclaimer in the report's cover page directing operators to PCI DSS v4.0.1 Appendix D for the verbatim CAO text. The Defined-only invariant per Appendix E (15 sub-requirements) is enforced at the schema layer.
How does NSAuditor handle CDE scope?
Engine cannot determine CDE scope from infrastructure scanning — operator-attested via the CDE Data Flow Diagram per Req 1.2.4 + Req 12.5.1. Every covered + partial control in pci-dss.json carries a cdeScope schema field (always-in-scope / cde-only / cde-conditional) classifying applicability. The cover-page disclaimer surfaces the macro-warning that Reqs 3 + 4 + 5 + 9 + 12 all gate on CDE-scope attestation.
What about card-brand AOC enforcement?
Visa CISP / Mastercard SDP / Amex DSOP / Discover DISC are the actual enforcement mechanism — fines $5K-$100K/month per brand + post-breach forensic-investigation (Visa PFI / Mastercard PFA) + acquirer-relationship termination. The renderer surfaces a QSA-priority view categorizing findings by card-brand AOC enforcement risk: externally-facing CDE with weak auth (Reqs 1 + 8); unpatched CDE infrastructure (Req 6.3.3); segmentation-change-triggered pen-test missing (Req 11.4.2); critical-control-failure undetected (Req 10.7).
What's the inheritance contract with soc2.json?
Every (source, titlePattern) pair in pci-dss.json MUST exist in soc2.json (defended by tests/pci_dss_mapping_anchor_drift.test.mjs). Closes the silent false-CLEAN class at the PCI DSS mapping layer. Parallel to HIPAA + NIST CSF inheritance defenses (EE 0.9.0 + EE 0.10.0). Cross-framework citation-leak defense enforced in all 6 pair-directions (4 frameworks → C(4,2)=6 pair-tests).
Can NSAuditor substitute for an ASV scan (Req 11.3.2)?
No. Req 11.3.2 is Defined-only per PCI DSS v4.0.1 Appendix E — operator MUST contract a PCI SSC-listed Approved Scanning Vendor (ASV) for external vulnerability scans ≥ quarterly. NSAuditor produces internal-scan substrate (Req 11.3.1 covered via Inspector2 + intelligence_engine); the ASV-attested external scan is operator-side. Req 11.3.2 is enumerated in the Req 11 OOS group with explicit ASV-only attribution.
Can NSAuditor substitute for a pen-test (Req 11.4)?
No. Req 11.4.1 (pen-test methodology) is partial — engine produces perimeter substrate informing pen-test scope; the formal pen-test report is operator-side (requires qualified pen-tester meeting Req 11.4.1 independence requirements). Req 11.4.2 (pen-test after significant segmentation change) is OOS — operator-side cadence-triggered execution.
How does NSAuditor handle the Magecart attack class (Req 11.5.2 + 11.6.1)?
Req 11.5.2 + Req 11.6.1 (change-and-tamper-detection on payment pages — NEW v4.0) are Defined-only per Appendix E. These require operator-side WAF/CSP/RASP (Cloudflare, Akamai, Imperva for WAF; CSP for inline-script integrity; RASP for runtime change detection). NSAuditor surfaces the OOS framing with explicit WAF/CSP/RASP alternatives named — does NOT substitute for the operator-side controls.
Does NSAuditor cover PCI DSS v3.2.1?
No — explicitly only PCI DSS v4.0.1 (PCI SSC, June 2024 errata). v3.2.1 was retired March 31, 2024. The version pin is enforced in data/compliance/pci-dss.jsonversion: "4.0.1" and reflected in the rendered frameworkLabel.