Cybersecurity GRC Explained: NIS2 Legislates the ‘G’, Defines the ‘R’, and Leaves the ‘C’ to You

The most widely used cybersecurity framework in the world does not contain the word “compliance.” Not once. NIST’s Cybersecurity Framework 2.0 runs to 32 pages and six functions, and across the entire publication “compliance,” “conformance,” “certification,” “assurance” and “attestation” appear zero times. “Audit” appears once — in a list of the people the framework might be useful to [3].

That is a clue about how the three letters of GRC actually behave: they are not equal partners, and no regulation treats them as such. NIS2 is the clearest case in EU law. It legislates the G — Article 20 makes your management body approve your security measures and exposes its members to liability. It defines the R — Article 21(2) hands you ten measures and tells you what risk management must contain. And it leaves the C largely to you: across the Directive’s enacting terms, the phrases “at planned intervals,” “at least annually” and “internal audit” appear exactly zero times [1].

Here is which article lands on which letter, and what to do about the letter nobody specified.

Cybersecurity GRC, and the loop most programs break

GRC is one discipline, not three departments. OCEG, the body that coined the acronym as early as 2002, defines it as “the integrated collection of capabilities that enable an organization to reliably achieve objectives, address uncertainty, and act with integrity” [4]. Strip the abstraction away and each letter answers a different question:

• Governance — who decides, and who answers for the decision?
• Risk — what could go wrong, how much of that do we accept, and what do we do about the rest?
• Compliance — how do we prove any of it to someone outside the room?

The word “integrated” carries the weight. GRC is a loop: governance sets risk appetite and authority; risk converts that appetite into decisions about specific controls; compliance converts those decisions into evidence; and the evidence returns to governance as oversight. Break any one arrow and you produce a recognisable failure. Governance without risk yields policies nobody ever tested against a real threat. Risk without compliance yields a register full of accepted risks nobody can evidence. Compliance without governance yields a folder of screenshots that no one with authority ever read — which is precisely what a supervisory authority uncovers when it asks who signed this off.

Practitioner definitions converge on the same shape — SANS frames governance as establishing “authority and accountability” and compliance as ensuring obligations “are consistently met” [5], TechTarget as handling the interdependencies of governance policy, enterprise risk management and regulatory compliance [6] — but neither mentions a single EU regulation. Whether NIS2 enters your loop at all, and how deeply, depends on what your organisation is.

Your organisation	Does NIS2 apply?	What changes in your GRC program
Essential entity (Article 3(1))	Yes	Article 20 governance duties plus the full Article 21 measure set. Supervision can be proactive under Article 32, including regular and ad hoc security audits.
Important entity (Article 3(2))	Yes	The same Article 20 and Article 21 duties. Supervision under Article 33 is ex post — triggered by evidence of an infringement, not routine.
One of the eleven categories in Article 1 of CIR 2024/2690 (DNS, TLD registry, cloud, data centre, CDN, MSP, MSSP, online marketplace, search engine, social network, trust service)	Yes, plus the Implementing Regulation	The only entities for which EU law actually specifies a compliance function: documented compliance monitoring and independent review.
Out of scope, but supplying an in-scope entity	Not directly	Your customer’s Article 21(2)(d) supply chain duty reaches you as contract clauses and security questionnaires.

Governance: the only letter NIS2 attaches personal liability to

Article 20 is two sentences long and it is the shortest route to understanding why NIS2 changed European security programs. Member States must ensure that the management bodies of essential and important entities “approve the cybersecurity risk-management measures taken by those entities in order to comply with Article 21, oversee its implementation and can be held liable for infringements by the entities of that Article” [1]. Paragraph 2 adds that members of those management bodies “are required to follow training” [1].

Read the verbs, because they are the design: approve, oversee, be held liable. Each is an act with a date and a name attached. “Approve” in particular converts governance from a posture into an artefact — you cannot evidence an approval that was never recorded. That is the mechanism worth internalising: liability attaches to the approval, so the record of the approval is the defence. A board that is genuinely engaged but never minutes its engagement stands, evidentially, where a board that never looked stands.

Note what Article 20 does not say. It names no chief information security officer, no security committee and no reporting line — those are choices you make and then have to justify. We compare three workable structures in our guide to Article 20 board governance models, and if you already run an IT governance framework, the question is which decisions you can fold into it and which four you cannot delegate.

The framework world moved the same way independently. When NIST published Cybersecurity Framework 2.0 in February 2024 it added GOVERN as a new function and placed it at the centre of the diagram, on the stated logic that GOVERN “informs how an organization will implement the other five Functions” [3]. GOVERN now spans six categories and 31 subcategories, covering organisational context, risk strategy, roles and responsibilities, policy, oversight and supply chain risk [3]. A European legislature and an American standards agency reached the same conclusion within fifteen months of each other.

Risk: the letter NIS2 writes for you

Most regulations require risk management and leave its content to you. NIS2 does the opposite.

