SAMA Network Segmentation Requirements for Secure Architecture

A financial institution can have strong perimeter firewalls, hardened endpoints, and mature identity controls and still face a fundamental architecture problem: once a user, server, or third-party connection is inside the network, how far can it reach?

If a compromised employee workstation can communicate directly with sensitive databases, backup infrastructure, or administrative systems, the perimeter has done little to contain the incident. The same concern applies when a vendor connection has broader access than necessary or when a publicly accessible application can reach systems it does not genuinely depend on.

This is the problem network segmentation is designed to solve.

For organizations supervised by the Saudi Central Bank (SAMA) and subject to its Cyber Security Framework, segmentation is also an explicit infrastructure security consideration. The SAMA Cyber Security Framework requires infrastructure security standards to include the segmentation of networks.

But satisfying that requirement is not simply a matter of creating more VLANs.

Effective SAMA network segmentation requires an architecture in which security zones reflect trust, business function, and risk, with traffic between those zones deliberately controlled and monitored. For Saudi financial institutions, that means turning a short regulatory requirement into an operational design that can restrict lateral movement while remaining manageable in production. This article forms part of our complete guide to ISO 27001 and compliance services for GCC SMBs.

SAMA's Cyber Security Framework establishes infrastructure security requirements under section 3.3.8 Infrastructure Security. More precisely, network segmentation appears under control consideration 3.3.8(6)(e) in the published framework.

The requirement itself is concise: the organization's infrastructure security standard should include "segmentation of networks."

That short statement sits within a much broader set of requirements.

Under SAMA 3.3.8 Infrastructure Security, member organizations should define, approve, and implement infrastructure security standards. Compliance with those standards should be monitored, while the effectiveness of infrastructure cybersecurity controls should be measured and periodically evaluated.

SAMA also says these standards should cover infrastructure in the organization's main data centers, disaster recovery data sites, and office spaces. The framework identifies infrastructure including operating systems, servers, virtual machines, firewalls, network devices, IDS/IPS systems, wireless networks, gateway servers, proxy servers, email gateways, external connections, databases, file shares, workstations, laptops, and other components.

That context matters. Segmentation should not exist as an isolated network diagram created for an assessment. It needs to form part of an approved infrastructure standard that is implemented, monitored, and periodically evaluated.

Consider a phishing attack that compromises an ordinary employee endpoint.

In a largely flat network, that workstation may provide an attacker with paths toward application servers, administrative interfaces, file shares, or other systems. Credentials captured during the compromise may open further paths.

Segmentation changes the problem. The employee endpoint may still be compromised, but communication from the user zone to a database or management zone can be denied unless a legitimate, explicitly authorized path exists. Security teams also gain control points where attempts to cross security boundaries can be logged, inspected, and investigated.

This concept is often described as restricting east-west traffic. North-south traffic generally refers to traffic entering or leaving an environment, while east-west traffic moves between internal systems and network segments.

A strong perimeter therefore does not remove the need for internal controls.

Segmentation can support several business objectives at once: containment of security incidents, protection of sensitive information, clearer monitoring boundaries, and more defensible control over third-party access. It can also make security architecture easier to explain during assessments because trust relationships become explicit rather than implicit.

SAMA 3.3.8 does not prescribe a mandatory list of nine zones. The following model is therefore an architectural approach, not a claim that SAMA specifically requires each named zone.

For many financial environments, a practical design can separate infrastructure into:

• User zone: Employee endpoints and normal corporate user devices.
• Server zone: Internal application and infrastructure servers that should not reside directly with user endpoints.
• Management zone: Privileged administration systems, jump hosts, and management interfaces.
• Database zone: Databases containing business, customer, or operational information, separated according to sensitivity and application requirements.
• DMZ: Internet-facing or externally accessible services isolated from trusted internal networks.
• Security zone: Appropriate security management and monitoring systems, such as SIEM collectors or security-management infrastructure.
• Backup zone: Backup systems and repositories separated from normal production access paths.
• Third-party zone: Controlled termination and access paths for vendors, partners, and other approved external parties.
• Disaster recovery (DR) zone: DR infrastructure designed with appropriate security controls and controlled connectivity to production environments.

