eGRACS Authority by Design
The eGRACS Schema structurally defines where the control mandate lives (the Method), how the rule is structured (the Framework), and how the rule is communicated to the GRC engine (the OSCAL representation). The underlying principle is "practices map to tier, giving organizations the flexibility to assign the person". Here is how eGRACS ensures demonstrable, distinct accountability.
The Three Accountability Pillars
1. The Logical Mandate: Structural Segregation (The Framework):
The eGRACS Framework mandates workflow independence by ensuring that controls at different tiers cannot be satisfied by the same evidence, activities, or operational components. In a standard compliance checklist (like a flat ISO 27001 spreadsheet), a single "Access Control Policy" might satisfy both the governance requirement and the technical requirement. In eGRACS, the pyramid-shaped hierarchy prevents this lumping:
- A Core Tier control statement mandates a Board Policy or Risk Appetite deliverable.
- A Tactical Tier control statement mandates a Technical Safeguard (such as configuration files or automated logs).
The structure of the controls themselves forces the separation of duties. An auditor can easily spot a breakdown in accountability because a single human actor cannot logically author the policy and execute the automated evidence collection simultaneously.
2. The Procedural Mandate: Standard Operating Procedures (The Method)
While the Framework defines the structure, the eGRACS Method serves as the "operational playbook" that explicitly mandates workflow independence.
- The Method provides the eGRACS SOPs (Standard Operating Procedures) and implementation roadmaps. These procedural documents establish the mandatory operational boundaries: They define the precise workflow gates (e.g., "A Tier 1 Core demand approval requires a formal Board Charter signature and cannot be delegated to an operational group").
- They outline the step-by-step instructions for implementation, ensuring that the GRC administrator has a clear, non-negotiable directive on how to configure the platform's workflow permissions.
The eGRACS Method is the blueprint that tells the GRC platform where to build the walls and the GRC platform is the "muscle" that enforces the locks.
3. The Role of OSCAL: Preventing "Config Drift" and Human Error
In traditional GRC setups, separating Board and Executive approvals requires manual, custom coding within GRC platofrms such as ServiceNow and RegScale. Over time, as platforms are upgraded or teams restructure, these custom workflows suffer from config drift and break down, leading to audit failures.
OSCAL solves this by translating the logical and procedural mandates of eGRACS into immutable metadata:
- Global Identity Relationships: Using UUID mappings, the OSCAL catalog programmatically binds specific controls to specific organizational roles.
- Programmatic Assurances: When an GRC platform ingests the eGRACS OSCAL Profile, it automatically parses these UUID relationships. The platform reads the metadata and auto-configures the approval workflows based on the defined roles.
This eliminates the risk of human configuration error during implementation. The GRC platform isn't guessing how to enforce segregation of duties; it is executing an authoritative, machine-readable rule set that is version-controlled and auditable.
eGRACS OSCAL Catalog Overview
Segregation of Duties (SoD) Automation: Key Points
Instead of treating role segregation as isolated documentation exercises, the eGRACS OSCAL toolchain transforms segregation of duties into a connected, machine-readable system.
The Division of Labour
The control to role relationship is a three-part system:
- Framework & Method (The Law): Mandates what must be separate and how those workflows must operate procedurally.
- The GRC Platform (The Police): Actively enforces the boundaries by blocking unauthorized users from executing approvals.
- OSCAL (The DNA): Seamlessly communicates the exact rules from the "Law" to the "Police" without manual, error-prone human translation.
Three programmatic controls prove accountability separation before any system configuration even begins:
1. Independent Identity Declarations (`metadata.roles` & `metadata.parties`):
Instead of typing names into a text cell, human and organizational actors are defined as unique, centralized entities using standard cryptographic UUIDs. The Board of Directors and the Chief Information Officer are established as separate logical entities with distinct authority classifications.
2. Structural Classification (`class` & `props`):
The controls are structurally segregated into different metadata classes (`Core-Tier` vs. `Strategic-Tier`) and assigned custom properties like `maturity_level`. This proves to the auditor that the framework separates board-level foundational demands from the executive-level strategies designed to fulfill them.
3. Explicit, Machine-Readable Responsibility Mapping (`responsible-parties`)
Under each control, the schema uses OSCAL UUID relationships to bind the control to its rightful owner. Because `egracs-core-md-1` references only the Board's UUID, and `egracs-strategic-as-1` references only the CIO's UUID, a GRC platform reading this catalog can programmatically enforce separate approval gates.
This machine-readable separation prevents configuration drift. If an executive tries to sign off on a Core-level policy, the GRC platform can block the action by verifying that the executive's identity UUID does not match the control's mandated `role-id`.
eGRACS OSCAL JSON Preview
This example OSCAL JSON catalog snippet is demonstrating how the eGRACS Framework separates board-level oversight from executive-level planning.
The snippet shows how a Core Tier control (Manage Demand) and its expanded Strategic Tier control (Assurance Controls) are declared, categorized via custom metadata properties, and programmatically bound to separate, UUID-defined roles to ensure strict segregation of duties.
{ "catalog": { "uuid": "ad2e51a7-11a6-424f-a038-4fd228fba123", "metadata": { "title": "eGRACS Framework OSCAL Catalog", "published": "2026-05-07T11:01:04.736-04:00", "last-modified": "2026-05-07T11:01:04.736-04:00", "version": "2026.1.1", "oscal-version": "1.1.2" "roles"[ { "id": "board-of-directors", "title": "Board of Directors" }, { "id": "chief-information-officer", "title": "Chief Information Officer" } ], "parties": [ { "uuid": "9e1d8a4f-5602-4b67-8aef-123456789abc", "type": "organization", "name": "Governing Board of Directors" }, { "uuid": "2f8e9c3d-6104-4c78-9bef-abcdef012345", "type": person", "name": "Chief Information Officer" } ] }, "controls": [ { "id": "egracs-core-md-1", "class": "Core-Tier", "title": "Manage Demand", "props": [ { "name": "maturity_level", "value": "1" }, { "name": governance_importance", "value": "critical" } ], "parts": [ { "id": "egracs-core-md-1-stmt", "name": "statement", "prose": "Establish and authorize the overarching strategic demand and investment limits for information and communication technology." } ], "responsible-parties": [ { "role-id": "board-of-directors", "party-uuids": [ "9e1d8a4f-5602-4b67-8aef-123456789abc" ] } ] }, { "id": "egracs-strategic-as-1", "class": "Strategic-Tier", "title": "Assurance Controls", "props": [ { "name": "maturity_level", "value": "2" }, { "name": "governance_importance", "value": "high" } ], "parts": [ { "id": "egracs-strategic-as-1-stmt", "name": "statement", "prose": "Develop strategic security programs, audit frameworks, and risk management policies to satisfy the Board's authorized IT demand and investment guidelines." } ], "responsible-parties": [ { "role-id": "chief-information-officer", "party-uuids": [ "2f8e9c3d-6104-4c78-9bef-abcdef012345" ] } ] } ] } }Governance as a Connected System
The future of governance is not more controls. It is connected controls.
Risk is rarely an isolated event. Ultimately, risk is a structural consequence that propagates upward. By combining a tiered control structure with machine-readable metadata and explicit operational playbooks, eGRACS ensures that workflow independence is structurally designed, procedurally mandated, and programmatically enforced.
Supporting Resources
The following documentation provides additional implementation guidance, engineering patterns and integration details for the eGRACS OSCAL toolchain.
How do developers and engineers integrate the eGRACS OSCAL artefacts? GRC Administrator Guide
How do administrators deploy and manage the eGRACS OSCAL artefacts within GRC platforms? System Owner Implementation Guide
How do system owners implement and document controls within an SSP?
