PCI DSS v4.0.1 evidence at the sub-requirement level — the way QSAs actually walk the RoC.

TL;DR — what this does for PCI DSS v4.0.1

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 hash-chained evidence artifacts (cover-page Scope Attestation, SHA-256 chain-of-custody sidecars, and a documented suppression workflow), and ships PCI reports in machine-readable form suitable for PCI-aware GRC platform ingestion + QSA RoC workflow.

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 operation 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 (314 identifiers in the twelve main-body Requirements, 227 of them leaves — e.g., 1.2.1 NSC configuration standards, 8.4.1 MFA on non-console admin, 10.2.1 audit logs enabled; "~250 sub-requirements" is an approximation of that leaf count) — the testing-procedure granularity at which PCI DSS v4.0.1 states its requirements, and the granularity pci-dss.json keys its controls and coverage on.

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 carries 24 identifiers, 19 of them leaves, and this page evidences four of them; 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:

The 4 load-bearing schema enrichments (controlType + approachEligibility + cloudProviderAttestation + cdeScope) defend against 13 ship-blocker classes identified in pre-authoring review, from the SOC 2 evidence-sufficiency, HIPAA OCR Required-vs-Addressable, and PCI DSS QSA perspectives. A schema-additive-fields propagation test enforces these fields reach the rendered report.

Defined Approach vs Customized Approach (PCI DSS v4.0.1 Appendix D; ineligibility stated per requirement)

PCI DSS v4.0 introduced the Customized Approach as a peer of the Defined Approach. Operators have three implementation paths per controlled sub-requirement:

1. 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.
2. 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.
3. 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.

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; calling a Customized-eligible sub-requirement Defined-only is the other direction, and it tells an operator that a path the standard leaves open to them is closed. NSAuditor enforces the discipline at the schema layer: the eligibility set is derived from the PCI DSS v4.0.1 PDF by scripts/derive_pci_dss_ids.mjs into data/standards/pci-dss-v4_0_1-ids.json (identifiers and one eligibility boolean each — the standard's text is not redistributed), pci-dss.json points at it, and any entry marked approachEligibility: 'defined-only' carries customizedApproachObjective: null perpetually. The test suite (tests/pci_dss_mapping_anchor_drift.test.mjs) provides asymmetric defense — positive (every main-body ineligible identifier is enumerated somewhere in the framework JSON) + negative (no Defined-only entry carries a non-null CAO) — and tests/pci_id_existence.test.mjs fails the build on any cited identifier absent from the derived set.

CAO text populated per Appendix D. 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"). The engine populates customizedApproachObjective on every one of the 28 mapped controls, each carrying a Customized Approach Objective flagged per control (objectiveProvenance: verbatim | paraphrase) as the standard's own cell wording or NSAuditor's paraphrase, verified against the document in both directions — the renderer labels each from that flag, surfaces a per-control CAO blockquote when the field is non-null and directs operators to verify against the PCI DSS v4.0.1 publication.

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.

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 (72 enumerated sub-requirements)

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).

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. Each report's citation map is built from its own framework's mapping file, so it is framework-pure by construction. As a prose-level backstop, finding text in every report additionally has the other frameworks' control-ID shapes stripped — one alternation rule covering all 10 pair-directions among the five frameworks whose IDs are unambiguously shaped (SOC 2 CC6.6, HIPAA §164.312, NIST CSF PR.AA-01, ISO 27001 A.8.24, GDPR Art.32). PCI DSS and CIS v8 IDs are deliberately exempt from that strip: a bare 3.5.1 or 3.11 is indistinguishable from a version number or a date, so stripping them would mangle legitimate prose. A stray PCI sub-requirement ID inside another framework's narrative text is therefore a documented producer-side residual, not something the backstop removes.

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).
• JSON (scan_compliance_pci-dss.json) — machine-readable structured envelope for PCI-aware GRC connector push (Vanta PCI + Drata PCI + Secureframe PCI connectors shipped with opt-in early-access scan-time push). Per-sub-requirement schema-additive fields propagated: requirement, subRequirement, requirementText, customizedApproachObjective, controlType, approachEligibility, cloudProviderAttestation, cdeScope, informativeReferences.
• CSV (scan_compliance_pci-dss.csv) — spreadsheet-friendly tabular view for stakeholder review.
• SHA-256 sidecars (scan_compliance_pci-dss.{md,html,json,csv}.sha256) — chain-of-custody integrity manifests. Auditors can verify offline with shasum -a 256 -c <file>.sha256.
• Trusted timestamping (RFC 3161) is opt-in as of EE 0.33.0 — set NSAUDITOR_TSA_URL to a Time-Stamp Authority you choose and each artifact gets a .tsr sidecar a QSA verifies offline with openssl ts -verify. Opt-in with no default, ever: a baked-in default would be third-party egress nobody asked for. Verified against a real authority on 2026-08-07 — Status Granted, Verification: OK, and a one-byte change to the artifact flips it to FAILED.

