Why GRC exists only on paper in many German companies
Because while Governance, Risk, and Compliance functions often exist organizationally, they are rarely consistently anchored in actual processes. These three functions operate in silos, responsibilities do not overlap, and this usually only becomes apparent when an audit, a regulatory inspection, or a security incident occurs. GRC expert Volker Bannasch illustrated this in a webinar with intellior, using numerous real-world examples ranging from small businesses to critical infrastructure (KRITIS) corporations.
This article summarizes his key insights.
What does GRC actually mean?
GRC stands for Governance, Risk, and Compliance and describes an integrated approach to corporate management. Governance sets the framework, risk management identifies and assesses risks, and compliance ensures that internal and external requirements are met.
Important for SMEs: GRC is not an end in itself for legal compliance. A standalone GRC organization is not mandatory in the same way for every company. The scope and structure depend heavily on company size, industry, risk profile, and the regulatory environment. Smaller companies often combine these roles within executive management. The true purpose is self-protection: safeguarding the business while simultaneously working more efficiently.
The starting point: present, but not practiced
A live poll during our webinar revealed a typical picture: 54% of participants work in GRC or are currently expanding it, 62% already work in a process-oriented manner, and 69% have a BPM team. Nevertheless, GRC often remains purely theoretical.
The consequences are always similar:
- Unclear accountability: When an external audit is approaching, no one gets particularly nervous until the question "Who is actually responsible?" remains unanswered.
- Documentation without impact: A lot of paperwork is generated that hardly anyone in practice actually reads or lives by.
- The tool fallacy: "We have a tool, so we are secure" – a misconception that masks real gaps.
Three practical examples from the perspective of GRC, BPM, and IT security
From a GRC perspective governance often acts as a stand-alone function that no one truly understands. Instead of an isolated control loop, what is needed is coordinated communication with departments and the board, ideally automated through processes.
From a BPM perspective process management documents workflows, but whether these are actually followed is another matter. Risks and controls belong directly within the process, exactly where a risk could arise.
In the event of an information security incident the gap becomes most apparent: cyber insurance can cushion financial consequences, but it does not replace functional emergency processes or operational capability in an emergency.
Success factor: BPM as the link to GRC
For GRC to be effective, process management and compliance must work together. In concrete terms, this means: risks and controls are assigned at the task level, methods and guidelines are aligned with GRC, and management provides the necessary attention and budget. A Business Impact Analysis (BIA) identifies business-critical processes. This is the foundation for effective Business Continuity Management (BCM), which is now also required by regulations such as NIS-2 and required by the BSI.
The key is not to manage risks in isolated registers, but to make them visible where they originate: directly within the process. Risks do not exist independently of workflows; they arise within them. Managing them separately leads to a loss of connection with operational reality: employees may know the process steps but fail to see the associated risks, while risk managers may know the risks but not always their specific impact on the workflow. Only by linking them directly can you create transparency regarding where errors, violations, or security incidents might occur and which controls can prevent or mitigate them. This transforms risk management from a mere documentation task into an active component of process control—a connection that regulatory requirements in information security, data protection, and BCM increasingly demand as verifiable proof of effectiveness.
The Orchestra: A Metaphor for Living GRC
Bannasch’s central metaphor: A company is like an orchestra. Every section plays its own instrument, but only the conductor, with a view of the whole, creates harmony.
"I cannot play the first violin if the other violins are not in harmony with me." – Volker Bannasch, BPM Consultant, GRC Practitioner, and Managing Director of ViaConsilium GmbH, LinkedIn
In an orchestra, mastering your own part is not enough to ensure a coherent result—coordination is everything.
Risk Management vs. Internal Control System (ICS)
The two complement each other but operate at different levels:
- Risk Management is strategically and long-term oriented. It protects corporate objectives.
- The ICS is operationally oriented and integrates controls into processes down to the task level. It is generally linked to governance and forms the interface between GRC, BPM, and the specialist departments.
Implementing GRC in practice
According to Bannasch, pure stand-alone GRC software is of little use unless it is linked to processes. He only sees an advantage if a dedicated tool covers specific technical requirements that other systems do not provide. Even then, however, the interfaces are crucial, as is ensuring they do not create more problems than they solve.
Bannasch is familiar with the typical scenario from practice: importing data from a process suite into a separate GRC tool does not work cleanly. The result is additional effort that ripples throughout the entire organization. The BPM team has to make data readable in an additional format, and ultimately, the specialist department is expected to document content twice and in different ways. This creates friction and resentment that nobody needs.
A more sensible approach is one that brings risks, controls, processes, and responsibilities together in one place. This is exactly where Aeneis by intellior comes in: With the ICS / Risk Management app, risks can be documented, assessed, and linked to processes, systems, controls, and tasks. This creates an integrated overview of where risks occur, which controls are in place, and what measures follow as a result.
In addition, Aeneis supports the development of a process-oriented integrated management system. Management systems such as quality management, compliance, information security, crisis or emergency management, and risk management can be consolidated into a single, unified system. This turns scattered documentation into a transparent management system that is directly connected to the relevant processes.
Conclusion
GRC rarely fails due to a lack of good intentions. It fails because governance, risk, compliance, and process management often operate in silos within companies instead of looking at the same processes together. This can become a problem, especially with mission-critical processes: when responsibilities are unclear, risks are not visible within the workflow, and controls are not applied where they are needed, GRC remains nothing more than documentation.
Therefore, the key is not to introduce even more regulations, lists, or individual tools. The key is to make GRC effective where it matters, where work actually happens: within the processes. Only when risks, controls, responsibilities, and measures become visible in the context of a process does the transparency emerge that companies need for audits, regulatory requirements, and secure decision-making.
If you want to do more than just document GRC and instead effectively anchor it within your processes, try Aeneis or schedule a live demo. With our ROI calculator , you can also calculate in less than 60 seconds how much time, money, and resources you can save through efficient BPM and GRC with Aeneis.
Frequently Asked Questions:
Does every company need its own GRC organization?
No. Not every company requires a dedicated GRC department or an extensive GRC system. The scope should always align with the company's size, complexity, and regulatory environment. A small craft business has different requirements than an international corporation or a company in a highly regulated industry. However, this does not mean that small companies have no GRC issues: every company makes decisions, takes risks, and must comply with legal requirements. In smaller organizations, these tasks are often handled by management or individual executives. As a company grows, faces increasing regulatory demands, and undergoes digital transformation, a structured GRC organization becomes increasingly important—not because it is mandatory, but because transparency regarding risks and responsibilities becomes a decisive competitive factor.
Can one person be responsible for both GRC and BPM?
As a company grows, this is not recommended. At first glance, the combination seems logical because both areas are closely related, but in practice, they pursue different goals. BPM focuses on efficiency, automation, standardization, and the optimization of workflows. GRC critically examines these same processes for risks, compliance requirements, and control needs. This easily creates a conflict of interest: the person who optimized a process is also expected to independently audit it for risks and vulnerabilities. The necessary objectivity is often lost in the process. This aligns with the principle of segregation of duties, which is also central to internal audit, compliance, and information security. In small companies, such a separation is often not fully feasible organizationally. There, it is common for one person to hold multiple roles. However, as the company grows, process ownership and risk monitoring should at least be organizationally separated. BPM and GRC are not opposites; they complement each other. BPM ensures that processes function efficiently, while GRC ensures they remain compliant, secure, and manageable.
Should I outsource GRC and ISMS to an external service provider?
Outsourcing GRC or an ISMS only makes sense if you have a firm handle on it. An external service provider must cover the same scope of control as an internal solution, which tends to become more difficult as a company grows because additional functions, such as service management, must be integrated. This makes areas like data protection and information security more vulnerable. From his experience, Bannasch often sees a pattern where, with outsourced services, the left hand doesn't know what the right is doing, the client is barely involved, and complaint management reacts only rarely—and even then, quite helplessly. Outsourcing is therefore only recommended if the supposedly lower costs are genuinely lower than internal implementation and if the necessary control mechanisms are already in place within the company without creating new cost factors. For large corporations, there is the added factor that certain tasks simply cannot be outsourced because responsibility cannot be transferred to third parties. In these cases, you should avoid outsourcing.
