The three letters
| Letter | Discipline | Core question | Typical ownership |
|---|---|---|---|
| G | Governance | Who decides what, under which rules, and who oversees it? | management board, supervisory board |
| R | Risk | Which events threaten our objectives, and how do we steer them? | risk management, business units |
| C | Compliance | Which rules apply, and how do we evidence that we follow them? | compliance function, legal |
Each of these disciplines has existed on its own for a long time. The collective term GRC emerged in the early 2000s from the observation that running them separately creates the same work several times over.
The problem GRC solves
A mid-sized company with ISO 27001, the GDPR and customer requirements from supplier audits typically maintains three worlds: a control matrix in the management system, a record of processing activities in data protection, and one spreadsheet per customer audit. The same access control appears in all three: in three wordings, with three states of evidence and three owners.
The GRC approach inverts that:
- One inventory base: assets, processes, systems and suppliers, each recorded once.
- One control catalogue: every control exists exactly once, with an owner and a frequency.
- Multiple mapping: the same control satisfies requirements from ISO 27001, the GDPR and a customer contract at the same time.
- One body of evidence: the record is produced once and used in every report.
The benefit lies less in the initial setup than in every further framework: the second framework costs considerably less than the first, because most of the controls already exist and only need to be mapped.
GRC in the German context
In Germany, the governance part is formalised for listed companies: the German Corporate Governance Code contains recommendations, and the management board and supervisory board issue an annual declaration of conformity with them under § 161 AktG. For unlisted companies there is no comparable codification. There, the governance requirement follows from the general duties of care of the management body.
Responsibilities are usually described using the three-lines model:
- First line. The business units that take risks and execute controls.
- Second line. Risk management, compliance and information security; they set requirements and monitor adherence to them.
- Third line. Internal audit, which reviews independently and reports to the supervisory body.
The most common design flaw in mid-sized companies is mixing the first and second lines: whoever executes a control cannot independently judge whether it works.
What GRC tools actually have to do
The market ranges from document repositories with workflow to platforms with their own data model. Four questions are worth asking during an evaluation:
- Mapping. Can one control be assigned to several requirements without copying it?
- Evidence. Does the record arise inside the system, or is it uploaded afterwards?
- Own frameworks. Can customer requirements be modelled as a framework of their own?
- Reporting. Does a report come out that management and external auditors accept?
Tools that only manage documents move the problem rather than solving it: the duplicate maintenance remains, it just happens in a different folder.
Where the boundaries lie
GRC is not a standard, and there is no certification for it. It is an organisational model that connects existing systems: the compliance management system, the internal control system and risk management. Anyone building one of them from scratch should think about the data models together from the start. Merging them afterwards is regularly more expensive than an integrated build.