Covered sub-requirements — direct substrate evidence

19 sub-requirements are covered with direct substrate evidence from the cloud plugins + network scanners (Req 7.2.2, listed below, is an honest partial — the job-classification half is operator-attested). Below is the canonical citation set:

Partial sub-requirements — substrate-only evidence (operator-side completion documented)

9 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):

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 (12.3.2 is part of the Customized Approach itself — neither Defined-only nor Customized-eligible), 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), 12.9.x TPSP Acknowledgment, 12.10.x Incident Response Plan execution (incl. 12.10.4 IR personnel training). None of these is out of scope because the standard withholds the Customized Approach from it. 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 + Req 9 Physical Access — OOS-entirely

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) — authored per Appendix D

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.

Defined-only invariant enforced at the schema layer. PCI DSS v4.0.1 states Customized Approach ineligibility in each requirement's own Customized Approach Objective cell; in the main body that is six identifiers (3.3.1, 3.3.1.1, 3.3.1.2, 3.3.1.3, 3.3.2, 11.3.2), every one of them enumerated here as out of scope, and none of the 28 mapped controls. Any entry marked Defined-only MUST carry customizedApproachObjective: null perpetually (Defined-only sub-requirements cannot have a CAO under any circumstance). The test suite asymmetric defense ensures (a) no Defined-only entry carries a non-null CAO, (b) every main-body ineligible identifier in the derived set 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.

Card-brand AOC enforcement (Visa CISP / Mastercard SDP / Amex DSOP / Discover DISC)

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:

NSAuditor's PCI DSS reports surface a QSA-priority view in the cover-page CHD-Scope section categorizing findings by card-brand AOC enforcement risk:

• Externally-facing CDE with weak auth (Reqs 1 + 8): highest enforcement priority — all four card brands focus enforcement here.
• Unpatched CDE infrastructure (Req 6.3.3 CRITICAL within 1 month): Visa CISP + Mastercard SDP enforcement post-breach.
• Segmentation-change-triggered pen-test missing (Req 11.4.5; Req 11.4.6 for service providers): failure to test segmentation controls after a significant segmentation change. Req 11.4.2 is the internal penetration test.
• Critical-control-failure undetected (Req 10.7): failure-detection gaps create breach-window exposure.

