Cybersecurity strategy with role-based security training and NIS2 compliance

Cybersecurity strategie: security opleiding bedrijven als structurele risicoreductie (NIS2).

Why this is now relevant to the boardroom

As a member of senior management or CTO, you focus on continuity, growth, and reputation. In 2026, the bar by which you are judged will change. Not only by attackers, but also by legislation, chain partners, and insurers. This means that cybersecurity will no longer be seen as "operational IT hygiene," but as a management issue that directly affects liability, audit pressure, and contract terms in the chain.

The figures make this tangible. In 2024, 16% of the Dutch population reported having been victims of online crime, with scams and fraud being the largest category. This is described in the CBS Cybersecurity Monitor 2024: CBS – Cybersecurity Monitor 2024 (one page). This is relevant for organizations because it shows how broad the threat landscape has become and how often incidents have an impact beyond the IT department: from customer contact and reputation to financial damage and legal follow-up.

At the same time, only a limited number of companies are insured against cyber incidents (also found in the same CBS monitor). This underscores one point: a cybersecurity strategy that relies solely on tooling often misses the part that weighs most heavily in audits, incidents, and NIS2 discussions: human behavior, role clarity, and governance. In other words, you may appear to be "technically" in order, but still be vulnerable in terms of decision-making, escalation, chain coordination, and recoverability.

In this article, you will learn how security training is changing companies from "training" to a structural capability line. The goal is no longer knowledge for knowledge's sake, but demonstrably reducing risk, acting faster and more consistently under pressure, and making your NIS2 strategy concrete and defensible.

Context 2026: skills are growing, threats are growing faster

The range of cybersecurity training courses on offer is growing. However, aligning these courses with what organizations really need remains a challenge. This is because many programs focus primarily on individual certifications or theoretical breadth, while organizations actually need a coherent mix of roles, responsibilities, and practical preparedness. Especially in environments where IT, engineering, and business ownership are divided, risks arise precisely in the transfer between teams.

Security Delta (HSD) published research on the skills gap between education and the labor market in cybersecurity. This research shows that employers are not only looking for technical skills, but also competencies such as security advice, relationship management, analysis, product development, and incident management. Read the summary at: HSD – Overview: new research maps future skills gap. This is important because it makes it clear that "security skills" are not just about "managing tools," but also about advising, prioritizing, collaborating, and acting within governance frameworks.

For more details about the connection between education and the labor market, you can also consult the report by Cyberveilig Nederland: Cyberveilig Nederland – Research report on education and the cybersecurity labor market (PDF). Sources like these help to gain internal support: you can show that skills shortages and role fit are not just "opinions," but widely recognized in the market.

The core issue: within many companies, this mix of technology, advice, and incident response skills is fragmented across IT, development, risk, and operations. If you don't make this mix manageable, cyber security will remain a series of separate initiatives. You may have completed training, but you will see little effect in terms of incident duration, recoverability, audit results, and chain issues.

That's why security development doesn't belong "in HR," but at the core of your cybersecurity strategy. It should be part of how you manage risks, not just how you train people.

The core risk: tooling without legal capacity

Many organizations have MFA, endpoint tooling, SIEM/SOC services, and policies. These are valuable and often necessary, but they are not enough. The greatest risk often lies in behavior and organization: what happens when there is time pressure, information is incomplete, or multiple teams have to act at the same time? It is precisely at that moment that role clarity, escalation, decision-making, and collaboration determine the outcome.

In practice, this can be seen in, for example:

  • decisions under time pressure without a clear mandate
  • Unclear ownership in cloud, SaaS, and integrations
  • chain errors and assumptions about supplier responsibility
  • secure-by-design that starts too late, resulting in rework
  • incident response that is only tested when things go wrong

These are not abstract problems. These are precisely the reasons why incidents take longer to resolve, why communication is difficult, and why audits more often find "process issues" than purely technical shortcomings.

This is reflected in three patterns.

1. Security remains an "IT problem"

If security is solely the responsibility of IT, you lose control over purchasing, product choices, customer data, suppliers, and business impact. What's more, security often becomes a "controlling" function that only intervenes late in the process, while most risks arise from choices made at the beginning: architecture, supplier selection, data flows, and ownership. A mature cybersecurity strategy ensures that security is an organizational competency, not an IT task.

2. The skills gap is not only technical

HSD emphasizes the combination of technology, advice, and incident management. This means being able to translate risk into decision-making and collaborating effectively across departments. (See: HSD – skills gap researchAttachment.tiff). In many organizations, this is precisely the missing piece: they have engineers, but too few people who can prioritize risks, engage stakeholders, and manage incidents.

