František Nonnemann, a regulatory compliance and risk management expert, argues that compliance risk belongs in the same cycle, on the same scale and often under the same controls as every other risk a company runs. To show the cost of doing otherwise, he walks through a composite case: a bank with three separate incident-reporting systems, where a cyberattack goes unreported for half a day while staff work out whom to tell.
A compliance management system and a risk management process have a great deal in common. Viewed as a whole rather than in isolation, they can bring an organization a range of benefits and savings.
In the day-to-day operation of the compliance process, compliance professionals and others involved in it (first-line owners, other control functions) often become absorbed in operations and routine. Under the pressure of new regulations, regulatory interpretations, group policies to implement and the need to resolve audit findings and incidents, they tend to adjust existing compliance processes or add new ones.
A compliance process, both its design and its updates, should be based on a risk assessment. The risk in question is compliance risk: the risk that an organization’s operations fail to comply with legal requirements or voluntarily adopted commitments, such as a code of ethics or self-regulatory and professional standards. It also covers the risk that practices fail to comply with internal rules or that one internal rule conflicts with another.
In practice, however, compliance risk assessment is sometimes underestimated and treated merely as a formality. That is a pity, because the risk management process as a whole, as well as its component processes and measures, can be used to make the compliance process itself more effective and efficient. Let me illustrate this with a few examples.
Principles risk management already covers
Risk identification
Identification has to reflect internal and external conditions, changes, past incidents and failures, the effectiveness of existing controls, anticipated events (such as an expansion of the business model or new legislation) and so on. Identifying and assessing risks correctly requires not only working with data from various sources but also interviewing the people concerned, then consolidating all the information and assessing the risks on a single scale (the severity and potential impact of the risk against the organization’s risk appetite). It makes sense for an organization to handle the collection and updating of risks uniformly, using the same processes, methodology and risk scale, regardless of whether the risk is financial, ICT, reputational or compliance. This is more efficient for everyone, including business units, and ensures a consistent assessment and informed decision on the appropriate risk response.
Why is it important to assess risks consistently across the organization? Because the resulting assessment of their severity helps risk owners make objective decisions in the organization’s best interests.
Each control function can suffer from a certain degree of functional bias and tend to perceive its risks as the most serious ones. But when we put all risks on the same scale (using the same matrix to compare the likelihood of a risk materializing with its potential material, typically financial, impact), we may find that a potential €10,000 fine represents only a low level of risk in the context of the organization. The business owner may therefore reasonably decide to accept the risk after assessing the actual costs of the measures needed to reduce it within their business area.
Risk mitigation
Mitigation means putting measures and controls in place to lower unacceptable risk, and here the principles should be unified too: One measure can mitigate several risks (see the examples below), outputs should be assessed in the same way, and the control environment should be verified. When a compliance audit reviews the control environment in a specific area, it can also cover other measures in place at the same time (i.e. measures mitigating risks other than compliance), and its findings can provide assurance regarding those measures as well. Conversely, verification of the control environment, or a breach of limits set for a specific risk, can be a relevant input for compliance, leading to an amendment of an internal rule, a detailed review, staff training or a change to a process. The outputs of compliance audit can likewise provide a basis for reassessing and adjusting the control environment.
Evidence and documentation
If it is not documented, it did not happen. The risk management process in general (risk identification, risk assessment, decisions on mitigation and the controls in place) must be documented. The same applies to each part of a compliance process.
The Most Radical Act a Compliance Officer Can Do? Delete a Pointless Control
Can AI help clean up the stench of sclerotic compliance?
Read moreDetailsProcesses that mitigate several risks at once
Let me also give three specific examples of processes, mitigating measures and tools that can usually be used jointly across an organization to mitigate a variety of risks, including compliance risks.
Incidents
Several regulations may oblige an organization to handle incidents, whether cybersecurity incidents, operational incidents affecting the provision of services, data breaches affecting personal data or others. Any failure to do so is therefore a compliance risk. At the same time, it is in the organization’s own interest to address security and operational risks beyond what any applicable regulation requires. It therefore makes sense to unify the processes for handling incidents of different kinds and levels of impact as far as possible. This not only improves efficiency but also reduces the risk that an incident is assessed and handled inadequately, for example, treated purely as an operational incident and resolved operationally while the organization overlooks the legal implications and obligations (such as notifying affected persons, regulators, contractual partners, etc.).
The following is a fictionalized example based on real-world experience: Bank X had established a process for managing operational incidents and IT outages. It had defined the internal channel through which incidents should be reported, who was responsible for the initial response to an alert (IT operations), how the incident response team was composed and which matrix was used to assess the severity of incidents.
Then GDPR came, with its requirements for managing personal data breaches. The bank created a new process, a new channel for reporting incidents (a different email address), a different person responsible for the initial response (data protection officer) and different criteria for assessing the severity of an incident.
And then came DORA. The bank created a third process for managing, reporting and assessing ICT-related incidents under the direction of the newly appointed chief information security officer.
Three different channels for reporting an incident, three different functions responsible for the first response, three differently composed response teams, three different sets of criteria for assessing and escalating an incident, three different internal policies and one confusing training program.
What happened next?
One day, the employees could no longer access the application used to approve loan applications. Before they could work out who they were supposed to report the incident to and how, half of the working day had passed. Because the outage was caused by a cyberattack, the hacker had gained additional time to extract even more customer data. The siloed processes had therefore contributed to a more serious incident, a higher fine and greater reputational damage for the bank.
Bank X learned from the experience and introduced the following key measures to prevent a similar situation from recurring. It established a single reporting channel for all types of incidents (security, operational and data-related incidents), designated one team responsible for the initial response to all of them and defined how incidents should be handled, including which steps are common to all incidents, which differ depending on their nature and which functions should be involved.
Third parties
It is in an organization’s own interest to manage risks connected to third parties (vendors, business partners), to screen them before entering into a relationship, assess the risks the relationship carries, keep a register of them, review them on an ongoing basis according to their risk level and adjust the rights and obligations in the contract based on the risks identified. These obligations are again imposed by various regulations, from AML rules through cybersecurity legislation to data protection regulation and specific outsourcing rules in some sectors (for example, financial services). A single process covering the selection, screening, risk assessment and contracting of a third party, and addressing the organization’s legal, operational, security, technical and commercial requirements alike, can therefore mitigate a number of risks.
Internal reporting channel
Internal control systems, such as the compliance management system, the risk management system and others, should as standard include a tool through which employees and other affected parties can report problems: New risks, an ineffective control, but also a new compliance issue or a suspected breach of rules or ethical values. Besides supporting the continuous improvement of control systems and the early identification of problems, such a tool or communication channel can also ensure that specific legal obligations on whistleblowing are met and so again contribute to managing and reducing the compliance risks the organization faces.
Compliance risk needs the same cycle as any other risk
The compliance management system is a subset of risk management. Responsible employees must first identify a specific category of risks, assess their severity, decide how to mitigate them and check whether the measures and controls in place are working. Many of the principles and procedures of risk management, both at the general level and at the level of individual measures and tools, can be used for addressing compliance risks as well. Beyond efficiency and savings in time and cost, this can also yield new qualitative findings (new risks, ineffective controls), which overall make the organization’s operations safer and more resilient.
František Nonnemann is a senior regulatory compliance and risk management expert with over 20 years of experience across banking, fintech and regulatory authorities. He works with organizations to build, implement, operate, and continuously improve compliance and risk management frameworks, combining regulatory expertise, technology and operational experience across financial regulation, AI governance, cybersecurity, risk management and data protection. 
