Skip to main content

BIA risks

Business Impact Analysis (BIA) risks are a risk data type for business continuity management. Instead of a single impact and likelihood estimate, a BIA risk records how the impact of a disruption grows over time — across six time intervals from four hours to four weeks — and calculates whether the assessed object is business-critical. Each assessment moves through a governed lifecycle that ends with a recorded board decision.

Requires the BIA Risk Data Type Early Access feature, available on iGrafx Cloud and enabled by an administrator under Admin → Server Settings → Early Access — see Early Access and General Access.

Overview​

A risk becomes a BIA risk through its Data Type setting: choose Business Impact Analysis on the risk's Settings tab. The risk's Data tab then holds time-based assessments instead of dated data points:

  • Each assessment links to one risk-relevant object — the same objects your repository administrator designates for ICS risks — and that object's materiality threshold drives the financial classification.
  • The Impact Assessment Over Time table records three impact categories across six time intervals (4h, 8h, 24h, 3d, 5d, and 4w): a numeric Financial Impact per interval, plus qualitative Regulatory Violation and Reputational Impact ratings of Low, Medium, or High. A rating left at Not Applicable counts as unset and blocks submission. Impact can stay level or grow as the disruption gets longer, but never shrink — the table warns when a value is lower than the previous interval's.
  • Financial impacts use the repository-wide ICS/BIA Risk Currency unit. The platform classifies each value against the linked object's materiality threshold and shows the result in the color-coded Financial Impact Indicator row: Low up to the threshold, Medium up to five times the threshold, and High above that.
  • Each assessment also captures Business Continuity KPIsKPI A quantitative measure used to evaluate process performance against a target — for example, average throughput time, automation rate, or rework percentage. — RPO (Recovery Point Objective), RPA (Recovery Point Actual), RTO (Recovery Time Objective), RTA (Recovery Time Actual), and MTPD (Maximum Tolerable Period of Disruption) in hours, and MBCO (Minimum Business Continuity Objective) as a percentage — plus a Justification / Comments text, which is required before the assessment can be submitted.

Business criticality​

The platform calculates criticality live as you fill in the table and shows it as a chip above it: red Business-Critical or green Not Business-Critical. An assessment is business-critical when any impact category reaches High within the criticality window — any interval up to and including the repository's BIA Criticality Threshold Column (the fourth column, 3d, unless your administrator changed it — see Configure BIA risks). That means any of:

  • the Financial Impact Indicator is High — the financial impact exceeds five times the materiality threshold,
  • Regulatory Violation is High, or
  • Reputational Impact is High.

When an assessment is confirmed, the calculated criticality, the threshold value, and the column in force are stored with it — later configuration changes don't rewrite confirmed history.

Assessment lifecycle​

A BIA risk has one assessment in progress at a time, moving through four statuses:

  • Draft — editable across sessions; the platform saves your changes as you make them. Nothing is final yet.
  • Submitted — all values are locked. A reviewer either confirms the assessment or sends it back to draft with a review comment.
  • Confirmed — an immutable record of the assessment, awaiting the board's decision.
  • Board Reviewed — final. The board's decision is recorded and the next assessment cycle can begin.

Submitting compares the assessment with the most recent board-reviewed one and flags significant changes for review: a financial value that at least doubled or halved, a qualitative rating that moved two levels, or an RPO, RTO, or MTPD that changed by more than 30 percent. You can go back and correct the values, or justify the change and submit anyway.

Confirmed and board-reviewed assessments stay available read-only, so the history of past cycles is preserved. A new assessment can't start until the previous one completes board review.

Board decision​

After confirmation, the board's sign-off on the criticality is recorded on the assessment. The Decision Outcome offers exactly two choices, depending on the calculated criticality: confirm it (Confirmed Critical or Confirmed Non-Critical) or override it to the opposite (Overridden to Critical or Overridden to Non-Critical). Comments and a decision date are required, the decision date can't be earlier than the confirmation date, and who entered the decision is recorded automatically. Finalizing the decision locks the assessment as Board Reviewed.

Key concepts​

  • Assessment — one complete pass through the impact table, KPIsKPI A quantitative measure used to evaluate process performance against a target — for example, average throughput time, automation rate, or rework percentage., and justification, tied to one risk-relevant object and one lifecycle from draft to board review.
  • Risk-relevant object — a resource object designated in the repository configuration as something risks can be measured against. BIA risks share these objects, and their materiality thresholds, with ICS risks.
  • Criticality threshold column — the time interval up to which a High impact makes the assessment business-critical. A High that first appears beyond this column doesn't.
  • Business-critical — the calculated outcome of an assessment, later confirmed or overridden by the board.

When to use​

Use BIA risks when the question is how bad does a disruption get, how fast — a business continuity assessment with recovery KPIsKPI A quantitative measure used to evaluate process performance against a target — for example, average throughput time, automation rate, or rework percentage. and a board-level sign-off trail. Use ICS risks when you assess materiality per data point in a structured risk and control system, and the Standard or Value data types for the flexible, relative risk model — see Risks and controls.

The data type is set per risk, so BIA risks coexist with the other types in the same repository. BIA and ICS risks share the risk-relevant object and currency configuration, so a repository set up for ICS risks is already prepared for BIA.

Related tasks & references​