RiskFlow by Yetitva
A program-driven, evidence-grounded GRC assurance platform — connecting governance objectives, programs, assessments, evidence, assurance, risk evaluation, treatment, and accountable decisions people can defend.
Through RiskFlow by Yetitva, these principles guide a product designed to connect findings and evidence, explain assurance, and support decisions people can defend.
RiskFlow is designed around the work people actually do: owning programs, running assessments, verifying evidence, explaining assurance, evaluating risk, and deciding with accountability. Technical differentiation supports that journey — it does not replace it.
Organize ongoing assurance work inside governance programs — not ad-hoc folders of questionnaires.
Programs carry business objectives, domain scope, ownership, and continuity. Policies, requirements, and obligations stay attached to scoped work. Program status describes governance activity; it is never treated as an assurance conclusion or compliance score.
Every assessment needs a subject, population, period, and accountable roles before conclusions are asserted.
RiskFlow keeps scope visible as work progresses so teams do not silently expand claims beyond what was examined. Domain scope helps operators focus without splitting the product into four siloed apps.
Bounded assurance activities link to programs when they belong there — or stand alone when the work requires it.
Assessments carry workflow orientation through the Context Ribbon and Inspector so reviewers understand where they are without inventing lifecycle or assurance state.
Assessment drafting and validation are available in the current product preview. Saved operational assessment libraries remain under development.
Intake and review preserve provenance, timing, and sufficiency — before any conclusion is asserted.
Evidence packages are reviewed against scoped expectations. Verification stays distinct from observation and from remediation tickets closed without re-checking operation. Enablement is not enforcement.
Deterministic, explainable comparison of expected versus observed conditions — with unknowns kept visible.
The designed Assurance Reasoning Engine evaluates requirements, evidence relevance and sufficiency, conflicts, scope, and temporal boundaries to produce structured assurance conclusions. Canonical states: Established, Partially Established, Not Established, Unknown, and Conflicting. Unknown is not treated as failed.
Assurance Reasoning is a designed capability and is not yet available as a live evaluator.
Governed natural-English explanations from structured conclusions — not unconstrained AI summaries.
Its Assurance Expression Engine is designed to turn structured findings, evidence, and reasoning into substantive, traceable explanations. Audience variants may change language and density; they must not change underlying facts, assurance state, or uncertainty.
Assurance Expression is a designed capability. The audience demonstration below is a conceptual illustration — not live engine output.
Risk scenarios, inherent and residual evaluation, treatment, and accountable decisions — separate from assurance state.
Teams frame threats, exposure, and consequences; assess likelihood and impact; distinguish inherent from residual risk; and record treatment and acceptance with ownership. Risk rating remains Not Rated until assessed. Assurance state does not set the risk score.
Risk evaluation concepts and decision framing are part of the product design. Live quantification and automated risk conclusions are not product behavior today.
Executives, GRC and program leadership, domain owners, and operational teams need different lenses on the same underlying information.
The Stakeholder Pyramid describes those information and decision needs across the organization. Interactive storytelling on this page is a UX concept — in-product role-aware perspectives remain designed and are not yet operational. Perspective selection is not permission and not decision authority.
Context Ribbon and Workflow Inspector keep orientation as teams move from enterprise → program → assessment → evidence.
Assurance Cube is designed so teams can explore governance information progressively — from a broad view into supporting details, with a path back to higher context. Risk Relationship Graph is designed to surface relevant dependencies and potential impacts that require review — correlation is not causality, and graphs do not auto-change ratings. Selecting a workflow stage for inspection does not invent lifecycle progress.
Continuous Compliance is an ongoing governance capability whose posture is derived from scoped, time-qualified assurance evaluations.
Cybersecurity, AI governance, third-party risk, and Continuous Compliance share one assurance core. Established is not Compliant. Reassessment closes the loop when evidence ages or scope changes.
Stakeholder Pyramid
Many perspectives. Shared understanding. Trusted decisions. Explore how the same conceptual governance situation can be considered from four perspectives — without inventing assessment results, metrics, or live authorization behavior.
UX concept — not a live role dashboard
Stakeholder pyramid levels. Use arrow keys to move between levels. Press Escape for the overview of all four levels.
Navy and teal bands echo brand perspectives. This diagram is not the Yetitva logo.
Select a level
Keyboard: arrows to move · Escape for overview
Overview
Governance information often fragments as it moves between operators, domain owners, program leadership, and executives. Different levels need different density — but conclusions should stay connected to the same underlying evidence.
The Stakeholder Pyramid is a product storytelling model for those perspectives. It is not a live role-switching dashboard. Selecting a level shows the information and decisions that level needs — always over shared governance records.
Executive & Board
Set governance priorities, demand accountability, and authorize decisions that require enterprise authority.
GRC & Program Leadership
Own program objectives, assessment coverage, evidence gaps, and decision queues across domains.
Domain & Risk Owners
Prioritize domain-specific assessments, control and evidence conditions, treatments, and dependencies.
Analysts & Contributors
Collect observations, fulfill evidence requests, verify against criteria, and prepare findings for review.
All three are intended to operate over the same programs, assessments, evidence, and decisions — not as disconnected features.
Direction and accountability flow downward. Evidence, risks, and feedback flow upward — connected through program and assessment records, not through invented enterprise aggregation.
Top-down
Direction and accountability
Connected through
Programs & assessments
Summaries are designed to link to supporting records for authorized users. RiskFlow does not invent automated enterprise risk ratings from raw evidence.
Bottom-up
Evidence and feedback
Assurance Reasoning & Expression
Reasoning determines what the evidence supports. Expression communicates that conclusion without inventing facts. Both are designed differentiators of RiskFlow; neither is claimed as a live production engine today.
Assurance Expression — conceptual illustration
Audience changes language and density. It must not change assurance state, scope, uncertainty, or risk status.
Decision-oriented language; same facts, less mechanics.
Privileged-account MFA is only partially established for the assessed production population: 240 of 250 accounts meet the required condition. The remaining gap creates a potential unauthorized-access risk condition. Likelihood and impact have not been assessed, so risk remains Not Rated. Remediation and current evidence are needed before the required state can be restored.
Labeled concept only — not output from a live Assurance Expression Engine, and not a published assessment result.
Risk Evaluation & Decision Intelligence
RiskFlow treats risk evaluation as its own discipline: scenario framing, inherent and residual assessment, control effectiveness, treatment, and authorized decisions — never inferred solely from an assurance state.
01
Subject, exposure, threat or trigger, adverse event, consequence, and assessment horizon — a gap alone is not a rating.
02
Explicit counterfactual baseline with named controls excluded and conditions retained. Requires its own likelihood and impact rationale.
03
Design, implementation, and operating effectiveness are separate inputs. Enablement is not enforcement; implemented is not verified.
04
Separately supported reassessment considering current controls and actual effectiveness — never a silent automatic discount.
05
Mitigate, avoid, transfer/share, accept, monitor, or investigate. Acceptance and escalation require recorded authority.
RiskFlow’s approved prototype direction uses ordinal likelihood and impact on a qualitative 5×5 model (RF-RISK-5X5). Scores are prioritization indices — not calibrated probabilities or expected loss. Production calibration remains a separate governance decision.
Missing required inputs yield Not Rated— never zero, Moderate-by-default, or an invented score. Assurance state does not set likelihood, impact, or rating.
Conceptual matrix
Likelihood × Impact — cells intentionally unlabeled
Visual orientation only. Band labels and calibration are not asserted as live product behavior on this website.
Supporting differentiation
These distinctions protect decision quality. Where capabilities remain designed or planned, that status stays visible.
Subject, scope, population, provenance, time, sufficiency, and uncertainty travel with evaluation — before a conclusion is asserted.
Observation, finding, assurance conclusion, risk rating, remediation, and decision remain distinct. Unknown is not Not Established. Established is not Compliant.
One shared assurance model across cybersecurity, AI governance, third-party risk, and Continuous Compliance — not four isolated apps. Domain detail lives on the Domains page.
Assurance Cube explores governance information progressively — from a broad view into supporting details. Risk Relationship Graph helps teams understand relevant dependencies and potential impacts that require review. Contextual Assistant is a planned assistance experience grounded in permitted application context — never a substitute for deterministic reasoning, governed expression, or authorized decisions. These capabilities are not live today.
