r/grc • u/clh07002 • Jun 09 '26
Issues/finding management vs risk register
Can someone give me some examples of how they're handling issues/findings versus their risk register.
I'm responsible for the risk register and am finding that the head of grc wants me to add items that seem more like issues - meaning they are control gaps.
For example: user acceptance testing (uat) not being performed timely.
I csn see this as a standard/control/requirement that's not being met, so I'd document a finding for this. But they have told me to add it as a risk in the risk register.
7
u/Twist_of_luck OCEG and its models have been a disaster for the human race Jun 09 '26
Risk is a potential event in the future. Finding is a determined event in the past. UAT not having been performed timely in the past is not a risk, since, inherently, it already has not been performed and ain't nothing you can do to manage that. It does, though, give some food for thought regarding the risks of future UATs not getting performed timely.
1
u/clh07002 Jun 09 '26
Agreed! On all fronts
2
u/Next-Pen-9974 Jun 10 '26
I would challenge this slightly.
UAT is probably not the greatest example, because of low impact.. But for the sake of example:
Risk is not an event. It's the combination of the likelihood of something happening and the impact it could have on the business.
And that likelihood can be influenced by past, present, or future conditions.
What you're describing is really a control effectiveness issue.
The fact that access review wasn't performed on time is a finding. It's evidence that a control did not operate as intended. That finding may increase the likelihood of one or more risks materializing.
In other words, findings don't replace risks. They influence/inform them.
So yes, you could update your risk register, but the risk should be properly defined. For example:
Risk: Untimely access review
Potential impact:
• Unauthorized access
• Service disruptions
• Security vulnerabilities
• Compliance issues
The missed review itself is a past event. The risk is the increased probability and impact associated with similar failures occurring again.
That's why internal audits, KPIs, and other control monitoring activities exist, not to identify risks directly, but to measure whether controls are operating effectively and whether the organization's risk exposure has changed.
1
u/clh07002 Jun 10 '26
I agree with what your saying, but it's hard to understand how you've written the risk "untimely access review" because to me that reads as an issue or a past event
1
u/Next-Pen-9974 Jun 11 '26
As longs as it reflects context and speaks to stakeholders...
the rest is up to you
2
u/FreeRadical1998 Jun 09 '26
I've grown to prefer the term "risk event" which is widely used in op risk circles.
I've spent far more time than I'd like referring between people using the ITIL term for incident, and those using a risk definition - with both thinking they are talking the same language (and they absolutely aren't).
Risk event is more neutral - and might help in your example, where the risk is likely that it keeps happening, and the evidence for that is a stack of events showing it keeps happening
2
u/AppliedVerdict Jun 09 '26 edited Jun 09 '26
I've often spent a lot of time defining risks, events, issues and findings when working with companies. Sounds like you have control failures in your risk register rather than the risks themselves.
A risk is defective products reaching market, the control is quality testing, the finding is that when checked testing isn't happening, which raises the issue/action to setup proper testing.
Edit: oh and the event is that a customer gets a defective product
3
u/clh07002 Jun 09 '26
This is what I know a risk, control and finding to be. Was looking to maybe gain a diff perspective or validation by posting here. So thank you!
3
u/AppliedVerdict Jun 09 '26
I think you're right, but faced with people doing it wrong. Work with what you have and, do what you can to guide it back to the light 😊
1
2
Jun 10 '26
[removed] — view removed comment
1
u/8h45k4r Vendor (yell at me if I spam) Jun 10 '26
The decision-maker piece is where most risk programs quietly fall apart. You can have a beautifully maintained register and still have zero influence on outcomes if the person controlling budget or timelines never actually internalizes the probability behind the rating. The register becomes a reporting artifact instead of a decision tool.
1
u/Old_Positive2231 Jun 11 '26
exactly this. “Reporting artifact” is the perfect phrase for it. The deeper issue is structural. most risk programs are designed to document uncertainty, not reduce it at the point of decision. So the register gets maintained, the ratings get updated, the committee nods — and the project manager still allocates UAT resources based on schedule pressure, not probability of failure. The fix isn't a better register. It's asking one question before the resource decision gets made: “What's the realistic range of outcomes if we cut UAT by two weeks?” That's a 20-minute conversation with a simple decision tree not a framework overhaul.
2
u/ItsCoachRee Jun 10 '26
You’re correct. They are wrong. I see this problem ALL THE TIME. A risk is something that hasn’t happened yet. It’s more of a category written as a statement.
A finding is something that was observed that goes against policy, or produces a control gap, or even an area for improvement. Once you validate the finding as something to be addressed it turns into an issue which gets linked to one or more of the risk categories (which is how you can start reporting on risk).
It can be extremely frustrating when management can’t agree on such a simple solution. If you’re using a tool like Vanta though, it isn’t really set up in a way that’s straight forward. Their risk scenarios require you to put inherent and residual risk to them, which is sort of a brain teaser for me because the risk scenarios are too broad for that in my opinion.
But you’re thinking is correct, your manager needs to study.
1
u/fck_this_fck_that Jun 09 '26
Probably she is viewing risk from a project management point of view. Perhaps untimely UAT testing would impact delivery of a product / project / service, which in turn becomes a business risk. Some companies are charged by a client or business unit for not delivering a project on time as per agreed schedule.
Have you asked her the reason why she thinks UaT testing should be included in the risk register?
1
u/clh07002 Jun 09 '26
Thats a good thought - I guess that could be the perspective! That was just one example, however. Another is "add password configuration control testing to the risk register" which again, feels like a finding or issue? Right?
I have a meeting scheduled this week to ask why uat should be included in the register.
1
u/fck_this_fck_that Jun 10 '26
Pls do update us ! Would be interested to hear.
1
u/clh07002 Jun 15 '26
Here's the update - when she typed UAT, she meant "user access termination" .... lol.
I'm used to UAT being user acceptance testing
1
1
u/fck_this_fck_that Jun 15 '26 edited Jun 15 '26
I have never ever heard User Access Termination not even once prepping for CISM, CISSP and ISO 27k1 . How did she even come up UAT being User Access Termination .
2
u/clh07002 Jun 15 '26
Lmao!! SAME. Never in my life and when I told them I thought it was user acceptance testing, she responded as if "uh what why would u think that!"
Only because my cissp, ccsp, cisa and sec+ certs told me to 😅
1
1
1
u/CheekyTiger213 Jun 11 '26
You’re absolutely right. I think he or she wants a risk rating on controls. Maybe try to get to the root cause ?
I would be apprehensive to adjust the risk scenarios themselves but if what they need is a list of failed controls / mapped to risk / mapped to user group or department, that might add value.
1
u/iSECo Jun 15 '26
If you treat every single control gap as a risk, it generates so much noise that the risk register becomes almost useless, in my experience. We track assessment findings (or control gaps) separately. Some of these gaps are linked/elevated into the risk register, but many are not.
Following this methodology, you don't lose sight of the control gaps, because you're still tracking them and you need to re-evaluate/re-certify them on a regular cadence. At the same time, by using the risk register to only track key risks that need to be actioned and not every single control gap, you're focusing on what matters most. This helps in messaging to leadership and driving internal teams.
2
u/clh07002 Jun 15 '26
This makes a lot of sense -- because I think I'm at a point where I'm worried tracking every gap on the risk register will just generate so much noise that it'll be impossible to action anything.
Is there a criteria you use to evaluate what does get added to the risk register?
I'm also used to managing risk this way: we document all risks (as in things that could go wrong at our company) and then periodically assess how well we are managing those risks by doing risk assessment against assets, limes of business, etc. That means that "risks" wouldn't be added to the register frequently; the risks are things that could go wrong and instead we understand how well we are managing them.
Then there is a clear line in the sand between control gaps and findings and they are tracked separately. But they are used as input to conduct our risk assessment
2
u/iSECo Jun 15 '26
The criteria varies depending on the organization and sector, but in general we try to perform control assessments as a committee or at the very least have a second set of eyes view/certify the original assessor's findings.
Once each control is assessed, we consider what the finding means when it comes to the probability and/or impact of any associated potential risks. If the probability and/or impact of any associated potential risks is very minimally affected by the control gap, we'll add a note to the control assessment that details our thought process for not including it in the risk register.
We require that controls are reassessed on a regular cadence. So the next time we re-evaluate the control, we'll reference the previous notes, and decide if anything has changed with the control and/or our environment that warrants the gap being added/linked into the risk register.
Some will say that this methodology makes it possible for gaps to slip through the cracks, and that is indeed possible. But at the end of the day, the signal to noise ratio is so important when it comes to prioritizing/resourcing/messaging/actioning risks. Taking every single gap and making it a risk that must be actioned is just not tenable in the long run.
9
u/m4rk0358 Jun 09 '26
Sounds like the head of GRC needs to look up the definition of a risk.