What Is the GRCL Framework? A Layered Approach to Governance, Risk and Compliance
Dr. Abeer Alshammari · Published 7/29/2026
Most organizations run governance, risk management, and compliance as three separate functions that occasionally exchange spreadsheets. Governance sets policy. Risk assesses exposure. Compliance checks boxes against a framework. Each does its job reasonably well in isolation, and yet the organization can still be surprised by a risk none of the three functions individually owned. GRCL, short for Governance, Risk and Compliance Layered, is the name Dr. Abeer Alshammari gave to the architecture she developed in her doctoral dissertation, Designing Adaptive Cybersecurity Governance Architectures: A Layered GRC Framework for Resilient Digital Transformation, to address exactly that gap.
A note on what GRCL is
GRCL is original doctoral research, developed by Dr. Abeer Alshammari and presented here as her own framework. It is not an ISO, NIST, or COBIT standard, and it is not positioned as one. Where this hub references published standards, they are cited separately and by name.
Why "layered" instead of "separate"
The core idea behind GRCL is that governance, risk, and compliance should be modeled as layers that inform each other continuously, rather than departments that meet quarterly. A policy decision made at the governance layer should visibly change what the risk layer treats as material. A new risk identified at the risk layer should be traceable to which compliance obligations it touches. When these three are structurally connected instead of loosely coordinated, an organization can trace a straight line from "why do we have this control" back to the governance decision that justified it, and forward to the risk it is meant to reduce.
The problem it responds to
Adaptive digital transformation, cloud migration, AI adoption, third-party dependency, moves faster than most GRC programs are structured to track. A layered architecture is meant to make governance adaptive rather than static: built to absorb new categories of risk (an AI agent, a new cloud dependency) without requiring the whole GRC program to be redesigned from scratch each time.
Where GRCL shows up at CyberAbeer
GreenTrust AI's risk assessment model and the CyberAbeer Labs governance curriculum both draw on the layered thinking behind GRCL: treating governance decisions, risk findings, and compliance obligations as connected records rather than independent artifacts. As more of the GRCL Knowledge Hub is published, later articles will go deeper into specific layers and how they apply to AI governance, data trust, and cybersecurity governance individually.
The full dissertation is not yet published in the CyberAbeer Insights library. A publication list is available on request via the Research page.
Try it yourself
An interactive CyberAbeer experience for this topic is in development.
Coming soonRelated reading
Cybersecurity Governance vs IT Governance: Why Confusing the Two Weakens Organizational Resilience
IT governance and cybersecurity governance are often treated as the same function under a different name. They are not, and the gap between them is where major incidents start.
Third-Party Risk Management: A GRC Practitioner's Framework for Vendor Security
A vendor security questionnaire is not a risk management program. Real third-party risk management requires ongoing ownership, not a one-time checklist at signing.
AI Agent Security: Identity, Permissions, Autonomy and the Governance Problem
Traditional software executes instructions. Chatbots mostly respond. AI agents act, on real systems, under someone's authority. That shift is a governance problem before it is a technical one.