Infrastructure architects at Saudi payment processors, banks and fintechs know that SAMA CSF Domain 5 DMZ architecture documentation is not optional. The Saudi Central Bank (SAMA) Cyber Security Framework Domain 5 addresses Cybersecurity Defense, and Control 5.2.3 specifically requires documented network segmentation for external-facing services. Yet most architecture submissions fail during regulatory review because they show topology without demonstrating traffic control.
The gap is not in the firewall rules themselves. It is in the documentation of how inbound traffic moves through the demilitarized zone, what inspection occurs at each boundary, and how the return path is logged. SAMA examiners and Qualified Security Assessors conducting PCI DSS assessments ask the same question: show us how a transaction request from the public internet reaches your cardholder-data environment, and prove that each hop enforces the principle of least privilege.
This article maps the three mandatory traffic patterns that must appear in every payment-gateway DMZ design submitted for SAMA CSF Domain 5 compliance and PCI DSS Requirement 1 validation. It explains what each pattern demonstrates, the documentation artifacts examiners expect, and the common omissions that trigger remediation findings.
Why Control 5.2.3 Focuses on External-Facing Services
SAMA CSF Domain 5 Control 5.2.3 requires organizations to implement network segmentation that isolates external-facing services from internal systems. The control exists because payment gateways, API endpoints and web-facing applications are the primary attack surface for credential theft, injection attacks and lateral movement into cardholder-data environments.
The control does not prescribe specific technologies. It requires documented evidence that external traffic cannot reach sensitive data without passing through multiple layers of inspection and access control. This means the architecture must show not only that a DMZ exists, but how traffic is constrained at every boundary.
For organizations subject to both SAMA CSF and PCI DSS, the overlap is deliberate. PCI DSS Requirement 1 mandates network segmentation and firewall configurations that restrict connections between untrusted networks and system components that store, process or transmit cardholder data. SAMA examiners expect the same rigor, and they verify it by tracing traffic flows through the documented architecture.
The Three Inbound-Traffic Patterns Examiners Verify
Every payment-gateway DMZ architecture must document three distinct traffic patterns. Each pattern demonstrates a different aspect of segmentation and control. Omitting any one of them creates a documentation gap that examiners will flag.
Pattern One: Public-to-DMZ Ingress and Filtering
The first pattern shows how traffic from the public internet enters the DMZ and what filtering occurs before it reaches any application server. This pattern must document:
Entry point and protocol filtering. The architecture must identify the external firewall or edge device, the permitted protocols (typically HTTPS on port 443 for payment APIs), and the explicit deny-all rule that blocks everything else. Examiners look for evidence that only necessary ports are open and that the default posture is deny.
Source validation and rate limiting. The design should show how the edge layer validates source IP addresses, applies geographic restrictions if relevant, and enforces rate limits to prevent volumetric attacks. This is often handled by a web application firewall or API gateway, and the architecture must name the component and describe its function.
Initial inspection and threat detection. Before traffic reaches the DMZ application tier, it should pass through an inspection layer that detects common attack patterns—SQL injection, cross-site scripting, malformed requests. The architecture must show where this inspection occurs, what technology performs it, and how alerts are routed to the security operations team.
Routing to the DMZ application tier. The pattern must show how legitimate traffic is forwarded to the application servers in the DMZ, and it must demonstrate that these servers cannot initiate outbound connections to the internet. This unidirectional flow is a key segmentation principle.
Common omissions in this pattern include failing to document the inspection technology, omitting rate-limiting controls, and not showing the deny-all default rule. Examiners will ask for firewall rule tables, but the architecture diagram itself must make the filtering logic clear.
Pattern Two: DMZ-to-Internal Access Control and Data-Flow Boundaries
The second pattern demonstrates how traffic moves from the DMZ application tier to internal systems that store or process cardholder data. This is the most scrutinized pattern because it represents the boundary between the exposed layer and the protected environment.
Internal firewall and access-control lists. The architecture must show a second firewall—logically or physically separate from the edge firewall—that sits between the DMZ and the internal network. This firewall must enforce strict access-control lists that permit only specific DMZ servers to reach specific internal services on specific ports. The documentation must list these allowed flows explicitly.
Service-specific segmentation. If the internal environment contains multiple systems—a payment switch, a card vault, a transaction database—the architecture must show that each is isolated in its own network segment and that the DMZ can reach only the services it needs. A DMZ web server that processes transactions should not have network access to the card vault if it does not need to retrieve full card numbers.
Authentication and encryption in transit. The pattern must document how the DMZ authenticates to internal services (mutual TLS, API keys, service accounts) and how data is encrypted in transit. Examiners expect to see that credentials are not embedded in application code and that encryption is enforced at the network or application layer.
Return-path restrictions. The architecture must show that internal systems cannot initiate connections back to the DMZ except in response to a legitimate request. This prevents compromised internal systems from being used as pivot points to attack the DMZ or exfiltrate data.
The most common gap in this pattern is failing to document the specific allowed flows. Many architectures show a firewall icon between the DMZ and internal network but do not list which servers can talk to which services. Examiners will request the firewall rule set, and if the architecture does not summarize it, the documentation is incomplete.
Pattern Three: Return-Path Logging and Session Tracking
The third pattern addresses how response traffic flows back from internal systems to the DMZ and out to the client, and how the organization logs and monitors these flows. This pattern is often overlooked because architects focus on inbound security, but SAMA examiners verify that return paths are controlled and observable.
Session state and response routing. The architecture must show how the system tracks sessions so that responses are routed only to the originating client. This typically involves session tokens, stateful firewall inspection or application-layer session management. The documentation should explain which component maintains session state and how it prevents response hijacking.
Logging at each boundary. The pattern must document logging at the edge firewall, the DMZ-to-internal firewall, and ideally at the application layer. Logs should capture source and destination addresses, ports, protocols, timestamps, and success or failure of each connection attempt. The architecture should show where logs are sent—typically to a centralized SIEM or log-management platform—and how long they are retained.
Anomaly detection and alerting. The design should demonstrate that the organization monitors return-path traffic for anomalies: unexpected destination addresses, unusual data volumes, or connections outside normal business hours. This is where the architecture intersects with security operations, and examiners expect to see integration between network logging and the SOC.
Egress filtering. The architecture must show that outbound traffic from the DMZ to the internet is also filtered. If the DMZ does not need to initiate outbound connections, the firewall should block them. If outbound access is required (for example, to call third-party APIs), the architecture must list the permitted destinations and protocols.
Gaps in this pattern typically involve missing log-flow diagrams and unclear session-management descriptions. Examiners want to see that the organization can reconstruct a transaction from end to end using logs, and that it can detect when a return path is abused.
Documenting the Patterns: Artifacts Examiners Expect
SAMA examiners and QSAs do not accept a single network diagram as sufficient documentation. They expect a set of artifacts that together demonstrate how the three traffic patterns are implemented and controlled.
Logical network diagram with trust boundaries. The primary artifact is a logical diagram that shows the edge firewall, the DMZ zone, the internal firewall, and the cardholder-data environment. The diagram must label trust boundaries—typically with dashed lines or color coding—and indicate the direction of permitted traffic flows with arrows. Each arrow should be annotated with the protocol and port.
Data-flow diagram for key transaction types. A separate diagram should trace a representative transaction (for example, a card authorization request) from the external client through each layer to the internal payment switch and back. This diagram should number each hop and include a table that describes what happens at each step: filtering, inspection, authentication, encryption, logging.
Firewall rule summary tables. While the full firewall configuration is typically provided as an appendix, the architecture documentation should include summary tables that list the most critical rules: what traffic is allowed from the internet to the DMZ, what traffic is allowed from the DMZ to internal systems, and what outbound traffic is permitted. Each rule should reference the business justification.
Log-flow and retention diagram. A diagram showing where logs are generated, how they are collected, where they are stored, and how long they are retained. This diagram should also show integration with the SIEM or SOC platform and indicate which log sources feed which detection use cases.
Integration with threat detection. The documentation should explain how the architecture integrates with intrusion detection systems, web application firewalls, and security operations. This is often a narrative section rather than a diagram, but it must be specific: which tools inspect which traffic, and how alerts are escalated.
Organizations that provide this full set of artifacts rarely face extended remediation cycles. Those that submit only a high-level topology diagram should expect detailed follow-up questions and requests for additional documentation.
Common Gaps and How to Avoid Them
Three gaps appear repeatedly in DMZ architecture submissions for SAMA CSF Domain 5 and PCI DSS assessments.
Gap one: Diagrams show components but not traffic control. Many architectures label firewalls, load balancers and application servers but do not show what filtering or inspection occurs at each boundary. The solution is to annotate every boundary with the control it enforces: protocol filtering, IP whitelisting, WAF inspection, mutual TLS authentication. If a boundary does not enforce a control, the architecture should explain why it is not needed.
Gap two: Missing documentation of return-path and logging. Architects focus on inbound security and omit the return path and log flows. The solution is to treat logging as a first-class architectural concern and include a dedicated diagram that shows log sources, collection points, storage and retention.
Gap three: Generic descriptions instead of specific flows. Phrases like "traffic is inspected by the firewall" or "logs are sent to the SIEM" are too vague. Examiners want specifics: which firewall, what inspection rules, which log sources, what retention period. The solution is to name every component and describe its function in concrete terms.
Addressing these gaps during the design phase is faster and cheaper than responding to examiner findings after the architecture is deployed.
How We Help: Security Architecture Review
Organizations that need to document DMZ architectures for SAMA CSF Domain 5 compliance or PCI DSS validation often engage us for a Security Architecture Review. We review the security of new and existing systems and network designs—segmentation, identity, data flows, integration and resilience—and recommend practical improvements.
The review follows a structured process. We collect diagrams, data flows and design documents. We model threats against key components and flows. We assess controls against secure design principles. We advise on options, trade-offs and agreed actions.
Deliverables include an architecture review report, a threat model for key flows, prioritized design recommendations, and reference security patterns. The review covers network segmentation and zoning, identity and trust boundaries, data-flow and encryption review, third-party and API integration, and resilience and recovery design.
The review is aligned to SAMA CSF and NCA ECC frameworks, and it typically takes two to four weeks per system.
The output is documentation that satisfies both regulatory examiners and internal stakeholders, and a design that reduces attack surface before the first transaction is processed.