3. NIS2 enforces demonstrable accountability

In practice, an NIS2 strategy is not just about measures, but also about governance, duty of care, and being able to demonstrate that you are working structurally on resilience. This means that you not only have to "do," but also have to be able to show that you are in control of the process: who is responsible, how you improve, how you practice, and how you report. An NIS2 plan without a training program will quickly remain "paper," because you will not sufficiently ensure that behavior and decision-making within the organization change accordingly.

What security training provides companies for your cybersecurity strategy

Security training for companies is not awareness + e-learning. In a mature cybersecurity strategy, it is a management tool: you make capabilities plannable, measurable, and repeatable. That is the difference between "we have done training" and "we have demonstrably increased our preparedness."

In concrete terms, this delivers boardroom value:

1. Predictability in risk and costs

If knowledge is concentrated in the hands of a few, you will always pay the rush rate in the event of incidents and audits. Role-based training helps you build internal resilience and reduce escalations. It also prevents you from becoming dependent on external parties for every substantive decision, enabling you to respond more quickly and better manage priorities.

2. Faster delivery with less rework

Teams that work secure-by-design deliver more stable results: fewer late findings, fewer emergency patches, less friction at the end of projects. In practical terms, this means that engineers apply the right patterns earlier and that security reviews result in fewer "blocker discussions." This increases both speed and quality and reduces the total cost of changes.

3. Stronger position vis-à-vis customers and chain partners

Customers are increasingly demanding proof. An organization that masters security as a capability sells trust. In tenders and contract discussions, it helps if you can demonstrate that roles have been trained, incident response has been practiced, and chain agreements have been secured. This strengthens your position, especially in sectors with high dependence on suppliers and data.

From training to training strategy: 4 steps (making it manageable)

Controllable means that you can answer these questions:

  1. What risks do we mitigate with training?
  2. What roles need to be able to do what, at what level?
  3. How do we measure progress and impact?

If you cannot answer this question, training will remain a separate activity. It will be difficult to discuss budgets and priorities, and you will rarely achieve the desired impact on incidents and compliance.

Step 1: Link training directly to your cybersecurity strategy

Start with your critical processes and assets. Choose scenarios that you want to control (ransomware, data breach, supply chain, identity misuse). Translate each scenario into concrete actions that people must be able to carry out. Also consider decision moments: when do we escalate, who is allowed to isolate systems, who communicates externally, and what evidence do we need to record?

Step 2: Make roles explicit (role clusters)

The greatest benefit lies in role-based training. A developer needs different skills than a product owner, and a board member needs different decision-making skills than a SOC analyst. By using role clusters, you avoid training that is too generic and prevent people from dropping out because the content does not match their responsibilities.

  • Management/MT: governance, decision-making, crisis communication
  • CTO/architects/leads: secure design, threat modeling, cloud baselines
  • Developers/DevOps: secure coding, secrets, CI/CD security, logging
  • IT ops: hardening, patching, identity, backup recovery tests
  • Procurement/vendor: supplier risk, security requirements, chain agreements
  • Security team: incident management, use cases, threat hunting, advisory skills

This ties in with the competencies for which HSD sees the greatest demand: HSD – competency gap research. By stating this, you make it clearer internally that you are not doing "extras," but filling a demonstrably relevant gap.

Step 3: Practice behavior under pressure

Awareness without practice fades away. Practicing means running through scenarios, making decisions, communicating, and implementing recovery plans. The goal is for teams to build up a routine: not thinking "what do we have to do again?", but automatically acting according to runbooks and governance. It is precisely this routine that makes incidents shorter and less damaging.

Step 4: Measure what the board wants to know (KPIs)

Choose KPIs that demonstrate continuity and control, so that you can translate the value of training into management language. For example:

  • time-to-detect and time-to-escalate
  • % of systems with verifiably recoverable backups (after testing)
  • phishing-resistant behavior (simulation + follow-up)
  • releases with security gates without blocking findings
  • training coverage per role: who has practiced, who has been declared competent

By periodically discussing KPIs in an MT/board context, you make training "manageable": it becomes a management tool, not a separate HR activity.

NIS2 strategy: demonstrable results require consistency

For many organizations, NIS2 is the trigger to do "something with training." The pitfall is a one-off campaign that fades away after a few months. A mature NIS2 strategy requires repeatability: you must be able to demonstrate that you are working structurally on improvement, that your governance is functioning, and that you are prepared for incidents and chain questions.

