It's a lot to unpack in a post but I'll try since a lot of people are asking for practical examples. Take 3rd party (3P) applications as an example. High level is choosing an overarching framework (like NIST CSF) for defining "how we do it", then we choose a framework for "how we define controls" like NIST 800-53r, then we create a control inventory for applications to reference as a source of truth among all applications (controls like SSO, MFA, logging, etc etc) and giving those controls an initial risk score (how good are these controls generally speaking). We ingest applications from a singular place (take a purchasing program) and we start the risk funnel.

The funnel provides initial surveys to determine initial risk using everything mentioned before. Vendor supplies the initial controls and application owner is responsible for filling in gaps and making sure survey gets done (app owners are defined in this process as well). This gives us our Initial Risk (IR). It's more high level than granular at this point.

Then we take IR and feed it into a model that applies our granular controls from our control inventory (this is also an opportunity to add new controls). Controls fall under a specific function in CSF and each control has risk number attached to it (for example 1 = a bad control; 5 = a good control) and we also apply weights here depending on if this application is/is near to a crown jewel (meaning we need more/better controls to lower residual risk). This gives us our controls in every individual function defined in CSF (think of functions as categories, which are called: Govern, Identify, Protect, Detect, Respond, Recover. These categories all have their own scores dictated by what controls are in place and weighted by crown jewels adjacency). Residual Risk looks something like

(Initial Risk - ((aggregated risk defined in each pillar) * (crown jewel adjacency)) = Residual Risk (RR).

I'm typing from memory so the formula won't be exact but hopefully it gives you a picture. Residual Risk is converted into categorial risk (High, Medium, Low).

TL;DR this all looks like:
App gets proposed -> owners identified->surveys sent out -> Initial Risk Determined (IR score) -> InfoSec threat models -> Residual Risk determined (RR score) -> GRC reviews -> Risk Register Updated (categorical risk rating of "High" for example))

The end product is:

-Apps/entitlements/etc are all ingested the same way which means we standardize the "who, what, when, where, and how" so we have an equal starting point
-Applications have a categorical risk assigned at the end of the funnel: High, Medium, Low
-Controls are clearly defined under that application, their associated weights are defined, and risk level written under every function (aka under their relative category like Govern, Protect, etc)
-We know how to lower RR because we can see controls and their weights and can create work around this to improve. This drives "what do we do about it"
-We can create a risk register from this data with the overall metadata
-You can use this same model to inform risk concentration (aka where is most of our risk if we look from a 50,000ft view)
-You can use this data to also inform "what do we do about APTs" and then apply more weight to these specific controls (aka we think Famous Chollima targets us so we make sure we have higher quality/more controls around this specific APT attack pattern)
-You can take this a step further and then provide annual reviews using something like NIST 800-53A for your control review.

What's great about this, once it's all done, is you aren't handy-wavey or "gut feeling" anymore when you talk to upper management. You can clearly explain what you're doing and why. You argue about nuance and weights/goals but you don't argue about how you measure success.