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.

Risk Acceptance in Vulnerability Management: Exceptions That Hold Up

Every vulnerability program has a pile of findings nobody is going to fix this quarter. A legacy server the vendor stopped supporting. A production database that can only be restarted twice a year. A medical device you are not allowed to touch. That pile is normal. What is not normal is how most organizations manage it: a "won't fix" status in a scanner, a ticket closed with "accepted by the business," and no one who remembers why two years later.

Risk acceptance is a legitimate risk response. NIST, ISO 27001 and PCI DSS all allow it. But they treat it as a decision someone makes and owns, not as a state a finding drifts into. This guide explains what a defensible risk acceptance looks like, who should be allowed to sign it, and the signals that should automatically reopen it.

Accepting risk is a real option, not a failure

NIST SP 800-40 Rev. 4, the US guide to enterprise patch management, lists four responses to the risk from vulnerable software:

Accept the risk as is, relying on existing controls or because the potential impact is low enough that no further action is needed.
Mitigate it, by eliminating the vulnerability (patching) or deploying additional controls that make exploitation harder.
Transfer it, by sharing the consequences with another party, for example by moving to a SaaS service.
Avoid it, by removing the attack surface, for example by decommissioning the asset.

NIST also points out something uncomfortable: by default, an organization already accepts the risk of every vulnerability it does not know about yet. The question is not whether you accept risk. It is whether you do it knowingly, with evidence, or by accident.

Accepted by whom?

ISO/IEC 27001:2022 is precise on this. Clause 6.1.2 requires you to define risk acceptance criteria, the threshold that separates the risks you treat from the risks you knowingly keep. Clause 6.1.3 requires the risk owners to approve the treatment plan and to accept the residual risk.

In practice, that rules out two common habits:

The engineer accepts the risk. The person who would have to apply the patch is rarely the person who would carry the consequences of a breach. They can recommend; they should not approve.
"The business" accepts the risk. A department is not a risk owner. A named person with authority over the asset or the process is.

A simple rule that works: the higher the residual risk, the higher the signature. A medium-severity finding on an internal test server can be accepted by the system owner. A vulnerability in CISA's KEV catalog on an internet-facing system should need the CISO, and ideally an executive who owns the business process.

What a defensible risk acceptance contains

If an auditor, a regulator or your own incident review asks "why was this still open?", the record should answer it on its own. At minimum:

Scope. The exact finding (CVE or rule), the affected assets and the environment. "All Windows servers" is not a scope.
Reason. The concrete constraint: no fix exists, the vendor no longer supports the product, the fix breaks a critical application, a maintenance window is months away.
Risk at the time of the decision. Severity, whether the vulnerability is known to be exploited, its exploit likelihood and the asset's exposure. This is what lets someone later see what changed.
Compensating controls, if any, and how you know they work.
Owner and approver, by name.
Expiry date. Every acceptance ends. When it does, it is renewed with fresh evidence, or the finding goes back into the remediation queue.

If you have read our guide to patch management, this is the same idea applied with more rigor: the exception is a record with a lifecycle, not a checkbox.

Compensating controls: the bar is higher than you think

"We have a firewall" is the most common compensating control and one of the weakest. PCI DSS has the clearest definition of what a real compensating control must do. It must:

Meet the intent and rigor of the original requirement.
Provide a similar level of defense to the control it replaces.
Be above and beyond other requirements you already have to meet. A control you were obliged to have anyway does not count.
Be commensurate with the additional risk of not meeting the requirement.

PCI DSS also expects each one to be documented with the constraint, the objective, the identified risk, the control itself, how it was validated and how it is maintained. You do not need to be in scope for PCI to borrow that structure. It forces the question that matters: does this control actually stop the attack path the vulnerability opens?

Good compensating controls are specific to the vulnerability: isolating the asset in its own network segment, disabling the vulnerable feature, a WAF rule that blocks the exploit pattern, removing internet exposure. NIST SP 800-40 adds that these long-term mitigations should be reviewed in advance by security architects and periodically re-evaluated to check they are still effective.

The triggers that should reopen a decision

An expiry date catches slow drift. It does not catch a threat that changes overnight. A risk acceptance was made under certain conditions; when those conditions change, the decision no longer holds. Reopen it automatically when:

The vulnerability lands in CISA KEV, or a credible source reports exploitation in the wild. See what the KEV catalog means.
A public exploit or proof of concept appears, or the exploit likelihood rises sharply.
The asset's exposure changes: it becomes reachable from the internet, it starts processing sensitive data, or it moves to a more critical business process.
The compensating control stops working: a firewall rule is removed, a segment is merged, a WAF goes into monitoring mode.
A fix becomes available for something that had none.

This is where prioritization frameworks help. A decision tree like CISA's SSVC makes these inputs explicit, so the same inputs that justified "track" can also tell you when the answer has become "act."

Metrics that keep acceptance honest

Accepted risk tends to grow silently. Three numbers keep it visible:

Open acceptances, and how many are past their expiry date. An expired acceptance is just an unpatched vulnerability with paperwork.
Acceptances on known-exploited vulnerabilities. This number should be small, each one should be signed at the highest level, and each one should have a compensating control you have tested.
Acceptances without an owner or a compensating control. These are the ones that will hurt in an incident review.

Report them next to remediation metrics, not hidden in a separate register. For more on what to show leadership, see board-level cyber risk metrics.

FAQ

Is risk acceptance allowed under ISO 27001? Yes. ISO/IEC 27001:2022 requires you to define risk acceptance criteria and to have risk owners accept the residual risk. What it does not allow is acceptance without criteria or without an owner.

Should every exception have an expiry date? Yes. NIST SP 800-40 recommends tracking all exceptions to maintenance plans and reviewing them regularly to see whether the plan can now be applied. An expiry date is the simplest way to force that review.

What if an asset can never be patched? Then the acceptance will be renewed again and again, and that is a sign it belongs in its own maintenance group with its own plan, as NIST suggests: isolation, strict access control and monitoring, reviewed on a schedule, until the asset can be replaced.

How priorIQ.ai helps

PriorIQ Core records every decision not to remediate in Risk Accepted & Decisions, with an owner, a justification, compensating controls and an expiry date, plus a full history in Risk Accepted and All Decisions. Because the same platform prioritizes by real risk (KEV, EPSS, public exploits and the asset's exposure), an accepted finding stays visible in context instead of disappearing from the queue, and its Mitigation Backlog keeps everything still pending with owner and SLA. Findings from ScannerIQ, CloudIQ and CodeIQ flow into the same model, so your exceptions cover endpoints, cloud and code alike. Request a demo.