Build a SAMA Authorization Matrix for Segregation of Duties

A firewall change needs to reach production before the end of the day. The network administrator raises the request, approves it, implements the rule, and later confirms that the change was successful.

Operationally, that may look efficient. From a control perspective, however, one person has controlled the transaction from beginning to end. There is no independent decision point between requesting privileged activity and executing it, and little protection against an error, inappropriate change, or misuse of administrative access.

For financial institutions and other Member Organizations within the applicability of the Saudi Central Bank (SAMA) Cyber Security Framework, this is the kind of infrastructure governance issue addressed by the Framework.

Under SAMA Cyber Security Framework control 3.3.8.6.b, the infrastructure security standard should include segregation of duties within the infrastructure component, supported by a documented authorization matrix. The broader Infrastructure Security requirements also call for standards to be defined, approved and implemented, monitored for compliance, and periodically evaluated for effectiveness. The scope extends across infrastructure including servers, virtual machines, firewalls, network devices, databases, workstations and other components. See SAMA's Cyber Security Framework in the SAMA Rulebook.

The practical challenge is turning that requirement into an operating control.

A useful SAMA authorization matrix cannot simply list who has administrator access. It needs to document rights and permissions by role in a way that supports segregation of conflicting duties within infrastructure components and can be reconciled with the access that actually exists. This article forms part of our complete guide to ISO 27001 and compliance services for GCC SMBs.

Section 3.3.8 of the SAMA Cyber Security Framework covers Infrastructure Security. Its objective is to support formal documentation of infrastructure cybersecurity controls while monitoring compliance and periodically evaluating their effectiveness.

Within the infrastructure security standard, control 3.3.8.6.b specifically addresses segregation of duties within the infrastructure component, supported with a documented authorization matrix.

SAMA also defines an authorization matrix as a matrix defining the rights and permissions a specific role needs for information. The matrix lists each user, the business-process tasks the user performs and the affected systems.

That distinction matters. Segregation of duties, often abbreviated as SoD, is the control principle. The authorization matrix is part of the documented mechanism for defining and demonstrating it.

This is consistent with established access-control practice. NIST SP 800-53 AC-5 calls for organizations to identify and document duties requiring separation and define system access authorizations that support that separation. NIST explains that the principle addresses potential abuse of authorized privileges and helps reduce the risk of malicious activity without collusion.

For a SAMA-regulated organization, a useful practical question is: Can one person exercise incompatible authority over a sensitive infrastructure action in a way that defeats the intended segregation?

If the answer is yes, the authorization model deserves closer examination.

Imagine that an auditor asks for the authorization matrix covering production firewalls. The infrastructure team produces a spreadsheet listing a network administrator with administrator access, a senior network engineer with administrator access, and a security engineer with read-only access.

That tells the auditor something about access, but very little about segregation of duties.

Who can request a firewall rule? Who assesses its security implications? Who authorizes the change? Who is allowed to implement it? Who verifies the resulting configuration? Who reviews the logs?

More importantly, can the same administrator approve the ticket and deploy the change? Can that administrator alter the logging configuration that records what happened?

A stronger SAMA access control matrix connects privileges to activities and decision points rather than simply recording account names.

SAMA 3.3.8.6.b does not prescribe a four-person request, approve, administer and review workflow for every infrastructure action. The appropriate separation should be designed according to the organization's requirements, risks, architecture and operating model.

A useful design model, however, can separate four functions.

The requester establishes that an action is needed.

For example, an application owner might request a firewall rule so a new service can communicate with a database. A systems engineer might request a privileged configuration change. A service owner might request restoration of a backup.

The requester supplies the business or technical justification. That does not automatically mean the requester should authorize the action.

The approver determines whether the requested activity is authorized.

Approval may depend on factors such as the system involved, business impact, information classification, security risk and change category.

For changes falling within SAMA's change-management requirements, the Framework requires approval by the business owner, approval from the cybersecurity function before submission to the Change Advisory Board (CAB), and CAB approval. It also requires post-implementation review of the related cybersecurity controls and segregation of development, testing and implementation for both the technical environment and the individuals involved.

The administrator performs the approved action.

This could mean changing a firewall policy, modifying an operating-system configuration, creating a database account, assigning a cloud role or restoring backup data.

The important control point is that possession of technical capability should not automatically confer authority to decide that the action should occur.

An independent reviewer can verify what actually happened where such review forms part of the organization's control design or applicable change-management process.

Depending on the activity, this might include reviewing the resulting configuration, privileged-access records, change evidence, security logs or exceptions.

This provides an additional safeguard. Even after an approved administrator performs an action, independent review can help detect a mistake or deviation from the authorized request.

