Glossary

Definitions of key terms used throughout the CSE specification and documentation.

A

Artifact

A piece of evidence or data supporting a finding. Artifacts provide the raw data that demonstrates why a finding was generated and can include configuration snapshots, API responses, log entries, or other technical evidence.

Learn more about artifacts →

C

Control

A specific requirement or safeguard defined by a compliance framework. CSE signals map to controls to indicate which compliance requirements are affected by a finding.

CSE (Compliance Signal Enumeration)

A public specification and registry that defines stable identifiers for recurring technical signals observed in software, infrastructure, and operational artifacts that are relevant to compliance and risk assessments.

D

Domain

The primary compliance framework or regulatory context a signal belongs to. Examples include HIPAA, SOC2, CMMC, GDPR. Each signal is assigned to one domain but can be mapped to controls in multiple frameworks.

E

Evidence

Structured data within a finding that documents the specific observations that led to detection. Evidence typically includes the property values or configurations that triggered the finding.

F

Finding

An instance of a signal observed in a specific environment at a specific time. While signals are abstract definitions, findings are concrete observations that security tools emit when they detect conditions described by signals.

Learn more about findings →

Framework

A compliance standard, regulation, or security benchmark that defines requirements organizations must meet. Examples include HIPAA, SOC 2, ISO 27001, PCI DSS, CMMC. CSE provides mappings to framework controls.

G

GRC (Governance, Risk, and Compliance)

The integrated collection of capabilities that enable an organization to reliably achieve objectives, address uncertainty, and act with integrity. GRC platforms often consume CSE data to track control compliance.

M

Mapping

A relationship linking a CSE signal to one or more framework controls. Mappings enable automatic correlation of findings to compliance requirements across multiple frameworks.

Learn more about mappings →

P

Primary Relationship

A mapping relationship type indicating that a signal directly addresses the control requirement. Primary mappings have the strongest correlation—an open finding typically indicates control failure.

Partial Relationship

A mapping relationship type indicating that a signal addresses only part of a control requirement. Multiple signals with partial relationships may be needed to fully assess a control.

R

Registry

The complete collection of CSE signals, organized by domain and category. The registry is publicly accessible and includes both web-based browsing and programmatic API access.

Relationship

The type of connection between a signal and a control in a mapping. Types include primary, supporting, and partial.

S

Severity

A classification indicating the potential impact of a signal. CSE uses five severity levels: critical, high, medium, low, and info. Severity is a default assessment—actual severity in context may vary.

Signal

The core unit of the CSE registry. A signal represents a canonical definition of a specific technical condition that is relevant to compliance or security assessments. Each signal has a unique, permanent identifier.

Learn more about signals →

Signal ID

The unique, permanent identifier for a signal. Signal IDs follow a structured format: CSE-DOMAIN-CATEGORY-NAME-SEQUENCE (e.g., CSE-HIPAA-TECH-ENCRYPT-REST-001).

Supporting Relationship

A mapping relationship type indicating that a signal provides evidence supporting control compliance, but does not directly address the control requirement.

T

Tag

A keyword associated with a signal for categorization and search. Tags help users discover related signals (e.g., "encryption", "aws", "network").