1. What the OBF Framework Is (and Isn’t)

Designed to support UAE Vision 2031 and a knowledge-based economy, the Outcomes-Based Evaluation Framework (OBEF),launched by the Ministry of Higher Education and Scientific Research (MoHESR) in 2024, marks a fundamental reorientation from input-focused metrics—such as infrastructure and resources—to measurable outputs including graduate employability, research impact, and societal value. Indeed, in addition to emphasizing 24 KPIs, multi-year rolling averages, and risk-based licensing and accreditation, the MoHESR’s OBEF organizes institutional performance across six weighted pillars: Employment Outcomes (25%), Learning Outcomes (25%), Collaboration with Partners (20%), Scientific Research Outcomes (15%), Reputation (10%), and Community Engagement (5%). Its latest update V11.5 (23 March 2026) introduces an additional, voluntary assessment for HEIs that evaluates future skills alignment, and AI-enabled teaching and learning. While these latest requirements are excluded from the official OBEF score and do not affect the 24-KPI institutional or programmatic scorecard, they are presented as forward-looking, non-compliance elements designed to support institutional innovation beyond the core OBF metrics.

What OBF is: - A KPI performance scoring system across 6 pillars - A continuous, periodic reporting obligation - An evidence-based framework — every KPI value must be supported by documented proof (surveys, master API extracts, Scopus/SciVal data) - A relative comparison mechanism (scores are normalised against KPI‑specific thresholds)

What OBF is not: - A simple checklist - A one-time certification - A system you can satisfy with spreadsheets at submission time (if you want to sleep)

2. The Six KPI Pillars (V11.5)

The OBF framework organises all performance requirements into six pillars. From a platform architecture perspective, these pillars map naturally to data domains — each requiring its own collection forms, validation logic, and reporting outputs.

3. What “Compliance” Actually Means in Code

This is where most developers get confused. The OBF framework doesn’t just require you to store data — it requires you to:

1. Calculate KPI values correctly according to specified formulae, respecting rolling‑average timeframes (3‑year, 5‑year, or cumulative sums)
2. Evidence each claim with supporting documentation (surveys, API extracts, certificates)
3. Workflow each submission through defined approval stages
4. Reporting in a specific MoHESR‑specified format (via the future master API or HEDB portal)
5. Audit — every value, every change, every approval must be traceable

# KPI 1.1 Employment Rate (%)
# Formula: (Employed or in further education 12 months after graduation) / (Total graduates in same cohort)
# Timeframe: Rolling 3‑year average across academic years

calculate_employment_rate <- function(employed_numer, total_grads_denom) {
  if (total_grads_denom == 0) return(NA_real_)
  round((employed_numer / total_grads_denom) * 100, 2)
}

# Rolling 3‑year average logic in R
kpi_data %>%
  group_by(institution_id, academic_year) %>%
  arrange(academic_year) %>%
  mutate(
    employment_rate_3yr_avg = zoo::rollapplyr(
      employment_rate_raw, width = 3, FUN = mean, fill = NA, align = "right"
    )
  )

# Evidence linked to KPI submissions (R Shiny / pool example)
observeEvent(input$evidence_upload, {
  req(input$evidence_upload)
  req(input$selected_kpi_submission_id)
  
  file_info <- input$evidence_upload
  
  pool::dbExecute(conn,
    "INSERT INTO evidence_files 
     (submission_id, original_filename, file_type, file_size_kb, uploaded_by, uploaded_at)
     VALUES (?, ?, ?, ?, ?, datetime('now'))",
    params = list(
      input$selected_kpi_submission_id,
      file_info$name,
      tools::file_ext(file_info$name),
      round(file_info$size / 1024, 1),
      session$userData$user_id
    )
  )
})

log_audit_event <- function(conn, user_id, action, entity_type, entity_id,
                             before_json = NULL, after_json = NULL) {
  pool::dbExecute(conn,
    "INSERT INTO audit_log 
     (user_id, action, entity_type, entity_id, before_state, after_state, logged_at)
     VALUES (?, ?, ?, ?, ?, ?, datetime('now'))",
    params = list(user_id, action, entity_type, entity_id,
                  before_json, after_json)
  )
}

4. Database Design for OBF Compliance (V11.5)

A well‑designed OBF database schema must accommodate 24 KPIs, both institutional and programmatic levels, and the various data collection methods (surveys, master API, Scopus/SciVal). From experience, these are the essential tables:

