First, I would suggest that estimating and understanding risk should be a shared activity (include developers, PMs, other stakeholders). While QA often understands a fair bit about some of the risk associated with software work, "scheduling risk" and other concerns that may not fall on QA should usually also be considered. Bringing in more roles will often also help to uncover additional risks that a single role may not think about or provide context around the impact if it occurs. When performing this exercise collaboratively or reviewing other roles' feedback it can be an opportunity for everyone to gain a deeper more complete understanding of areas of risk in the system you're all working in.
For the question you actually asked, I believe you're talking about what I've usually been exposed to as "Risk Analysis". When I've been involved in risk analysis we approach each proposed change to the system from the angle of...
- "What might go wrong" (direct and indirect to the change if its integrated with other modules, etc.)
- "How likely do we think these things are to go wrong" (this can be a gut feeling or backed by something more factual)
- "If those things do go wrong, what's the probable impact to customers of the software" (how many people will it effect, what will happen to them, for how long, etc.)
This can be more of a loose-feel conversation or you can attempt to quantify using estimates in a number range. Once you have an idea of what might go wrong and what's the biggest deal if it breaks, you can use this assessment to plan the scope of your regression testing to target areas of greatest risk.
Other than my answer, I'd highly recommend searching the internet for "Risk Based Testing". I think you'll find a lot more/better information than I can personally provide.