Training supports this on three levels:

  1. Governance and responsibility: Management and MT must be able to make incident decisions, prioritize under pressure, and know what information they need to manage responsibly. This goes beyond basic awareness; it involves decisiveness, mandates, and crisis communication.
  2. Operational readiness: Incident response is a team sport. Without practice, it is a theoretical plan that is implemented slowly and fragmentarily in practice. Practice ensures that IT, engineering, legal, communications, and suppliers find each other at the right moment and that escalation lines work.
  3. Supply chain and suppliers: Procurement and vendor management must be able to formulate, assess, and follow up on security requirements. They must also know how escalation works in the event of vulnerabilities, how to request evidence, and how to contractually steer responses. This is a skill, not a policy, which is precisely why it belongs in a corporate security training program.

Practical example: from incident stress to predictable response

Your organization runs on SaaS, cloud, and critical integrations. A supplier reports a vulnerability that is being actively exploited. The first questions are rarely purely technical, because the focus quickly shifts to business impact, timing, communication, and decision-making authority:

  • Who decides?
  • What is the impact?
  • How quickly can we mitigate?
  • Who informs customers and stakeholders?

Without a training program, teams often start working in parallel without a shared vision: legal/communications joins late, priorities between product and operations clash, and suppliers are only tightly managed once time has already been lost. This prolongs the duration of incidents and increases reputational risk.

With security training companies as part of your cybersecurity strategy: management practices decision-making, ownership is clear, DevOps knows the mitigating steps, and procurement knows the escalation channels. This not only results in speed, but also consistency: everyone knows what scenario this is, what "good" looks like, and what information needs to be recorded for evaluation and demonstrability.

That is the difference between reacting and directing, and precisely why you should view training as part of your NIS2 strategy.

 Conclusion: make training a controllable link in your cybersecurity strategy

If you are reading this because you have to or want to do "something with training," don't opt for volume, opt for impact. The biggest gains are usually not found in more modules, but in better links to scenarios, roles, and measurable outcomes. This also makes it easier to justify the budget and time to management, auditors, and chain partners.

Ask yourself three questions:

  1. Which three cyber risks pose the greatest threat to our continuity?
  2. Which two role groups determine whether we manage those risks?
  3. What exercise or training program will we plan within 60 days to achieve demonstrable improvement?

This is how you build a cybersecurity strategy that not only looks good on paper, but also works in terms of behavior, governance, and implementation, including demonstrable results within your NIS2 strategy. You create a rhythm of improvement, practice, and reporting that makes your organization structurally more resilient.

Frequently Asked Questions

What is the difference between awareness and security training companies?

Awareness is about consciousness and basic behavior. Security training companies build role competencies and measure effectiveness in KPIs, exercises, and demonstrably better actions in scenarios. This makes it part of your cybersecurity strategy rather than a separate intervention.

How does security training for companies fit into a cybersecurity strategy?

By linking training to scenarios, roles, and measurable goals. You train what is needed to manage risks, not what happens to be in a training catalog. This makes it manageable and auditable, and also supports the NIS2 strategy.

Which roles are most important for NIS2 strategy and demonstrable compliance?

Usually management/MT (governance and duty of care) and the executive core (CTO/engineering/IT ops). In many organizations, procurement is also crucial, because chain risk and supplier agreements determine your demonstrability and speed in the event of incidents.

How do you measure whether training really reduces risk?

Link to incident KPIs (detection/escalation), recovery tests, release quality (security gates), and role coverage (who has practiced and been declared competent). Combine this with post-exercise evaluations so you can demonstrate that areas for improvement have actually been addressed.

How often do you need to practice to become demonstrably mature?

Work with rhythm: scenario exercises for critical teams at least once per quarter and periodic updates in the event of new threats. For management/MT, a shorter but recurring format is often more effective than one long session per year.

How Trivian tackles this: training as part of your security operating model

Trivian positions cybersecurity not as a separate training course, but as part of your security approach. The starting point is your organizational context: maturity, risks, cloud and application landscape, chain dependency, and NIS2 pressure. By linking training to governance, scenarios, and role responsibility, it becomes a structural capability line rather than a one-off "action."

Check out the entries on Trivian:

Trivian's approach boils down to three lines:

  1. Boardroom-proof training program that you can defend based on risk, scenarios, and KPIs.
  2. Role-based learning paths for technical and non-technical roles, so everyone trains for responsibility.
  3. Practice, secure, repeat as a rhythm in your operating model, so that the effect continues to grow and demonstrable results are achieved.

Discuss your training strategy

Do you want to set up security training programs in such a way that management, CTOs, and auditors hear the same message, and teams demonstrably perform better under pressure? Trivian helps you design a training program that is role-oriented, measurable, and repeatable, linked to your risks and NIS2 strategy. This makes your training not only useful, but also manageable and defensible in audits and customer inquiries.

Please contact us.