kpi_pillars          — 6 pillars (Employment, Learning, Industry, Research, Reputation, Community)
kpi_indicators       — All 24 KPI definitions, with formulae, timeframes, weights, and level (institution/program)
kpi_submissions      — Term‑level submissions (one per indicator per institution/program per period)
kpi_values           — Calculated values and raw inputs (e.g., numerator, denominator)
evidence_submissions — Evidence package per KPI submission
evidence_files       — Individual files (PDF, CSV, certificates, survey exports)
workflow_stages      — Stage definitions (Draft → Under Review → Approved → Certified)
workflow_audit       — Stage transitions with timestamps and actors
survey_responses     — Raw survey data (GDS, ESS, SES, EWS) for auditability
report_runs          — Record of every generated report (including data snapshot)
audit_log            — Full change history for all mutable records

The relationship between kpi_submissions and evidence_submissions is one-to-one. The relationship between evidence_submissions and evidence_files is one-to-many. This design allows for the replacement of an entire evidence package without deleting file records. For KPIs collected centrally by MoHESR (e.g., Employment Rate via GDS, FWCI via SciVal), your platform must still be able to ingest the official scores and link them to local evidence for cross‑validation.

5. Common Implementation Mistakes

After building and certifying OBF platforms against v11.5, these are the most frequent errors we see:

Mistake 1: Ignoring rolling‑average logic Several KPIs require 3‑year or 5‑year rolling averages. Storing only the current year’s value without historical cohort data will break compliance. Always store the underlying annual numerators and denominators.

Mistake 2: Mis‑handling program‑level vs institution‑level Some KPIs (Impact of Research, Awarded IP) are institution‑only. For others, programmatic weights are redistributed (see Guidebook page 7). Your schema must support both aggregation levels and weight redistribution rules.

Mistake 3: Not supporting small‑population sampling guidelines For programs with fewer than 70 students, MoHESR allows merging of similar programs or a 50% sample. Your platform must implement the sampling logic described in Appendix C (pages 73–77) and flag when samples are used.

Mistake 4: Overlooking evidence for “centrally collected” KPIs Even when MoHESR administers a survey (e.g., GDS, ESS), the institution must ensure adequate response rates. Your platform should track response rates and allow upload of follow‑up evidence (e.g., student contact lists, reminder logs).

Mistake 5: No support for the “Future Readiness” label (optional but strategic) Although excluded from the OBF score, the separate Future Readiness assessment (Future Skills Alignment + AI‑Enabled Teaching & Learning) is increasingly important. Build modular extensions to accommodate it.

Conclusion

The MoHESR OBF framework v11.5 is demanding precisely because it requires that compliance be demonstrated rather than asserted — with 24 KPIs, six pillars, rolling averages, evidence trails, and distinct institutional/programmatic weights. Certified platforms are those built around the framework’s data structures, calculation rules, and audit requirements from the first sprint — not the ones that try to retrofit compliance to an existing data tool.

If you are building an OBF compliance platform for v11.5 and want to discuss the architecture, get in touch.

📧 brassbe1982@gmail.com · 🤝 Request a consultation

1. Modular Architecture: The Non-Negotiable Foundation

The single most important architectural decision in any enterprise Shiny application is using modules, especially in a 10,000+line application this becomes very critical for code maintenance, and continuous platform improvement.

R/
├── mod_auth.R           # Authentication & MFA
├── mod_dashboard.R      # KPI compliance overview
├── mod_kpi_entry.R      # Data entry per pillar
├── mod_evidence.R       # Evidence upload & review
├── mod_workflow.R       # Approval stage management
├── mod_reports.R        # Report generation
├── mod_admin.R          # User & system management
├── utils_db.R           # Database helper functions
├── utils_rbac.R         # RBAC enforcement helpers
└── utils_audit.R        # Audit logging functions

# Module UI
mod_kpi_entry_ui <- function(id) {
  ns <- NS(id)
  tagList(
    card(
      card_header("KPI Data Entry"),
      selectInput(ns("pillar"),   "KPI Pillar",     choices = NULL),
      selectInput(ns("indicator"),"KPI Indicator",   choices = NULL),
      numericInput(ns("value"),   "Submitted Value", value = NA),
      fileInput(ns("evidence"),   "Supporting Evidence", multiple = TRUE),
      actionButton(ns("submit"),  "Submit", class = "btn-primary")
    )
  )
}

