Risk management and compliance management are often considered different disciplines, but are they? At a minimum they should be close partners, both focused on achieving organisational objectives. Operating these two disciplines in silos can lead to missed opportunities for effective collaboration.
In Protecht’s recent Risk and compliance: Can’t we just be friends? webinar, we went through a practical approach to explore the intrinsic link between risk and compliance, and how a shift in perspective can unlock value.
We had great engagement as well as positive feedback from our attendees. We had a bunch of great questions, which we’ve answered below. Where appropriate they have been categorised or combined when they were on similar topics.
If you missed the webinar live, then you can view it on demand here:
Questions
For this webinar we've divided the audience questions up into macro-level topics. Follow the links below to review the questions on each topic:
Risk rating obligations
Linking risk and compliance
Who wears which hat?
Frameworks and governance
Controls
Compliance
The rest
Risk rating obligations
We have approximately 1000 obligations. Can you suggest an approach to assist with rating the risk for each obligation?
This may depend on the level at which you capture the obligations. An approach we recommend is to consolidate detailed obligations into broader obligations, and risk rate the obligations at that level. Protecht integrates with partners such as LexisNexis who provide libraries of detailed obligations which they consolidate into core obligations to streamline this process.
What are the parameters for risk rating of compliance obligations?
ISO 37301 on compliance management systems suggests likelihood and consequence, based on noncompliance. Some people get nervous about assessing likelihood, as they think it should be zero. Our approach to combining risk and compliance, and in particular our view that compliance risks are risks that could lead to noncompliance, shifts the likelihood equation to the related risks, rather than the obligation specifically. You’ll need to choose your own approach.
Compliance managers spend most of their time convincing management to have a consensus on the severity of risk. What should a compliance manager do to deal with such instances?
It may depend on the definition of severity. If it's about the impact or consequence, you may be able to rely on recent enforcement, information in industry and trends over time to highlight the potential impact if you are noncompliant. If the severity rating combines the likelihood of noncompliance (or risks that could result in noncompliance), some of those data sources may still apply. A pointed approach to questioning likelihood is to ensure they are assessing the likelihood of whether you are meeting obligations – not whether you are likely to get caught or be penalised
How do you differentiate levels of risk? Our compliance risks are traditionally more granular than a business unit risk or a board reported risk.
If you are using qualitative assessments such as risk matrices or overall risk ratings, you may have different risk criteria or levels for compliance than broader operational risk. An approach is to aggregate the more detailed assessments into broader compliance and risk reporting. We showed an example during the webinar of our Compliance Scorecard which provided information about key compliance themes.
Linking risk and compliance
Perhaps I misunderstood the section on mapping compliance and enterprise risk management, but wouldn't compliance risk management be a subset of ERM?
Can you please explain the difference between compliance management and compliance risk management?
Compliance risk management is a subset of operational risk, which is a subset of ERM. Compliance management is made up of all of the activities that support the management of compliance. This includes identifying obligations, developing processes and procedures in order to comply, and monitoring that we are complying. Compliance risk management is managing the risks that could lead to noncompliance. This often includes more focus earlier in the lifecycle of risk, where preventive measures can be put in place even if they are not controls needed to meet a specific compliance requirement.
How would an organisation with hundreds of compliance requirements deliver compliance risk management?
This is where the friendship comes together. I'd recommend starting from risks that you've already identified, and then linking them to relevant compliance obligations that you've documented (those that might be breached if the risk occurred). You could also look at your compliance obligations, and consider whether you have existing risks they map to. You may end up with some obligations that are not attached to material risks; this might mean the obligations are also not material (my personal bugbear was a documented compliance obligation to display business registration paperwork in a head office).
How do you achieve the peace in between the "R" and "C" when "C" thinks they are more important than "R" – also, the control attestation might be repeated in the risk?
One may think they are more important than the other, but can't we just be friends? Compliance has their dedicated focus, and risk will (or should be) covering all types of risk to the organisation whether they have a compliance component or not. As we did in the webinar, try and look at each other's perspective, review the objectives of each team, and see how you can work together to enhance both of those objectives together.
In particular, consider how you can you share information that supports each other’s objectives. If you are using a common control framework, hopefully those attestations can be shared to provide assurance for each of you.
Sometimes risk see compliance as one risk, i.e. regulatory risk. However, that risk is huge, i.e. it contains the whole of the regulatory handbook. But then, at a more granular level, Risk will sometimes capture a risk, on the risk register, that is a regulatory (compliance) risk/activity, e.g. miscommunicating with clients. Compliance will see that as a compliance risk, but risk will see it as another operational risk. And then confusion arises. How do we eliminate this?
You might be close to being on the same page! We see compliance risk and operational risk as the same thing. To use your example, I would expect 'miscommunicating with clients' to be an operational risk and the centre of a risk bow tie. If I was to build out the right-hand side (what objectives might be impacted by the miscommunication) that might include compliance breaches but could also include customer dissatisfaction, compensation to customers, loss of customers, etc, even if the miscommunication is not deemed to be a compliance breach.
Risk teams will need to aggregate all the risks to the organisation, so it does make sense that they will have a method to compare categories, perhaps using a risk taxonomy.
What is the difference between compliance assessment (assessing yes/no compliant) and the business line evaluating the effectiveness of the controls? Do we really need to evaluate control so many times by different departments?
Great question! In my view this is the difference between asking "Have we complied?" And "Are we likely to continue to comply?" Take for example, requirements to assess criteria for a customer when applying for a product. You can review historical applications to see if they met the compliance criteria, but this only tells you whether it happened in the past. If you check the design and operation of controls (procedures being applied, automated processes etc), this provides some assurance over whether you will continue to comply with the obligation. WHY were those historical applications compliant?
You may need to do both (assess compliance as well as controls over risks that may result in noncompliance), but co-ordination between teams over these assurance activities should minimise duplication or inefficiencies. It is why we recommend teams use enterprise risk tools and a common controls framework.
Who wears which hat?
What are the pros and cons of having people working in a combined risk and compliance role?
Any balancing hacks for wearing both risk and compliance hats?
I assume the first question is about individuals, rather than distinct roles working in a team. Here are a quick list of pros and cons.
Pros:
- Better able to use common tools. Separate roles may want to 'patch protect' or move to the beat of their own drum when collaboration on common processes or tools would improve outcomes
- May have stronger awareness of the relationship between risk and compliance
- Likely to have awareness of controls / processes that serve both compliance and risk functions
- Potential for streamlined processes if they can engage the frontline on risk and compliance activities at the same time
- May introduce some cost efficiencies
Cons:
- More likely to be reactionary driven. Compliance often has a more immediate operational need, which might impact on ability to focus on longer term objectives of the risk side of the function
- They are different skillsets and focuses. While compliance is more rules-based, risk is about making decisions under uncertainty. They may feel conflicted in some scenarios.
- By covering both, they may have less specialisation and depth of knowledge and expertise.
Having cut my teeth in a role that covered both, I would recommend they are separate. One challenge I faced was people assuming that risks and compliance are the same. If you do wear both hats, try and ensure during your communication with others they understand the distinction, and which hat you might be wearing in that interaction.
Always bring it back to how you are going to help them achieve their objectives.
Where within the organisation would the two disciplines reside (compliance management & risk management)?
Should risk and compliance be headed differently in organisations or both under one roof?
The age-old question. There is no one right answer, and it will depend heavily on the structure of the organisation, as well as experience and capability of executives and leaders. Here are a few common structures:
- Chief Risk Officer and Chief Compliance Officer (or equivalent). These may report directly to the CEO with access to relevant board committees. This keeps them, and their departments, distinct from each other and enables independent oversight.
- Risk and compliance teams may report to a broader Governance or Corporate Services function, which might include other 'back office' or support functions like People & Culture, Business Continuity (if not directly part of the risk team), and legal functions. Leadership is important here; if they have limited experience in each of the disciplines, they need to understand the value in order to be able to champion them.
- Risk and compliance might both report to a Risk & Compliance Manager or equivalent. This can be effective if there are individual teams carrying out the day-to-day work, with a manager that understands their distinct roles and is able to champion for both effectively. If not handled well, there is a danger that one or the other (perhaps whichever the manager has more experience in) can dominate conversations at higher levels, which may impact motivation of the team who feels left out.
- Chief Risk Officer with risk and compliance teams reporting to them. This may be perceived that compliance is part of and incorporated into broader risk management. This can result in a balanced approach, but if there is a Compliance Manager it may also be beneficial to give them some access to the board or relevant committees.
- One or both may report to the CFO. This may influence the functions to have a bigger focus on financial risk or the financial impact of compliance breaches. This may be beneficial as it keeps the focus on financial stability, but may undermine focus on other objectives and reduce independence, particularly in relation to risk and compliance oversight of the finance function itself.
Whichever model is used, our key message is for the teams to collaborate and use common tools and processes in order to create efficiencies.
Who should conduct the compliance risk assessment? Is it business line when conducting its RCSA or it is compliance team or both?
Do you think compliance should be a separate function or embedded in operations?
The business is responsible for its compliance obligations, and good practice would be for them to understand their compliance risks; not someone else on their behalf. Depending on the size and structure of the organisation, there may be dedicated compliance specialists in Line 1, focused on the obligations related to their business unit activities.
Either way, responsibility to comply should sit the with first line. This may be supported by a Line 2 compliance function, who should be assessing whether the business is correctly applying the compliance management and compliance risk management framework, which may include challenging compliance risk assessments. They may act as facilitators for risk assessments with the First Line.
Of course, in practice there can be an expectation that this is the Line 2 compliance teams work. If you find yourself in this position – managing compliance obligations on behalf of the business – try and shift this back to the Line 1.
Frameworks and governance
When documenting a framework, what are your thoughts on having one risk and compliance management framework or do you think the frameworks need to be separate?
Do you think an organisation should have separate documents for the risk management framework (covering the ERP) and a subset document documenting the process and procedures for compliance (i.e. a compliance management framework)?
Like David and I needing our own rooms to live in even though we share a living space, the same for frameworks. They may reference each other and need to be aligned, but they do serve different purposes.
Where does compliance sit in 3 Lines of Defence and why is 3 Lines of Defence the most acceptable risk management governance structure?
I'll leave aside why the 3 Lines of Defence (IIA refer to this now as the 3 Lines model) is the most acceptable – that's a massive topic in and of itself which we’ll revisit in future.
Like risk, compliance is everyone's responsibility. People without compliance in their title need to ensure they comply with the obligations of society and those that bind the organisation. When it comes to more formal roles, it can be a combination of Line 2 and Line 1. A Line 2 role would typically include managing the compliance framework across the organisation, often including centralised recording of business obligations, translating them into business language, and implementing compliance processes such as attestations, breach management and independent assurance. Line 1 teams may have dedicated compliance resources that are aligned with the business unit, with a closer focus on controls and monitoring compliance within the business unit.
I work in internal audit, and I would like to see how this conversation could also include us. How can risk, compliance and internal audit work together more effectively?
Bring everything back to objectives. When completing their work, all three teams need to keep the organisations enterprise objectives in mind. While internal audit needs to maintain a level of independence from the risk and compliance teams as it should be assessing their effectiveness, determine when it might be appropriate to use information from those teams to support internal audits work. What are they concerned about, and why? This might drive a more dynamic internal audit program – but don't repeat work others have done if management are already aware of the issues.
Controls
Why would you not link risks to obligations and controls to the risks, not the controls directly to the obligations?
We allow for both. Some risks might lead to noncompliance, but would have a range of causes. In that scenario, it makes sense to attach the control the risk. In some cases, an obligation is to implement a specific control, and can be linked directly to the obligation. While I'd lean towards the 'risk view', it enables different perspectives for different roles.
Are KCIs a risk indicator or a performance indicator?
We collectively call these 'risk metrics' which includes Key Performance Indicators (effect on objectives), KRI's (monitoring risk during it's lifecycle) and Key Control Indicators (monitor controls over risks).
They are all related, but KPI is lagging, while the others are (in an ideal world) leading and indicators of future performance.
Who in the organisation makes the determination on the effectiveness of a control?
As always, this will be dependent on the organisation. In larger organisations, and especially in financial services, someone in Line 1 independent of the control operator would assess the design and operating effectiveness of the controls. In smaller organisations or with less mature frameworks, this might be a responsibility given to Line 2, but it still remains with Line 1 managers to ensure they are effective.
We cover this in-depth in our Controls Design and Assurance course.
Compliance
Would the compliance and risk management slide that begins with rules and goes onto obligations, plain English etc not start with objectives?
Good pick-up. We started with defining the rules that apply, which does shortcut a few steps. In our training on compliance management and compliance risk management we cover this more comprehensively, which includes considering the scope of your compliance framework. Assessing that scope includes considering objectives of the organisation, and the operating model that gives rise to the rules that apply.
We highlighted changes to regulation as part of the cycle, but you are absolutely right that changes to the strategy or operating model may also require revision of the rules that apply.
I sometimes just find it hard to distinguish between compliance and obligation.
My shorthand is that the obligation is what you need to meet. Compliance means that you are meeting it. So noncompliance doesn’t change the obligation, it just means you aren’t meeting it.
Any tips on getting the compliance guys onboard and engaged?
I’ll assume you’re a risk guy! Without knowing your starting point, here are a few quick thoughts:
- See if you can use common tools, such as the way you capture controls, conduct control assurance, or use risk metrics.
- Demonstrate how risks often have a compliance component (maybe using a risk bow tie) as well as other impacts on business objectives, which might be a good reason to integrate your processes
- Develop some common ground on incidents and breaches, which might include sharing information or ideally considering them one and the same.
What have you found to be the biggest challenge/obstacle when talking to compliance staff about risk appetite?
The biggest challenge is explaining the difference between risk appetite for noncompliance, and an appetite for risks related to compliance. There shouldn’t be a threshold for which compliance breaches are accepted; they will always be actioned if they do. But you also need to acknowledge they can happen. If you do not accept that there is some chance of a compliance breach, quite simply you shouldn’t be undertaking the activity that gives rise to the obligation. Obviously that is not a practical approach.
The rest
Future of risk and compliance with AI surge?
A much bigger question than I can answer in depth here. If you haven’t already, you can view our webinar on AI from earlier this year. A few quick comments:
- AI can streamline the plain language interpretation of obligations (with appropriate human review right now)
- AI can recommend controls or risk metrics that may be applicable to risks and compliance, and may be able to provide automation on control assurance
- With access to the right data, AI tools will be able to provide more insights into risk profiles, risk drivers
These will require human review and intervention, but I think the end result is richer and more timely information about risks, more efficient processes for risk and compliance teams, and better information for decision makers.
Do you recommend a single source of risk and compliance incidents/events/issues so that there is less duplication, easier internal/external reporting and to help with trend analysis?
How are incident management and breach management done differently? When data breach occurs, both risk and compliance have to come in. What are the differences in terms of objectives and actions of the two units.
When an incident causes cost or a reputational loss, how is risk vs compliance responsibility assessed?
I recommend combining incident and breach management. From an ERM perspective, incidents are risk events that have occurred and impacted on objectives. This may or may not include the objective to comply (which we assume all organisations have). I recommend capturing them in one incident register, with triggers for review by the compliance team if they are a possible breach. This reduces duplication of incidents, and they can easily be filtered if specific teams only need to see specific information. Line 1 should be responsible for managing incidents, including conducting root cause analysis, with oversight from the Line 2 risk team. Compliance teams may need to conduct specific breach assessments, which may include external reporting to a regulator depending on your sector.
I also recommend using the same data and processes for issues and actions. In Protecht ERM, actions can be linked to deficient controls after control testing, incidents if control gaps or inadequate processes are identified, compliance attestations that are negative, or risk metrics beyond thresholds. This enables one complete view of all actions to reduce duplication, while being able to report on the specific drivers of action.
How do you ensure that compliance does not hinder profitability if you are operating in a highly regulated environment?
If you are highly regulated, I’d assume that noncompliance is more costly! Of course, formal compliance management needs to be practical. There is likely to be a trade-off between the effort of compliance activities including assurance, and the likelihood of incidents that result in noncompliance. Look for ways to optimise compliance processes where possible while meeting your compliance objectives.
Here is a twist; can your compliance teams provide advice to the business on how to structure their operations to pursue opportunities they might otherwise be afraid of? I’ve witnessed some practices which had ‘always been done that way’ which were more cautious than they needed to be. Once people had a better understanding of the rules, customers they had been turning away were able to be accepted.
Struggling to differentiate between risk appetite and tolerance and how to practically implement the two aspects.
We consider risk appetite to be the qualitative component, and tolerance to be a quantitative measure over a specific type of risk or component of risk. For compliance, this might include a qualitative statement that there is no appetite for intentional noncompliance, with an acknowledgment that compliance breaches may still occur despite best efforts. In those cases, the breaches will be investigated and rectified. This can be supported by tolerance of 0 incidents, meaning that any number greater than it prompts action.
We are a small organisation with no budget for ERM software. How can we begin incorporating ERM concepts and practices that are useful and not overburdensome and will provide actionable insight as we work toward our strategic goals?
Enterprise Risk Management is a concept – software just supports it. It sounds like you are on the journey already, but the biggest piece of advice if you are looking to make sure it is ‘Enterprise’ Risk Management is to link to those strategic goals and objectives.
Our Enterprise Risk Management – Bringing It To Life course might be of interest.
Conclusions and next steps for your organisation
If you missed this webinar live, Protecht’s Chief Research & Content Officer David Tattam and Research & Content Lead Michael Howell went through a practical approach to explore the intrinsic link between risk and compliance, and how a shift in perspective can unlock value. You can view it on demand here: