Payment security standardInternational

PCI DSS v4.0.1 Compliance and Payment-Security Readiness

Bring current PCI DSS requirements into continuous managed operation across a correctly scoped cardholder data environment.

View the control mapping

Where we contribute

A managed security layer within a broader compliance program.

PCI DSS applies to the people, processes, technologies, facilities, payment channels, providers, and evidence involved in storing, processing, or transmitting account data, as well as those affecting the security of the cardholder data environment. Network Box can operate substantial technical controls, but it does not certify compliance or replace a QSA, ISA, ASV, or the entity that accepts the client's validation.

Current standard status

Reviewed September 2, 2026

PCI DSS v4.0.1 is the currently published standard.

PCI SSC published v4.0.1 as a limited revision in June 2024. PCI DSS v4.0 retired on December 31, 2024, and the future-dated v4.x requirements became effective on March 31, 2025.

Read PCI SSC's v4.0.1 announcement ↗
  • PCI DSS v4.0.1 did not add or remove requirements; it clarified wording, applicability, and guidance.
  • Requirements formerly described as future-dated are now effective requirements, not optional preparation items.
  • Active examples include expanded MFA, authenticated internal scanning, automated public-facing application protection, payment-page script controls, browser-facing tamper detection, and targeted risk analyses.
  • PCI SSC maintains the standard, while payment brands, acquirers, and other compliance programs determine validation and submission obligations.
  • Each entity should confirm its merchant or service-provider level, reporting route, validation documents, and deadlines with the receiving organization.

Scope and applicability

Start with the payment environment, not the questionnaire.

A defensible PCI program begins by locating account data and identifying every person, process, technology, facility, service, and connection that can store, process, transmit, or affect it.

Cardholder data

Know where PAN exists

PAN and any associated cardholder name, expiration date, or service code must be mapped, minimized, protected, retained only as needed, and securely deleted.

Sensitive authentication data

Do not retain it after authorization

Full track data, card verification codes or values, and PIN/PIN-block data generally may not be stored after authorization, even when encrypted.

CDE scope

Include security-impacting systems

Identity, security, administration, logging, virtualization, cloud control planes, software delivery, and connected systems may be in scope even without directly storing card data.

Validation

Confirm the required reporting route

The applicable payment brand, acquirer, or compliance-accepting entity determines the required SAQ, AOC, ROC, ASV evidence, assessor involvement, and submission schedule.

Control mapping

PCI DSS v4.0.1 requirements and Network Box support.

The twelve requirement families below distinguish continuous managed-security contributions from the merchant or service provider responsibilities that remain necessary for assessment and validation.

Authoritative sourcePCI Security Standards Council document library ↗
Select a framework area to explore its detailed control mapping.
Framework areaNetwork Box contributionRelevant servicesCoverage
Managed boundaries, segmentation, secure connectivity, rule changes, inspection, and monitoring restrict traffic within scope.
UTM+FirewallsSecure SD-WANVPNNetwork segmentationIDS/IPS24/7 SOC
Strong
Secure configurations, restricted administration, updates, change records, and monitoring protect managed services.
Managed platform operationsUTM+Secure SD-WANSecure Web GatewayWAFManaged Cloud Email Security
Partial
Segmentation, access restrictions, monitoring, and detection reduce exposure but do not replace storage minimization or cryptography.
Network segmentationAccess controlsWAFSIEMNBX: MDR, EDR, XDR
Supporting
Managed encrypted connectivity and gateway controls protect covered public-network paths and reveal unexpected communications.
VPNSecure SD-WANUTM+Secure remote accessGateway controlsNetwork monitoring
Strong
Layered network, email, web, endpoint, intelligence, and SOC controls prevent and respond to malware.
Anti-malwareSecure Web GatewayManaged Cloud Email SecurityUTM+NBX: MDR, EDR, XDRThreat intelligence24/7 SOC
Strong
Vulnerability findings, WAF, threat response, advisories, and controlled managed-service changes support secure operation.
Vulnerability ManagementWAFIDS/IPSSIEMNBX: MDR, EDR, XDRThreat intelligence
Partial
Network policy, segmentation, managed roles, secure remote access, and telemetry support least-privilege enforcement.
UTM+Network segmentationVPNSecure SD-WANDirectory integrationSIEM
Partial
Unique managed-service accounts, secure administration, supported MFA, directory integration, and logging protect managed access.
VPNMFA/TOTP supportDirectory integrationManaged administrative accessAuthentication loggingSIEM
Partial
Service and assurance information can support review of facilities used for Network Box-managed services.
Service documentationAssurance documentationNetwork monitoringNetwork segmentation
Supporting
Connected telemetry, correlation, continuous analyst review, alerting, investigations, dashboards, and reports support auditability.
SIEMNBX: MDR, EDR, XDRManaged-device logging24/7 SOCCorrelationDashboardsSecurity reporting
Strong
Vulnerability assessment, monitoring, attack detection, change telemetry, WAF, and SOC investigations support recurring testing.
Vulnerability ManagementAuthenticated scanningIDS/IPSWAFSIEMNBX: MDR, EDR, XDR24/7 SOC
Partial
Responsibilities, reporting, intelligence, response support, awareness training, and operational records support the entity's program.
Service documentationResponsibility assignmentsThreat intelligenceSecurity reportingIncident responseSecurity Awareness TrainingService reviews
Partial

These mappings are illustrative and depend on deployment, configuration, service scope, the client environment, and evidence requirements. Strong, Partial, and Supporting describe Network Box's potential contribution, not a compliance conclusion.

Segmentation and scope

Segmentation can reduce scope, but it must be proven.

