GV.OC (Organizational Context) is the first category of the Govern function in the NIST Cybersecurity Framework 2.0. For companies preparing for NIS2, it is the step everything else depends on. This article explains why, sets out its five outcomes, and links them to the governance obligations of GEO 155/2024.
Why security often goes wrong at the first step
Companies invest heavily in technical security — network protection, endpoint software, security event monitoring — and still remain exposed or fail compliance audits. The reason is usually the same: they skipped the foundation and bought technology before answering the simplest question, what are we protecting, and why? It is like fitting an expensive alarm to a house without knowing which room holds the valuables or where someone could get in.
NIST CSF 2.0 calls that foundation GV.OC. For organisations preparing for NIS2, it is where the work starts.
What GV.OC is
Put simply: understand the real context of the organisation before taking any cybersecurity decision. Before buying solutions or writing policies, answer these questions:
- What do we do, and what is critical for the business to survive and grow?
- Who depends on us, and whom do we depend on?
- What do customers, suppliers, investors and authorities expect from us on security?
- What legal and contractual obligations do we have?
It is called the foundation because the other functions of the framework — Identify, Protect, Detect, Respond, Recover — only make sense against this context. Without it, each technical measure is a tick on a list nobody understands and nobody can defend to an auditor.
The five GV.OC outcomes
GV.OC-01 — The organisational mission informs cybersecurity risk management
Cyber risk is prioritised according to what the business actually does.
Take an automotive parts plant. Its real mission is not “making parts” but delivering defect-free components on time to manufacturers working just-in-time. An attack that stops the line for 48 hours is not a technical incident; it is a contractual penalty and possibly a lost customer. That changes the order of security priorities.
GV.OC-02 — Internal and external stakeholders, and their expectations, are understood
You need to know who has a stake in your security and what they expect.
For an IT services provider: corporate customers (who may require certifications by contract), DNSC as the supervisory authority, employees, cloud hosting partners, cyber insurers and investors. Each expects something different, and the company has to know what before promising what it cannot deliver.
GV.OC-03 — Legal, regulatory and contractual requirements are understood and managed
The whole applicable framework: GEO 155/2024 (NIS2), the GDPR, and contract clauses with large customers that require ISO/IEC 27001 or equivalent.
A medical clinic processes health data (a special category under the GDPR), may fall under NIS2 through the health sector, and often has contracts with insurers or hospitals that impose security requirements. Three sources of obligations, which have to be inventoried together, not separately.
GV.OC-04 — Critical objectives, capabilities and services that others depend on are understood and communicated
If other organisations depend on you, you need to know which systems are critical and say so clearly.
An IT provider hosting the data of several clinics: an outage of its infrastructure affects dozens of practices at once. It has to know which services are critical, who depends on them and how it communicates during an incident.
GV.OC-05 — Outcomes, capabilities and services the organisation depends on are understood and communicated
The mirror image of GV.OC-04: what would stop you if it failed.
Cloud platforms, payment processors, telecom links, a single software vendor, a key subcontractor. For NIS2 this feeds directly into supply chain security, one of the measures Article 21 requires.
The link with GEO 155/2024 and management accountability
GEO 155/2024, approved by Law no. 124/2025, transposes NIS2 in Romania and puts strong emphasis on governance. Under Article 20 of the Directive, the management body approves the cybersecurity risk management measures, oversees their implementation, can be held liable for failures and must follow training. “IT is dealing with it” is no longer enough.
GV.OC is a structured way of meeting that expectation and showing it. When an auditor or DNSC asks how management set its security priorities, the GV.OC document is the answer. NIS2 does not require the NIST framework as such — ISO/IEC 27001 or the DNSC methodology can serve the same purpose — but whichever framework is used, the context has to come first. For a quick check of NIS2 applicability, the NIS2 checker is available in Romanian.
Common mistakes
- Starting with technology purchases
Solutions bought before anyone understands what needs protecting; investment without a structured view of priorities.
- Documentation copied from other companies
Policies taken from the internet or another firm, not adapted. An auditor notices at once.
- Management not genuinely involved
“IT will handle it” — the opposite of what NIS2 requires.
- Critical services and dependencies not identified
The company does not know what would stop it completely if it failed.
- External providers ignored
Cloud services, rented software, third parties processing data — often where the largest risk lies.
How to do it, step by step
- 1A working session with management
Chief executive, operations, finance and the person responsible for information security. Nothing else works without this step.
- 2Define the mission and critical objectives
From a cybersecurity perspective: what would hurt most if it were compromised.
- 3Map stakeholders and their expectations
Who depends on you and whom you depend on — customers, authorities, insurers, partners.
- 4Inventory legal and contractual obligations
NIS2 (GEO 155/2024), the GDPR, contract clauses, certification requirements (ISO/IEC 27001 where it applies).
- 5Identify critical services and dependencies
In both directions: what others rely on you for (GV.OC-04) and what you rely on — cloud, SaaS, partners (GV.OC-05).
- 6A short, clear document
Proportionate to the size of the company. Not a thick volume nobody reads.
- 7Review
Periodically, and on major change: mergers, new services, geographic expansion, new regulatory requirements.
Conclusion
GV.OC aligns the security programme with the reality of the business. Organisations that do it well end up with a programme that is relevant and defensible to auditors, customers and authorities; those that skip it tend to pay later, in solutions that do not fit, or in incidents and fines. For the full NIS2 picture in Romania, see NIS2 in Romania — scope, DNSC registration, fines.
Frequently asked questions
What is GV.OC in NIST CSF 2.0?
GV.OC, Organizational Context, is the first category of the Govern function in the NIST Cybersecurity Framework 2.0. It means understanding the organisation’s mission, stakeholders, legal and contractual obligations, the services others depend on and the services it depends on, before taking cybersecurity decisions. The other functions — Identify, Protect, Detect, Respond, Recover — are prioritised against it.
How does GV.OC relate to NIS2 and GEO 155/2024?
NIS2, transposed in Romania by GEO 155/2024 as approved by Law 124/2025, makes the management body responsible for approving and overseeing cybersecurity risk management measures. GV.OC is a structured way of meeting that expectation and showing how priorities were set. NIS2 does not require the NIST framework as such; it is one way of organising the work.
What are the GV.OC outcomes?
There are five: GV.OC-01, the mission informs cybersecurity risk management; GV.OC-02, internal and external stakeholders and their expectations are understood; GV.OC-03, legal, regulatory and contractual requirements, including privacy, are understood and managed; GV.OC-04, the critical objectives, capabilities and services that external stakeholders depend on are understood and communicated; GV.OC-05, the outcomes, capabilities and services the organisation itself depends on are understood and communicated.
What are the common mistakes?
Buying technology before knowing what needs protecting; documentation copied from other companies; management not genuinely involved; critical services and dependencies not identified; and external providers — cloud, SaaS, third parties processing data — left out, although that is often where the largest risk lies.