Phishing simulations and NIS2 compliance: why role and risk matching matters

NIS2 has changed what compliance means for cybersecurity training. It is no longer enough to run an annual awareness session and file it away as evidence of good faith. The directive expects organizations to show, with data, that employees understand the threats relevant to their job and that the organization is actively managing human risk. Phishing simulations sit right at the center of that expectation, but only if they are built the right way. 

A generic simulation sent to every employee on the same day, with the same template, checks a box. It does not reflect how NIS2 actually asks organizations to think about risk. The directive is built around the idea that risk is not evenly distributed across a workforce, and training shouldn’t be either. A payroll administrator, a developer with production access, and a receptionist all face different attackers with different goals, and a simulation program that treats them identically ends up measuring engagement rather than exposure. 

This post looks at why phishing simulations support NIS2 compliance, and why matching those simulations to roles and risk levels is what separates a program that checks a box from one that actually reduces exposure.

Why NIS2 puts phishing simulations on the compliance map

NIS2, formally Directive (EU) 2022/2555, expanded the scope of European cybersecurity regulation to cover 18 sectors and classified organizations as either essential or important entities. Article 21 lists cybersecurity risk management measures that covered entities must implement, and cybersecurity training and awareness sit explicitly within that list. Regulators are not asking whether a training program exists. They are asking whether it addresses the specific risks the organization faces. 

Phishing remains the most common entry point for the incidents NIS2 is designed to prevent. Ransomware, credential theft, and business email compromise nearly always start with a message that convinces someone to click, reply, or hand over information. That is exactly why phishing simulations matter so much to the directive. They give organizations a way to test, rather than assume, how employees would respond to a real attack, and they generate the kind of evidence NIS2 auditors expect to see. 

What NIS2 actually requires from your training program 

NIS2 does not hand organizations a training template. It asks for something broader: a risk management approach that is proportionate to the threats an entity faces and to the role each person plays within it. That means training has to be tied to actual risk, not delivered as a flat, one size fits all exercise. 

In practice, this shows up in a few concrete expectations. Training needs to happen on a regular basis, not once a year. It needs to be documented in a way that shows who was trained, when, and how they responded. And it needs to reflect the reality that different employees face different levels of exposure. A finance clerk who processes wire transfers faces a different threat profile than someone in an administrative role with no access to sensitive systems. NIS2's emphasis on proportional risk management is precisely why role-based and risk-based training design has become the standard that compliant organizations are moving toward. 

Why generic phishing simulations fall short of the mandate 

A phishing simulation program that sends the same fake invoice email to the entire company every quarter will produce numbers. It will not produce insight. The organization learns very little about where its actual exposure sits. 

The problem is that generic simulations test for engagement, not for risk. An employee in a role with no financial access might fail a wire transfer themed simulation and it barely matters. Meanwhile, someone in accounts payable might pass a generic phishing test easily but never face a simulation that mirrors the specific business email compromise tactics attackers use against people in their position. Under a compliance model built around proportional risk, that gap is a problem. NIS2 auditors increasingly want to see that an organization understands its own risk landscape, not just that it sent training emails on schedule. 

There is also a behavioral issue. Employees who receive irrelevant simulations tend to disengage. If the same predictable template shows up every quarter, people learn to recognize the test rather than the underlying tactic, which defeats the purpose of running simulations at all. 

Matching simulations to roles: what this looks like in practice 

Role based simulation design starts with a simple question: what does this person actually have access to, and what would an attacker want from them? Finance teams see simulations built around invoice fraud, payment redirection, and executive impersonation. IT and system administrators see credential harvesting attempts and fake software update prompts. HR sees simulations involving fake job applicants or payroll and benefits-related phishing. Executives and other high-profile targets see more sophisticated multi-layer attempts, since they are the employees attackers research carefully before an attack. 

This is exactly the model built into Nimblr's simulated attacks, which are customized using organization specific details like internal logos, executive names, and common vendor relationships so that each simulation reflects a threat that is plausible for the person receiving it. A generic simulation asks whether an employee can spot a phishing email in the abstract. A role-matched simulation asks whether they can spot the phishing email that is most likely to land in their inbox. 

This kind of targeting also produces better compliance documentation. Instead of a single blanket metric showing an organization wide click rate, role-based simulations let security teams demonstrate that high-risk functions receive training calibrated to their actual exposure, which is a much closer match to what NIS2's proportional risk requirement is asking for. 

Matching simulations to risk level: the adaptive difficulty piece 

Role is only one half of the equation. Risk level, meaning how an individual has actually performed over time, is the other. Two people in the same role can have very different risk profiles depending on what they have clicked, reported, or missed in the past. 

An adaptive approach adjusts simulation difficulty and frequency based on that individual history. Someone who consistently falls for fake sender addresses receives more simulations targeting that specific weakness. Someone who repeatedly clicks on reward-based lures, such as fake gift cards or prize notifications, gets simulations aligned to that pattern instead. Employees who demonstrate strong detection skills over time can shift toward more advanced tests, so the program keeps stretching them rather than wasting their attention on easy wins. 

This adaptive model is core to how Nimblr's simulation engine works, and it connects directly to instant, in the moment feedback whenever someone clicks a simulated link. The combination matters for NIS2 because the directive is not interested in static compliance. It wants evidence of continuous risk management, and adaptive simulations are a direct, measurable way to show that risk is being tracked and addressed as it changes, not just assessed once and forgotten. 

How role and risk matching creates the audit trail NIS2 auditors want 

Compliance is not just about running the right program. It is about proving it. NIS2 requires organizations to document their risk management measures in a way that holds under scrutiny, and generic training data does not tell a very convincing story. 

Role and risk matched simulations generate a much richer record. Security teams can show which departments were tested against which threat types, how individual and team performance changed over time, and how the organization adjusted its approach in response to that data. This is the kind of detail that turns a training program from a vague assurance into something closer to a real risk register. 

Automated reporting dashboards make this practical rather than theoretical. Instead of security teams manually compiling spreadsheets before an audit, a well built simulation program tracks every simulated attack, every click, and every completed follow up lesson automatically. That data can be pulled into board level reports or handed directly to an auditor, which is a much stronger position than trying to reconstruct a year of training activity after the fact. 

Building a NIS2 ready simulation program 

None of this requires organizations to build a perfect system from day one. It does require a shift in mindset, from training as a scheduled event to training as an ongoing, calibrated process tied to actual roles and actual behavior. 

At Nimblr, we’ve already mapped the roles that carry the highest risk and automated learning tracks for those roles. We layer in adaptive difficulty, so simulations respond to individual performance rather than treating every employee identically. The program produces documentation automatically, since manual record keeping is rarely sustainable. And we treat every failed simulation as a training opportunity rather than a punishment, since behavior change sticks far better when mistakes lead to immediate, constructive feedback instead of blame. 

NIS2 was written around the idea that cybersecurity risk is proportional, specific, and constantly shifting. Phishing simulations that reflect roles and risk levels are one of the clearest ways to prove that an organization takes that idea seriously.