Updated terms and definitions in README

README.md

@@ -36,7 +36,7 @@ A side-by-side comparison of the legacy GRC mindset and the GRC Engineering appr
 |---|---|---|
 | All | • Framework-centric approaches<br>• Shallow & narrow problem solving mindset<br>• Cumbersome user experience (UX) across GRC processes, tools, etc.<br>• Work products = static documents, manual workflows, disjointed processes, and theatrical controls<br>• Processes are excessively, if not exclusively, manual<br>• Trivial outputs conflated with meaningful outcomes<br>• GRC treated as a program that serves GRC teams' needs and preferences | • Objectives-centric, risk-focused, and threat-informed approaches<br>• Systems thinking applied broadly (organizational governance, risk analysis, control modeling, etc.)<br>• Design thinking harnessed to make the right thing to do the easy thing to do<br>• Work products = dynamic systems, automated workflows, embedded processes, and enforced guardrails<br>• Processes are automated, early on and often<br>• Measurable, meaningful outcomes (or bust)<br>• GRC treated as a product that serves internal and external customers' needs and preferences |
 | Governance | • Mainly consists of static policies, standards, and procedures that everyone "acknowledges" but never remembers<br>• Static governance documentation rarely reflects reality of controls<br>• Committees exist to check boxes but rarely, if ever, drive strategic decisions that effect change<br>• Awareness training checks boxes but is too infrequent, delayed, unengaging, and ill designed to durably change behaviors | • Mainly consists of strong guardrails (e.g. policy-as-code) that enforce risk tolerance & paved paths that make it easy to do the right thing the right way<br>• Dynamic governance documentation is enforced via policy-as-code, expressed via policy-to-code, and reconciled via policy-from-code<br>• Committees exist to define/refine decision making frameworks & to facilitate strategic decisions<br>• Real-time behavioral interventions prevent improper behaviors, while awareness training leverages science-based pedagogy to durably change behaviors |
-| Risk | • Risk program is built on qualitative risk analyses that are heavily, if not entirely, based on unvalidated assumptions, uncalibrated intuition, and generic heatmap frameworks<br>• "Risks" are ambiguous hypotheticals or "control gap findings" that are detached from a real-world understanding of relevant threats, threat vectors, weaknesses, assets, and/or impacts<br>• Numerical risk scores conflated with "risk quantification"<br>• Risk tolerance/appetite are imaginary concepts that exist in policy documents with no real-world grounding<br>• Fear, uncertainty, & doubt (FUD) dominates risk register entries and risk conversations<br>• Risk team operates as "accountability police" that attempts to pressure, shame, or strong arm fellow teams into taking action<br>• Third-party risk management (TPRM) is really just third-party **compliance** management (TPCM) in disguise, focused entirely on third-party controls/mitigations while overlooking first-party risk mitigation opportunities | • Risk program is built on quantitative risk analyses that are based in scientifically-sound forecasting methods, statistical modeling, real-world evidence, and proven frameworks (e.g. FAIR)<br>• "Risks" are holistic scenarios that account for threats, threat vectors, weaknesses, assets, controls, and impacts<br>• True risk quantification is in place, with quantitative inputs producing quantitative outputs<br>• Risk tolerance/appetite is derived from real-world and measurable constraints, such as insurance limits, cash reserves, organizational goals, and executive leaderships' values and principles<br>• Evidence, logic, math, & reason (ELMR) dominates risk register entries and risk conversations<br>• Risk team operates as "decision support partners" that enable their organization to make smart risk decisions<br>• TPRM is actually managing **risk**, focused on holistic scenarios, quantitative risk analyses, and both first-party and third-party controls/mitigations |
+| Risk | • Risk program is built on qualitative risk analyses that are heavily, if not entirely, based on unvalidated assumptions, uncalibrated intuition, and generic heatmap frameworks<br>• "Risks" are ambiguous hypotheticals or "control gap findings" that are detached from a real-world understanding of relevant threats, threat vectors, weaknesses, assets, and/or impacts<br>• Numerical risk scores conflated with "risk quantification"<br>• Risk tolerance/appetite are imaginary concepts that exist in policy documents with no real-world grounding<br>• Fear, uncertainty, & doubt (FUD) dominates risk register entries and risk conversations<br>• Risk team operates as "accountability police" that attempts to pressure, shame, or strong arm fellow teams into taking action<br>• Third-party risk management (TPRM) is really just third-party **compliance** management (TPCM) in disguise, focused entirely on third-party controls/mitigations while overlooking first-party risk mitigation opportunities | • Risk program is built on quantitative risk analyses that are based in scientifically-sound forecasting methods, statistical modeling, real-world evidence, and proven frameworks (e.g. FAIR)<br>• "Risks" are holistic scenarios that account for threats, threat vectors, weaknesses, assets, controls, exposure, value-at-risk, risk transfer, and residual losses<br>• True risk quantification is in place, with quantitative inputs producing quantitative outputs<br>• Risk tolerance/appetite is derived from real-world and measurable constraints — the insurance limit is the contractually obligating expression of risk tolerance defined by the CFO and General Counsel, alongside cash reserves, organizational goals, and executive leadership's values and principles<br>• Evidence, logic, math, & reason (ELMR) dominates risk register entries and risk conversations<br>• Risk team operates as "decision support partners" that enable their organization to make smart risk decisions<br>• TPRM is actually managing **risk**, focused on holistic scenarios, quantitative risk analyses, and both first-party and third-party controls/mitigations |
 | Compliance | • Control monitoring is done periodically, infrequently, and manually<br>• Control design evaluations and testing methods are ignorant of real-world threat models<br>• Control evidence assessments are sampling-based and are partially or totally unscientific, ignorant of effect size, statistical power, etc. | • Control monitoring is event-driven (i.e. real-time) whenever possible, highly automated, and frequent<br>• Control design evaluations and testing methods are rooted in evidence-based real-world threat models<br>• Control evidence assessments are full population-based. When sampling is unavoidable, sampling methods are scientific and account for effect size, statistical power, etc. |
 | Trust & Assurance | • Trust signals are predominantly in the form of questionnaires and static documents<br>• Customers gather trust & assurance artifacts via cumbersome RFP/RFI processes that are largely mediated over email or support tickets | • Trust signals in the form of historical control monitoring metrics are transparently and programmatically provided, and are consumable in human-readable and machine-readable formats<br>• Customers can easily self-serve their way through gathering trust & assurance artifacts, getting questionnaires automatically completed, etc. |
 