# Module Server
mod_kpi_entry_server <- function(id, conn, user_session) {
  moduleServer(id, function(input, output, session) {
    
    # Only load indicators for pillars the user can access (RBAC)
    observe({
      req(user_session$role)
      pillars <- get_accessible_pillars(conn, user_session$role)
      updateSelectInput(session, "pillar", choices = pillars)
    })
    
    # Submission with parameterised query
    observeEvent(input$submit, {
      req(input$pillar, input$indicator, input$value)
      
      submit_kpi_value(
        conn    = conn,
        user_id = user_session$user_id,
        pillar  = input$pillar,
        indicator = input$indicator,
        value   = input$value
      )
    })
  })
}

2. Database Connection Pooling

This is the most operationally critical pattern for any multi-user Shiny application using SQLite.

The problem: By default, each Shiny session that calls dbConnect() opens a new database connection. Under concurrent load, you will exhaust SQLite’s connection limits and produce database is locked errors.

The solution: A single connection pool shared across all sessions, initialised at application startup.

# global.R — Pool initialised once at app startup
library(pool)
library(DBI)
library(RSQLite)

conn <- pool::dbPool(
  drv     = RSQLite::SQLite(),
  dbname  = Sys.getenv("DB_PATH", "data/obf_platform.sqlite"),
  minSize = 2,     # Keep at least 2 connections alive
  maxSize = 10,    # Allow up to 10 concurrent connections
  idleTimeout = 300000  # Release idle connections after 5 minutes
)

# Ensure pool is closed when app stops
onStop(function() {
  pool::poolClose(conn)
})

Important: Pass conn into every module as an argument — never access the pool as a global variable inside module server functions. This keeps modules testable and deployable independently.

3. Security: Parameterised Queries Are Mandatory

SQL injection is not a theoretical risk in institutional software — it is the most common vulnerability class in data-driven applications. Every database query in a BRASS platform uses parameterised statements with no exceptions.

# ❌ NEVER do this — vulnerable to SQL injection
user_data <- dbGetQuery(conn,
  paste0("SELECT * FROM users WHERE email = '", input$email, "'")
)

# ✅ Always use parameterised queries
user_data <- pool::dbGetQuery(conn,
  "SELECT user_id, name, role FROM users WHERE email = ? AND is_active = 1",
  params = list(input$email)
)

This applies equally to INSERT, UPDATE, and DELETE statements:

# Parameterised INSERT — safe from injection
pool::dbExecute(conn,
  "INSERT INTO kpi_submissions 
   (indicator_id, term_id, submitted_value, submitted_by, submitted_at)
   VALUES (?, ?, ?, ?, datetime('now'))",
  params = list(
    input$indicator_id,
    input$term_id,
    input$submitted_value,
    user_session$user_id
  )
)

4. Role-Based Access Control (RBAC)

RBAC in a Shiny application has two layers: UI-layer (show/hide elements) and server-layer (enforce on data operations). Both are required. UI-only RBAC is not RBAC — it is a cosmetic filter that any developer can bypass.

# On login, load the user's role into the session
init_user_session <- function(conn, user_id) {
  user <- pool::dbGetQuery(conn,
    "SELECT u.user_id, u.name, u.email, r.role_name, r.permissions_json
     FROM users u
     JOIN user_roles ur ON u.user_id = ur.user_id
     JOIN roles r ON ur.role_id = r.role_id
     WHERE u.user_id = ? AND u.is_active = 1",
    params = list(user_id)
  )
  
  list(
    user_id     = user$user_id,
    name        = user$name,
    role        = user$role_name,
    permissions = jsonlite::fromJSON(user$permissions_json)
  )
}

# Enforce RBAC at the server level — not just UI
observe({
  req(user_session$permissions)
  
  if (!"edit_kpi_data" %in% user_session$permissions) {
    # Disable the submit button programmatically
    shinyjs::disable("submit")
    showNotification("Insufficient permissions to submit KPI data.",
                      type = "error")
    return()
  }
})

5. Audit Logging

Every compliance platform requires a complete, tamper-evident audit trail. The pattern is simple: a dedicated log_audit_event() function called at every state-changing operation.

# utils_audit.R
log_audit_event <- function(conn, user_id, action, entity_type, entity_id,
                             before = NULL, after = NULL) {
  pool::dbExecute(conn,
    "INSERT INTO audit_log 
     (user_id, action, entity_type, entity_id, 
      before_state, after_state, logged_at, session_id)
     VALUES (?, ?, ?, ?, ?, ?, datetime('now'), ?)",
    params = list(
      user_id,
      action,
      entity_type,
      entity_id,
      if (!is.null(before)) jsonlite::toJSON(before, auto_unbox = TRUE) else NA,
      if (!is.null(after))  jsonlite::toJSON(after,  auto_unbox = TRUE) else NA,
      session$token
    )
  )
}