Article 21(1) supplies the proportionality rule everyone quotes: measures must be “appropriate and proportionate technical, operational and organisational measures,” taking into account “the state-of-the-art and, where applicable, relevant European and international standards, as well as the cost of implementation,” with proportionality judged on your exposure to risk, your size, and the likelihood and severity of incidents [1]. That is what lets a 60-person managed service provider and a national grid operator both comply without doing the same things.

Article 21(2) then removes the discretion about scope. The measures must rest on an “all-hazards approach” and “shall include at least” the following ten [1]:

Article 21(2)	What it obliges
(a)	Policies on risk analysis and information system security
(b)	Incident handling
(c)	Business continuity — backup management, disaster recovery, crisis management
(d)	Supply chain security, including the security of direct suppliers and service providers
(e)	Security in acquisition, development and maintenance, including vulnerability handling and disclosure
(f)	Policies and procedures to assess the effectiveness of the risk-management measures
(g)	Basic cyber hygiene practices and cybersecurity training
(h)	Policies on cryptography and, where appropriate, encryption
(i)	Human resources security, access control policies and asset management
(j)	Multi-factor or continuous authentication, secured voice, video and text communications, and secured emergency communications

Two of those ten are quietly the bridge into the compliance letter. Point (f) demands procedures for assessing whether the measures work, and point (a) demands the risk-analysis policy itself. Neither is a control — both are meta-controls about knowing the state of your controls. Our full breakdown of the ten measures takes each one in turn, and the risk register structure behind Article 21(2)(a) covers how the outputs are recorded.

Then there is Article 21(4), which practitioners routinely under-read. An entity that “finds that it does not comply with the measures provided for in paragraph 2” must take “without undue delay, all necessary, appropriate and proportionate corrective measures” [1]. The trigger is your own discovery, and the sentence contains no risk-acceptance branch — the flexibility sits in “appropriate and proportionate,” not in a right to leave a known non-compliance open. This is why the R and C letters cannot be run as separate projects: the moment a compliance activity finds a gap, a legal clock starts on the risk side.

Compliance: the letter NIS2 leaves to you, with one expensive exception

Here is the finding that should change how you budget. Across everything the NIS2 Directive enacts — Articles 1 to 46 and the annexes, roughly 160,000 characters after the recitals end — the phrases “at planned intervals,” “at least annually,” “annually” and “internal audit” appear zero times [1]. The word “periodic” appears once, in Article 34(6), where it refers to periodic penalty payments [1].

The word “audit” does appear, 21 times. Every one of them sits in Article 32, Article 33 or Article 37 — supervision of essential entities, supervision of important entities, and mutual assistance between authorities [1]. Not one asks you to audit yourself. (We produced these counts by pulling the official text of both instruments from the EU Publications Office, splitting the recitals from the enacting text, and counting occurrences directly — you can reproduce them from the sources listed at the end.)

That architecture carries a price tag. Under Article 32, competent authorities may subject essential entities to “regular and targeted security audits carried out by an independent body or a competent authority” and to “ad hoc audits” — and the Directive provides that “the costs of such targeted security audit carried out by an independent body shall be paid by the audited entity, except in duly substantiated cases when the competent authority decides otherwise” [1]. For important entities, Article 33 is narrower: ex post supervision and targeted audits, without the “regular” and “ad hoc” categories [1]. We set the two regimes side by side in our guide to NIS2 supervisory measures.

Certification does not fill the gap either: Article 24(1) provides that Member States may require entities to use certified ICT products, services and processes [1] — a power granted to Member States, not an obligation landing on you unless your Member State exercises it. So for most essential and important entities, EU law specifies no internal audit function, no review frequency and no certification requirement. The compliance letter is yours to design.

The exception is Commission Implementing Regulation (EU) 2024/2690. It binds exactly eleven categories of entity — DNS service providers, TLD name registries, cloud computing providers, data centre providers, content delivery networks, managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers [2] — and its Annex is the only place in EU NIS2 law where a compliance function is actually described:

• Compliance monitoring, performed “at planned intervals and when significant incidents or significant changes to operations or risks occur” (Annex 2.2.3) [2]
• Independent review of the entity’s whole approach to network and information system security “including people, processes and technologies” (2.3.1) [2]
• Reviewers with “appropriate audit competence,” where internal reviewers “shall not be in the line of authority of the personnel of the area under review” — and, where the entity is too small to separate them, “alternative measures to guarantee the impartiality of the reviews” (2.3.2) [2]
• Results reported to the management bodies, where “corrective actions shall be taken or residual risk accepted according to the relevant entities’ risk acceptance criteria” (2.3.3) [2]

The phrase “at planned intervals” appears 30 times across that Annex [2]. What the Annex never does is say what the interval should be. And read 2.3.3 again — the review output goes to the management bodies. Even where EU law does define a compliance function, it hands the result straight back to the governance letter.