@@ -88,7 +88,7 @@ Vocabulary that distinguishes GRC Engineering thinking from legacy GRC.
 | **ELMR** | Evidence, Logic, Math, Reason. The GRC Engineering alternative to FUD—grounded in verifiable data and sound reasoning. |
 | **Evidence Populations** | Complete control records collected automatically over a period. Eliminates sampling risk with full coverage. |
 | **Evidence Samples** | Legacy subset of records selected to demonstrate control operation. Incomplete and vulnerable to selection bias. |
-| **FUD** | Fear, Uncertainty, and Doubt. Legacy fear-based risk communication used to justify budget without rigorous analysis. |
+| **FUD** | Fear, Uncertainty, and Doubt. Legacy fear-based risk communication used to justify budget without rigorous analysis. Its risk-acceptance counterpart is **unstructured worry** — accepting risk without quantifying who actually bears the loss. |
 | **Governance** | Governing with due care so the organization reliably achieves its objectives — paved paths, guardrails, and policy-as-code. |
 | **GRC as a Product** | Treating GRC programs as products serving internal and external customers, with user research, feedback loops, and measurable outcomes. |
 | **Heatmaps** | Legacy likelihood × impact matrices on ordinal scales. Obscure actual risk magnitude behind coarse, subjective categories. |
@@ -100,11 +100,14 @@ Vocabulary that distinguishes GRC Engineering thinking from legacy GRC.
 | **Qualitative Risk Analysis** | Subjective High/Medium/Low scales based on expert judgment. Manual, inconsistent, and difficult to aggregate. |
 | **Quantitative Risk Analysis** | Numerical models, probability distributions, and measurable data. Automated, reproducible, and comparable across scenarios. |
 | **Risk** | Managing risk with due diligence so the organization addresses uncertainty — threat-informed quantitative analysis, evidence-based scenarios, and continuous exposure monitoring. |
-| **Risk Scenarios** | Holistic descriptions combining threat + attack vector + affected asset + impact into a single analyzable unit. |
+| **Risk Operations Center (ROC)** | A Risk Operations Center is the _left-of-boom_ (Govern, Identify) counterpart to the Security Operations Center (Detect, Respond). Its pipeline converts raw security telemetry into prioritized, business-aligned risk reduction through seven steps: 1. Unified asset inventory, 2. Risk factor aggregation, 3. Threat intelligence enrichment, 4. Business context quantification, 5. Risk prioritization, 6. Risk response orchestration, 7. Compliance and executive reporting. |
+| **Risk Scenarios** | Holistic descriptions combining threat + attack vector + affected asset + controls + exposure + impact + value-at-risk + risk transfer into a single analyzable unit. |
+| **Risk Surface** | The complete causal chain from assets → vulnerabilities → controls → exposure → compromise → impact → value-at-risk → risk transfer → residual losses. Generalizes "attack surface" (assets/vulnerabilities/controls/exposure) to include what the business actually stands to lose. |
 | **Scientific Pedagogy** | Evidence-based learning science—spaced repetition, scenario-based exercises, measurable retention—applied to security training. |
 | **Systems Thinking** | Examining how components interrelate and work together over time within larger systems. Applied across governance, risk analysis, and control modeling. |
 | **Threat-Informed** | Grounding policies, controls, and trainings in real-world threat intelligence rather than abstract framework checklists. |
 | **TPCM** | Third-party compliance management. Legacy questionnaire-focused approach that conflates compliance with risk. |
+| **Value at Risk (VaR)** | The dollar value the business is actively exposing to more people, more channels, and higher velocities through digital and AI transformation — the financial center of the risk surface. |
 | **TPRM** | Third-party risk management. Balanced third + first-party focus, evaluating real-world threat scenarios and value-at-risk. |
 
 ---