The important principle is not the zone names. It is whether systems with materially different functions and trust levels can communicate only through approved pathways.

A common design objective is to prevent ordinary employee networks from directly reaching sensitive infrastructure simply because the systems share corporate connectivity.

Where a user's application needs information from a database, for example, the preferred communication flow may be `User -> Application -> Database` rather than `User -> Database`.

That architecture allows controls to be applied at each boundary. The workstation communicates with the business application, while only authorized application components can initiate the necessary database connections.

This reduces unnecessary reachability and makes the intended application flow easier to understand and monitor.

Administrative access is particularly sensitive because management interfaces can provide significant control over servers, firewalls, hypervisors, and other infrastructure.

A dedicated management zone can separate privileged activity from ordinary user traffic. Depending on the architecture and risk assessment, organizations can add controls such as hardened administrative workstations, privileged access systems, jump hosts, multi-factor authentication, and restricted management protocols.

This also reinforces a broader SAMA principle. Under SAMA 3.3.5 Identity and Access Management, access to information assets should be restricted according to business requirements and need-to-have or need-to-know principles.

Network access and identity access should therefore complement each other rather than operate independently.

Creating virtual local area networks (VLANs) is useful for separating broadcast domains and organizing a network. But a VLAN is not automatically an effective security boundary.

Suppose the organization builds separate user, server, and database VLANs but allows broad routing between all three. The network looks segmented on a diagram, but very little prevents an attacker from moving between those environments.

Security segmentation requires enforcement. A stronger architecture places appropriate security controls between trust zones and establishes rules for what traffic is permitted to cross those boundaries.

SAMA's broader network architecture requirements reinforce this approach. Its Information Technology Governance Framework section on Network Architecture and Monitoring requires segmentation into separate network domains based on required trust levels and says each domain perimeter should be protected by a security gateway, such as a firewall or filtering router. It also requires separate service-access rules for each security gateway so that only authorized traffic is allowed through.

For organizations to which those requirements apply, the distinction is important: network zoning creates boundaries, and security-gateway policy makes those boundaries meaningful.

Firewall rules should reflect business and technical dependencies rather than simply allowing one entire zone to communicate with another.

Instead of `User Zone -> Server Zone: Allow Any`, the design should identify the actual dependency: `Approved User Subnet -> Application Service: Required Protocol/Port`.

The same principle applies between application and database tiers, management systems and infrastructure, third-party connections and internal resources, and production and DR systems.

This approach supports least privilege at the network layer. It also creates a practical question for every proposed rule: Why does this source need to communicate with this destination using this service? If the architecture team cannot answer that question, the rule deserves further investigation.

Firewall governance should therefore capture enough information to understand the business or technical purpose of important access rules, with ownership and change control aligned to the organization's approved processes. Over time, obsolete systems and temporary exceptions can otherwise leave pathways that no longer have a valid operational purpose.

Traditional security architectures frequently concentrate inspection at the internet boundary. Effective network segmentation requires organizations to think about internal paths as well.

A database does not necessarily need to accept connections from every server. A backup platform does not necessarily need unrestricted connectivity from every production endpoint. A third-party support engineer does not necessarily need general access to an entire server network.

Firewalls or other appropriate security-gateway controls between internal zones provide one layer of control over these paths.

For environments that need more granular separation, microsegmentation can take the concept further. Rather than relying primarily on broad network zones, microsegmentation can apply controls to individual workloads or smaller groups of workloads.

Microsegmentation is not explicitly mandated by SAMA 3.3.8(6)(e). It is an architectural option that may be useful where application sensitivity, virtualization, cloud architecture, or lateral-movement risk justifies finer controls.

