Subscribe & import
Pull Source Statements and their mapped Practices from any subscribed release into your tenant.
Practice Engine
From standards to executable practice — in your specific context.
Same Practice. Many contexts. One coherent model.
ISO 27001NIST CSFSOC 2RBIPCI DSS
The Problem
Real organizations don't live in one control per requirement.
Conventional GRC tools model one control per framework requirement. But that's not how real organizations operate. A single requirement — 'enforce role-based access control' — exists across cloud infrastructure, on-prem systems, HR systems, branch banking systems, SaaS applications. Different owners. Different evidence locations. Different assurance modes. Different criticality.
Force-fitting all of that into one control loses operational truth. Splitting it into five controls loses regulatory traceability.
The GRAC Approach
A Practice is the concept. A Practice Instance is the operation.
PRACTICE
A Practice in GRAC is a normalized template — the framework-agnostic concept of what the requirement means.
PRACTICE INSTANCE
A Practice Instance is the operational reality of how that Practice runs in a specific context.
Your organization creates as many Practice Instances per Practice as your reality requires — one per environment, one per business unit, one per geography, one per branch — each with its own owner, evidence, dependencies, and assurance mode.
A Practice does not run. A Practice Instance runs.
What You Get
A model that matches how compliance actually runs.
Internal policy authoring
Author internal Source Statements alongside subscribed releases, mapped to Practices, flowing through the same operationalization pipeline.
Applicability at the Instance level
Decide how many Instances of each Practice your organization needs (zero, one, or many). Capture rationale for non-applicability. Bulk-create Instances for Practices that operationalize identically across many contexts.
Instance configuration
Primary, secondary and escalation owner; department; business function; criticality; execution frequency; assurance frequency; evidence type; retention period.
Instance operationalization
Evidence location and locator; full dependency map (people, processes, tools, vendors, third parties); assurance mode (automated via API / connector / agent, or manual via assurance ticket).
Multi-level approval workflows
At every stage — applicability, configuration, operationalization.
Dependency health flagging
For incomplete or inactive dependencies, before they cause a failure.
A Real Example
One Source Statement. One Practice. Four Instances.
SOURCE STATEMENT
ISO 27001 A.5.15 — with parallel statements in NIST CSF, RBI, PCI DSS, SOC 2.
PRACTICE
Enforce role-based access control
In a typical enterprise, this Practice instantiates as multiple Instances:
RBAC on production AWS
Automated via AWS IAM API
Owned by Cloud Security Team
RBAC on on-prem Active Directory
Automated via agent
Owned by Identity Team
RBAC on HRMS
Manual quarterly review
Owned by HR Director
RBAC on branch banking system
Manual monthly review
Owned by Branch Manager
Same Source Statement. Same Practice. Four Instances. Four owners. Four assurance regimes. One coherent compliance picture.
What Changes For You
A data model that matches your reality.
Every control has a named, accountable owner — zero ambiguity.
The same Practice can have some Instances automated and others manual — no artificial splits.
Multi-context audit becomes possible — scope to specific Instances, all Instances under a Practice, or all Practices in a Release.
Multi-branch banks, multi-ward hospitals, multi-plant manufacturers, multi-product SaaS teams — all finally have a data model that matches their reality.
Proof
Built for the way real organizations actually run.
3–12
Instances per Practice in a typical enterprise
30+
attributes per Instance, forming the complete Practice Operationalization Signature
100+
branches instantiating the same Practice with comparative analytics built in
| MODERN COMPLIANCE TOOLS | LEGACY GRC | GRAC | |
|---|---|---|---|
| Control model | One control per requirement | Static control library | Practice template → many Instances |
| Multi-context handling | Loses operational variation | Tribal knowledge in notes | Atomic Instances per context |
| Mixed-mode assurance | All-or-nothing | All-or-nothing | Per-Instance choice |
| Owner clarity | Diffuse | Often ambiguous | One named owner per Instance |
See it in your environment
Book a Demo.
We'll walk you through the Practice Instance Model with examples from your industry.