The matrix can begin with sensitive activities and then map those activities to users or roles and affected systems, consistent with SAMA's definition of an authorization matrix.

A practical structure records, for each infrastructure area and activity, who requests, approves, implements and reviews it:

• Firewall, production rule change: service owner requests, authorized approver approves, network admin implements, security or change reviewer reviews.
• Server, privileged configuration change: system owner or admin requests, authorized approver approves, server admin implements, independent reviewer reviews.
• Database, create privileged account: system or data owner requests, authorized approver approves, DBA implements, security or IAM reviewer reviews.
• Cloud, assign privileged role: service owner requests, authorized approver approves, cloud or IAM admin implements, security reviewer reviews.
• IAM, create administrative entitlement: manager or system owner requests, authorized approver approves, IAM admin implements, access reviewer reviews.
• Backup, restore production data: system owner requests, authorized approver approves, backup admin implements, independent reviewer reviews.
• Security tooling, modify detection configuration: security operations requests, authorized security owner approves, security admin implements, independent security reviewer reviews.

This is an illustrative design, not a set of prescribed SAMA role names or workflows. Each institution needs to establish the roles, approval thresholds and conflicting permissions appropriate to its organization and infrastructure while satisfying applicable Framework requirements.

The resulting matrix should then be mapped to the actual permissions implemented in systems. That step is critical.

A spreadsheet can document segregation while the underlying technology still grants privileges inconsistent with the approved model. Documented segregation and technical access should be aligned.

SAMA's Infrastructure Security control is broad. The Framework states that infrastructure standards should cover all instances of infrastructure available in main data centers, disaster recovery data sites and office spaces, and gives examples ranging from operating systems and servers to firewalls, databases, network devices and endpoints.

Infrastructure segregation of duties should therefore not become a firewall-only exercise.

Network administrators often possess permissions capable of changing routing, firewall policy, VPN configuration and other security-sensitive settings.

The authorization model should distinguish conflicting responsibilities where appropriate, including the ability to propose a network change and the authority required to approve it.

Organizations should also consider who reviews configurations and activity records. Giving the same role unrestricted control over both security enforcement and the evidence used to review its actions can undermine the intended separation. Our post on SAMA network segmentation requirements covers the related architecture controls.

Server administrators may have extensive privileges across production systems.

The organization should identify which activities require independent authorization, particularly privileged-account creation, critical configuration changes, security-control modifications and other high-impact actions.

Routine administration can still remain efficient. Segregation should be applied based on identified conflicts, applicable requirements and risk.

Database administrators (DBAs) can hold powerful privileges over both platform configuration and information.

An effective matrix can distinguish between database ownership, administration, privileged-access approval and access review.

For highly sensitive environments, the institution should examine whether a single DBA can request elevated access, grant that access, use it against production information and alter or remove relevant audit evidence.

Cloud infrastructure creates an additional challenge because administrative roles can span identity, infrastructure, networking and security.

Instead of assuming that "cloud administrator" is one indivisible function, identify the sensitive actions available inside the platform. These could include assigning privileged roles, changing network security controls, creating credentials, modifying logging, provisioning production resources or altering security policies.

The authorization matrix should describe who is authorized to perform relevant activities, while the cloud platform's identity and access management controls should enforce the approved design wherever technically possible.

Identity and Access Management (IAM) is particularly important because administrators controlling IAM may be able to grant privileges elsewhere.

Avoid situations in which one identity administrator can request elevated access for themselves, approve it and grant the entitlement without appropriate independent authorization or oversight.

Role-based access control, privileged access management and time-limited elevation can help translate the matrix into technical controls. Cyberactics' Identity and Access Management services include MFA and privileged-access control that can support organizations implementing stronger identity controls. Our post on just-in-time admin access explains how time-limited elevation works in practice.

Backups are sometimes omitted from SoD exercises because teams focus primarily on production access. That can create a control gap.

Backup administrators may be able to access protected copies of sensitive information, alter retention settings, delete recovery points or initiate restores, depending on the technology and assigned privileges.

Map these activities explicitly. In particular, distinguish the ability to administer backup infrastructure from authorization for sensitive restoration or destructive operations where the platform and operating model allow it.

SOC, SIEM, XDR and other security technologies also require consideration when defining segregation. Security Operations Center (SOC), Security Information and Event Management (SIEM), and Extended Detection and Response (XDR) platforms can each include powerful administrative capabilities.

A privileged security administrator might be able to change detection policies, suppress alerts, modify retention settings or administer log sources, depending on the platform and permissions. The institution should identify which of these activities could affect independent monitoring and design its roles accordingly.

