Prior Work

Much prior work exists to guide organizations in the adoption of Compliance Management Systems (CMS), such as ISO 19600: Compliance management systems — Guidelines and ISO 37301: Compliance management systems — Requirements with guidance for use.

Other similar resources abound — such as the recent Automated Governance Maturity Model from the CNCF, which allows organizations to measure themselves and set growth goals for their GRC programs. Also, much work has been done in the standardization space by the US National Institute for Standards and Technology (NIST) on the Open Security Controls Assessment Language (OSCAL).

Still, there is a deficiency when it comes to consistent use of terminology, schemas, and processes — and the cross-team interoperability that should reasonably be expected when governing sensitive activities. These divisions have resulted in re-work both within organizations and across industries, and repeat gaps between policy and reality.

Establishing a Layered Approach

The strategic value of adopting a layered architectural model for GRC lies in its ability to create a clear separation of concerns, breaking down a complex domain into manageable, interconnected components.

The Gemara model’s structure was directly inspired by ISO 7498: Information Technology — Open Systems Interconnection — Basic Reference Model. Better known as the OSI Model, it is an authoritative and proven framework which describes distinct layers of network functionality.

By taking a similar approach to GRC, we enable different teams and tools to focus on specific activities—from high-level guidance to low-level enforcement—while ensuring they can interoperate within a cohesive system. Similar to the OSI Model, some tools may operate at multiple layers, and yet they still benefit from the clarity provided by describing their different activities according to the model.

Mirroring the layered approach, the Gemara model defines a contiguous seven-layer architecture. Within this structure, Layer 4 represents a pivot point: implementing policies in a way that will later be evaluated. where the model shifts from providing requirements to active oversight. This layer captures the sensitive activities — such as software design or infrastructure provisioning — that serve as a bridge where requirements and operational reality meet.

Continue Reading