The legal team keeps a list of NIS2 requirements. The security team maintains a risk register, and IT a catalogue of policies and procedures. Each table is complete and up to date. When the board asks which controls meet the directive’s obligations and what risk remains despite them, the answer requires manually reconciling three spreadsheets, none of which refers to the others.
The industry has a name for the answer to this problem: GRC, or governance, risk and compliance. In cybersecurity it means combining governance, risk and compliance into one decision-making process, not buying another tool. Such a process rests on a shared register of requirements, risks and controls in which every decision has an owner.
What is GRC in cybersecurity?
GRC (governance, risk and compliance) is a set of capabilities that allows an organization to achieve its objectives, deal with uncertainty and act with integrity. That is how OCEG (Open Compliance and Ethics Group) defines GRC: the “integrated collection of capabilities that enable an organization to reliably achieve objectives, address uncertainty, and act with integrity”.
In cybersecurity the definition translates easily into practice. The objectives are service continuity and data protection, the uncertainty is the risk of an incident, and acting with integrity means complying with regulations and commitments to customers. GRC combines these three perspectives so that a single decision about a control answers both the question about risk and the question about a requirement.
OCEG adds a clear caveat: “GRC is not a technology. GRC is not a department”. GRC describes the people, processes, technology and information that together lead to the objective. A company can therefore buy a platform with “GRC” in its name and still not have GRC, or it can run a well-functioning process in a spreadsheet.
How do governance, risk and compliance differ?
Governance answers the question of who decides and who answers for the consequences, risk the question of what may prevent the organization from reaching its objectives, and compliance the question of what the company must observe and what it can prove. Each of these areas has its own tools and its own specialists, which is why they are so easy to separate.
Governance is the structure of decisions: who approves the security strategy, who accepts risk, who allocates the budget and how the board learns whether the plan is working. Risk management is the systematic identification, analysis, assessment and control of threats. Compliance means ensuring that the organization observes laws, industry regulations, standards and internal policies.
Backups illustrate the difference well. From the compliance perspective what matters is whether the procedure exists and meets the business continuity requirement. From the risk perspective it is whether the backups will allow a system to be restored within the time the company considers acceptable. From the governance perspective it is who signed off that acceptable time and who checks whether the restore test took place.
Why do separate governance, risk and compliance processes fail?
Separate processes usually fail for one reason: each optimizes its own measure. Compliance counts met requirements, risk management assesses threats and governance tracks the budget, and none of these measures shows whether the company is secure. The effects show up in three places.
The first is duplicated work. The same access control is often described separately for NIS2, for ISO 27001 and for a customer’s requirements, and each description has a different author and a different review date. The second is conflicting priorities. The compliance list calls for closing a formal gap, the risk register points to a more serious technical weakness, and the budget covers only one of them, yet nobody has the mandate to choose.
The third is scattered evidence. When an auditor or a supervisory authority asks for proof that a control works, the company searches for screenshots in several people’s mailboxes. Meanwhile Article 24 of the GDPR requires the controller not only to implement measures but also to be able to demonstrate compliance, and Article 21(2)(f) of NIS2 requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures (as of 15 November 2026).
How does NIST CSF 2.0 describe cybersecurity governance?
NIST Cybersecurity Framework 2.0 of 26 February 2024 describes governance as a separate GOVERN function, in which the organization’s cybersecurity risk management strategy, expectations and policy are established, communicated and monitored. Alongside it the framework lists five other functions: identify, protect, detect, respond and recover.
The document explicitly links governance with enterprise risk. According to NIST, governance activities are critical for incorporating cybersecurity into an organization’s broader enterprise risk management (ERM) strategy. The function covers organizational context, risk management strategy, roles and responsibilities, policy, oversight and cybersecurity supply chain risk management.
Three outcomes from this function show well what GRC means in practice. GV.OC-03 requires legal, regulatory and contractual requirements regarding cybersecurity to be understood and managed. GV.RM-03 includes cybersecurity risk management activities in enterprise risk management processes. GV.RR-01 states that organizational leadership is responsible and accountable for cybersecurity risk.
The CSF does not prescribe how to achieve these outcomes and is not a regulation. It does, however, provide a common language in which the security team, the compliance function and the board can describe the same process.
What do NIS2, the Polish KSC Act and DORA require of the board?
All three acts assign responsibility for cybersecurity risk management to senior management, not to the IT department (as of 15 November 2026). A board that is personally accountable needs one picture, not three unconnected spreadsheets.
Article 20(1) of the NIS2 directive requires management bodies of essential and important entities to approve cybersecurity risk-management measures, oversee their implementation and be liable for infringements of Article 21. Article 20(2) obliges members of those bodies to follow regular training that enables them to identify risks and assess risk-management practices.
In Poland, NIS2 is transposed by the Act of 23 January 2026 amending the Act on the National Cybersecurity System (Journal of Laws 2026, item 252), in force since 3 April 2026. Article 8c, added by it, provides that the head of an essential or important entity is responsible for the performance of cybersecurity obligations, also when they have been entrusted to another person with that person’s consent, and where the head is a collective body with no designated person, all its members are responsible. Article 8d lists what the head does: decides on the information security management system, plans financial resources, assigns tasks and oversees their execution, ensures staff awareness and ensures compliance with the law. Article 8e requires annual, documented training.
Article 5(2) of the DORA regulation requires the management body of a financial entity to define, approve and oversee the ICT risk management framework, and assigns it ultimate responsibility for that risk. The common denominator is simple: a risk decision has an owner at board level.
Key points:
- NIS2 (Article 20), the Polish KSC Act (Articles 8c–8e) and DORA (Article 5(2)) assign responsibility to senior management.
- Entrusting tasks to another person does not relieve the head of the entity of responsibility (Article 8c(3) of the KSC Act).
- The board needs a shared report on requirements, risks and controls, not three separate ones.
How does risk connect governance with compliance?
Risk connects governance with compliance, because it is the risk decision that turns a general requirement into a specific control. Regulations rarely say which tool to deploy. In the version in force on 15 November 2026, Article 8(1) of the Polish KSC Act requires an information security management system that ensures systematic risk estimation and measures proportionate to the estimated risk.
The requirement therefore says “appropriate to the risk”, and only the risk assessment says what that means in a given company. Governance identifies who approves that assessment and who signs off the risk that remains. Without this link, the compliance list turns into a shopping list and the risk register into a document nobody reads.
The risk treatment decision itself, the choice between acceptance, avoidance, mitigation and transfer, is the subject of the article on risk mitigation strategies. From the GRC perspective, what matters is that every such decision is recorded next to the requirement it concerns.
How do you build a single register of requirements, risks and controls?
A single register is built by mapping four elements in one row: the requirement, the risk, the control and the evidence that it works. This layout lets you answer both the auditor and the board at a glance.
The first step is a list of the requirements that apply to the company: regulations, standards it has committed to and contracts with customers. The second is assigning to each requirement the risks it concerns. The third is identifying the controls that reduce those risks and the owners of those controls. The fourth is the evidence: a test result, a report, a dated review record.
The biggest benefit comes from controls that meet many requirements at once. NIS2 names multi-factor authentication, vulnerability handling and backups explicitly in Article 21(2) (points (j), (e) and (c)), and the same controls can also meet GDPR and customer contract requirements. Described once, with one owner and one piece of evidence, they stop generating three separate tasks.
The register does not have to be perfect from day one. It is better to start with the requirements of one regulation and the most important risks, and then add further sources of requirements to existing controls, than to build a complete map that is never finished.
Who is responsible for GRC in an organization?
Senior management is responsible for GRC, in line with the provisions described in the section on board requirements (in NIST CSF 2.0 this is outcome GV.RR-01), and the other roles carry out and check the decisions it approves.
In practice the roles fall into several groups. The board approves the strategy, accepts high risk and allocates resources. Risk owners on the business side decide on risk treatment in their processes. The security team designs and maintains the controls. The compliance function tracks requirements and collects evidence, and internal audit independently checks whether the whole works.
The roles alone are not enough, because someone has to tie them together. This is usually the CISO or a person performing that function externally: they make sure the register is shared, reviews take place on time and the board receives a report it can make decisions from.
Is a platform needed for GRC?
A platform is not a precondition for GRC, because its basis is a process with decision owners, not a tool. A tool becomes necessary only when a spreadsheet can no longer keep up with the number of connections.
The signs that this moment has arrived are fairly clear. A single control has to be mapped to a dozen or more requirements from different sources. Evidence is collected by several teams and gets lost between file versions. The company has several subsidiaries or locations with different obligations. The board report requires data to be assembled by hand every time.
The order matters, though. First you decide who makes decisions, what a risk review looks like and what evidence is required, and only then do you choose a tool that reflects this process. A platform deployed before the process is defined preserves the mess in a more expensive form.
How do you assess the maturity of a GRC process?
The maturity of a GRC process is assessed by checking whether, in each area, decisions, risks and requirements are linked and whether there is evidence of it. The table below helps find the places where governance, risk and compliance still work separately.
| Area | Symptom of disconnection | Target state | Evidence for the auditor | First step |
|---|---|---|---|---|
| Accountability | nobody signs off risk decisions | designated head of entity and risk owners | resolution or decision on the allocation of roles | assigning an owner to every high risk |
| Requirements | the list of requirements lives in the legal team | one list of regulations, standards and contracts | register of requirements with a review date | listing the requirements of one regulation |
| Risk | risk register with no reference to requirements | every risk linked to a requirement and a control | register with a requirements column | adding a requirements column to the register |
| Controls | the same control described several times | one control, many requirements | map of controls to requirements | choosing five controls shared by the regulations |
| Evidence | screenshots in mailboxes | evidence kept with the control, dated | evidence repository | deciding what evidence confirms each control |
| Board training | a one-off presentation | annual, documented training | attendance list and programme | scheduling the training in the board’s calendar |
| Reporting | three reports for the board | one picture of requirements, risks and controls | minutes of meetings with decisions | a shared quarterly report template |
The table does not measure the level of security, only the coherence of the process. A company with many controls can score poorly on it if it cannot show who chose them and why.
How can nFlo help in the area of governance, risk and compliance?
In the area of governance, risk and compliance, nFlo helps link risk assessment with board decisions. The reviews, audits and consulting in the area of risk analysis service ends with a risk register with likelihood and financial impact ratings, a risk treatment plan with a cost-benefit analysis and a report for the board.
For organizations that want to put risk management in order across the whole company, nFlo runs projects aligned with ISO 31000: from a maturity assessment and defining risk appetite, through methodology and roles, to an enterprise risk register and indicators for the board. If you want to check how coherent governance, risk and compliance are in your organization, contact us.
What else is worth knowing about GRC?
Is GRC the same as compliance?
No. Compliance is one of the three elements of GRC. Governance defines who makes decisions and answers for their consequences, and risk management shows what may prevent the organization from reaching its objectives. GRC combines the three areas into one decision-making process.
Does GRC require buying a platform?
No. A tool makes it easier to map requirements, risks and controls when there are many of them, but it will not replace the decision about who owns the risk and how the process works.
Who in a company is responsible for GRC?
Ultimate responsibility lies with senior management. In entities covered by NIS2, Article 20 of the directive requires management bodies to approve cybersecurity risk-management measures and oversee them, and in Poland Article 8c of the Act on the National Cybersecurity System assigns responsibility to the head of the entity.
How is GRC different from enterprise risk management?
Enterprise risk management covers all types of risk a company faces, while GRC in cybersecurity links risk with governance and compliance. NIST CSF 2.0 calls for including cybersecurity risk-management activities in enterprise risk management processes.
Where should you start putting GRC in order?
With naming the person who signs off risk decisions and with a single list of the requirements that apply to the company. Only then is it worth assigning risks, controls and evidence of their effectiveness to that list.