NIST specifically uses separating access-control administration from audit administration as an example of separation of duties. NIST's AC-5 guidance also notes that SoD issues can cross systems and application domains, which is why an organization-wide view matters.

Suppose the authorization matrix says: Network Engineer: Implement approved firewall changes only.

But the engineer's firewall account has unrestricted super-administrator privileges. The engineer can create rules, alter administrative accounts and modify logging without another person's involvement.

The documented process and technical reality are now different.

The organization should therefore validate the matrix against its actual access architecture, including:

• Privileged groups and administrative roles
• Local and shared administrator accounts
• Cloud IAM roles
• Database privileges
• Firewall and network-device roles
• Backup administrative permissions
• Security platform permissions
• Service and automation accounts
• Emergency or "break-glass" access
• Privileged access management configurations

This exercise can expose privileges accumulated through role changes, temporary projects, migrations or historical administrative practices.

The authorization matrix becomes more useful when it acts as the approved baseline against which actual access can be assessed.

Individual accountability becomes difficult when several people routinely administer infrastructure using the same shared credentials.

Where supported by the platform, privileged activity should be attributable to individual identities. Administrative privileges can then be granted through controlled roles or privileged-access mechanisms.

Legacy technologies sometimes make this difficult. Where unique administrator identities cannot be implemented, the organization should document the limitation, assess the associated risk and establish appropriate controls for credential access and activity monitoring.

An authorization matrix should describe the intended control model without pretending a technical limitation does not exist.

Segregation of duties can be particularly challenging for organizations with small infrastructure teams.

If only two engineers understand a specialist platform, creating four entirely separate technical departments is neither realistic nor explicitly required by SAMA 3.3.8.6.b. The goal is meaningful separation of conflicting duties rather than a prescribed number of organizational units.

A smaller team might separate the workflow across a system owner, technical administrator and cybersecurity or management reviewer. Sensitive privileged activities can require secondary approval, while monitoring provides additional oversight.

NIST describes separation of duties as something that can be implemented statically by preventing conflicting roles from being assigned together, or dynamically by enforcing separation when an operation is performed.

Static segregation might prevent an employee from holding two conflicting privileged roles simultaneously.

Dynamic segregation might permit multiple authorized administrators to perform an activity while requiring a different authorized person to provide approval for a particular high-risk operation.

The appropriate approach depends on the infrastructure, identified conflicts and risk involved.

Real infrastructure operations include emergencies.

A critical service may fail outside normal working hours. A security incident may require immediate firewall containment. A privileged identity system itself may become unavailable.

SAMA's change-management requirements explicitly call for a procedure for emergency changes and fixes.

Define emergency access and emergency-change processes explicitly. Depending on the organization's risk and technology, controls can include tightly controlled break-glass accounts, restricted credential custody, strong authentication, enhanced logging and post-event review.

The objective is to make exceptional privilege identifiable and reviewable rather than allowing the exception to become normal operating practice.

An authorization matrix is stronger when it forms part of a chain of evidence rather than standing alone.

SAMA's Infrastructure Security section requires infrastructure security standards to be defined, approved and implemented, with compliance monitored and control effectiveness measured and periodically evaluated. The wider Framework also assigns responsibility to the CISO for ensuring detailed security standards and procedures are established, approved and implemented.

An organization preparing for assessment should therefore be able to connect its written control design to operation.

A practical evidence trail may include the approved infrastructure security standard, current authorization matrices, IAM procedures, role definitions, access approvals, privileged-account inventories, access-review records, change tickets, system configurations and relevant logs.

For example: Policy or standard -> Authorization matrix -> Approved role -> Technical entitlement -> Change or access record -> Audit trail -> Periodic review

That sequence can provide stronger evidence of an operating control than a standalone spreadsheet.

Cyberactics' Compliance and Risk and advisory services can support organizations assessing gaps between documented security requirements, technical configurations and operational evidence.

An authorization matrix should not be treated as a one-time compliance artifact.

Consider what happens after a cloud migration. A traditional network administrator may gain cloud-network permissions. A DevOps team may begin managing production infrastructure through Infrastructure as Code (IaC). A managed service provider may receive administrative access. A security team may deploy a new SIEM with its own privileged roles.

The old matrix can remain perfectly formatted while becoming operationally obsolete.

Review triggers can therefore include significant infrastructure changes, organizational restructuring, new technology adoption, changes in administrative responsibility and material changes to privileged roles.

Periodic access reviews can also test whether actual permissions still correspond to approved responsibilities.

Automation changes the implementation of SoD, but it does not remove the principle.

