Skip to main content

Core Concepts

This page explains the key concepts and terminology used throughout Claw GRC. Understanding these building blocks will help you get the most out of the platform.

Frameworks​

A framework is a published set of compliance requirements from a standards body. Claw GRC ships with 11 pre-loaded frameworks and their complete control catalogs. Frameworks are global -- they are shared across all organizations and represent the canonical version of each standard.

Examples: SOC 2 Type II, ISO 27001:2022, NIST 800-53 Rev 5, HIPAA, PCI DSS 4.0, EU AI Act.

Each framework has:

  • A name and version (e.g., "ISO 27001:2022")
  • A standard body (e.g., "ISO/IEC")
  • A set of framework controls -- the individual requirements defined by the standard

Controls​

Controls are the building blocks of compliance. They represent specific security or governance requirements that your organization must implement and demonstrate.

Framework Controls​

Framework controls are the controls as defined by a specific framework. For example, SOC 2's CC6.1 is a framework control that addresses logical access security. These are tied to a specific framework and use the framework's own numbering scheme.

Unified Controls​

Unified controls are Claw GRC's cross-framework abstraction layer. When the same requirement appears in multiple frameworks (which happens frequently), Claw GRC maps those framework controls to a single unified control.

This means that when you satisfy a unified control, you get credit across every mapped framework simultaneously. The mapping includes a confidence score (0.0 to 1.0) indicating how closely the framework control aligns with the unified control.

Control Categories​

Unified controls are organized into categories:

  • Access Control -- Authentication, authorization, and identity management
  • Asset Management -- Inventory, classification, and lifecycle
  • Audit & Accountability -- Logging, monitoring, and review
  • Configuration Management -- Baseline configurations and change control
  • Incident Response -- Detection, handling, and recovery
  • Risk Assessment -- Identification, analysis, and treatment
  • System & Communications Protection -- Encryption, network segmentation, boundary defense
  • And more...

Evidence​

Evidence (formally "evidence artifacts") are the documents, screenshots, logs, API exports, and other artifacts that prove your organization has implemented a control. Evidence is tenant-scoped -- each organization manages its own evidence independently.

Key properties of evidence:

  • Source type -- Where the evidence came from (screenshot, document, api_export, log, configuration)
  • Source identifier -- A human-readable label (e.g., "AWS CloudTrail - Production Account")
  • Requirement mapping -- Which evidence requirement and unified control this artifact satisfies
  • Status -- pending, validated, or rejected
  • Freshness -- Evidence requirements define a freshness window (e.g., 90 days). The platform tracks when evidence was collected and alerts you when it is approaching expiration.
  • File hash -- A SHA-256 hash of the uploaded file for integrity verification

Evidence Requirements​

Evidence requirements define what type of evidence is needed for each unified control. They specify:

  • The evidence type expected (e.g., "screenshot of IAM policy configuration")
  • The automation level (manual, semi_automated, fully_automated)
  • The freshness period in days (how often evidence must be refreshed)

Policies​

Policies are formal documents that describe your organization's rules, procedures, and standards for security and governance. In Claw GRC, policies are versioned documents that go through a lifecycle:

  1. Draft -- The policy is being written or revised
  2. In Review -- The policy is submitted for approval
  3. Approved -- The policy has been reviewed and approved by an authorized person
  4. Archived -- The policy has been superseded by a newer version

Policies can be linked to unified controls to demonstrate that your organization has documented procedures for specific compliance requirements.

Risks​

Risks represent threats, vulnerabilities, or potential events that could impact your organization. Claw GRC uses the AIRSS (AI Risk Scoring System) methodology for risk assessment, which combines traditional risk matrix scoring with AI-enhanced analysis.

