Lesson 20: Building an Information Security Governance (GRC) Program from Scratch

What You Will Learn in This Lesson

• What GRC actually means in the context of Saudi financial institutions and why it matters beyond checkbox compliance
• How to design a GRC organizational structure that maps to SAMA CSCC domains and NCA ECC controls simultaneously
• A step-by-step approach to building your first GRC program from zero — including policy hierarchy, risk register, and compliance calendar
• How to select and implement GRC tooling that scales with your institution's regulatory obligations

GRC Is Not a Tool — It Is an Operating Model

Ask ten CISOs what GRC means and you will get ten different answers. Some point to a software platform. Others describe a compliance team. The reality is simpler and more demanding: GRC — Governance, Risk, and Compliance — is an operating model that connects three disciplines into a single decision-making framework. Governance defines who makes security decisions and how. Risk management identifies what can go wrong and quantifies the impact. Compliance ensures the organization meets its regulatory obligations. When these three functions operate in silos, you get duplicated effort, conflicting priorities, and audit findings that surprise the board.

For Saudi financial institutions, this is not theoretical. SAMA expects member organizations to demonstrate an integrated approach to cybersecurity governance under CSCC Domain 1. NCA's ECC framework has its own governance requirements under the Cybersecurity Governance subdomain. Running separate programs for each regulator is unsustainable — a unified GRC program lets you satisfy both from a single source of truth.

The Three Pillars: Governance, Risk, and Compliance

Before building anything, you need clarity on what each pillar delivers. Governance is your decision-making architecture: the cybersecurity steering committee, the CISO's reporting line, the policy approval workflow, and the escalation matrix for incidents. It answers the question "who is accountable?" Risk management is your radar system: the threat landscape analysis, vulnerability assessments, risk registers, risk appetite statements, and treatment plans. It answers "what could hurt us and how badly?" Compliance is your evidence engine: the control inventory mapped to regulatory frameworks, the audit schedule, evidence collection workflows, and gap remediation tracking. It answers "can we prove we are doing what we said we would do?"

Practical Example: A mid-size Saudi payment processor was preparing for both its annual SAMA review and an NCA compliance audit scheduled three months later. Their security team maintained two separate spreadsheets — one mapping controls to SAMA CSCC and another to NCA ECC. When an auditor asked about access control policies, the team produced two different documents with conflicting review dates. The finding was not about the policy content — it was about governance failure. A unified GRC program with a single control library cross-mapped to both frameworks would have prevented this entirely.

Step-by-Step: Building Your GRC Program

Here is a practical roadmap for building a GRC program from zero. This sequence has been tested with Saudi financial institutions ranging from fintech startups to mid-tier banks.

Step 1: Establish the Governance Structure

Create a Cybersecurity Steering Committee with representation from IT, Legal, Risk, Operations, and the business. Define the CISO's reporting line — SAMA CSCC recommends direct reporting to the CEO or the board, not buried under IT. Document a RACI matrix for key security decisions: policy approval, risk acceptance, incident escalation, and vendor onboarding. This becomes your governance charter.

Step 2: Build Your Policy Hierarchy

Structure your documentation in four tiers. Tier 1 is the Information Security Policy — a board-approved, high-level document that states the organization's commitment and scope. Tier 2 contains domain-specific policies: Access Control Policy, Data Classification Policy, Incident Response Policy, and so on. Tier 3 holds procedures and standards — the "how-to" documents. Tier 4 covers guidelines and templates. Every policy must have an owner, a review cycle (annual minimum), and a version history. Map each policy to the SAMA CSCC domains and NCA ECC controls it satisfies.

# Example Policy Mapping Structure (YAML)
policies:
  - name: "Access Control Policy"
    owner: "CISO"
    review_cycle: "annual"
    last_reviewed: "2026-01-15"
    next_review: "2027-01-15"
    regulatory_mapping:
      sama_cscc:
        - "3.3.1 - User Access Management"
        - "3.3.3 - Privileged Access Management"
      nca_ecc:
        - "2-5-1 - Identity and Access Management"
        - "2-5-2 - Privileged Access Management"
      pdpl:
        - "Article 10 - Data Access Controls"
    status: "approved"
    version: "3.1"

Step 3: Create Your Risk Register

Start with a risk identification workshop. Bring together IT, security, business unit heads, and compliance. Use a structured taxonomy — NIST CSF categories work well as a starting point. For each risk, document the threat source, vulnerability, affected asset, likelihood (1–5), impact (1–5), inherent risk score, existing controls, residual risk score, risk owner, and treatment plan. SAMA requires institutions to maintain a cyber risk register reviewed quarterly. NCA expects risk assessments to be conducted at least annually. Your register satisfies both when maintained properly.