# Usage — called after any state change
observeEvent(input$approve_submission, {
  
  # Read current state before change
  before_state <- get_submission(conn, input$submission_id)
  
  # Make the change
  approve_submission(conn, input$submission_id, user_session$user_id)
  
  # Read new state
  after_state <- get_submission(conn, input$submission_id)
  
  # Log it
  log_audit_event(
    conn        = conn,
    user_id     = user_session$user_id,
    action      = "APPROVE",
    entity_type = "kpi_submission",
    entity_id   = input$submission_id,
    before      = before_state,
    after       = after_state
  )
})

6. Environment Variable Credential Management

Never commit credentials to Git. Never. Use .Renviron for all sensitive configuration:

# .Renviron (never committed — add to .gitignore)
DB_PATH=/path/to/obf_platform.sqlite
ADMIN_EMAIL=admin@institution.ac.ae
MFA_SECRET_KEY=your-totp-secret-key-here
SHINY_SESSION_SECRET=random-session-secret

# global.R — read from environment, never hard-coded
DB_PATH      <- Sys.getenv("DB_PATH", unset = "data/obf_platform.sqlite")
ADMIN_EMAIL  <- Sys.getenv("ADMIN_EMAIL")
SESSION_KEY  <- Sys.getenv("SHINY_SESSION_SECRET")

For shinyapps.io deployment, set environment variables in the Apps → Settings → Vars panel — they are encrypted at rest.

Architecture Checklist

Use this as a pre-deployment checklist for any compliance Shiny application:

Conclusion

Building an enterprise compliance platform in R Shiny is entirely feasible — the OBF platform is proof of that. But it requires treating Shiny as a proper application framework, not a dashboarding shortcut. Modules, connection pooling, parameterised queries, RBAC, and audit logging are not optional extras for compliance software. They are the foundation.

If you are building a compliance platform and want a code review or architecture consultation, get in touch.

📧 brassbe1982@gmail.com · 🤝 Request a consultation

The Short Answer

UAE Federal Decree-Law No. 1/2021 on the Organisation of Higher Education and Scientific Research mandates that all accredited higher education institutions in the UAE demonstrate compliance with MoHESR’s performance evaluation frameworks — including the Outcome-Based Framework (OBF). There is no minimum size threshold, no institutional type exemption, and no emirate-specific carve-out. All 76+ accredited HEIs are subject to this obligation.

If your institution holds a MoHESR licence, OBF compliance is a statutory requirement — not a voluntary quality improvement exercise.

Background: What Federal Law No. 1/2021 Does

Federal Decree-Law No. 1/2021 reorganised the governance structure of UAE higher education under the Ministry of Higher Education & Scientific Research. Its key provisions for institutional compliance purposes are:

Article — MoHESR supervisory authority. The law grants MoHESR explicit supervisory authority over all licensed higher education institutions, including the power to set performance evaluation criteria and require institutions to demonstrate compliance.

Article — Outcome-Based Framework as the evaluation mechanism. The OBF is established as MoHESR’s primary performance measurement mechanism for all licensed institutions. Institutions are required to submit performance data in the format prescribed by MoHESR.

Article — Consequences of non-compliance. The law provides MoHESR with enforcement powers including formal notices, conditional licensing, suspension of accreditation, and revocation of institutional licence for persistent non-compliance.

What the OBF Requires in Practice

The MoHESR Outcome-Based Framework (currently Guidebook v11.5) structures institutional performance evaluation across six KPI pillars:

Each pillar contains multiple KPI indicators, each with a defined data source, calculation method, and reporting format. Institutions must:

1. Collect and maintain data against every applicable KPI indicator
2. Calculate indicator values using MoHESR-prescribed methodologies
3. Maintain evidence documentation supporting each data point
4. Submit data in MoHESR’s prescribed format at each reporting cycle
5. Participate in compliance review processes as required by MoHESR

Why Excel and Manual Processes Are Insufficient

Many institutions continue to manage OBF compliance through Excel workbooks, email-based evidence collection, and manual report assembly. While these approaches technically produce the required outputs, they create material risks:

Audit risk. When MoHESR reviewers examine compliance evidence, they need structured, traceable documentation linking each data point to its source evidence. Excel workbooks with no audit trail cannot reliably demonstrate that data has not been modified after-the-fact.

