What is GRC? Governance, risk and compliance, run as one system

GRC stands for governance, risk and compliance, and a GRC framework runs those three as one connected system rather than three separate exercises. Governance sets direction and accountability, risk management works out what could stop you, and compliance proves you are meeting the rules that apply. In the EU, that description is incomplete. For regulated financial entities and organisations in NIS2 scope, GRC stopped being a management approach and became a legal structure with named accountability attached.

What follows covers the three parts, the order the work has to happen in, and what GRC looks like with no GRC team, which is most companies. Copla builds a compliance and risk management platform for EU regulated entities.

What GRC stands for: governance, risk and compliance

Governance, risk and compliance ran as three separate disciplines for decades before anyone bundled them into an acronym. GRC is the argument for connecting them, on the grounds that all three serve the same business objectives and get in each other’s way when managed apart. A control nobody governs, a risk nobody owns, and evidence nobody can locate produce compliance that exists on paper and nowhere else. Kept apart, GRC processes duplicate each other’s work and still leave gaps at the joins, which is where regulatory compliance usually fails.

Governance

Governance is the part of GRC that answers who decides, who is accountable, and how that gets written down.

In practice it covers setting direction and risk appetite, assigning roles so that work has an owner rather than a volunteer, approving policies, overseeing the people doing the work, and maintaining a reporting line that carries a problem upward before it becomes an incident. An escalation path that only functions when someone remembers it exists is not a reporting line, and a policy nobody has acknowledged is a draft.

If nobody can say who signed off on a decision, there is no governance, however many policies sit in the folder. Auditors and supervisors probe governance by asking for the approval, the date and the person, in that order. Documents are easy to produce. Decision trails are not.

Senior executives have to back a GRC strategy for implementation to work. A GRC programme that senior management treats as a compliance department project stalls at the first budget conversation, because nobody in the room can free up a system owner’s time.

Risk management

Risk management is the process of working out what could go wrong, how badly, how likely it is, who owns it, and what is being done about it.

Most organisations carry several categories at once: operational risk in the business processes that deliver the service, financial risk in liquidity and counterparties, legal, regulatory and compliance risk when a requirement is missed, strategic risk in the bets the business has already placed, and security or ICT risk in the systems everything else depends on. They interact. An ICT failure becomes an operational failure, then a regulatory one, usually within the same afternoon.

A register where everything is marked high has told leadership nothing. What separates a working register from a filled-in template is whether each entry traces back to something the business actually depends on. A risk register tool gives you structure, ownership and version history. The tracing is analytical work, and it stays yours. Effective risk management is judged on what changed as a result, and a risk assessment that changes no decision has produced nothing.

Compliance

Compliance is proving you meet the compliance requirements that apply to you: industry and government regulations, standards, and your own internal policies.

Being compliant and being able to evidence compliance are two different states, and only the second survives an audit. An organisation can have every control operating correctly and still fail a review, because the operation was never recorded in a form anyone outside the team can check. Supervisors work from records. Where the record is missing, the control did not happen.

Compliance also sits downstream of the other two and inherits whatever they produced. Where ownership is vague and the risk picture is guesswork, controls get written to satisfy the wording of a requirement rather than the risk behind it, which is how organisations end up certified and exposed at once. That gap is widest in compliance in cybersecurity. Cyber threats do not consult the control matrix, and cybersecurity GRC is judged on whether data security holds under pressure rather than on whether documentation is complete.

Where the term came from: OCEG and the GRC Capability Model

OCEG, originally the Open Compliance and Ethics Group, says it was using the acronym in the early 2000s, with the first peer-reviewed paper published in 2007 by founder Scott Mitchell. It emerged from the corporate governance failures of that period, and OCEG’s GRC Capability Model still defines the discipline as the capabilities that let an organisation reliably achieve objectives while addressing uncertainty.

The argument was that the three ran in separate silos, with separate tooling, separate reporting lines and no shared view of the same facts. It has aged well, which is not a compliment to the industry. The same control still appears in three programmes, still gets evidenced three times, and still nobody can say who owns it or when it was last tested.

In the EU, GRC is not a philosophy