Step 4: Build the Unified Control Library

This is the core of your GRC program. Create a single inventory of all security controls your organization implements. Each control gets a unique ID, a description, an owner, implementation evidence, and a multi-framework mapping. A single control like "multi-factor authentication for privileged accounts" might map to SAMA CSCC 3.3.3, NCA ECC 2-5-2, PCI-DSS Requirement 8.4.2, and ISO 27001 Annex A 8.5. When an auditor from any framework asks about MFA, you point to the same control, the same evidence, and the same test results.

Step 5: Design the Compliance Calendar

Plot every regulatory obligation on a 12-month calendar: SAMA annual review submission dates, NCA compliance reporting deadlines, PCI-DSS quarterly ASV scans, internal audit cycles, policy review dates, penetration testing windows, and board reporting dates. Work backward from each deadline to set preparation milestones. Assign owners to each milestone. This calendar becomes your operational heartbeat.

# Example Compliance Calendar Entry
Q2 2026:
  April:
    - "Policy review cycle begins (Tier 2 policies)" → Owner: GRC Lead
    - "Q1 risk register review" → Owner: Risk Manager
    - "PCI-DSS quarterly ASV scan" → Owner: Security Engineer
  May:
    - "SAMA CSCC self-assessment draft due" → Owner: CISO
    - "Internal audit: Access Management controls" → Owner: Internal Audit
    - "Board cybersecurity report preparation" → Owner: GRC Lead
  June:
    - "SAMA CSCC submission deadline" → Owner: CISO
    - "Penetration test execution window" → Owner: Red Team Lead
    - "NCA ECC gap remediation status update" → Owner: Compliance Analyst

Step 6: Select and Implement GRC Tooling

Start simple. Many organizations try to buy a GRC platform before they have defined their processes — the tool then dictates the workflow instead of supporting it. For the first six months, a well-structured SharePoint site or even a set of interconnected spreadsheets can work. When you are ready for a platform, evaluate based on: multi-framework mapping capability, automated evidence collection, workflow automation for reviews and approvals, risk register with quantitative scoring, dashboard and board-level reporting, and API integrations with your existing security stack (SIEM, vulnerability scanner, IAM). Popular options in the Saudi market include ServiceNow GRC, Archer, OneTrust, and open-source alternatives like Eramba.

Connecting It to the Saudi Regulatory Landscape

A well-built GRC program is your single answer to the multi-regulator reality of Saudi financial services. SAMA CSCC Domain 1 (Cyber Security Leadership and Governance) explicitly requires a governance framework, defined roles and responsibilities, and a policy management process — your GRC program delivers all three. NCA ECC's Cybersecurity Governance subdomain requires risk management processes, compliance monitoring, and periodic reviews — your risk register and compliance calendar cover these. PDPL requires documented data processing activities, privacy impact assessments, and breach notification procedures — these become controls in your unified library. Instead of running three separate compliance programs, your GRC operating model lets you manage one set of controls, collect evidence once, and report to multiple regulators from a single source.

Common Mistakes to Avoid

• Buying a GRC tool before defining your processes: The tool should automate a process you already understand. If you cannot describe your risk assessment workflow on a whiteboard, no software will fix that. Define your governance structure, policy hierarchy, and control library first. Then select tooling that fits.
• Treating GRC as a compliance-only function: If your GRC program only activates before audits, it is not governance — it is cramming. GRC should drive daily security decisions: Which risks do we accept? Which controls need investment? What is our board reporting this quarter? Make it operational, not periodic.
• Maintaining separate control inventories for each framework: This is the most common and most expensive mistake. Every duplicated control means duplicated evidence collection, duplicated testing, and conflicting audit responses. Build one control library, map it to all applicable frameworks, and enforce single-source-of-truth discipline from day one.

Lesson Summary

• GRC is an operating model — not a tool — that unifies governance, risk management, and compliance into a single decision-making framework for your organization
• Building a GRC program follows six steps: establish governance structure, build policy hierarchy, create risk register, build unified control library, design compliance calendar, then select tooling
• For Saudi financial institutions, a unified GRC program is the most efficient way to satisfy SAMA CSCC, NCA ECC, PCI-DSS, and PDPL requirements from a single source of truth

Next Lesson

This concludes the Saudi Regulatory Compliance learning path. In the next lesson, we begin a new path — Hands-On Cybersecurity — starting with: Introduction to Penetration Testing: Methodologies and Tools. You will learn the difference between black-box, grey-box, and white-box testing, explore methodologies like OWASP Testing Guide and PTES, and set up your first penetration testing lab.

Ready to apply these concepts in your organization? Contact Fyntralink for a complimentary SAMA Cyber Maturity Assessment.