Do I need to buy every module?

No. PriorIQ Core is the foundation and you turn on the modules you need. They all live in the same application and share users, data and prioritization.

Does priorIQ.ai replace my scanner?

Not necessarily. You can use the native modules (ScannerIQ, CloudIQ and CodeIQ) or connect Microsoft Defender, Tenable, Qualys, Rapid7, Snyk, AWS Inspector and Wiz and reconcile everything into a single view.

Is it available on-premise?

Yes. We offer multi-tenant SaaS and self-hosted deployments, including air-gapped.

How long does it take to go live?

Typical time-to-value is under 2 weeks from connecting the first scanner.

How is prioritization calculated?

We combine CVSS, EPSS, CISA KEV presence, verified public exploits, exploit-in-kit, the asset's business exposure and active threat signals: incidents confirmed by SentinelIQ and dark web activity detected by OnGuardIQ.

Does it support air-gapped environments?

Yes, with a local NVD catalog mirror and an offline update channel.

Which compliance frameworks are supported?

CIS Benchmarks per OS, NIS2, DORA, SOC 2 and ISO/IEC 27001:2022, all with continuous evaluation.

How is sensitive data handled?

AES-256 encryption at rest, credentials never exposed in API responses or logs, immutable audit log.

Do you integrate with ticketing?

Yes, natively with Jira, ServiceNow and Freshservice. Create, update and close tickets from priorIQ.ai.

What sources does OnGuardIQ monitor?

The deep and dark web, hacking forums, underground marketplaces, Telegram channels and paste sites, looking for leaked credentials, access for sale, brand impersonation and exploits that affect your environment.

NIS2 and DORA: What They Require for Vulnerability Management

NIS2 and DORA have moved cybersecurity in Europe from "good practice" to legal obligation. For many organizations, the first question is scope. The second, and harder one, is what to show a regulator or auditor when they ask how you manage vulnerabilities. Neither text gives you a patching SLA or a tool list. Both expect a risk-based, documented and continuously working process, with management held accountable for it.

This article covers what the two frameworks expect from vulnerability management, who is in scope at a high level, what evidence tends to be requested, and why a continuous approach is easier to defend than a once-a-year audit sprint.

This article is general information, not legal advice. Scope and obligations depend on national transposition, your sector and your specific situation. Check with your legal and compliance advisors.

NIS2 and DORA in one paragraph each

NIS2 (Directive (EU) 2022/2555) replaces the original NIS Directive and widens its reach considerably. Member States had to transpose it into national law by October 2024. It applies to "essential" and "important" entities across a long list of sectors, including energy, transport, banking, health, drinking water, digital infrastructure, ICT service management, public administration, manufacturing, food, postal services and digital providers. As a general rule it covers medium and large organizations in those sectors, with some entities in scope regardless of size. It requires cybersecurity risk-management measures, incident reporting and accountability of management bodies.

DORA (the Digital Operational Resilience Act, Regulation (EU) 2022/2554) applies from 17 January 2025 and is specific to the financial sector: banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers and many others. As a regulation it applies directly, without national transposition. It is organized around ICT risk management, ICT incident management and reporting, digital operational resilience testing, ICT third-party risk and information sharing. It also creates an oversight framework for ICT providers designated as critical.

If you are a financial entity, DORA is generally the more specific rulebook for ICT risk. If you are elsewhere in the economy, NIS2 is likely the one that applies.

What they expect from vulnerability management

Neither framework reads like a technical standard, but the expectations for vulnerability management are clear once you map them out.

Risk management measures

NIS2 asks for appropriate and proportionate technical, operational and organizational measures based on an all-hazards approach. The listed areas include risk analysis, incident handling, business continuity, supply chain security, security in acquisition, development and maintenance of systems, including vulnerability handling and disclosure, policies to assess the effectiveness of those measures, basic cyber hygiene, cryptography, access control and asset management.

DORA asks financial entities to maintain an ICT risk management framework: identify and classify ICT assets and their dependencies, protect and prevent, detect anomalies, respond and recover, and learn and evolve. Identifying vulnerabilities and applying patches and updates are an explicit part of that cycle.

