Hey well thanks for watching glad it was in some way helpful and sorry it seems I missed the point a little!
So I do not think that GRC will do what you want straight OOTB but it could be possible. Let me explain why I think it does what it does, and not what you want...
The generation of the Risk::Control mapping is automatic and only matched on Entity; so it assumes the relevant Control or Risk exists in order to map. What you are asking for is to scope the Controls based on the scoping of Risk... the system does not KNOW that you have that control in place and it might not be relevant for the respective Entity.
e.g.
the Risk: Loss of Integrity could be scoped to both Critical and Non-Critical Apps... , let's say that Slack is non-critical, but MS Teams is critical... so you have the same Risk for both of these applications.
You might have a Control in place to "Validate Integrity"; which would be mapped to the Risk above (using Control Objective::Risk Statement (CO::RS)) mapping).
BUT as this Validate Integrity is manually intensive, you only scope if for Critical Apps. Therefore you would have a Control for MS Teams but not Slack.
When you look at the Risk for MS Teams you see it has a Control against it, but the Risk for Slack does not... If the system took this CO::RS mapping as the guiding light for Entity Scoping too, you could end up with high volumes of Controls which are not really relevant or would ever really be implemented.
Is there any way you can organise your Risk Statements and Control Objectives using Risk Framework and Policies, to ensure that the scoping is appropriate? And thus, you can benefit from the automation? If you are just trying to avoid the initial scoping exercise due to overhead, it should be set & forget- so once its done, you can focus on other activities, such as managing the processes (Attest & Assess). Rather than scoping Entity Type to content, you can scope it to the document and cascade to the content. This can provide greater clarity over what is in scope and why.
If this doesn't work (why not?), it could be possible to introduce some additional logic - as we have the triggers coming in from the initial CO::RS mapping, and other Generate Links methods.. but I would challenge that requirement and really exercise caution because my worry for you would be that it could easily get out of hand, or rather out of control 😛
CO::RS mapping is relatively new in the GRC apps, it used to be that you always had to map Control to Risk at the item level and never at the statement level, so its a much needed enhancement which I think is very well received. Maybe it does need what you require, but you should consider a System Property to allow you to turn it off! Some of the biggest challenge implementing GRC and driving adoption is around the fact it can generate significant volume when let loose and has to be reined in so you need to be able to apply scoping in an appropriate way..
Hope this helps and appreciate the discussion!
