From ca6d2952cb91fb0e5c459f34fee74d8288ba768e Mon Sep 17 00:00:00 2001 From: CPAtoCybersecurity <150057814+CPAtoCybersecurity@users.noreply.github.com> Date: Sun, 17 May 2026 14:52:42 -0400 Subject: [PATCH] Updated terms and definitions in README Adds Risk Operations Center, Risk Surface, and Value at Risk as Terms; refines FUD and Risk Scenarios; updates two Risk-row bullets in the comparison table. --- README.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 62ec7d6..bb5d25e 100644 --- a/README.md +++ b/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
• Shallow & narrow problem solving mindset
• Cumbersome user experience (UX) across GRC processes, tools, etc.
• Work products = static documents, manual workflows, disjointed processes, and theatrical controls
• Processes are excessively, if not exclusively, manual
• Trivial outputs conflated with meaningful outcomes
• GRC treated as a program that serves GRC teams' needs and preferences | • Objectives-centric, risk-focused, and threat-informed approaches
• Systems thinking applied broadly (organizational governance, risk analysis, control modeling, etc.)
• Design thinking harnessed to make the right thing to do the easy thing to do
• Work products = dynamic systems, automated workflows, embedded processes, and enforced guardrails
• Processes are automated, early on and often
• Measurable, meaningful outcomes (or bust)
• 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
• Static governance documentation rarely reflects reality of controls
• Committees exist to check boxes but rarely, if ever, drive strategic decisions that effect change
• 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
• Dynamic governance documentation is enforced via policy-as-code, expressed via policy-to-code, and reconciled via policy-from-code
• Committees exist to define/refine decision making frameworks & to facilitate strategic decisions
• 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
• "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
• Numerical risk scores conflated with "risk quantification"
• Risk tolerance/appetite are imaginary concepts that exist in policy documents with no real-world grounding
• Fear, uncertainty, & doubt (FUD) dominates risk register entries and risk conversations
• Risk team operates as "accountability police" that attempts to pressure, shame, or strong arm fellow teams into taking action
• 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)
• "Risks" are holistic scenarios that account for threats, threat vectors, weaknesses, assets, controls, and impacts
• True risk quantification is in place, with quantitative inputs producing quantitative outputs
• 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
• Evidence, logic, math, & reason (ELMR) dominates risk register entries and risk conversations
• Risk team operates as "decision support partners" that enable their organization to make smart risk decisions
• 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
• "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
• Numerical risk scores conflated with "risk quantification"
• Risk tolerance/appetite are imaginary concepts that exist in policy documents with no real-world grounding
• Fear, uncertainty, & doubt (FUD) dominates risk register entries and risk conversations
• Risk team operates as "accountability police" that attempts to pressure, shame, or strong arm fellow teams into taking action
• 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)
• "Risks" are holistic scenarios that account for threats, threat vectors, weaknesses, assets, controls, exposure, value-at-risk, risk transfer, and residual losses
• True risk quantification is in place, with quantitative inputs producing quantitative outputs
• 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
• Evidence, logic, math, & reason (ELMR) dominates risk register entries and risk conversations
• Risk team operates as "decision support partners" that enable their organization to make smart risk decisions
• 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
• Control design evaluations and testing methods are ignorant of real-world threat models
• 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
• Control design evaluations and testing methods are rooted in evidence-based real-world threat models
• 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
• 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
• 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. | ---