An IT team receives a request for access to beneficiary records to prepare a report. Before it can grant useful, appropriate access, several questions need answers: which records, for what decision, with whose approval, and for how long? Granting access too early can leave permissions broader than the task requires. Sending an incomplete request from team to team can also delay legitimate work.

A data management office can make the process easier to operate by linking the business need, decision, provisioning and review in one record. This article proposes a practical model for internal data access requests. Adapt it to the organisation’s approved policies, delegated authorities and operating structure. Sharing data with another organisation or transferring it outside Saudi Arabia requires the relevant separate assessment; an internal access approval is not sufficient.

Define the purpose and data boundary

Replace a request for the entire database with a task that can be assessed, such as analysing processing time for a particular service during a defined quarter. Identify the dataset, fields, date range and operation required: viewing, analysis, editing or export. An aggregated report may meet the need without access to individual records. A restricted analytics environment may also be more appropriate than a portable copy.

Where personal data is involved, document the purpose and appropriate legal basis, and review the necessity of the requested fields with the relevant specialists. A manager’s or data owner’s internal approval does not itself establish a legal basis for processing. SDAIA’s guidance discusses purpose limitation, data minimisation and protection. Read that guidance alongside the law and implementing regulations; it does not replace them.

Assign decision ownership and provisioning responsibility

Identify the data owner in the approved asset register or data catalogue, together with an authorised substitute. Hosting data in an IT-managed system does not automatically make the system administrator the business decision-maker for access. If a request combines several data domains, identify the relevant owners’ approvals rather than relying on a general approval that does not cover every dataset.

Role	Suggested responsibility
Requester and manager	Explain the task, confirm its business relevance and justify the required duration.
Data owner	Assess the need, permitted scope and use restrictions within delegated authority.
Data management office	Check completeness, classification and ownership; coordinate the route and retain evidence.
Cybersecurity and privacy specialists	Review relevant safeguards or processing requirements according to sensitivity and risk.
System or identity administrator	Provision the approved access, check its scope and record changes and revocation.

This is a suggested allocation of responsibilities, not a requirement for every role to sign every request. Establish an approval matrix based on classification, data type, privilege level and intended environment. A routine request for an established role may use a shorter route. Sensitive exports or elevated privileges require closer assessment.

Separate the access decision from technical provisioning.

Use a request form that supports later review

The existing service request system may be sufficient; collecting approvals does not necessarily require a new product. Give each request a unique reference and attach its decisions, changes and implementation evidence. The fields below provide a starting point for an organisation-specific form.

Field	What to record
Identity and task	Requester, team, manager and the specific business purpose.
Data scope	Dataset, fields, date range, classification and accountable owner.
Access method	Role, permitted operations and the environment where access will be used.
Duration	Start and end dates or expiry condition, plus a review date.
Privacy and restrictions	Personal-data involvement, legal-basis reference where applicable, and use or sharing restrictions.
Decision	Approver or rejector, authority, timestamp, rationale and conditions.
Provisioning	Actual role or group assigned, implementer, activation time and verification evidence.
Review and closure	Keep, adjust or revoke decision, responsible person, completion date and evidence.

Explain rejections and requests for clarification in concrete terms, such as missing field definitions or an unconfirmed owner. Reassess changes to the purpose or scope rather than expanding access under an earlier, narrower approval. Restrict access to the request record itself: it may contain personal information or sensitive details about systems.

Check the access that was actually provisioned

Compare the implemented role with the approved decision and check whether another group grants broader inherited access. Confirm that the user can perform the authorised task and cannot perform an out-of-scope operation, such as exporting records when only viewing was approved. Record that verification against the request.

The identity and access management provisions in Saudi Arabia’s Essential Cybersecurity Controls, ECC 2-2024, address need-to-know and need-to-use, least privilege, segregation of duties and periodic reviews of identities and access rights. Apply the controls according to their scope and the organisation’s circumstances. This article does not prescribe one universal review interval, and a completed form alone is not evidence of compliance. [1]

A hypothetical request with a defined boundary

Suppose an analyst needs to explain delays in service requests. The initial request asks for all beneficiary records. After clarifying the task, the participants agree on request identifiers, service type, stage dates and region, excluding names and contact details. They also assess whether combining those fields could identify individuals. If aggregated data meets the analytical purpose, unnecessary record-level detail can be avoided.

The analyst receives a read-only role in the analytics environment, with editing and export disabled, for an illustrative 30-day period justified by the task. The owner approves the scope, relevant specialists complete their assessments, and the administrator provisions and checks the access. Additional fields or an extension require a documented change request. The period is hypothetical; it is neither a regulatory deadline nor an RMG client result.

Turn each review into a decision and verified action

Give the owner a readable list of users, purposes, effective roles and expiry dates. Request a decision for each entitlement: retain it with a reason, reduce it or revoke it. Usage evidence can inform that assessment, but a recent login does not prove a continuing business need. An apparently unused operational account should also be understood before its access is removed.

Set review frequency according to risk and applicable requirements. Add event-driven triggers for role changes, project completion, changed tasks and the end of employment or a contract. Avoid silent renewal of temporary permissions. Handle emergency access through an approved, time-limited procedure with usage evidence and subsequent review. Close a review after agreed changes and revocations are implemented and verified, rather than when responses have merely been collected.

Record the review decision: keep, adjust or revoke.

Measure the process and start with a defined scope

Track turnaround time for complete requests, requests returned for missing scope or ownership, temporary permissions past their end date and revocation decisions awaiting implementation. Define the start and end of each measure and the denominator of every rate. Separate requester waiting time from internal processing time. Faster approval is not sufficient if permissions become broader or agreed revocations remain incomplete.

Start with one dataset that has an identified owner and recurring access requests. Test the form, routing and review process before expanding. RMG’s data governance and data management office services can support clearer roles and policies, improved processes and operational follow-up. A useful first step is to sample current requests and ask whether the organisation can explain why access was granted, who authorised it and when the need will be reassessed.