Define a project lexicon of GRC terms

[jpower432]

Objective

As we continue to implement gemara, it's useful to establish unambiguous lexicon of GRC terms. A shared understanding of these terms is foundational for consistent risk assessment, policy development, evaluation, enforcement, and audit reporting across all layers of the model and for communication with the community.

Completion Criteria

Review GRC terms used in the layers, include at least these terms:

• Risk
• Governance
• Compliance
• Conformance
• Guidance
• Control
• Policy
• Assessment
• Evaluation
• Enforcement
• Audit

[jpower432]

This work can also help support visual explanations. Added a work in progress example below.

[eddie-knight]

Not all of this will be helpful, but here's the product of a recent definitions activity that we did...

GRC Engineering Terms

Entity	Definition	Context
GRC Engineering	An approach that strategically applies engineering principles to GRC processes to make them more efficient and integrated. Also known as automated governance.
GRC	An integrated strategy for managing an organization's Governance, Risk, and Compliance to reliably achieve objectives, address uncertainty, and ensure integrity.
Engineering	The application of scientific principles to design, build, and maintain efficient, reliable, and scalable systems, structures, and processes.
Governance	The set of rules, policies, processes, and structures through which an organization is directed and controlled to achieve its objectives.
Risk	The potential for loss or damage when a threat is actualized. Typically informed by a threat assessment, calculated as the situational likelihood of a negative outcome, then modified by the resulting impact.	Layer 3
Compliance	The act of adhering to stated requirements, which can include laws, regulations, industry standards, and internal corporate policies.
Cybersecurity	The processes and procedures implemented to reduce risk to a software system.
Threat	Any circumstance or event with the potential to adversely impact organizational operations or assets, often by exploiting a vulnerability but some therats are also inherent based on software capabilities.	Layer 2
Threat Actor	Any entity or group that can manifest a threat, whether internal or external, human or machine, intentional or malicious.
Threat Assessment	The process and subsequent result of reviewing the possible threats and attack vectors for a particular service.	Layer 2
Attack Vector	The specific path or method a threat actor uses to exploit a vulnerability. Examples include phishing emails, a compromised API endpoint, or an exposed server port.
Vulnerability	Any part of a system which creates opportunity for undesirable outcomes to be brought about by neglect, mistakes, or malicious action.
Guidance	High-level, abstract rules and frameworks pertaining to cybersecurity, typically developed by industry groups or government bodies. Because these are not tied to specific technologies, they are not likely to need frequent updates and may remain useful for years after creation.	Layer 1
Control Catalog	A version-controlled document containing controls tailored to a specific technology. The catalog may also contain threats for better understanding the rationale behind the controls, and capabilities to increase precision around when and how the controls should be enforced.	Layer 2
Control	A specific, technology-focused, threat-informed safeguard or countermeasure containing a clear cybersecurity or compliance objective.	Layer 2
Control Family	A logical grouping of controls which share a common purpose or function. Useful for quickly navigating complex control catalogs, and for ensuring proper coverage within a topical domain.	Layer 2
Mapping	The process and subsequent result of identifying correlated entries across different documents, or internal to a document — such as mapping controls to threats or threats to capabilities in a control catalog. One entry may map to multiple others with varying strength levels, indicating how effective the source will satisfy the requirements of the target.
Capability	Highly specific descriptions of software behavior for elements such as command line interface, network accessibility, encryption by default, backups, recovery, and much more.	Layer 2
Assessment Requirement	A specific, testable statement within a control that defines the exact conditions or evidence needed to verify its successful implementation. These requirements form the basis for evaluations, when deemed applicable according to the organization's policy.	Layer 2
Policy	A formal statement or rule, informed by Guidance and Controls. It is tailored to an organization's specific risk appetite, and dictates the required or prohibited actions.	Layer 3
Risk Appetite	The level of risk an organization is willing to accept in pursuit of its objectives.
Evaluation	The inspection and assessment of code, configurations, and deployments to verify compliance with established policies.	Layer 4
Assessment	The manual or automated process of evaluating control compliance following a specific assessment requirement. Multiple assessments may be required for a single control.	Layer 4
Evaluation Plan	A set of assessment plans that can be executed together to evaluate a specific scenario, such as for a particular technology, deployment region, and purpose.	Layer 4
Assessment Plan	An outline of assessment details for a specific control, based on the assessment requirements that are applicable for the given scenario. This includes information such as the procedure for executing each assessment.	Layer 4
Evaluation Log	A group of assessment logs corresponding to an evaluation plan. Provides the details necessary for enforcment actions.
Assessment Log	The documented result of an assessment, containing details about when and how a specific set of steps was taken in accordance with an assessment requirement.	Layer 4
Enforcement	The preventive or remedial actions taken based on evaluation findings, such as blocking a non-compliant deployment or automatically fixing a misconfiguration.	Layer 5
Enforcement Gate	A manual or automated process which will prevent the deployment of any resource that cannot demonstrate compliance to achieve a satisfactory degree.	Layer 5
Remediation	A manual or automated process which will fix any compliance issues that are identified by drift detection.	Layer 5
Drift Detection	The process of evaluating resources after they have been deployed, with the aim of ensuring that there are no changes which might impact compliance or indicate a breach.
Audit	A formal, systematic review of an organization's policies, procedures, and conformance to ensure GRC processes are effective.	Layer 6
Inherent vs. Residual Risk	Inherent Risk is the level of risk before any controls or mitigation efforts are applied. Residual Risk is the risk that remains after security controls have been implemented.
Risk Treatment	The process of selecting and implementing measures to modify risk. Common strategies are Mitigation (applying controls), Acceptance (formally acknowledging the risk), Transference (e.g., buying insurance), and Avoidance (ceasing the risky activity).
Baseline	A standardized level of minimum security configuration that is required for all systems of a certain type. A system must at least meet the baseline to be considered compliant.
Compensating Control	An alternative measure that can be used to satisfy a security requirement when the primary control cannot be implemented. It must provide a similar or greater level of defense.
Policy as Code (PaC)	The practice of managing security and compliance policies using a high-level, declarative programming language. This allows policies to be version-controlled, tested, and automatically enforced as part of the development lifecycle.
Continuous ATO	A modern approach to authorization where the Authority To Operate is maintained through continuous monitoring, automated assessments, and real-time risk data, rather than through static, point-in-time audits.
Gemara	Open source logical model to describe the categories of compliance activities, how they interact, and the associated schemas to enable automated interoperability between them. Governed by the Open Source Security Foundation under an Apache 2 license.
OSCAL	The Open Security Controls Assessment Language. A set of standardized, machine-readable formats (XML, JSON, YAML) for expressing and exchanging security control and assessment information, developed and governed by the United States' National Institute of Standards and Technology (NIST).
OSCAL Compass	Open source toolkit that enables the creation, validation, and governance of compliance artifacts. It leverages NIST's OSCAL as a standard data format and provides an OSCAL SDK. Governed by the Cloud Native Computing Foundation under an Apache 2 license.
NIST 800-53	A publication by the National Institute of Standards and Technology that provides a comprehensive catalog of security and privacy controls for U.S. federal information systems.	Uses approaches from Gemara Layer 1
ISO 27001	An international standard specifying the requirements for establishing, implementing, maintaining, and continually improving an Information Security Management System.	Uses approaches from Gemara Layer 1
CSA Cloud Controls Matrix	A cybersecurity control framework for cloud computing from the Cloud Security Alliance (CSA) that provides guidance on securing the cloud environment.	Uses approaches from Gemara Layer 1
MITRE ATT&CK	A globally accessible knowledge base of adversary tactics and techniques based on real-world observations, used for threat modeling and security analysis.	Uses approaches from Gemara Layer 1
MITRE D3FEND	A knowledge base of cybersecurity countermeasures that catalogs defensive techniques and maps them to offensive techniques in the MITRE ATT&CK framework.	Uses approaches from Gemara Layer 1
STRIDE	A threat modeling methodology from Microsoft for identifying security threats, standing for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.
NIST CSF	The National Institute of Standards and Technology Cybersecurity Framework is a set of voluntary guidelines and best practices to help organizations manage cybersecurity risk.	Uses approaches from Gemara Layer 1
SSDF	The Secure Software Development Framework (NIST SP 800-218) is a set of secure software development practices intended to be integrated into the software development lifecycle.	Uses approaches from Gemara Layer 1
Open Policy Agent	An open-source, general-purpose policy engine that enables unified, context-aware policy enforcement across the entire technology stack using a declarative language called Rego.	Combines approaches from Gemara Layers 4 and 5
FINOS CCC	A FINOS project that creates a unified set of cybersecurity controls for the financial services industry by harmonizing global regulations and standards to simplify cloud adoption and compliance.	Adheres to Gemara Layer 2
OSPS Baseline	A set of minimum security requirements for open-source projects, established by the OpenSSF (Open Source Security Foundation). It provides a clear baseline of practices to improve the security posture of open-source software.	Adheres to Gemara Layer 2
Privateer	An open-source, read-only policy engine used to validate actual state and detect drift. It uses plugins to evaluate target resources—from cloud infrastructure to GitHub repositories—against policies and assessment requirements.	Adheres to Gemara Layer 4
SOC 2	A compliance framework developed by the AICPA that focuses on how a company handles customer data. Audits result in a report on the organization's adherence to the five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.
FedRAMP	The Federal Risk and Authorization Management Program (FedRAMP) is a U.S. government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services.

[hbraswelrh]

@jpower432 @eddie-knight I would like to help out on defining the lexicon of GRC terms. This will be very beneficial for establishing informed discussion within the community and for new contributors :).

[jpower432]

We need to use the lexicon to increase clarity about Evaluations vs Assessments