For EU regulated financial entities, the governance layer of GRC is a legal requirement with a named owner: the management body.

Under DORA, Regulation (EU) 2022/2554, Article 5(2) makes the management body define, approve, oversee and take responsibility for implementing the ICT risk management framework. Article 5(4) requires those members to keep their knowledge current through training proportionate to the ICT risk managed.

NIS2, Directive (EU) 2022/2555, carries comparable accountability and reaches individuals. Article 20(1) requires Member States to ensure management bodies of essential and important entities approve the cybersecurity risk-management measures, oversee implementation, and can be held liable for infringements. Article 20(2) adds a training obligation on those members. For essential entities, Article 32(5)(b) lets authorities ask a court to temporarily bar a chief executive or legal representative from managerial functions until the deficiency is remedied. NIS2 is a Directive, so the liability mechanics vary by Member State.

Where an entity sits in both scopes, DORA takes precedence: Article 1(2) makes it the sector-specific act, so the ICT regulatory requirements are read from DORA. The five pillars of DORA and who NIS2 applies to set out each scope.

GRC becomes a structure you must have, must evidence, and must explain to a supervisor on request. The board cannot outsource its way out of it, and buying a platform is not an answer to the accountability question.

A small team can meet that bar, provided decisions are made by the right people, recorded when made, and retrievable on request. 

How a GRC framework actually works

A GRC framework is usually described as a set of parallel activities. It behaves more like a chain, and the order is what makes it hold.

Scope, then dependencies, then impact, then controls, then evidence. Each link is only as good as the one feeding it, and programmes fail at the joins more often than at the steps.

Implementing GRC follows the same order. Build on one business unit first, because a pilot surfaces gaps cheaply, then phase the rollout, since a GRC programme landing on all business units at once competes with the work it protects.

Know what applies to you

Everything starts with scope: which regulations, standards, internal policies and contractual compliance obligations apply, and to which parts of the business.

This is a legal and commercial judgment before it is a technical one. It turns on the licences held, the services provided, the jurisdictions operated in, headcount and turnover thresholds, and whether a customer contract has imported a standard you would not otherwise owe. Two payment institutions of identical size can land in different scope because one holds an extra authorisation.

Get scope wrong and the programme is precisely correct about the wrong things, which is an expensive way to allocate resources. Scope also moves. A new market, a new licence, a new product line or a change in the size-cap thresholds can pull an entity into a regime it sat outside last year, and a scheduled scope review is rare in the organisations that need one most.

Know what the business runs on

The second link is an inventory of what the organisation actually depends on: systems, data, vendors, and the processes that connect them.

You cannot assess what you have not inventoried, and a register built from memory misses exactly the dependencies nobody thinks about, which tend to be the ones that fail. The scheduling tool bought on a card that holds customer data. The subcontractor behind a provider you have assessed carefully.

Knowing that you use a provider is different from knowing which process stops when that provider does, and only the second is useful during an incident. This inventory is also what third party risk management runs on: you cannot rank a vendor’s criticality without knowing which process sits behind it. The inventory has a shelf life too, because procurement, offboarding and product changes all move it without announcing themselves.

Work out what failure costs

Business impact analysis determines which business processes are critical, what breaks when a dependency fails, how quickly, and what that costs the business and its customers.

It turns criticality from an instinct into an analysed judgment. Without it, teams mark vendors and systems critical by feel, and criticality is the switch that decides which contracts and which providers get the heavier regulatory treatment. The analysis also produces recovery targets that mean something: how long a process can be unavailable before the damage turns regulatory.

Organisations that run it come out of disruption better for an unglamorous reason: they already know which processes matter, who owns the decision and what the recovery order is. Operational resilience is largely that knowledge, held in advance. Business impact analysis is explicitly required under some regimes and optional under others, and it is worth doing either way, because every downstream risk assessment depends on it.

Apply controls where they reduce exposure

Internal controls belong in a programme because a risk justifies them, not because a compliance framework listed them.

Framework-first programmes implement the full control list at minimum depth and end up with uniform coverage of uneven risk. Starting from exposure instead produces heavier treatment in a few places and lighter treatment elsewhere. That version is also easier to defend, because a supervisor asking why a control looks the way it does wants the reasoning, not the checklist it came from.

