Many access governance projects stall for the same reason: the organisation selects and configures a tool before it has agreed what the roles are, who owns them, and which combinations of access should never sit with one person. The tool then automates confusion. This article describes how we approach identity access governance SAMA CSF implementation, so that CISOs, IT directors and compliance heads can see what each phase involves and what they should expect to hold at the end.
SAMA's Cyber Security Framework expects institutions to control how access is granted, reviewed and removed. In practice, supervisors and auditors look for evidence that this happens on a schedule and that exceptions are explained. The method below is built around producing that evidence as a by-product of normal operation rather than as a scramble before an audit.
The principle: define before you automate
Our Identity & Access Governance service strengthens how access is granted, reviewed and removed, covering joiner-mover-leaver processes, privileged access, segregation of duties and periodic access reviews. The project runs for 6–10 weeks and follows four phases: Baseline, Design, Review and Embed. The order matters. Roles and rules come before workflows, and workflows come before review campaigns.
Phase 1: Baseline
What happens. We start with current processes, systems and access data. That means understanding how access requests, approvals, transfers and terminations work today, and extracting actual permissions from the key systems in scope. Role mining begins here, and it starts from what people really hold, not from job titles or an organisation chart. Actual permissions show where access has accumulated over time, where several people hold identical entitlements without a documented reason, and where a single account carries combinations that conflict.
Client participation. The IT or identity administrators who can export access data take part, along with HR contacts who understand the joiner, mover and leaver events, and application owners for the systems in scope. The compliance or risk lead agrees which systems count as key.
What the client holds at the end. A clear picture of the starting position: how access is currently managed, and a body of permission data ready to be turned into roles.
Phase 2: Design
What happens. We design roles, rules and processes. This is where the decisions that make or break the programme are taken. The work covers:
- A role-based access model, built from the mined permissions and refined with business input.
- Segregation-of-duties rules that state which combinations of access must not be held together.
- A joiner-mover-leaver process that defines how access is granted on joining, adjusted on transfer and removed on exit.
- A privileged access standard, with privileged access management requirements for administrative and elevated accounts.
- IAM policy and procedures that record the above in a form the institution can adopt.
Movers deserve particular attention. Leavers and joiners are usually well understood, but staff who change roles tend to keep old access while gaining new access. The design therefore states explicitly what is removed when someone moves.
Client participation. Business and application owners validate the roles, because they know what each team genuinely needs. Compliance and risk approve the segregation rules. HR confirms how events are triggered, and the CISO or delegate signs off the policy and the privileged access standard.
What the client holds at the end. An approved role catalog for the key systems, segregation-of-duties rules, a documented joiner-mover-leaver process, a privileged access standard, and the IAM policy and procedures.
Phase 3: Review
What happens. We run the first access review campaign. Reviewers confirm or revoke the access recorded against the role catalog, and the campaign is configured so that each decision, each revocation and each exception is captured. Running the first campaign during the project, rather than leaving it for later, tests whether the roles are usable and whether reviewers can make decisions with the information they are given.
The first campaign usually surfaces access that nobody can justify. Handling that calmly, with clear ownership of each revocation, is part of the exercise. It also gives the institution a realistic sense of the effort a recurring cycle will take.
Client participation. Line managers and application owners act as reviewers. A named coordinator on the client side tracks completion and chases outstanding decisions. IT administrators carry out the revocations that reviewers approve.
What the client holds at the end. A completed review campaign and the first access review evidence pack: who reviewed what, what was decided, and what was changed as a result.
Phase 4: Embed
What happens. We hand over and establish the recurring cycle. The institution's team takes ownership of the process, and the review cadence is set so that campaigns repeat on a quarterly rhythm, with the evidence pack growing each time. The handover covers how to run a campaign, how to update the role catalog when systems or organisational structures change, how to handle exceptions, and how to keep the evidence in a form that can be produced on request.
Client participation. The people who will run the process day to day take part in the handover: the identity administrators, the campaign coordinator and the compliance contact who answers audit queries. Their involvement matters more than any document, because a runbook that nobody has practised tends to be abandoned within a cycle or two.
What the client holds at the end. A process the institution can run without us, with its policy, catalog, standard and evidence in place.
How this supports SAMA CSF
The deliverables map to the access-related expectations in SAMA CSF, and the programme is also aligned with NCA ECC. We describe the mapping without citing individual control numbers here, because the exact references should be confirmed against the version of the framework your institution is assessed against. What auditors generally ask to see is consistent: a policy, a defined way of granting and removing access, controls on privileged accounts, segregation rules, and dated evidence of periodic review. Each of these corresponds to a deliverable below.
Full list of deliverables
At the end of the project, the client holds:
- IAM policy and procedures
- Role catalog for key systems
- Privileged access standard
- Access review evidence pack
Together these cover the joiner-mover-leaver process, the role-based access model, privileged access management, segregation-of-duties rules and access review campaigns that make up the service.
Common questions before starting
Do we need an identity tool first? No. The design phase is where roles and rules are settled, and those decisions apply whether access is managed in a dedicated platform or through existing systems. Settling them first also makes any later tool selection far more specific.
How many systems should be in scope? Start with the key systems, those holding sensitive data or supporting critical processes, and extend the role catalog as the cycle matures.
Next step
If your access reviews are irregular, your roles are undocumented, or you are preparing for a SAMA CSF assessment, our Identity & Access Governance service is designed for that starting point. Speak with us about scoping a project and we will discuss which systems to put in the first campaign.