Consider IaC, where firewall, cloud or server configuration is stored in version-controlled code. An engineer might create a pull request, another authorized person reviews and approves it, and an automated deployment pipeline applies the approved configuration while logging records the deployment. Our posts on infrastructure as code drift and secure CI/CD pipelines explore those controls further.

Some execution is performed by a machine rather than a human administrator, but authorization and segregation can remain meaningful.

The same principle should apply to automation identities themselves. Service principals, API keys and deployment accounts can hold powerful privileges. Their rights should be documented and controlled according to what the automation actually needs.

Organizations preparing for SAMA assessments should examine whether any of these patterns exist:

• The authorization matrix lists job titles but not the rights, permissions, business-process tasks and affected systems needed to demonstrate the intended segregation.
• Administrators can approve their own privileged access where that creates a conflict with the organization's approved SoD model.
• Conflicting stages of sensitive changes are controlled by the same person without appropriate segregation or a compensating control.
• Actual system privileges are broader than the authorization matrix indicates.
• Former roles or transferred employees retain legacy administrative access.
• Shared administrator accounts prevent reliable attribution.
• Cloud administrative roles are missing from an older, data-center-focused matrix.
• Backup, IAM and security platforms are excluded from the applicable infrastructure SoD scope.
• Emergency accounts exist without controlled use and review.
• Service accounts and automation identities hold unnecessary privileges.
• The matrix has an approval date but no effective process for keeping it aligned with infrastructure changes.
• Procedures describe segregation, but available technical and operational evidence does not demonstrate that the documented model operates in practice.

These are not a substitute for assessing the Framework itself. They are practical indicators that documented authorization and operational privilege may have drifted apart.

SAMA 3.3.8.6.b is specifically relevant to Member Organizations within the applicability of the Saudi Central Bank's Cyber Security Framework. Organizations should determine their applicable SAMA requirements based on their regulatory status rather than assuming that the control applies merely because they operate in Saudi Arabia.

For financial groups operating across the GCC and wider MENA region, however, segregation of duties can also have broader architectural implications.

A group may operate infrastructure across Saudi Arabia and the UAE, use shared cloud platforms, or centralize administration elsewhere in the region. An administrator outside Saudi Arabia might still possess privileged rights over infrastructure supporting a Saudi-regulated entity. Similarly, organizations operating in Oman alongside Saudi operations may use common identity systems, network teams or managed platforms.

In these environments, an effective authorization exercise should account for who can actually exercise privilege over the relevant systems, including cross-border or centralized administrative roles, rather than relying solely on national organizational charts.

This is one reason centrally governed IAM, privileged-access controls and consistent infrastructure management can be valuable for multi-country GCC organizations.

For organizations starting their SAMA SoD compliance work, a practical sequence is to:

1. Identify infrastructure in scope under the SAMA Framework and determine its owners.
2. Inventory privileged roles, administrative accounts and relevant automation identities.
3. Identify potentially conflicting or high-risk activities for each platform.
4. Define the users or roles authorized to request, approve, implement or review those activities as applicable.
5. Create the authorization matrix, including applicable rights and permissions, business-process tasks and affected systems.
6. Compare the approved model with actual system access and address unnecessary permissions or conflicting roles where appropriate.
7. Establish controls around privileged, emergency and exceptional access.
8. Test recent activities to determine whether the available authorization, implementation and review evidence supports the documented model.

The evidence should enable the organization to determine what occurred, which identity performed the action and whether the activity complied with its approved authorization and change-management requirements.

The most useful way to interpret SAMA 3.3.8.6.b is not as a request for another document.

The authorization matrix should help answer a more important question: Who has the rights and permissions to perform sensitive infrastructure activities, and how does the organization separate duties that should not be controlled by the same individual or role?

When that model is properly designed, segregation of duties can strengthen accountability, make privileged activity easier to investigate, reduce opportunities for unauthorized changes and give infrastructure teams a clearer operating model.

SAMA's Infrastructure Security requirements reinforce this approach by connecting documented standards with implementation, compliance monitoring and periodic evaluation.

For SAMA Member Organizations, the objective is to build a matrix that reflects how infrastructure is actually operated, align technical access with the documented authorization model, and retain sufficient evidence to demonstrate that the control operates as intended.

Cyberactics can support organizations reviewing infrastructure permissions, IAM controls, administrative workflows and compliance evidence against applicable security requirements. Its Compliance and Risk, vCISO, Identity and Access Management, and Managed IT services can help teams identify gaps between the authorization matrix and real technical access and develop a practical remediation plan for their environment. Get in touch to discuss your environment.