PCI-DSS 4.0 Firewall Requirements: What Changes for German Payment Processors
PCI-DSS 4.0 firewall requirements underwent significant changes that took full effect on March 31, 2025. For German payment processors, merchants, and service providers, these changes demand stricter network segmentation, more frequent rule reviews, and comprehensive change documentation. Whether you process Girocard transactions, handle SCA flows for European payments, or maintain payment infrastructure for Sparkassen or Volksbanken, the updated requirements affect how you manage every firewall in your cardholder data environment.
What Changed in PCI-DSS 4.0
PCI-DSS 4.0 restructured and expanded the firewall-specific requirements under Requirement 1. The most impactful changes for German organizations are:
- Expanded Scope: The term “firewalls” has been replaced with “Network Security Controls” (NSCs), expanding scope to include cloud security groups, WAFs, and micro-segmentation solutions alongside traditional firewalls.
- Stricter Rule Documentation: Every NSC rule must now have a documented business justification. Previously a best practice, this is now an explicit requirement with audit implications. Rules without justification are findings.
- Semi-Annual Reviews: NSC configurations must be reviewed at least every six months (Requirement 1.2.7). The review must confirm that rules are still relevant and effective. This is new — the previous version required annual reviews.
Core PCI-DSS 4.0 Firewall Requirements
The firewall requirements in PCI-DSS 4.0 are organized under three key sub-requirements. Each has specific documentation and implementation demands:
Requirement 1.2 — NSC Configuration Standards
This is the core requirement governing how firewalls are configured and managed:
- 1.2.1: Configuration standards are defined and applied to all NSCs. Default vendor passwords changed, unnecessary services disabled.
- 1.2.2: All changes to NSCs are approved and managed per the defined change control process.
- 1.2.4: Accurate network diagrams showing all connections to and from the CDE, updated when changes occur.
- 1.2.5: All allowed services, protocols, and ports are documented with business need.
- 1.2.6: Security features documented for insecure services, with justification and approval.
- 1.2.7: NSC configurations reviewed at least every six months to confirm relevance and effectiveness.
- 1.2.8 (New): Configuration files for NSCs are secured from unauthorized access and kept consistent with active configurations.
Requirement 1.3 — Network Access Restrictions
Controls on traffic between the cardholder data environment and other networks:
- 1.3.1: Inbound traffic to the CDE restricted to only what is necessary.
- 1.3.2: Outbound traffic from the CDE restricted to only what is necessary.
- 1.3.3: NSCs installed between all wireless networks and the CDE, configured to deny or control traffic.
Requirement 1.4 — Trusted and Untrusted Network Boundaries
Controls at the boundaries between trusted and untrusted networks:
- 1.4.1: NSCs implemented between trusted and untrusted networks with explicit rules controlling traffic.
- 1.4.2: Inbound traffic from untrusted networks to trusted networks is restricted to only necessary communications.
- 1.4.3: Anti-spoofing measures implemented to detect and block forged source addresses.
- 1.4.4: Personal firewall software on portable computing devices that connect to both untrusted networks and the CDE.
Common Compliance Gaps in German Organizations
German payment processors and merchants face specific challenges when meeting PCI-DSS 4.0 firewall requirements. These are the most common gaps identified during assessments:
- Legacy Rules Without Justification: Rulebases that have grown over years contain hundreds of rules with no documented business justification. Under PCI-DSS 4.0, every rule needs one. Retrospectively documenting justifications for legacy rules is time-consuming but mandatory.
- Missing Change Documentation: Firewall changes are made through informal processes — a quick email, a verbal request, or direct CLI access. PCI-DSS 4.0 requires a formal, documented change management process with approval records for every change.
- Incomplete Segmentation: Network segmentation between the CDE and other environments is often incomplete or inconsistent. Rules that allow broad access between segments undermine the segmentation controls and result in audit findings.
- Stale Rules: Shadow rules, redundancies, and unused rules accumulate in rulebases over time. PCI-DSS 4.0’s semi-annual review requirement means organizations must actively identify and remove stale rules — not just review them on paper.
How FwChange Supports PCI-DSS Compliance
Achieving PCI-DSS 4.0 compliance for firewall management requires both process discipline and tooling. FwChange addresses the core requirements directly:
- Automated Rule Documentation: Every firewall rule is documented with business justification, owner, creation date, and review status. Meeting Requirement 1.2.5 becomes automated instead of manual.
- Semi-Annual Review Workflow: Built-in review scheduling ensures every rule is reviewed within the six-month window required by 1.2.7. Review evidence is automatically captured for auditors.
- AI-Powered Rule Analysis: Detect shadow rules, redundancies, and conflicts automatically across your entire firewall estate. Identify overly permissive rules that violate the least-privilege requirements of 1.3.1 and 1.3.2.
- Multi-Vendor Support: Manage Palo Alto, Fortinet, Check Point, and Cisco firewalls through a single unified platform with consistent change management and documentation, regardless of vendor.
The German Payment Landscape
The German payment ecosystem has unique characteristics that affect PCI-DSS compliance:
- Girocard Dominance: Germany’s electronic payment market is still heavily influenced by the Girocard system (formerly EC-Karte). Payment processors handling Girocard transactions must meet PCI-DSS requirements while also complying with the specific security standards of the German banking sector.
- Sparkassen and Volksbanken: The decentralized structure of German savings banks and cooperative banks means many smaller institutions process payments independently. Each institution handling cardholder data must maintain its own PCI-DSS compliance, including firewall management.
- Strong Customer Authentication (SCA): PSD2’s SCA requirements add another layer of complexity. The infrastructure supporting SCA — authentication servers, 3DS systems, and associated firewalls — falls within the PCI-DSS scope and must meet all NSC requirements.
- BaFin Oversight: In addition to PCI-DSS, German payment processors are supervised by BaFin, which has its own IT security requirements (BAIT/VAIT). Firewall documentation that satisfies PCI-DSS should be aligned with BaFin expectations to avoid maintaining separate documentation sets.
Frequently Asked Questions
What is the deadline for PCI-DSS 4.0 compliance?
PCI-DSS 4.0 became effective on March 31, 2024, with the future-dated requirements (including the semi-annual review requirement 1.2.7 and the new 1.2.8) becoming mandatory on March 31, 2025. Organizations that have not yet transitioned from PCI-DSS 3.2.1 are already non-compliant.
How does PCI-DSS 4.0 affect multi-vendor firewall environments?
PCI-DSS 4.0 applies equally to all network security controls regardless of vendor. If you run Palo Alto at the perimeter and Fortinet for internal segmentation, both must meet the same documentation, change management, and review requirements. A unified management platform ensures consistent compliance across all vendors.
Do cloud security groups count as NSCs under PCI-DSS 4.0?
Yes. PCI-DSS 4.0 explicitly includes cloud-based security controls — AWS Security Groups, Azure NSGs, and GCP firewall rules — under the NSC definition. If your cardholder data environment includes cloud components, the cloud security controls must meet the same documentation, review, and change management requirements as traditional firewalls.
What is the customized approach in PCI-DSS 4.0?
PCI-DSS 4.0 introduces a “customized approach” that allows organizations to meet the security objective of a requirement through alternative controls. For firewall requirements, this means you could implement controls differently from the defined approach — but you must document the alternative controls, demonstrate they meet the security objective, and have them validated by your QSA. In practice, most German organizations use the defined approach for firewall requirements because the PCI SSC requirements are straightforward to implement with proper tooling.
How often must firewall rules be reviewed under PCI-DSS 4.0?
Requirement 1.2.7 mandates review at least every six months. This is a minimum — organizations handling high transaction volumes or operating in complex environments should consider more frequent reviews. The review must confirm that each rule is still needed, appropriately scoped, and correctly documented. Evidence of the review (date, reviewer, outcome for each rule) must be retained for audit.
If you are preparing for a PCI-DSS 4.0 assessment and want to identify compliance gaps in your firewall configuration, the free rulebase scanner provides an instant analysis of your current rule health, including documentation gaps, shadow rules, and optimization opportunities.
See How Your Firewall Rules Score
Upload your config and get a free compliance report with shadow rule detection, conflict analysis, and optimization recommendations.
Stay Updated
Get firewall management tips, compliance guides, and product updates.
No spam. Unsubscribe anytime.