Each risk has:

  • Likelihood -- How likely is this risk to materialize? (1-5 scale)
  • Impact -- How severe would the consequences be? (1-5 scale)
  • Risk Score -- Calculated as likelihood x impact (1-25 range)
  • Treatment -- The chosen response strategy:
    • mitigate -- Reduce the likelihood or impact
    • accept -- Acknowledge the risk and take no action
    • transfer -- Shift the risk to a third party (e.g., insurance)
    • avoid -- Eliminate the activity that creates the risk
  • Owner -- The person responsible for managing this risk
  • Status -- open, in_treatment, closed, or accepted

Risks are stored in a risk register that provides a centralized view of your organization's risk landscape.

Assessments and Findings​

Security Assessments​

A security assessment is a structured evaluation of your organization's security posture. Assessments can be:

  • Vulnerability scans -- Automated scanning of systems and applications
  • Penetration tests -- Manual or automated testing of security controls
  • Configuration reviews -- Assessment of system configurations against baselines
  • Code reviews -- Analysis of application source code for security issues

Security Findings​

A finding is a specific issue discovered during an assessment. Each finding includes:

  • Severity -- critical, high, medium, low, or info
  • CWE ID -- Common Weakness Enumeration identifier (e.g., CWE-79 for XSS)
  • CVSS Score -- Common Vulnerability Scoring System score (0.0-10.0)
  • Status -- open, in_progress, resolved, accepted, or false_positive
  • Remediation -- Recommended steps to fix the issue
  • Control mapping -- Which unified controls are affected by this finding

Findings from assessments and scans automatically reduce the compliance score for affected controls until they are resolved.

Agents​

Agents are AI systems that register with Claw GRC and interact with the platform programmatically. Unlike human users who authenticate with Firebase JWT tokens, agents authenticate with API keys (prefixed cgrc_).

Key agent properties:

  • Type -- The agent's function (compliance, security, monitoring, remediation, audit)
  • Capabilities -- A list of MCP tools the agent is authorized to use
  • Trust Score -- A 0.0-1.0 score computed from interaction history (see Trust Scoring)
  • Status -- active or inactive
  • Data Classifications -- What data sensitivity levels the agent can access

Agents interact with Claw GRC through the Model Context Protocol (MCP), which provides a structured way to invoke GRC operations, with every interaction recorded in the audit trail. See Agent Overview for details.

Audit Trail​

The audit trail is an immutable, tamper-evident log of every action taken in the system. It covers:

  • Human actions (creating evidence, approving policies, updating risks)
  • Agent actions (MCP tool invocations, agent-to-agent communication)
  • System events (trust score recalculations, automated scans)

Each entry in the audit trail includes a chain hash -- a cryptographic link to the previous entry that makes tampering detectable. See Audit Logging for the full technical details.

Multi-Tenancy​

Claw GRC uses Row-Level Security (RLS) in PostgreSQL to enforce strict data isolation between organizations. Every tenant table includes an org_id column, and database policies ensure that queries only return data belonging to the current organization.

This isolation is enforced at the database level, not the application level, which means:

  • A bug in application code cannot leak data across tenants
  • Database administrators querying directly must explicitly set the tenant context
  • Even the table owner role is subject to RLS enforcement (FORCE ROW LEVEL SECURITY)

See Multi-Tenancy for details.

Tickets​

Tickets are actionable work items linked to findings, controls, or risks. They bridge the gap between identifying compliance issues and resolving them. Tickets have:

  • Priority -- critical, high, medium, or low
  • Status -- open, in_progress, resolved, closed
  • Assignee -- The person or agent responsible
  • Linked resources -- The finding, control, or risk this ticket addresses

Reports​

Reports are generated compliance documents that aggregate your organization's data into auditor-ready formats. Report types include:

  • Compliance Summary -- Overall posture across all frameworks
  • Framework-Specific -- Detailed status for a single framework (e.g., SOC 2 readiness)
  • Evidence Report -- All evidence artifacts with their control mappings and freshness status
  • Risk Report -- Complete risk register with scoring and treatment plans
  • Audit Trail Export -- CSV export of the immutable audit log with chain hash verification