In practice, both point to the same operating model. Keep an accurate inventory, find vulnerabilities continuously, prioritize by risk, remediate within defined timeframes and prove that it works.

Vulnerability handling and disclosure

NIS2 also introduces a coordinated vulnerability disclosure approach at the EU level, with national CSIRTs acting as coordinators and ENISA running a European vulnerability database. For you, this means having a way to receive reports about vulnerabilities in your own products and services, and to triage them.

Testing

DORA requires a digital operational resilience testing programme, which includes vulnerability assessments and scans, among other tests, and advanced threat-led penetration testing for certain entities. NIS2 asks you to assess how effective your measures are. Either way, a scan you ran once and filed away is not enough. Testing has to be regular and tied to remediation.

Third-party and supply chain risk

Both frameworks put real weight on suppliers. NIS2 includes supply chain security in its risk measures. DORA goes further, with ICT third-party risk management, contractual requirements and a register of information covering ICT service arrangements. For vulnerability management, this means looking at the software components and services you depend on, not just the servers you run.

Incident reporting

NIS2 sets a staged reporting process for significant incidents: an early warning within 24 hours of becoming aware, an incident notification within 72 hours and a final report within one month. DORA has its own classification and reporting regime for major ICT-related incidents. These obligations matter to vulnerability management because many incidents start with a known, unpatched weakness, and regulators will ask about it afterwards.

The evidence auditors and regulators tend to ask for

Policies are necessary but not sufficient. Expect questions like these:

Asset inventory: what you have, who owns it, how critical it is, and how you keep it current.
Coverage: which assets are scanned or assessed, how often, and what is excluded and why.
Prioritization logic: how you decide what to fix first. A documented, risk-based method using exploitability signals such as CISA KEV and EPSS is far easier to defend than "we patch criticals".
Remediation timeframes and performance: your targets and how you actually perform against them, for example through SLA and MTTR metrics.
Exceptions: risk acceptances with an owner, a justification, compensating controls and an expiry date.
Configuration baselines: hardening evidence against recognized standards such as CIS Benchmarks.
Management oversight: proof that leadership sees and acts on cyber risk, not just signs a policy.

Why continuous compliance beats the annual sprint

Many teams still prepare for audits by collecting screenshots, exporting spreadsheets and writing narratives a few weeks beforehand. That approach was already painful. Under NIS2 and DORA it is also risky, because supervisors can ask for evidence at any time and because management is personally accountable.

Continuous compliance flips the model. Controls are mapped to the data you already produce: scan results, configuration assessments, tickets, risk decisions. Status is visible every day. The gap list is a working backlog, not a surprise. When evidence is a by-product of normal operations, it is also more credible.

Common pitfalls

Treating it as a documentation exercise. Policies without operating evidence will not hold up.
Ignoring scope edges. Cloud accounts, code repositories, containers and suppliers are part of your attack surface.
Severity-only prioritization. It produces huge backlogs and weak justifications.
Untracked exceptions. A risk you accepted without an owner or expiry date looks like a risk you forgot.
No executive view. If the board cannot see the risk trend, it is hard to show governance.

Frequently asked questions

Does NIS2 or DORA set a mandatory patching deadline? Neither sets a single universal number. They expect timeframes that are proportionate to risk, defined by you, documented and met.

If we are a financial entity, do we follow NIS2 or DORA? DORA is generally treated as the sector-specific rulebook for ICT risk in finance. Confirm your exact position with your advisors.

Is a yearly penetration test enough? Usually not on its own. Both frameworks expect ongoing identification and handling of vulnerabilities, with testing as one part of it.

How priorIQ.ai helps

PriorIQ Core brings findings from every module and your existing tools into one prioritized remediation queue. It uses CVSS, EPSS, CISA KEV, exploit signals and business context, and it keeps a full audit trail of risk-acceptance decisions. Its continuous compliance view maps that data to frameworks including NIS2, DORA, CIS, SOC 2 and ISO 27001, with PDF and CSV reports ready for auditors. BoardIQ gives management a single 0–100 risk index with drivers and trend history, which is the kind of oversight evidence these regulations expect. See the platform or request a demo.