Every PCI DSS report renders the structured QSA-priority view with four card-brand AOC enforcement categories: Cat 1 externally-facing CDE weak auth (Req 1 + Req 8) · Cat 2 unpatched CDE infrastructure (Req 6.3.3 + 6.4.1) · Cat 3 pen-test substrate (Req 11.3.x + 11.4.x) · Cat 4 critical-control-failure substrate (Req 10.2.1 / 10.4.1 / 10.5.1 / 10.6.1 / 10.7.x). Operators can triage CDE findings by what reviewers actually escalate on.

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 — a stale AOC reference is exactly the kind of currency defect a QSA raises on review.

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 Section 6 of PCI DSS v4.0.1 ("For Assessors: Sampling for PCI DSS Assessments"), which prescribes no sample size and no population threshold — the size is the assessor's determination, documented with its rationale; any figure NSAuditor suggests is a starting point, never a PCI SSC figure. 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 per the requirement's own CAO cell) — 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 internal pen test and Req 11.4.5 / 11.4.6 segmentation pen tests 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: no scan data, cloud-API credential or evidence artifact is ever transmitted to Nsasoft — we do not see, store or process any of it. Every outbound path the product can take is enumerated in its published egress register, so the claim is one you can audit rather than one you have to trust. 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 operation 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.

Comparison vs the PCI DSS market

QSA-Auditor FAQ

Does NSAuditor map at the Requirement or sub-requirement level?

Sub-requirement level — the auditor-canonical granularity, the level at which PCI DSS v4.0.1 states its requirements, which pci-dss.json keys its controls and coverage on. 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 Req 12.3.1 (Targeted Risk Analysis), Req 12.3.2 (Customized Approach Documentation — part of the Customized Approach itself, neither Defined-only nor Customized-eligible), Req 12.8.5 (TPSP Responsibility Matrix), and Req 12.10.4 (IR personnel training). None is out of scope because the standard withholds the Customized Approach from it. 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. Every one of the 28 mapped controls carries a Customized Approach Objective flagged per control as the standard's own cell wording or NSAuditor's paraphrase, verified against the document in both directions (any Defined-only entry carries customizedApproachObjective: null); the renderer labels each from that flag, surfaces a per-control CAO blockquote and directs operators to verify against the PCI SSC publication. PCI DSS v4.0.1 states Customized Approach ineligibility in each requirement's own Customized Approach Objective cell, not in an appendix — six main-body identifiers (3.3.1, 3.3.1.1, 3.3.1.2, 3.3.1.3, 3.3.2, 11.3.2), all out of scope for this engine, and none of the 28 mapped controls. The invariant is enforced at the schema layer, and a build guard refuses any cited identifier the standard does not contain.

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.5 — the segmentation-controls test; Req 11.4.2 is internal penetration testing and Req 11.4.6 the service-provider segmentation cadence); 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 the HIPAA + NIST CSF inheritance defenses. Cross-framework citation-leak defense covers all 10 pair-directions among the five unambiguously-shaped frameworks (SOC 2 / HIPAA / NIST CSF / ISO 27001 / GDPR); PCI DSS and CIS v8 bare-decimal IDs are exempt by design, being indistinguishable from version numbers — a documented producer-side residual.

Can NSAuditor substitute for an ASV scan (Req 11.3.2)?

No. Req 11.3.2 is Defined-only — not eligible for the Customized Approach, stated in the requirement's own Customized Approach Objective cell in PCI DSS v4.0.1 — and the 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 (internal penetration test, annually and after any significant infrastructure or application change) and Req 11.4.5 / 11.4.6 (segmentation-controls penetration tests — annually and after any change to segmentation controls; every six months for service providers) are OOS — operator-side cadence-triggered execution.

How does NSAuditor handle the Magecart attack class (Req 6.4.3 + 11.6.1)?

Req 11.6.1 (a change- and tamper-detection mechanism over the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser, at least weekly or at the frequency set in the entity's targeted risk analysis — NEW v4.0) is Customized-eligible and out of scope because the engine cannot evidence it. Its companion obligation is Req 6.4.3 (every payment page script confirmed authorized, integrity assured, and inventoried with a written business or technical justification), which this matrix does not enumerate. Req 11.5.2 is a different requirement, listed separately in the matrix above: a change-detection mechanism — file integrity monitoring is the standard's own example — over critical files, compared at least once weekly. 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.json version: "4.0.1" and reflected in the rendered frameworkLabel.