This is also where Zero Trust principles can complement network zoning. NIST describes Zero Trust as an approach in which implicit trust is not granted simply because an asset or user is located on a particular network. Segmentation provides boundaries, while identity, device posture, authorization, and application-level controls can provide additional context for access decisions. Our post on how Zero Trust access works for GCC businesses covers that model in more detail.

Internet-facing services require particularly careful placement.

A demilitarized zone, or DMZ, creates a controlled network segment for externally accessible services, separating them from more trusted internal environments. Public-facing web infrastructure, gateways, and similar services may be positioned here according to architectural requirements.

The critical design question is what the DMZ can reach internally. A compromised internet-facing server should not become a bridge into unrestricted internal networks. Connections from the DMZ toward internal application or data tiers should be limited to the communications actually required by the service architecture.

SAMA's IT Governance network controls also require a web application firewall (WAF) for customer-facing applications and specify additional protections for network domains, security gateways, and traffic passing to DMZ or internal servers.

For network architects, the practical lesson is that public exposure should not automatically imply broad internal access.

Financial organizations depend on technology vendors, service providers, partners, and other outside organizations. Their connectivity can create operational value while also extending the network's trust relationships.

A dedicated third-party access zone provides a place to terminate and control those connections before access reaches internal resources.

SAMA devotes a separate section of its Cyber Security Framework to Third Party Cyber Security, addressing how cybersecurity requirements between member organizations and third parties should be organized, implemented, and monitored.

Network segmentation can help translate that principle into architecture. Vendor access can be restricted to approved destinations instead of entire internal subnets. Administrative access can also be separated from normal user connectivity and controlled according to business need.

The goal is straightforward: a supplier's legitimate requirement to maintain one service should not automatically create reachability to unrelated environments.

Segmentation projects frequently concentrate on production applications while overlooking the systems that become most important during recovery.

Backup infrastructure deserves special attention because it supports restoration after an outage or security incident. Separating backup management and repositories from normal user and server networks can reduce unnecessary access paths and make the recovery architecture more deliberate.

Disaster recovery requires the same thinking. SAMA 3.3.8 states that infrastructure standards should cover the main data centers, disaster recovery data sites, and office spaces. SAMA's IT Disaster Recovery Plan requirements additionally state that member organizations should implement the same logical, physical, environmental, and cybersecurity controls for the alternative data center as for the primary data center.

A production network that is carefully segmented while the alternative data center remains broadly connected therefore creates an architectural inconsistency as well as unnecessary risk. Security architecture should follow the workload when it fails over.

Blocking unauthorized traffic is only part of the value of a segmented network. Attempts to cross a boundary can also tell defenders something important.

A workstation repeatedly trying to reach database servers may indicate misconfiguration, unauthorized software, or suspicious activity. A server initiating unexpected management connections may deserve investigation. Third-party access outside the normal service pattern can provide another useful signal.

Relevant firewall and security-gateway telemetry can therefore feed the organization's monitoring architecture and Security Operations Center (SOC), where appropriate.

This connects network design with incident detection. Instead of regarding the firewall only as a gate, the organization can also use it as a source of evidence about how systems are actually communicating.

For organizations using security information and event management (SIEM) or extended detection and response (XDR) platforms, segmentation can provide clearer context for detection rules. An allowed application-to-database connection may be ordinary, while user-to-database traffic may be considerably more unusual.

A mature implementation should be explainable without relying on a single engineer's memory.

Start with an accurate network diagram showing major trust zones, security gateways, external connections, important application flows, data-center relationships, and DR architecture. That documentation should correspond with the environment that actually exists.

Then connect the architecture to the approved infrastructure security standard. For each important security boundary, teams should be able to establish why the boundary exists, what communication is allowed across it, and how those rules are controlled and monitored.

This is especially important because SAMA 3.3.8 goes beyond implementation. The framework calls for compliance with infrastructure security standards to be monitored and for the effectiveness of infrastructure cybersecurity controls to be measured and periodically evaluated.

