Risk management is still treated in many organizations as an administrative exercise.

Once in a while, someone opens a spreadsheet.

A list of risks is updated.

Probability is assigned.

Impact is assigned.

A matrix is produced.

Then comes an audit, a presentation or an internal meeting, and everyone acts as if the organization has risk under control.

But infrastructure changes every day.

Configurations change.

Access rights change.

Services change.

Vulnerabilities change.

Suppliers change.

Regulatory expectations change.

And now one more thing is changing: artificial intelligence is entering the environment.

Not as a theoretical topic.

As a practical factor that accelerates attacks, development, automation, decision-making and mistakes.

NIS2 changes the meaning of risk management

NIS2 is not just another document to satisfy.

It changes how organizations should think about cyber risk.

Cyber risk is no longer only a technical problem for IT.

It is a management responsibility.

It is an operational resilience issue.

It is a question of whether the organization can show that it can:

  • identify risks,
  • manage security measures,
  • respond to incidents,
  • protect network and information systems,
  • work with supplier risk,
  • maintain continuity,
  • and prove that adopted measures are not only formal.

The largest problem is often not that organizations have no policies.

The problem is that they cannot prove whether the policies work in practice.

Risk cannot be managed without evidence

If an organization says that access, configurations, backups, vulnerabilities or security settings are under control, it should be able to answer simple questions:

What is the current state?
When did it change?
Who made the change?
Was the change approved?
Is the state still aligned with policy?
Can we prove it?

Without these answers, risk management is only description.

It is not control.

Risk cannot be managed effectively if the organization has no evidence about the current state of its systems.

This is where the gap appears between traditional compliance and modern infrastructure.

Documentation says what should be true.

Infrastructure shows what is true now.

AI makes this gap larger

Artificial intelligence changes speed.

Attackers can use AI to analyze public information, search for weaknesses, generate phishing scenarios, combine multiple attack steps and automate work that previously required more time.

Developers can also use AI to create applications, scripts and infrastructure changes much faster than before.

That has a positive and a negative side.

The positive side is productivity.

The negative side is faster change without proportional control.

If systems change faster, risk management cannot remain slow.

If attacks are assembled faster, cannot be produced manually once per quarter.

If AI helps an attacker adapt in real time, the organization cannot wait until the next audit to discover that a system is no longer in the expected state.

Traditional tools solve only part of the problem

There are several open-source and community solutions that cover parts of this area.

Some of them are very useful.

But most solve only one segment of the broader problem.

A short audit of existing open-source options

Wazuh

Wazuh is a strong open-source security platform for monitoring, SIEM/XDR scenarios, log collection, endpoint visibility and security rules.

It is useful for operational security.

It helps detect events and incidents.

But its primary purpose is not to manage NIS2 risk management, compliance pipelines, control ownership, audit evidence and management accountability as one unified process.

Wazuh is a strong security operations tool.

It is not a complete system for governance and evidence-based risk management.

OpenSCAP

OpenSCAP is an important toolkit for security benchmarks, configuration compliance and SCAP-based checks.

It helps answer a technical question:

Is this system configured according to a defined security profile?

That is valuable.

But OpenSCAP does not cover the full risk lifecycle by itself:

  • risk ownership,
  • mapping to NIS2 measures,
  • asset context,
  • exception handling,
  • long-term audit trails,
  • management reporting,
  • and the connection between technical state and organizational decisions.

It is an excellent technical compliance tool.

It is not a complete security operating layer.

DefectDojo

DefectDojo is a strong open-source solution for vulnerability management, DevSecOps and application security posture management.

It helps centralize findings from scanners, manage vulnerabilities and track remediation.

It is useful for AppSec and product security.

But risk management under NIS2 and operational resilience is broader than vulnerabilities.

Organizations also need to manage:

  • configurations,
  • identity,
  • system integrity,
  • operational evidence,
  • continuity,
  • supplier risk,
  • process controls,
  • exceptions,
  • and auditability of decisions.

DefectDojo solves an important part of the problem.

It does not solve the whole architecture of trust.

SimpleRisk

SimpleRisk is closer to classic GRC and risk management.

It supports structured risk registers, assessments, controls and related processes.

That is useful when an organization needs a formal way to manage risk records.

Its strength is the administrative and process layer.

The key question is how deeply such a system is connected to the real state of infrastructure.

For modern environments, it is not enough to know that a risk exists.

The organization also needs to know whether technical measures were actually implemented, whether they are still active and whether evidence exists for their current state.

A risk register is necessary.

But without automated evidence from infrastructure, it remains partly separated from reality.

OpenRMF

OpenRMF is an interesting project around risk management frameworks, controls and compliance documentation.

It is closer to formal security assessment and control mapping.

It can be useful where organizations need to manage controls, assessments and security requirements.

But modern infrastructure requires more than control mapping.

It needs a live evidence flow.

It needs continuous verification.

It needs to know whether technical and organizational measures evolve together with the system, not only after documentation is manually updated.

Newer open-source GRC platforms

Newer open-source or community GRC platforms are also appearing.

Some focus on ISO 27001, , SOC 2, NIST or broader compliance management.

Some try to become open-source alternatives to platforms such as Vanta or Drata.

That direction is important.

But each of these platforms should be evaluated with practical questions:

Is the project actively maintained?
Is it really open-source, or mainly open-core?
Can it work with infrastructure evidence?
Can it generate machine-readable evidence?
Can it connect controls to the current state of systems?
Can it work well in Linux infrastructure environments?
Can it support NIS2 and CRA as a live process, not only as a checklist?

There are many partial tools.

There are fewer unified layers that connect infrastructure, integrity, audit evidence, compliance and risk management into one operating model.

The missing layer is security operations evidence

The problem is not that tools do not exist.

They do.

But they are divided into historical categories:

SIEM
vulnerability management
configuration compliance
GRC
audit documentation
asset inventory
monitoring
identity
backup
incident response

NIS2 and AI push organizations toward a different question:

How can we continuously prove that our infrastructure is still trustworthy?

This question does not live only in a SIEM.

It does not live only in a GRC tool.

It does not live only in configuration management.

It does not live only in an audit document.

It lives between them.

That is why a security operating layer starts to make sense.

Not another dashboard.

Not another spreadsheet.

Not another isolated scanner.

A layer that can:

  • collect evidence,
  • verify integrity,
  • map state to controls,
  • preserve audit trails,
  • support NIS2 and CRA,
  • manage exceptions,
  • create machine-readable evidence,
  • and provide both technical and management views of infrastructure trust.

The future of risk management is evidence-based

Risk management has to move from the question:

Do we have the risk recorded?

to the question:

Do we have evidence that the risk is managed?

That is a fundamental difference.

The first question creates documentation.

The second creates accountability.

In an environment shaped by NIS2, CRA and AI, a well-written policy will not be enough.

Organizations will need evidence that their systems are still in the expected state.

Evidence that changes are tracked.

Evidence that integrity is not only assumed.

Evidence that controls exist outside the audit window.

Evidence that security is an operating process, not an annual project.

Conclusion

AI changes the speed of attacks and development.

NIS2 changes management responsibility.

Risk management must change as well.

A risk register is not enough.

A scanner is not enough.

Documentation is not enough.

A dashboard is not enough.

Modern organizations will need the ability to continuously prove that their infrastructure remains trustworthy.

Not once per year.

Not only during an audit.

Continuously.

That is why the next generation of security platforms will likely stand on three words:

risk
evidence
integrity

Organizations that understand this earlier will have an advantage.

Not because they will have more documents.

Because they will be better able to prove that their systems are still under control.