Key takeaways
- AI risk management changes what a security function can see, not who is accountable for it. Clauses 6.1.2 and 6.1.3 of ISO/IEC 27001:2022 still require defined criteria and a named owner for every risk treatment decision.
- FIRST projects roughly 66,000 CVEs for 2026, the first year on pace to approach 70,000. CISA's Known Exploited Vulnerabilities catalog held 1,587 entries as of May 1, 2026. Prioritization, not detection, is the actual bottleneck.
- ENISA recorded 4,875 incidents in the EU between July 1, 2024 and June 30, 2025. Phishing was the access route in 60 percent of observed cases and vulnerability exploitation in 21.3 percent.
- By early 2025, AI-assisted phishing accounted for more than 80 percent of observed social engineering activity worldwide. Attackers adopted AI faster than most risk functions did.
- Article 9(2) of the EU AI Act defines a risk management system as a continuous iterative process run across the entire lifecycle of a high-risk AI system. If you use AI to manage risk, that system is itself in scope for governance.
The Limitations of Traditional Risk Management
Traditional risk management is a calendar exercise. A team gathers information, scores it for likelihood and impact, records the result, and returns to it in six or twelve months. Between those two dates, systems change, permissions drift, vendors are added, and the threat landscape moves on without waiting for the next review cycle.
Conventional risk management typically involves annual or quarterly assessments, manual data collection, subjective scoring against a small number of factors, a static risk register, and reactive responses once something has already gone wrong. Each of these was reasonable when infrastructure changed slowly. None of them survives contact with an environment that changes weekly.
The scale of the gap is visible in the numbers. In its threat landscape for the period July 2024 to June 2025, the European Union Agency for Cybersecurity recorded 4,875 incidents across the EU. Phishing was the access route in 60 percent of observed cases, and exploitation of a vulnerability in 21.3 percent. Some 53.7 percent of the incidents involved entities within the scope of NIS2.
None of those three figures is manageable on an annual cycle. A vulnerability published in March and exploited in April does not appear in a register last reviewed in January.
A common misconception is worth correcting here, because it shapes a lot of budget conversations: the annual risk assessment is not a requirement of the standard. Clause 8.2 of ISO/IEC 27001:2022 asks for assessments at planned intervals and whenever significant changes occur or are proposed. The second condition is the demanding one, and it is the actual argument for continuous risk work. Auditors read both halves of that clause even when organizations only budget for the first.
AI-Powered Risk Management: A New Paradigm
AI risk management shifts the work from collection to judgment. Five capabilities account for most of the difference, and they compound: each one is more useful when the others are in place.
Automated Threat Intelligence Analysis
Threat intelligence arrives fragmented across vulnerability databases, vendor advisories, log data, and your own configuration state. A model can reconcile those sources continuously and answer the only question that matters operationally: does this advisory touch a system that appears in our asset inventory? That correlation step is where manual processes break down, not the scoring that follows it.
The asymmetry is real and it currently runs against defenders. ENISA found that by early 2025, AI-assisted phishing campaigns represented more than 80 percent of observed social engineering activity worldwide. Attackers industrialized AI before most security functions finished evaluating it.
Predictive Risk Identification
Historical incidents, current control effectiveness, and live threat data together support a defensible statement about where the next failure is likely. The value is not the forecast itself, which will often be wrong at the level of the individual prediction. The value is ordering: knowing which of the 93 Annex A controls to reinforce first when you can only fund three.
Treat predictions as hypotheses with an owner and a review date, not as findings. A predicted risk that nobody has evaluated is not risk intelligence, it is a queue.
Continuous Control Monitoring
Instead of periodic manual testing, control state is compared against intended configuration on an ongoing basis:
- configuration and control settings are checked continuously rather than sampled
- a control that drifts is surfaced when it drifts, not at the next review
- technical controls are tested automatically where testing can be automated
- control performance is visible on demand rather than at quarter end
This is also the mechanism that makes audit evidence a byproduct of operations. Evidence assembled continuously does not need to be reconstructed in the week before an assessment, which is where most external audit preparation effort has historically gone.
Quantitative Risk Analysis
Traditional assessment leans on qualitative labels: high, medium, low. Those labels are cheap to produce and almost impossible to aggregate, compare across teams, or defend to a finance function. Richer data supports probability modeling, impact estimates grounded in actual system criticality, scoring across multiple weighted factors, and scenario analysis across attack paths.
The honest caveat: quantification inherits the quality of its inputs. A confident number derived from a stale asset inventory is more dangerous than an admitted "medium", because it survives challenge in a meeting that a hedge would not.
Dynamic Risk Prioritization
A static register goes stale by design. Continuous reprioritization reflects changing exploitability, business context that shifts as products launch, and resource allocation that follows the current top of the list rather than last quarter's. Different stakeholders need different views of the same underlying data: a board wants exposure trend, an engineering lead wants this sprint's queue.
Practical Applications of AI in Risk Management
The capabilities above translate into four applications where the operational gain is measurable rather than theoretical.
Enhanced Vulnerability Management
This is the clearest case, because the raw numbers have moved beyond human triage. FIRST's mid-year 2026 forecast projects roughly 66,000 CVEs for the year, revised upward from a February estimate of 59,427, and the first year on pace to approach 70,000 disclosures. Actionable exploitability has not grown at anything like that rate: CISA's Known Exploited Vulnerabilities catalog held 1,587 entries as of May 1, 2026.
That gap between roughly 66,000 disclosures and 1,587 confirmed exploited vulnerabilities is the entire argument for intelligent prioritization. Three public signals do most of the work, and they answer different questions.
| Signal | Question it answers | What it does not tell you |
|---|---|---|
| CVSS | How severe would exploitation be, in the abstract? | Whether anyone is exploiting it, or whether you are exposed |
| EPSS | How likely is exploitation in the wild in the next 30 days? | What the impact on your business would be |
| CISA KEV | Is exploitation confirmed and observed already? | Anything about vulnerabilities not yet catalogued |
| Your asset inventory | Do we actually run the affected component, and where? | Nothing, and this is the signal most often missing |
EPSS, maintained by FIRST, is a machine learning model that estimates the probability a published CVE will be exploited in the wild within the next 30 days, scored daily from 0 to 1. Combining it with KEV status and your own inventory turns a 66,000 item feed into a list a team can actually work. The mistake most teams make is stopping at CVSS, which describes severity in a vacuum and says nothing about whether the vulnerability is being used or whether you are even running the affected software.
Advanced User Behavior Analytics
Behavioral analysis addresses the risks that controls-based assessment handles poorly: a valid credential used by the wrong person, an account compromised through one of those phishing campaigns, privilege quietly accumulating over years of role changes.
- baseline modeling to establish what normal looks like per user and service account
- anomaly detection against that baseline rather than against generic rules
- risk-based authentication that raises requirements when behavior is unusual
- closer monitoring of privileged access, where a single misuse has outsized consequences
One caution specific to this application. Behavioral monitoring of employees is personal data processing, and in the EU it carries works council consultation and GDPR obligations that a security team cannot resolve alone. Involve your data protection function before deployment, not after. Article 88 GDPR and national employment law both bear on what is permissible here.
Supply Chain Risk Intelligence
NIS2 makes third party risk explicit rather than optional: Article 21(2)(d) requires measures addressing supply chain security, including security aspects of relationships with direct suppliers. That obligation is difficult to meet with an annual questionnaire, because a supplier's posture changes between questionnaires.
Continuous vendor monitoring, dependency mapping to surface concentration risk, and early indicators of supplier compromise all become tractable when the assessment is data driven rather than survey driven. The full set of obligations is broken down in our guide to the NIS2 requirements.
Automated Compliance Risk Management
For organizations running several frameworks, the recurring cost is not the assessment but the mapping. Annex A of ISO/IEC 27001:2022 contains 93 controls in four themes: 37 organizational, 8 people, 14 physical, and 34 technological. NIS2 requires risk analysis and information system security policies under Article 21(2)(a). A SOC 2 report draws on substantially the same measures.
These control sets overlap heavily. Maintaining them separately means doing the same work three times, which is the reasoning behind running ISO 27001, GDPR, and SOC 2 against one control set. Automated mapping identifies which single measure satisfies several requirements at once, and more usefully, where a genuine gap remains after the overlaps are accounted for.
Implementation Strategy: From Traditional to AI-Powered Risk Management
The transition works in stages. Twelve months is a realistic horizon when one person owns the outcome and has at least half a full time equivalent to spend on it. Compressing it below that tends to produce tooling without process.
Phase 1: Foundation (Months 1 to 3)
Document the existing method, including scoring criteria and risk acceptance thresholds, because AI will amplify whatever definitions it inherits. Map where risk data currently lives. Establish baselines you can be measured against later: how many risks are open, how old the newest entry is, how long a full cycle takes, and how many findings the last audit produced.
Data quality assessment belongs here rather than later. An asset inventory that is 70 percent complete sets a hard ceiling on everything built on top of it, and no model corrects for inventory that does not exist.
Phase 2: Initial Implementation (Months 3 to 6)
Start with one framework and the systems carrying the highest protection requirement. Connect the sources that already generate evidence: identity and access management, endpoint management, cloud configuration, and the ticketing system where remediation actually happens. One framework completed end to end is worth more than three at half depth, both for the team's confidence and for the audit.
Phase 3: Advanced Capabilities (Months 6 to 12)
Cross domain correlation, predictive models, and automated recommendations belong here, once the definitions underneath them are stable. This phase reveals whether Phase 1 was done honestly. Without agreed criteria and named owners, continuous monitoring mostly produces alerts that nobody evaluates, and the program acquires a backlog instead of a capability.
A note on cost, since the question usually arrives too early. Platform licensing is rarely the deciding factor. What drives the total is the number of systems to integrate, the number of frameworks run in parallel, and the internal capacity available for the assessment decisions that cannot be automated at all.
Ethical Considerations and Human Oversight
If you use AI to manage risk, that AI is itself a system requiring governance. Article 9(2) of the EU AI Act describes a risk management system for high risk AI as a continuous iterative process planned and run across the entire lifecycle, with regular systematic review, covering identification and analysis of foreseeable risks, estimation under intended use and foreseeable misuse, evaluation of risks emerging from post market monitoring, and adoption of measures to address them. Whether or not your particular use case is classified as high risk, that is a sound description of what responsible operation looks like. Which systems fall inside the classification is covered in our guide to high risk AI under the EU AI Act.
Bias Mitigation
A risk model trained on historical incident data learns your historical blind spots along with your history. If a business unit was never monitored closely, it generated few recorded incidents, and the model will infer that it is low risk. Test scoring outputs for systematic skew across business units, geographies, and system types, and document how conclusions are reached. Re-test after retraining, not only at launch.
Explainability and Transparency
Explainability is not a philosophical preference in this context, it is an audit requirement. An assessor asking why a risk was rated as it was will not accept the model as the answer. Keep the decision factors, confidence levels, and the inputs behind each output, and make sure a human can reconstruct the reasoning without the vendor's help.
Human-AI Collaboration
Define precisely where the system advises and where a person decides. In practice the line sits at the treatment decision: models can identify, correlate, and rank, but accepting, mitigating, or transferring a risk is an accountable act that ISO/IEC 27001:2022 assigns to a risk owner under clause 6.1.3. Define exception handling for cases the model gets wrong, and route human corrections back as training signal rather than losing them in a ticket.
"The question in an audit is never whether your tooling is sophisticated. It is who decided to accept this risk, on what basis, and when. Automation that cannot answer that has added throughput without adding assurance, and we see teams discover this late, usually in the room with the auditor."
Kutluhan Abut, Information Security and AI Governance Specialist at Kertos
Measuring Success: KPIs for AI-Powered Risk Management
Three groups of metrics are enough. All three need the Phase 1 baseline to mean anything, which is why the baseline work is not optional.
| Dimension | Metric | Why it is the right one |
|---|---|---|
| Detection | Mean time from risk emergence to documented assessment | Measures the gap the annual cycle creates, in days |
| Detection | Share of predicted risks later validated as real | Keeps predictive models honest instead of merely productive |
| Efficiency | Working hours per assessment cycle | The number that funds the program in year two |
| Efficiency | Time to map a new framework onto the existing control set | Isolates the mapping cost, which is the real overhead |
| Business impact | Audit findings versus the prior year | The outcome an executive sponsor already cares about |
| Business impact | Turnaround on inbound customer security questionnaires | Connects risk work directly to revenue velocity |
One metric deserves more attention than it usually gets: the age of the oldest open risk with no treatment decision. It is unflattering, it is hard to game, and it tells you whether the program is closing risks or only finding them faster.
For scale, consider a worked example rather than an industry average. A 300 person software company runs ISO 27001 alongside a SOC 2 report, with 640 systems and applications in its inventory. At a semi annual review and 15 minutes per asset, that is 160 hours per cycle, 320 hours a year, before a single treatment decision is made. The figures are illustrative, the ratio is not: effort scales with the inventory, not with headcount.
Conclusion: The Future of AI-Powered Risk Management
AI moves the boundary between what a team has to collect and what it has to decide. Collection gets dramatically cheaper. Deciding does not, and the organizations that struggle with this transition are usually the ones that budgeted as though it would.
What changes in practice: risk state is current rather than annual, prioritization reflects live exploitability instead of abstract severity, mapping across frameworks becomes tractable, and audit evidence accumulates during operations rather than during the panic before an assessment.
What does not change: someone accountable still has to decide what to do about each risk, and be able to explain that decision a year later.
AI Risk Management with Kertos
Kertos implements this across three connected areas of the platform. The core is risk management, where risks, controls, and treatment decisions live in one place and carry their assessment history with them. That history is what answers the accountability question in an audit without anyone reconstructing spreadsheets after the fact.
Underneath it, asset management maps risks and controls to the systems they actually affect. That mapping is the prerequisite for turning a vulnerability feed into a work queue rather than a report, and it is the piece most AI risk management projects underestimate.
Third party exposure runs through vendor management, which is where the NIS2 supply chain obligation gets operationalized instead of surveyed once a year. Risks arising from AI systems themselves have their own assessment path in AI risk assessment, aligned to ISO 42001 and the EU AI Act.
Questions that come up during operation go to KAIA, the platform's compliance assistant, which maps a requirement to a control and explains what evidence is expected. Certified experts work through the assessment decisions with you rather than handing over templates. Kertos reports a 100 percent audit success rate and 97 percent customer satisfaction across more than ten industries.
What customers tend to describe is the consolidation rather than the automation:
"Rather than spending hours working on documentation, overlooking risks and filling out endless documents we have one software we can do all this in."
Ziad H., VP of Operations, mid-market company
Frequently asked questions
What is AI risk management?
AI risk management is the use of machine learning to automate data collection, correlation, and pre-assessment within a risk management process. Connected systems supply configuration, access, and vulnerability data, and a model relates it to the asset inventory and the control set. Scoring against defined criteria and the decision on treatment remain with the organization.
Can AI replace the risk assessment required by ISO 27001?
No. ISO/IEC 27001:2022 requires a defined process with established criteria under clause 6.1.2, and a documented treatment decision attributable to a named risk owner under clause 6.1.3. AI can supply the basis for that decision but not the decision itself, and an audit tests precisely that attribution.
How often should a risk assessment be performed?
Clause 8.2 of ISO/IEC 27001:2022 sets no fixed interval. It requires assessments at planned intervals and additionally whenever significant changes occur or are proposed. In practice the second condition means an annual cycle alone is insufficient once the system landscape changes regularly.
How do you prioritize vulnerabilities with AI?
Combine four signals rather than relying on severity alone: CVSS for abstract severity, EPSS for the probability of exploitation in the wild within 30 days, CISA's KEV catalog for confirmed exploitation, and your own asset inventory for whether you run the affected component. With roughly 66,000 CVEs projected for 2026 and 1,587 KEV entries as of May 2026, the inventory check removes most of the volume.
Does the EU AI Act apply to AI used for risk management?
It depends on classification, and this is a question for your compliance function rather than a general answer. Article 9 of the AI Act sets out risk management system obligations for high risk AI, and Annex III defines which use cases fall into that category. Independently of classification, Article 9(2) describes a continuous lifecycle process with systematic review that is a reasonable operating standard for any AI you rely on for security decisions.