That yields the practical mechanism, and it holds whether or not the Implementing Regulation binds you: because no instrument names a number, the interval you document becomes the benchmark you are measured against. In practice, an authority reviewing your program after an incident has no statutory cadence to compare you with, so the comparison available to it is between the cadence you wrote down and the cadence you kept. Setting the interval, and recording why you chose it, is itself the control. Our guide to CIR 2024/2690 covers the Annex in full, and if you are choosing tooling to carry that evidence, we scored ten GRC platforms on Article 21 evidence and real pricing.

What this means for your role

The same directive produces four different first moves, because the three letters do not sit with the same person.

Role	Your first move	The failure mode to avoid
CISO / IT security manager	Map existing controls onto the ten Article 21(2) points and find which you cannot evidence. Point (f), assessing effectiveness, is usually the thinnest.	Treating Article 21 as a technical checklist. Points (a), (f) and (g) are management activities, and tooling will not close them.
Compliance officer	Write down the review interval nobody gave you, with your reasoning, and put it under change control.	Waiting for a mandated frequency. For most entities it does not exist, and the absence is not a deferral.
Board member / management body	Make the Article 20(1) approval a minuted decision with a date, a version reference and named attendees, and complete the Article 20(2) training.	Confusing being briefed with having approved. Only one of the two is an act the Directive names.
SME owner (in scope, no security function)	Use the Article 21(1) proportionality language deliberately: record your size, exposure and incident likelihood as the stated basis for each measure’s depth.	Buying an enterprise control set you cannot operate. An unmet documented control is worse evidence than a proportionate one.

A GRC gap analysis you can run this week

Six artefacts carry most of the evidentiary weight across the three letters. The effort ratings below are practitioner estimates for a mid-sized entity starting from a functioning IT operation, not figures drawn from the Directive — treat them as planning heuristics rather than benchmarks.

Artefact	Required state	Effort to close
Minuted management-body approval (G)	A dated resolution approving a specific version of the measures, per Article 20(1)	Low — one meeting, if the measures already exist
Management-body training record (G)	Evidence that members completed training, per Article 20(2)	Low
Risk register aligned to Article 21(2)(a) (R)	Risks, treatment decisions, owners and acceptance criteria, all traceable	Medium
Effectiveness-assessment procedure (R/C)	A documented method for testing whether measures work, per Article 21(2)(f)	Medium — most programs have testing but no method statement
Documented review interval (C)	A stated cadence with recorded reasoning, and a trigger for significant change	Low — and the highest return of anything on this list
Independent review capability (C)	Reviewers outside the line of authority of the area reviewed; mandatory for CIR entities under Annex 2.3.2	High for a small entity — the impartiality requirement, not the review itself, is the hard part

If you want a broader sequencing view, our NIS2 compliance checklist walks the whole programme step by step.

Frequently asked questions

Is cybersecurity GRC just a new name for compliance?
No — compliance is one third of it, and under NIS2 it is the third with the least legal definition. Governance carries the personal liability (Article 20) and risk management carries the prescribed content (Article 21(2)). A program that only does compliance produces evidence nobody authorised and risks nobody assessed.

Does NIS2 require us to buy a GRC platform?
No. The acronym “GRC” appears nowhere in either the Directive or Implementing Regulation (EU) 2024/2690 [1][2]. What the text requires is that decisions, measures and review results exist, are approved by the right people, and can be produced on request. A spreadsheet that survives scrutiny satisfies that; a platform nobody maintains does not.

How often does NIS2 require us to review our security measures?
For most entities, the Directive sets no frequency at all — the terms “annually” and “at planned intervals” do not appear in its enacting terms [1]. If you fall within the eleven categories in Article 1 of CIR 2024/2690, compliance monitoring and independent review must happen “at planned intervals” and on significant change or incident, but the Regulation leaves the interval itself to you [2].

Who owns GRC — the CISO or the board?
Under NIS2 the split is written into the text. Article 20(1) places the approval and oversight duty on the management body itself, and attaches liability for infringements of Article 21 to its members [1]. The CISO or equivalent typically operates the risk and compliance activity day to day, but the approving act sits with the management body. Our 12-month CISO programme guide covers how that division works month by month.

Sources

1. Directive (EU) 2022/2555 (NIS2) — EUR-Lex, Official Journal. Articles 20, 21, 24, 32, 33, 34 and 37. The term counts quoted above were produced by extracting the Directive’s enacting terms and counting occurrences directly.
2. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex, Official Journal. Article 1 (scope) and Annex points 2.2 and 2.3.
3. The NIST Cybersecurity Framework (CSF) 2.0 — NIST CSWP 29, 26 February 2024.
4. What is GRC (Governance, Risk, and Compliance)? — OCEG.
5. What Is GRC: A Practical Guide to Cybersecurity Governance, Risk, and Compliance — SANS Institute.
6. Governance, risk and compliance (GRC) — TechTarget.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.