Data integrity risk. Multiple Excel files maintained across departments, with no single authoritative source, regularly produce inconsistent figures. Discrepancies between submitted data and source documents are a common finding in MoHESR review processes.

Operational risk. Manual consolidation of OBF data typically consumes 40–60 institutional hours per reporting cycle. This is pure compliance overhead with no strategic value — and a direct consequence of not having purpose-built compliance infrastructure.

Version control risk. When MoHESR releases a new OBF Guidebook version, such as the recent release of V11.5, institutions using manual processes must manually update every Excel template, formula, and report format. This is error-prone and typically produces a period of uncertainty about whether current outputs meet the new requirements.

What a Purpose-Built Compliance Platform Changes

A dedicated OBF compliance platform — built specifically for the MoHESR regulatory framework — addresses each of these risks by design:

Audit trail. Every data entry, edit, and submission is timestamped with user reference. The system maintains a complete, unalterable record of the compliance history — satisfying MoHESR review requirements without manual preparation.

Single authoritative source. All KPI data, evidence files, and submissions are stored in a single normalised database. There is no version conflict between departments; the platform is the single source of truth.

Automated reporting. MoHESR-format reports are generated automatically from the data in the system — eliminating manual assembly and the associated error risk. Format compliance is guaranteed because the report template is engineered to the MoHESR specification.

Version management. When MoHESR releases a new OBF Guidebook version, the platform’s KPI framework can be updated to the new version without disrupting existing data or workflows.

The Compliance Gap in the UAE HE Sector

As of early 2026, a significant proportion of the 76+ accredited UAE HEIs are managing OBF compliance without purpose-built infrastructure. The sector-wide pattern is familiar:

• Institutions that deployed structured compliance platforms achieve real-time compliance visibility and consistently pass MoHESR reviews
• Institutions relying on manual processes face recurring data integrity issues, high compliance overhead, and audit risk

BRASS Digital Lab’s Edu-RegTech OBF Platform — with 4 live deployments and 100% MoHESR certification across every platform — represents what purpose-built compliance infrastructure achieves. The companion Edu-SupTech Portal, operating at the MoHESR/CAA supervisory layer, provides regulators with real-time visibility of both individual HEI and sector-wide compliance status.

Practical Implications for Your Institution

If your institution has not yet conducted a structured review of its OBF compliance infrastructure, the following questions are worth addressing with your compliance and IT teams:

1. Do you have a single, authoritative source for all OBF KPI data?
2. Is every data point traceable to its source evidence with a complete audit trail?
3. Can you generate a MoHESR-format compliance report within 24 hours of a request?
4. When MoHESR releases the next OBF Guidebook version, how will you update your compliance processes?
5. How long does your current OBF reporting cycle take, and what is the cost in staff time?

If any of these questions do not have a clear, documented answer, your institution has a compliance infrastructure gap that carries material regulatory risk.

1. Font Selection for Arabic Web UIs

Not all Arabic fonts render well in web environments. After testing seven Arabic font options in bslib Shiny applications, two perform reliably:

Cairo — Modern, professional Arabic font with excellent web rendering. Matches well with Latin sans-serif typefaces like DM Sans or Source Sans Pro. Best for dashboards and institutional applications.

Noto Sans Arabic — Google’s universal font project. Excellent coverage of all Arabic Unicode characters. Slightly more compact than Cairo. Recommended when font consistency across devices is critical.

Load both in your custom.scss as a fallback stack:

// Custom SCSS — Arabic font loading
@import url('https://fonts.googleapis.com/css2?family=Cairo:wght@400;600;700&family=Noto+Sans+Arabic:wght@400;600;700&display=swap');

// Apply to all Arabic-direction elements
[lang="ar"], .arabic, .rtl {
  font-family: 'Cairo', 'Noto Sans Arabic', 'Amiri', serif;
  direction: rtl;
  text-align: right;
}

Avoid: Amiri (beautiful but too literary for dashboards), Scheherazade (same issue), and system Arabic fonts (inconsistent rendering across Windows/Mac/iOS).

2. Language Switching Architecture

The cleanest implementation uses a reactive app_language value that all UI elements observe. This allows every label, help text, and message to switch simultaneously without page reload.

