---
title: "Key concepts"
canonical: "https://support.appfire.com/space/RM/3459317964/Key%20concepts"
format: markdown
---
Use this page as a quick reference to the terms used throughout Appfire LiveRisk.

## Risks and signals

- **Risk register:** The LiveRisk area within a Jira space. Each space can have its own risk register, containing its risks, signals, dashboards, and space-specific configuration.
- **Risk work item:** A Jira work item that represents a governed risk. It has an owner, lifecycle status, scores, treatment information, linked work, and activity history.
- **Signal:** A security finding imported from a connected source system, such as Wiz or Snyk. Signals can be reviewed individually, linked to risks, or used to create static and dynamic risks.
- **Risk source:** Where a risk originated. A risk’s **Source Origin** can be Manual, Signals, or OneTrust.
- **Source number:** The user-facing identifier for a risk imported from OneTrust.
- **Source ID:** The internal identifier used to track an imported risk. It isn’t displayed in the LiveRisk UI.
- **Signal source lineage:** Information identifying the security provider and connection that produced a signal.
- **Source system:** The security provider that produced a signal, such as Snyk or Wiz.
- **Signal Source ID:** The stable identifier assigned to a finding by its source system. This appears as **Source ID** for signals.
- **Asset:** A system, service, or data object that risks and signals relate to. Signal groups can be mapped to assets, and assets can be used as matching criteria for dynamic risks.

## Risk lifecycle

A risk moves through the following lifecycle:

**Identified → Evaluation → Treatment → Monitoring**

- **Identified:** The risk has been recorded but has not yet entered formal evaluation.
- **Evaluation:** The risk is assessed, scored, and assigned a treatment decision.
- **Treatment:** Approved mitigation work is in progress.
- **Monitoring:** Treatment is complete or the risk is being retained and reviewed on a schedule.
- **Re-evaluation:** The risk requires another assessment after entering Treatment or Monitoring, usually because its context or exposure has changed.

## Static and dynamic risks

- **Static risk:** A risk created with a fixed set of signals. The signals linked during creation remain attached unless they are changed manually.
- **Dynamic risk:** A risk that continues tracking changing security findings. Matching Open and In progress signals are linked automatically as source data changes.
- **Signal funnel:** The criteria that determine which signals match a dynamic risk. A funnel can use a Snyk project or Wiz subscription; selected assets; a title search; a severity threshold; and supported signal statuses.

## Risk scoring

- **Impact:** How serious the consequences would be if the risk occurred.
- **Probability:** How likely the risk is to occur. Some documentation may refer to this dimension as *likelihood*. The default matrix uses **Impact** for columns and **Probability** for rows, but space administrators can rename both axes.
- **Risk matrix:** The space-specific model that maps Impact and Probability combinations to risk tiers and scores. Matrix labels, values, tiers, colors, and scores can differ between spaces.
- **Tier:** A named, color-coded risk level assigned to one or more matrix cells. Examples include Low, Medium, High, and Critical.
- **Inherent score:** The risk level before controls or treatment are considered.
- **Current score:** The risk’s current level after considering existing controls and current treatment progress.
- **Target score:** The level the organization intends to reach through treatment.
- **Risk appetite:** The target score that risks should remain below. It appears as a reference line on risk trend charts.

## Classification and compliance

- **Risk category:** A space-level value used to group risks by areas such as security, compliance, operations, or third-party exposure.
- **Vulnerability:** A weakness associated with a risk. Space administrators manage the values available in the **Vulnerabilities** field.
- **Threat:** A potential cause or event associated with a risk. Space administrators manage the values available in the **Threats** field.
- **Control:** A requirement or safeguard from an enabled compliance framework that can be associated with a risk.
- **Security posture:** A governance view that organizes risk information by framework, domain, and control. It uses the compliance frameworks enabled in the space’s Controls configuration.

## Treatment and governance

- **Treatment decision:** The selected response to a risk:
  - **Reduce:** Take action to lower the risk.
  - **Retain:** Accept and monitor the risk.
  - **Avoid:** Stop or change the activity that creates the risk.
  - **Transfer:** Shift responsibility or exposure to another party.
- **Risk Treatment plan (RTP):** The plan that turns the treatment decision into trackable Jira work. It includes the target score, due date, linked tasks, and expected score changes.
- **Mitigation task:** A Jira work item created from the treatment plan to complete a specific risk-reduction activity.
- **Approval mode:** The agreed level of automation for Current score or treatment-plan changes. A mode can require manual acceptance or allow approved AI-assisted updates within defined boundaries.
- **Risk Manager next action:** The governance action currently available for a risk, such as reviewing the risk, beginning evaluation, approving treatment, or completing another action required by its current lifecycle state.

## Roles and AI

- **Risk Owner:** The person responsible for assessing a risk, reviewing AI estimates, proposing scores and treatment, and creating the treatment plan.
- **LiveRisk Manager and LiveRisk Analyst:** Governance roles used to manage risks and move them through the risk lifecycle. Access to LiveRisk actions is controlled by Jira permissions, including **Manage LiveRisk Risk Register**, rather than by the role name alone.
- **AI Estimate:** An AI-generated scoring proposal that includes Impact, Probability, a tier, and the rationale behind the estimate. Users can answer refinement questions before accepting it.
- **AI treatment plan:** An AI-generated draft containing a target-score journey and proposed mitigation tasks.
- **Human-in-the-loop:** AI can estimate, recommend, and act within an accepted mandate, but people remain responsible for governance decisions. AI does not silently accept risks, override approvals, or change scores outside approved boundaries.