Network Box firewalls, routing, VLAN controls, SD-WAN policy, access restrictions, and monitoring can establish a strong segmentation foundation. The assessed entity must still map every account-data flow and security-impacting dependency, apply documented least-access paths, test segmentation at required frequencies and after applicable changes, and have the assessor confirm whether isolation is effective for PCI DSS scope reduction.

Architecture-specific validation

Similar security activities are not interchangeable.

Several active v4.0.1 requirements depend on exact technical scope, implementation, cadence, independence, and testing evidence. General product capability is not enough.

01

6.4.2 · Public-facing applications

An appropriately scoped, current, monitored, and actively blocking WAF can strongly support the required automated protection, but every applicable application and response process must be covered.

02

6.4.3 · Payment-page scripts

The entity must authorize browser-executed scripts, assure their integrity, and maintain a justified inventory. A traditional WAF alone does not establish these outcomes.

03

11.6.1 · Browser-facing tamper detection

The mechanism must evaluate payment-page headers and content as received by the consumer's browser. Server-side monitoring alone may not satisfy the requirement.

04

Internal vulnerability scanning

Confirm complete in-scope coverage, required authenticated scanning, qualified independence, passing criteria, rescans, and scans after applicable significant changes.

05

External ASV scanning

A standard vulnerability report is not automatically an ASV scan. Required external compliance scans must use a PCI SSC Approved Scanning Vendor and achieve the required passing result.

06

Penetration and segmentation testing

Vulnerability scanning does not replace penetration testing. Required tests need compliant scope, methodology, independence, cadence, remediation, and retesting evidence.

Assessment evidence

Show that safeguards are operating.

Available evidence depends on deployed services, configured log sources, agreed scope, format, and retention period.

  1. 01Service descriptions, scope statements, contracts, and responsibility assignments
  2. 02Inventories of managed devices, services, protected endpoints, and connected log sources
  3. 03Network and account-data-flow diagrams with managed boundaries, connections, and segments
  4. 04Firewall, VPN, SD-WAN, routing, segmentation, web, email, IDS/IPS, and WAF policies
  5. 05Business justifications, approvals, changes, and periodic reviews for managed network rules
  6. 06Secure configuration information, managed updates, and change records
  7. 07Administrative access, authentication, and MFA records for managed services
  8. 08Centralized logs, log-source health, audit trails, searches, dashboards, and reports
  9. 09Evidence of recurring security-event review, alert handling, escalation, and follow-up
  10. 10Time-synchronization information for managed devices and services
  11. 11SOC alerts, investigations, incident tickets, timelines, and response actions
  12. 12Vulnerability scan results, authenticated-scan details, trends, remediation advice, and rescans
  13. 13WAF events, blocked attacks, policy changes, and monitored-coverage information
  14. 14Malware, email, web, endpoint, identity, network, and IDS/IPS threat events
  15. 15Security-awareness participation and phishing-simulation results
  16. 16Incident-response contacts, escalation procedures, and exercise support
  17. 17Available TPSP compliance-status and shared-responsibility information
  18. 18Service reviews, exceptions, remediation tracking, and operational performance records

Coverage key

What each label means.

Strong

Network Box can directly deliver and operate a substantial part of this technical outcome when the relevant services are in scope.

Partial

Network Box contributes meaningful controls, but the requirement also depends on the client's systems, configuration, people, or processes.

Supporting

Network Box provides useful security operations or evidence, but does not satisfy the requirement by itself.

Client responsibility

This area primarily remains with the MSP and client, their assessors, or other qualified parties.

Shared responsibility

Network Box helps operate the controls. The organization owns the compliance program.

The merchant or service provider owns PCI applicability, payment channels and account-data flows, annual scope confirmation, stored-data protection, enterprise identity and physical controls, secure development, remediation, required scanning and penetration testing, third-party governance, incident obligations, evidence completeness, and accurate SAQ, AOC, ROC, or other validation submissions.

PCI DSS v4.0.1 FAQ

Questions about scope, evidence, and responsibility.

What is PCI DSS v4.0.1?

Bring current PCI DSS requirements into continuous managed operation across a correctly scoped cardholder data environment.

How can Network Box USA support PCI DSS v4.0.1?

Network Box USA can operate managed technical safeguards, monitor the subscribed environment, investigate and escalate security activity, maintain managed configurations, and produce service evidence that may support applicable PCI DSS v4.0.1 requirements.

Does using Network Box USA make an organization PCI DSS v4.0.1 compliant?

No. A managed security service can contribute controls, operations, and evidence, but it cannot guarantee compliance or replace the organization's governance, complete scope, legal interpretation, assessment, or formal certification and attestation work.

How should the PCI DSS v4.0.1 control mapping be used?

Use the mapping as a scoping and evidence-planning aid. Each row explains the requirement, the potential Network Box contribution, available evidence, the coverage level, and the work that remains with the organization.

What evidence may be available for a PCI DSS v4.0.1 assessment?

Depending on the deployed services and agreed retention, evidence may include managed configurations, logs, alerts, incident records, vulnerability findings, change records, service reports, and recurring operational reviews. The assessor determines whether evidence is sufficient.

What remains the organization's responsibility under PCI DSS v4.0.1?

The merchant or service provider owns PCI applicability, payment channels and account-data flows, annual scope confirmation, stored-data protection, enterprise identity and physical controls, secure development, remediation, required scanning and penetration testing, third-party governance, incident obligations, evidence completeness, and accurate SAQ, AOC, ROC, or other validation submissions.

Explore another frameworkReturn to the Compliance Center →

Security stack review

Map the technical foundation before the assessment starts.

Request a Security Stack Review