Trainer thoughts and tips
Trainer reflections on NIS2 Lead Implementer training
Delivering NIS2 Lead Implementer training is always a useful reminder that cybersecurity regulation is not only about technical controls. It is also about governance, accountability, risk ownership, supply chain dependencies, business continuity, incident response, communication, training, monitoring, and evidence.
At NIS Institute, we provide professional training for organisations and practitioners who need to understand how NIS2 can be translated into a realistic implementation approach. One of the training paths we offer is the PECB NIS 2 Directive Lead Implementer training. PECB provides the certification framework and training structure, while NIS Institute brings the practical delivery, discussion, and implementation-oriented learning experience.
These notes are not official course material, not legal advice, and not a replacement for formal training. They are personal trainer reflections on themes that repeatedly matter when professionals start thinking seriously about NIS2 implementation.
NIS2 is a management topic, not only a cybersecurity topic
One of the most important messages to bring across during training is that NIS2 cannot be delegated entirely to IT.
Technical measures are necessary, but they are not enough. NIS2 requires organisations to think about decision-making, responsibilities, ownership, reporting, risk appetite, supplier dependencies, and continuity of services.
For many organisations, this means that cybersecurity needs to move closer to the management table. The question is not only “Which controls do we have?” but also:
- Who owns the risk?
- Who approves the approach?
- Who follows up on weaknesses?
- Who decides what level of risk is acceptable?
- Who can demonstrate that the organisation is improving?
That management dimension is often where the real implementation work starts.
Certification can support compliance, but it is not the same thing
A recurring point in training discussions is the relationship between standards, certifications, and legal obligations.
Standards such as ISO/IEC 27001 can be very helpful. They provide structure, terminology, management-system discipline, and a recognised way to organise information security. But certification against a standard should not be confused with automatic NIS2 compliance.
NIS2 has its own scope, obligations, governance expectations, reporting requirements, and national implementation context. A certified management system can support the journey, but organisations still need to assess what NIS2 specifically requires from them.
That distinction is important, because it prevents false comfort.
Risk management remains the foundation
NIS2 implementation quickly becomes abstract if risk management is not made practical.
In training, I find it useful to return to a few simple questions:
- What are the organisation’s important services?
- Which assets and suppliers support those services?
- What can realistically go wrong?
- What would the impact be?
- Who owns the risk?
- What has already been done?
- What still needs to be improved?
- How will management know?
Risk management should not become a theoretical document that is updated once a year and then forgotten. It should support real decisions about priorities, resources, controls, suppliers, continuity, and incident readiness.
The all-hazards view is useful
NIS2 also benefits from an all-hazards mindset.
Cyberattacks are important, but they are not the only scenario that can disrupt critical or important services. Organisations may also face IT outages, power failures, supplier failures, natural events, human error, physical incidents, or communication breakdowns.
The practical point is not to create an endless list of possible disasters. The point is to identify the disruptions that are relevant to the organisation and to prepare for them in a structured way.
This broader view helps connect cybersecurity with business continuity and crisis management.
Asset management is more strategic than it looks
Asset management is sometimes treated as a boring inventory exercise. In practice, it is one of the foundations of cybersecurity governance.
If an organisation does not know which systems, data, applications, suppliers, locations, and services matter, it becomes very difficult to manage risk properly.
Good asset management helps answer questions such as:
- Which systems support essential or important services?
- Which assets are exposed?
- Which assets depend on external suppliers?
- Which vulnerabilities matter most?
- Which systems need stronger continuity planning?
- Which assets require stricter access control?
Asset management is not only about hardware. It is about understanding the operational reality of the organisation.
Supply chain security deserves serious attention
Supply chain security is one of the most practical and sometimes uncomfortable NIS2 topics.
Many organisations depend on external providers for technology, infrastructure, support, hosting, managed services, software, data processing, or operational continuity. Outsourcing may transfer activities, but it does not remove accountability.
Useful questions include:
- Which suppliers support important services?
- What security expectations are included in supplier agreements?
- How are supplier incidents reported?
- Are suppliers included in continuity planning?
- How are critical supplier risks reviewed?
- What happens if a key supplier is unavailable?
A one-time supplier questionnaire is rarely enough. Supplier security needs to become part of ongoing governance.
Incident response should lead to learning
Incident response is not only about reacting when something goes wrong. It is also about learning.
A mature approach includes preparation, detection, escalation, containment, communication, recovery, evidence, and review. Near misses can also be valuable, because they reveal weaknesses before they become serious incidents.
In training discussions, this often leads to a practical point: organisations should not wait for a major incident to discover that reporting lines, escalation paths, contact details, evidence handling, or crisis communication are unclear.
Preparedness is part of resilience.
Crisis communication needs preparation
Crisis communication is often underestimated.
During a cyber incident, communication can easily become confused, too technical, too slow, too vague, or too revealing. That is why organisations need communication protocols before the crisis happens.
Important preparation points include:
- who communicates internally;
- who communicates externally;
- who approves messages;
- which channels are used;
- what the fallback channels are;
- when regulators, customers, partners, or suppliers need to be informed;
- how to avoid disclosing sensitive details too early.
Exercises are useful because they reveal practical gaps that documents alone do not show.
Business continuity and cybersecurity belong together
Business continuity is not the same as disaster recovery. Disaster recovery is part of the picture, but business continuity is broader.
A useful implementation discussion should include:
- how long a service can be unavailable;
- how much data loss is acceptable;
- which services must be restored first;
- what minimum service level is acceptable during disruption;
- which dependencies could block recovery;
- whether recovery arrangements have been tested.
Higher resilience usually requires more preparation, more infrastructure, more supplier alignment, and more cost. That makes it a management decision, not only a technical one.
Awareness, training, and competence are different things
Awareness and training are often mentioned together, but they are not identical.
Awareness helps people recognise risks and behave responsibly. Training develops specific knowledge or skills. Competence means people can apply what is needed in their role.
This distinction matters because not everyone in an organisation needs the same depth of knowledge. Management, IT, procurement, legal, HR, communications, operations, and end users may all need different learning outcomes.
Good cybersecurity learning is role-based, repeated, and evaluated.
Testing, monitoring, and evidence make the system real
A policy is only useful if it is implemented. A control is only useful if it works. A plan is only useful if it can survive contact with reality.
That is why testing, monitoring, measurement, and evidence are so important.
Practical reminders:
- define the scope before testing;
- test in a controlled way;
- document results;
- follow up on findings;
- keep evidence;
- report meaningful indicators to management;
- connect monitoring with improvement.
Evidence is not bureaucracy for its own sake. It is how an organisation demonstrates that cybersecurity is being managed deliberately.
Internal review and audit as improvement tools
Monitoring and audit are not the same thing.
Monitoring observes what is happening. Audit checks whether requirements are met and whether the system works as intended.
A useful review mindset asks:
- are responsibilities clear?
- are controls implemented?
- is evidence available?
- are incidents followed up?
- are supplier risks reviewed?
- is management informed?
- are improvements tracked?
The value of audit is not only in finding nonconformities. It is also in creating confidence that the organisation understands its obligations and is improving over time.
Closing reflection
Delivering NIS2 Lead Implementer training confirms how important it is to approach NIS2 as an organisational resilience programme, not only as a cybersecurity project.
The technical controls matter, but they need governance, risk ownership, supplier management, continuity planning, incident readiness, communication, awareness, testing, monitoring, and management review behind them.
That is also why structured professional training has value. A good training environment gives participants time to connect the legal requirements, the cybersecurity concepts, and the implementation reality of their own organisations.
At NIS Institute, that practical connection is exactly what we want to support: helping professionals understand NIS2 in a way that is structured, useful, and applicable in real organisational contexts.