# global.R — Language string bundles
STRINGS <- list(
  en = list(
    page_title       = "OBF Compliance Platform",
    login_title      = "Sign In",
    login_btn        = "Sign In",
    username_label   = "Email Address",
    password_label   = "Password",
    dashboard_title  = "Compliance Dashboard",
    kpi_submit_btn   = "Submit KPI Data",
    submit_success   = "KPI data submitted successfully.",
    submit_error     = "Submission failed. Please check required fields."
  ),
  ar = list(
    page_title       = "منصة الامتثال لصندوق التعليم المبني على النتائج",
    login_title      = "تسجيل الدخول",
    login_btn        = "دخول",
    username_label   = "البريد الإلكتروني",
    password_label   = "كلمة المرور",
    dashboard_title  = "لوحة متابعة الامتثال",
    kpi_submit_btn   = "إرسال بيانات مؤشرات الأداء",
    submit_success   = "تم إرسال بيانات مؤشر الأداء بنجاح.",
    submit_error     = "فشل الإرسال. يرجى التحقق من الحقول المطلوبة."
  )
)

In the server:

server <- function(input, output, session) {
  
  # Reactive language state — default English
  app_lang <- reactiveVal("en")
  
  # Language toggle button
  observeEvent(input$toggle_language, {
    new_lang <- if (app_lang() == "en") "ar" else "en"
    app_lang(new_lang)
    
    # Switch body direction
    shinyjs::toggleClass("body", "rtl-mode", condition = (new_lang == "ar"))
  })
  
  # Reactive string lookup helper
  s <- reactive({
    function(key) STRINGS[[app_lang()]][[key]] %||% paste0("[", key, "]")
  })
  
  # Use in outputs
  output$page_title <- renderText(s()("page_title"))
  output$submit_btn_label <- renderText(s()("kpi_submit_btn"))
}

3. RTL Layout Management

The most common failure in Arabic Shiny UIs is broken layout — RTL text pushing LTR elements out of alignment, or columns appearing in the wrong order. The solution is a rtl-mode CSS class on the body that flips directional properties:

// custom.scss — RTL mode overrides
body.rtl-mode {
  direction: rtl;
  text-align: right;

  // Bootstrap grid in RTL
  .row { flex-direction: row-reverse; }
  .col, [class^="col-"] { float: right; }

  // Form elements
  .form-control, .form-select {
    text-align: right;
    direction: rtl;
  }

  // Navbar — reverse item order
  .navbar-nav { flex-direction: row-reverse; }

  // Sidebar — flip to right side
  .sidebar { border-right: none; border-left: 1px solid var(--border); }

  // Icon spacing — flip left/right margins
  .me-2 { margin-right: 0 !important; margin-left: 0.5rem !important; }
  .ms-2 { margin-left:  0 !important; margin-right: 0.5rem !important; }
}

For elements that should always be LTR regardless of page direction (e.g., numbers, codes, URLs):

# Wrap LTR-only elements in a span with explicit direction
textOutput_ltr <- function(id) {
  tags$span(textOutput(id), dir = "ltr", style = "display:inline;")
}

# Use for KPI values, percentages, dates
output$kpi_value_display <- renderUI({
  tags$span(
    input$kpi_value, "%",
    dir   = "ltr",
    style = "font-family: 'DM Mono', monospace; direction: ltr;"
  )
})

4. Bilingual Document Generation

For regulatory report generation, both languages are often required in the same document. In the OBF platform, we use R Markdown → LaTeX → PDF with explicit language regions:

% LaTeX preamble for bilingual document
\usepackage{polyglossia}
\setmainlanguage{english}
\setotherlanguage{arabic}

\newfontfamily\arabicfont[Script=Arabic]{Cairo}

% In the document body
\textbf{Compliance Report — Al Ain University}

\begin{Arabic}
\textbf{تقرير الامتثال - جامعة العين}
\end{Arabic}

This produces correctly typeset bilingual PDFs where Arabic sections are right-aligned with proper Arabic shaping and English sections remain left-aligned.

5. Testing Bilingual Interfaces

Before delivery, bilingual UIs should be tested for:

Conclusion

Bilingual English/Arabic R Shiny applications are entirely achievable with deliberate architecture decisions. The key choices are: Cairo or Noto Sans Arabic for typography, a reactive language string system rather than conditional UI elements, rtl-mode CSS toggling rather than per-element direction attributes, and explicit LTR preservation for numeric and code content.

These bilingual English/Arabic patterns are production-tested in all MoHESR’s OBF Compliance Platforms developed by BRASS DIGITAL LAB for UAE HEIs.

📧 brassbe1982@gmail.com · 🤝 Request a consultation

Why PDPL Matters for HEI Compliance Platforms