SAMA's Cyber Security Review requirements further require periodic reviews of critical information assets, with details of reviews, results, identified issues, and recommended actions recorded.

The question is therefore not only, "Do we have segmentation?" A stronger compliance position can demonstrate: "This is our segmentation standard, this is the implemented architecture, these are the enforcement points, these are the authorized flows, and this is how we verify that the controls continue to operate effectively."

For a large Saudi financial environment, attempting to redesign the entire network simultaneously can introduce unnecessary operational risk. A staged approach is often more manageable.

1. Discover and map the current environment. Identify networks, routing relationships, applications, databases, management systems, external connections, backup services, and DR dependencies. Application owners are essential here because a technically undocumented connection may still support an important business process.
2. Classify systems and define target zones. Group systems by function, sensitivity, and trust requirements, then identify the communication that should legitimately cross each boundary.
3. Observe existing traffic. Before aggressively restricting connectivity, use logs, flow data, and other network telemetry to uncover dependencies that documentation may have missed.
4. Implement and test enforcement. Develop firewall rules around approved flows, test them, and introduce them through formal change management. Management systems, sensitive databases, public-facing services, third-party connections, and backup infrastructure often warrant particular scrutiny.
5. Operate segmentation as an ongoing control. New applications, cloud workloads, acquisitions, temporary vendor connections, and infrastructure changes will alter network relationships. Architecture, firewall policy, and documentation must evolve with them.

Cyberactics can support this type of review by helping organizations examine network zones, firewall policies, and traffic relationships as part of a broader network security and compliance architecture assessment.

SAMA 3.3.8 is specifically relevant to organizations within the Cyber Security Framework's applicability. The SAMA Cyber Security Framework applies to member organizations regulated by SAMA, subject to the applicability provisions and exceptions set out in the Framework.

The underlying architectural challenge extends beyond Saudi Arabia, however.

Financial institutions and other organizations across the GCC, including the UAE and Oman, may operate hybrid environments spanning offices, data centers, cloud platforms, external service providers, and disaster recovery infrastructure. Network boundaries that were straightforward when applications lived inside a single data center can become considerably harder to define in these environments.

Organizations should apply the requirements of their own regulator and jurisdiction rather than treating SAMA as a GCC-wide standard. Nevertheless, the engineering principles behind controlled network zoning remain broadly useful: separate systems according to trust and function, restrict unnecessary paths, monitor boundary traffic, and ensure the architecture remains effective as infrastructure changes.

For regional organizations operating across Saudi Arabia, the UAE, Oman, and wider MENA markets, a coherent security architecture can also support mapping individual controls to the specific regulatory frameworks that apply in each jurisdiction.

The biggest mistake with SAMA 3.3.8(6)(e) is to reduce network segmentation to a compliance diagram. A defensible implementation has to work when something goes wrong.

If a workstation is compromised, where can it communicate? If a public-facing server is breached, which internal systems become reachable? If vendor credentials are stolen, what does that account and connection expose? If production fails over to DR, are the required security boundaries still present? If suspicious east-west traffic appears, can the SOC see it?

Those questions reveal whether segmentation exists as an operational security control or merely as network documentation.

For Saudi financial organizations subject to the Framework, the objective should be an approved architecture in which environments are separated according to genuine risk, business requirements, and required trust levels. Firewalls and other appropriate security gateways then enforce authorized communications across those boundaries, while monitoring provides evidence that the architecture remains effective.

SAMA 3.3.8(6)(e) may be expressed in only a few words, but implementing it well has a much larger outcome: turning the internal network from an assumed area of trust into a set of controlled, observable security boundaries.

Cyberactics works with organizations across the GCC and MENA on network security, firewall management, Zero Trust, managed cybersecurity, and compliance-related security architecture. For organizations reviewing their SAMA network segmentation requirements, Cyberactics can help assess existing network zones, security gateways, and traffic relationships and translate identified gaps into a practical architecture that supports both security operations and compliance. Get in touch to discuss your environment.