Requirements overlap heavily. Access control, incident and event management, supplier oversight and business continuity appear in some form across ISO 27001, SOC 2, NIS2, DORA and PCI DSS. One control, operated once and evidenced once, can satisfy several requirements at the same time. Mapping that overlap is where the real work of mitigating risks across several regimes sits, and it is what makes a multi-framework programme survivable instead of additive.

Evidence it and report it

The last link attaches evidence to the control it proves and the requirement that control satisfies, then turns the result into reporting a board, an auditor and a supervisor can each read.

Evidence collected as work happens holds up, which is why collection belongs inside compliance processes rather than alongside them. Evidence reconstructed the week before an audit rarely does, because the timestamps tell the story regardless of the document. A folder of screenshots proves nothing if nobody can say which requirement each one answers.

Reporting is where GRC either pays for itself or reveals that the previous four links were never built. Management reports that cannot say which risks moved, which controls failed and what was done in response describe activity rather than position. Regulator-facing reporting is less forgiving, and the DORA ICT risk management framework assumes the underlying analysis exists and is current.

GRC when you do not have a GRC team

Most organisations that need GRC have no chief risk officer, no chief compliance officer, no CISO, no internal audit function and no board risk committee, and the obligations apply to them in full.

Nearly every explainer describes that org chart anyway. For a 60-person payment institution inside DORA scope, that org chart is one person who also owns vendor contracts and the questionnaire backlog, and got the compliance title because someone had to.

The regulation does not scale down. Proportionality affects how much depth is expected, not whether the obligation exists. What changes is how the work gets done, in four parts, none of which requires the compliance teams the explainers assume.

One accountable owner instead of a function, named in writing, with authority to make a call and access to escalate one. Governance documented rather than staffed: with no risk committee, a short standing meeting with real minutes produces the same record. Tooling that carries the collection, routing and chasing, so the owner is not the integration layer between departments. And expert judgment bought in where internal knowledge runs out.

The weakness of a one-owner model is that owners leave. Where the decisions are written down, the successor inherits a position rather than a rumour. None of which moves the accountability.

What GRC software does

GRC also names a software category, and it covers products that are not substitutes for each other.

GRC solutions fall into four groups: GRC platforms that automate evidence collection and control monitoring, enterprise risk management suites built around a staffed risk function, point tools that do one job well such as a register or an audit management workflow, and services with software attached. They compete for the same budget line while solving different problems, which is why category-level comparison disappoints.

What ties the four groups together is the job GRC software does: keep governance, risk and compliance moving as one system, so a decision, a risk score and the evidence behind it stay linked rather than rebuilt on request. In practice that means holding the requirement register, mapping controls to requirements, collecting evidence, assigning and chasing work, and handling risk data management and reporting.

The limits are equally consistent. Software cannot decide your scope. It cannot score your risk, because scoring is a judgment about your business and your tolerance for losing part of it. It carries the record and routes the work, which is most of the labour and none of the responsibility. Where GRC tools cut cost, the saving comes from control reuse across frameworks rather than from the software. Comparing GRC solution providers comes down to which links you need carried, and how much judgment comes with the software.

Copla runs on that same chain: one platform holding governance, risk and compliance together, with business impact analysis run before controls are chosen rather than after, so what gets built is sized to real exposure instead of a generic checklist.

Where a team hits the point internal knowledge runs out, a judgment call needing sign-off, or a supervisory question nobody has answered before, Copla’s CISO team works inside the same system as CISO-as-a-Service, so the accountable owner has expert backup rather than a blank page.

It is built for EU regulated financial entities and the wider regulated industries working under DORA, NIS2, ISO 27001, SOC 2 and PCI DSS.

Book a call

Scope, dependencies and evidence are the three places most GRC programmes turn out to be thinnest, and the three a board, an auditor and a regulator ask about first. Meeting those stakeholder expectations from one set of records is what turns reporting into something key stakeholders trust rather than re-check.

Copla cuts compliance workloads by up to 80%, and the saving comes from that reuse rather than from the software itself. Book a demo and we will walk through where yours stands and what GRC implementation would actually involve.