UAE Federal Decree-Law No. 45/2021 on Personal Data Protection (the UAE PDPL) applies to any organisation that processes personal data in the UAE — including universities and the technology platforms they deploy. For higher education compliance platforms, this is significant: OBF platforms process student data (enrolment, academic performance), staff data (faculty credentials, workload), and operational data that often includes personally identifiable information.

Building PDPL compliance in as an afterthought — after the platform is live — is the most expensive way to achieve it. Building it in from the data model design phase costs far less and produces better outcomes. This article covers the key patterns BRASS Digital Lab uses on every platform build.

1. Data Minimisation at the Schema Level

The PDPL principle of data minimisation requires that you collect and retain only the personal data necessary for the stated purpose. In a Shiny/SQLite context, this starts with the database schema.

Pattern: purpose-tagged columns

For every personal data column in the schema, document the purpose explicitly in your schema design:

-- ✅ Well-documented, purpose-justified column
CREATE TABLE kpi_submissions (
  id           INTEGER PRIMARY KEY,
  user_id      INTEGER REFERENCES users(id),  -- Required for audit trail
  submitted_at TEXT NOT NULL,                 -- Required for compliance timestamping
  -- NOT storing: user email, name, department -- these are in users table, not duplicated
  ...
);

Avoid denormalising personal data into compliance record tables — link to the users table via foreign key and pull personal data only when generating reports.

Pattern: defined retention fields

Add retention_expires_at columns to tables containing personal data. A scheduled cleanup job (or manual admin action) can then identify and handle records past their retention period:

