What is GRC? Governance, risk and compliance

GRC (governance, risk and compliance) is the approach that links three activities often carried out separately: setting rules and responsibilities, identifying and treating risks, and demonstrating that requirements are met. In cybersecurity, it lets the CISO and management steer security with shared, up-to-date information rather than scattered files. Here is what GRC covers, where it comes from, which frameworks it relies on and how to choose a GRC tool.

GRC in one sentence

GRC describes how an organisation directs itself (governance), anticipates what could stop it from reaching its objectives (risk) and follows the rules that apply to it (compliance), treating these three topics as a whole. The starting idea is simple: a management decision, a risk assessment and a compliance audit often concern the same asset, the same control or the same supplier. Running each in its own corner produces duplicates, blind spots and contradictory dashboards.

Where does the term GRC come from?

The term was popularised in the early 2000s by OCEG (Open Compliance and Ethics Group), a US professional association that says it formalised the concept in 2002. OCEG defines GRC as the integrated collection of capabilities that enable an organisation to "reliably achieve objectives, address uncertainty, and act with integrity". This definition has one merit: it reminds us that GRC serves the organisation's performance first, not just control.

Governance: who decides, under which rules

Governance sets the course. It defines security objectives, roles and responsibilities, decision bodies (security committee, risk committee) and the rules of the game, starting with the information security policy. It also sets the risk appetite: the level of risk management is willing to take to reach its objectives. The guide on controlling digital risk published by ANSSI (France's national cybersecurity agency) and AMRAE (the French association of risk managers) puts it plainly: digital risk must be handled at the highest level of the organisation.

Risk management: prioritising what matters

Risk management identifies what could harm the organisation's activities, estimates severity and likelihood, then decides on treatment: reduce, transfer, avoid or accept. In cybersecurity, it relies on a recognised method such as EBIOS Risk Manager, published by ANSSI, or ISO/IEC 27005. This is what turns a list of requirements into priorities: not all controls are equal, and risk analysis tells you which ones matter most to you.

Compliance: demonstrating that rules are applied

Compliance checks that the organisation meets the requirements that apply to it: laws and regulations (NIS 2, DORA, GDPR), standards it commits to (ISO 27001), contracts and internal rules. It is not just about ticking boxes: it must produce evidence, measure gaps and follow corrective actions through to closure.

Taken in isolation, each pillar works poorly. Governance without risk analysis decides blindly; risk analysis without compliance tracking remains a document; compliance without governance becomes a race from one audit to the next. GRC is a loop:

GRC was born in finance and audit, where it covers all of a company's risks: financial, legal, operational, reputational. This is enterprise GRC, often run by the risk or internal control function, with frameworks such as ISO 31000 for risk management or ISO 37301 for compliance management systems.

Cybersecurity GRC (or IT GRC) applies the same logic to information security. It is usually led by the CISO, and its objects are more concrete: information systems, data, suppliers, security controls.

The two meet: cyber risk is part of the company's risk map, and the CISO must be able to translate scenarios into the risk manager's language (financial impact, business impact). That is precisely what the ANSSI and AMRAE guide sets out to do.

A cybersecurity GRC approach relies on frameworks of different kinds: some are laws, others voluntary standards, others methods. Knowing them avoids treating them as separate projects, when they often require the same controls.

NIS 2 shows why GRC is becoming essential. The directive requires management bodies to approve cybersecurity risk management measures and to follow training, and provides for their liability in case of failure (Article 20). In France, its transposition was still before Parliament in autumn 2026, while ANSSI is already supporting the entities concerned. For more detail, read our article From NIS to NIS 2, and see how to track these requirements with compliance campaigns and a framework and policy editor.

GRC is not one person's job. It shares responsibilities between several players:

• Executive management sets the risk appetite, arbitrates budgets and, under NIS 2 and DORA, bears direct responsibility.
• The CISO organises security governance, runs risk assessments, writes the security policy and tracks compliance. In many SMEs and mid-sized companies, the CISO is the de facto GRC manager.
• The risk manager integrates cyber risk into the company's risk map and translates it into financial and business impacts.
• The DPO (data protection officer) oversees GDPR compliance and advises on data protection impact assessments (DPIA).
• The compliance officer tracks regulatory obligations, especially in regulated sectors (banking, insurance, healthcare).
• Internal audit independently checks that the system works.
• Business units know the value of their activities and data: without them, risk analysis remains theoretical.

To organise these roles, many organisations use the Three Lines Model of the Institute of Internal Auditors (IIA), updated in 2020: operational teams manage risk day to day (first line), risk, compliance and security functions provide expertise and challenge (second line), and internal audit provides independent assurance (third line). The CISO usually sits in the second line.

• Assess once, serve several frameworks. The same control (access management, backups, logging) meets ISO 27001, NIS 2, DORA and your security policy. Once linked, these frameworks no longer require four assessments.
• Prioritise investment. Risk analysis shows where each euro reduces risk most, instead of funding the most visible control.
• Give management a clear view. Risk level, compliance rate, action plan progress: indicators calculated from the same data.
• Prepare audits calmly. Evidence is attached to requirements as you go, not gathered the night before the audit.
• Control the supply chain. Suppliers are assessed against the same requirements as internal teams: this is third-party risk management.
• Earn the trust of customers and partners. An organisation that can demonstrate control of its risks answers security questionnaires and tenders faster.

There is no single recipe, but approaches that work often follow the same order:

1. Get a mandate from management: a sponsor, a scope, resources.
2. List the applicable requirements: laws, standards, contracts, internal rules.
3. Define roles and decision bodies (security committee, reviews).
4. Choose a risk assessment method and apply it first to the most critical scope.
5. Assess compliance gaps and attach existing evidence.
6. Build a single action plan, fed by risks and gaps, with owners and deadlines.
7. Measure and report at regular intervals, then start again.

Before choosing a tool, it helps to know where you start from. Maturity models, such as OCEG's or the staged grids used by consultancies, generally distinguish a reactive organisation from one that steers its risks with indicators. Find out where you stand in five questions:

Many organisations start their GRC in spreadsheets. That works while the scope is small; beyond that, the links between risks, requirements and actions break with every update, and preparing an audit becomes a consolidation project. GRC software then takes over. Here are the criteria that really matter; our GRC tools comparison guide covers them in depth with an interactive scoring grid:

Functional coverage

• Risk assessment using a recognised method: in France, an EBIOS RM module labelled by ANSSI guarantees fidelity to the method.
• A catalogue of frameworks (ISO 27001/27002, NIS 2, DORA, GDPR…) and the ability to add your own security policy.
• Mappings between frameworks, so the same control is not assessed twice.
• Compliance assessments with evidence, and access for auditors.
• Action plans with owners, deadlines and reminders.
• Third-party risk: questionnaires and supplier follow-up.

Fit and adoption

• Does the tool adapt to your methods, scales and risk libraries, or do you have to change everything?
• Can business contributors take part without heavy training?
• Can you import the history of your existing files?
• Can you start with one module and extend later?

Sovereignty and security requirements

• Where is the data hosted (your risk assessments are sensitive)? Is a SecNumCloud-qualified cloud option or an on-premise installation available?
• Are single sign-on (SAML, OAuth) and fine-grained role management supported?

As an example, Phinasoft is a French GRC platform dedicated to cybersecurity, with five modules sharing the same data: risk analysis (including an EBIOS RM module labelled by ANSSI, and ISO 27005), frameworks and security policies, compliance campaigns, vendor risk management and GDPR compliance. It can be hosted as European SaaS, in a French sovereign cloud with a SecNumCloud option, or on premise. The simplest way to judge a tool is still to see it on your own cases: that is what a demo is for.