# In your Shiny server — data retention audit
expired_records <- dbGetQuery(pool, "
  SELECT id, created_at, retention_expires_at
  FROM user_activity_log
  WHERE retention_expires_at < date('now')
")

2. Lawful Basis Documentation

The PDPL requires a lawful basis for every category of personal data processing. For institutional compliance platforms, the typical bases are:

Document the lawful basis for each data category in your platform’s Privacy Impact Assessment (PIA) — which should be completed before development begins.

3. Access Control as a PDPL Control

Role-Based Access Control (RBAC) is not just a security feature in a PDPL context — it is a data protection control. It enforces data minimisation by ensuring users only access personal data relevant to their role.

Pattern: server-side enforcement

Critically, RBAC must be enforced at the server level, not just by hiding UI elements. A user with database access but no UI permission should still be blocked:

# ✅ Correct — server-side check on every data query
get_student_data <- function(user_role, programme_id) {
  if (!user_role %in% c("admin", "programme_lead")) {
    stop("Access denied: insufficient role for student-level data")
  }
  dbGetQuery(pool,
    "SELECT * FROM student_performance WHERE programme_id = ?",
    params = list(programme_id)
  )
}

# ❌ Wrong — UI-only "hiding" is not an access control
output$student_tab <- renderUI({
  if (user_role() == "admin") tabPanel("Students", ...) # still accessible via URL
})

Pattern: data scoping by role

Admin users see all data; programme leads see their programme; faculty see their courses. Implement this at the SQL level, not in R filtering after a full data pull:

# ✅ Scoped query — only pulls authorised data
get_kpi_data <- function(pool, user_id, user_role) {
  if (user_role == "admin") {
    dbGetQuery(pool, "SELECT * FROM kpi_submissions")
  } else if (user_role == "programme_lead") {
    dbGetQuery(pool,
      "SELECT ks.* FROM kpi_submissions ks
       JOIN programme_assignments pa ON pa.programme_id = ks.programme_id
       WHERE pa.user_id = ?",
      params = list(user_id)
    )
  }
}

4. Audit Trail as PDPL Evidence

The PDPL requires that data controllers demonstrate compliance — which means your audit trail is not just operational logging; it is a regulatory evidence record. Every significant data processing action should be logged.

Pattern: standardised audit log table

CREATE TABLE audit_log (
  id          INTEGER PRIMARY KEY AUTOINCREMENT,
  event_time  TEXT NOT NULL DEFAULT (datetime('now')),
  user_id     INTEGER REFERENCES users(id),
  action      TEXT NOT NULL,          -- 'INSERT', 'UPDATE', 'DELETE', 'EXPORT', 'LOGIN'
  table_name  TEXT,                   -- affected table
  record_id   INTEGER,                -- affected record
  old_value   TEXT,                   -- JSON of previous values (for UPDATE/DELETE)
  new_value   TEXT,                   -- JSON of new values (for INSERT/UPDATE)
  ip_source   TEXT,                   -- not mandatory but useful for security reviews
  session_id  TEXT
);

Pattern: automatic audit logging via a wrapper function

Rather than manually logging in every server function, use a wrapper:

db_write <- function(pool, sql, params, user_id, session_id, action_desc) {
  # Execute the main query
  dbExecute(pool, sql, params = params)

  # Log the action
  dbExecute(pool,
    "INSERT INTO audit_log (user_id, action, session_id, new_value)
     VALUES (?, ?, ?, ?)",
    params = list(user_id, action_desc, session_id,
                  jsonlite::toJSON(params, auto_unbox = TRUE))
  )
}

5. Data Subject Rights Implementation

The PDPL grants data subjects rights including access, correction, erasure, and portability. In a Shiny platform context, this means your admin module needs to support these requests operationally.

Minimum admin capabilities for PDPL rights:

• Right of access: Admin can query all data associated with a specific user ID and export to PDF/CSV
• Right to correction: Admin can update personal data fields with a logged reason
• Right to erasure: Admin can anonymise or delete personal data records (while preserving audit trail integrity — replace personal data with [REDACTED] rather than deleting audit rows)
• Right to portability: Admin can export all data for a specific user in a structured format

Pattern: non-destructive erasure

Deleting audit trail records to fulfil an erasure request conflicts with your regulatory logging obligations. The correct approach is anonymisation:

anonymise_user <- function(pool, user_id, admin_id) {
  # Anonymise personal data in the users table
  dbExecute(pool,
    "UPDATE users SET
       name = '[REDACTED]',
       email = CONCAT('redacted_', id, '@deleted.invalid'),
       phone = NULL
     WHERE id = ?",
    params = list(user_id)
  )

  # Log the anonymisation action (do NOT delete audit rows)
  dbExecute(pool,
    "INSERT INTO audit_log (user_id, action, record_id, new_value)
     VALUES (?, 'GDPR_ERASURE', ?, 'User data anonymised per PDPL erasure request')",
    params = list(admin_id, user_id)
  )
}

6. MFA as a PDPL Security Requirement

The PDPL requires appropriate technical security measures to protect personal data. For a platform handling institutional and student data, multi-factor authentication satisfies the PDPL’s technical security requirement — and BRASS Digital Lab implements TOTP-based MFA on all accounts as standard.

The TOTP secret itself must be stored in hashed form, not plaintext, in the database:

# Verify TOTP token (using the otp package)
verify_totp <- function(pool, user_id, submitted_token) {
  user_secret_hash <- dbGetQuery(pool,
    "SELECT totp_secret_hash FROM users WHERE id = ?",
    params = list(user_id)
  )$totp_secret_hash

  # Decrypt secret for verification only (store encrypted, decrypt on use)
  secret <- decrypt_secret(user_secret_hash)
  otp::totp_verify(secret, submitted_token, window = 1L)
}

Summary: PDPL Compliance Checklist for Shiny Platforms

The Three Approaches

Every UAE higher education institution managing OBF compliance falls into one of three approaches:

1. Manual/Excel — OBF data managed through spreadsheets, Word documents, email, and manual report assembly
2. International RegTech vendor — a generic compliance or quality management platform from an international software vendor, adapted for OBF requirements
3. Purpose-built platform — an OBF compliance platform built specifically for the MoHESR regulatory framework, such as BRASS Digital Lab’s Edu-RegTech OBF Platform

This analysis compares the three approaches across the dimensions that matter most for institutional decision-making: total cost of ownership, compliance risk, operational overhead, and regulatory outcomes.

Approach 1: Manual / Excel

Approach 2: International RegTech Vendor

Approach 3: Purpose-Built R Shiny Platform

Direct Comparison

The Decision Framework

For UAE HEI procurement teams, the decision between approaches reduces to three questions:

1. What is your tolerance for compliance risk? Manual processes carry material audit and data integrity risk. If a MoHESR review finds unverifiable data provenance, the consequences — remediation requirements, reputational impact, potential licence conditions — cost far more than a platform build.

2. What is your priority: lowest upfront cost or lowest total cost of ownership? Manual appears cheapest upfront because staff time is already budgeted. But it creates no institutional asset, and the cumulative staff cost over five years exceeds a purpose-built platform build.

3. Does the platform need to be UAE OBF-specific, or do you need a generic compliance system for multiple frameworks? If your primary driver is MoHESR OBF compliance, a generic international platform adapted for OBF costs more, fits less well, and produces higher ongoing maintenance burden than a purpose-built system. If you need a single platform covering OBF, ISO, and other international frameworks simultaneously, a generic platform may have a case — but evaluate the OBF fit gap honestly.