Automating Security Risk Assessments with AI

SolarWinds Is Why You Should Care About Faster Risk Assessments

SolarWinds wasn’t “just” a supply-chain story. SUNBURST sat in signed Orion DLLs for months, and roughly 18,000 customers got dragged into the cleanup whether they liked it or not. That’s the kind of failure that makes ISO 27001 risk registers look quaint if you only update them once a year. The real question is simple: can AI help you produce better risk assessments fast enough to matter, without turning the whole exercise into compliance theater?

Yes — if you use it for triage, evidence extraction, and consistency checks, not as a magic oracle. I’ve seen too many risk workshops turn into group therapy with a spreadsheet. The useful part is not “AI writes the assessment.” The useful part is that it can read your policies, asset inventory, cloud configs, and prior incidents in minutes, then surface the gaps you would otherwise find after the auditor or attacker does.

Where AI Actually Helps in ISO 27001 and SOC 2

A decent risk assessment has four chores: identify assets, map threats, estimate likelihood and impact, and decide treatment. AI is best at the first and last miles of that process. It can parse a CMDB export, pull control statements from your policies, and summarize what changed since last quarter. It can also flag when your “encryption at rest” claim is unsupported by actual AWS KMS or Azure Key Vault settings. That’s not sexy, but neither is explaining to an auditor why your evidence came from a slide deck.

Tools like Microsoft Copilot for Security, Google Security Operations, and ServiceNow SecOps can accelerate the evidence-gathering phase if you point them at the right data. Feed them ticket history, cloud logs, IAM changes, and prior exceptions, and they’ll usually do a better first pass than a tired analyst on a Friday. The catch is that they are pattern matchers, not judges. If your source data is garbage, the output will be a polished version of garbage. Very efficient garbage, though.

For ISO 27001, that matters because Annex A controls are often assessed with stale evidence and hand-wavy likelihood scores. For SOC 2, it matters because the Trust Services Criteria reward consistency, not theater. AI can help you standardize the language you use for risks like exposed S3 buckets, stale service accounts, or missing MFA on admin paths. It can also highlight when the same risk is described three different ways across business units, which is a polite sign that nobody actually owns it.

What AI Can Score Better Than Your Spreadsheet

Risk scoring is where AI can be useful without pretending to be clairvoyant. If you train or prompt it on your own incident history, control exceptions, and asset criticality, it can cluster similar risks and suggest a treatment pattern: accept, mitigate, transfer, or avoid. That is especially handy when you have dozens of “medium” risks that are really the same problem wearing different hats.

Here’s the non-hype version: use AI to normalize inputs, not to invent probabilities. A model can help you compare “publicly reachable VPN appliance with known CVE exposure” against “internal wiki page with stale content” and assign them different weights. It can also identify when a risk is technically low-likelihood but high-blast-radius, which is the sort of thing that gets missed when people overfit to CVSS. CVSS is useful. It is also not a business impact model, despite what some dashboards imply.

Midnight Blizzard is a good reminder of why this matters. Microsoft said the actor used password spraying against a legacy test tenant and then moved into corporate email and source code. That’s not an exotic zero-day story; it’s a control failure story. AI can help you spot those control failures faster by correlating legacy accounts, weak auth paths, and stale tenants before somebody else does. Fancy, that.

Where You Should Not Let the Model Near the Steering Wheel

Do not let AI decide risk treatment on its own. That sounds obvious until someone pastes a policy pack into a chat interface and asks for a “final risk register.” The model has no native sense of your regulatory exposure, customer commitments, or tolerance for being embarrassed in front of an auditor. It will happily produce a confident answer that is wrong in a way only a machine can be wrong.

The contrarian bit: you do not need a bespoke model to do this well. In many cases, a controlled workflow around an LLM plus retrieval over your own evidence is enough. The real value is in forcing structure: one risk statement format, one scoring rubric, one treatment taxonomy, one approval path. If AI helps you enforce that discipline, great. If it creates a second source of truth, you’ve just automated confusion.

Also, be careful with sensitive inputs. Risk assessments often contain details about privileged accounts, network segmentation, vendor weaknesses, and known exploit paths. If you dump that into a public chatbot, you’ve created a new data handling problem while trying to solve an old one. Security teams love that move right up until Legal asks who approved it.

A Practical Workflow That Doesn’t Waste Everyone’s Time

Start with your existing artifacts: asset inventory, cloud posture data, IAM exports, prior audit findings, incident tickets, and exception logs. Use AI to extract candidate risks and map them to control families like access management, change management, logging, and vendor oversight. Then have a human reviewer validate the top risks, because the model will miss business nuance and occasionally hallucinate one with great confidence.

Next, score risks using a fixed rubric. I prefer a simple matrix tied to likelihood evidence and impact evidence, not a mystical “AI score” with no provenance. If the model says a risk is high because a system is internet-facing, show the evidence. If it says impact is severe, tie that to actual data sensitivity, revenue dependency, or regulatory exposure. You want traceability, not vibes.

Finally, use AI to draft treatment plans and control mappings. A good system can suggest that a risk tied to weak MFA should map to conditional access, phishing-resistant authentication, and periodic access review. It can also propose evidence requests for the next audit cycle. That saves time, but more importantly, it reduces the drift between what you think the control is and what the evidence actually shows.

The Bottom Line

Use AI to accelerate risk assessments, not to outsource judgment. Keep the model on evidence extraction, normalization, and drafting, then require human approval for scoring and treatment.

If you can’t trace each risk score back to concrete artifacts — logs, configs, tickets, or prior incidents — the assessment is just compliance fan fiction. Start there, and you’ll get something defensible instead of decorative.

References

• SolarWinds Secure by Design: https://www.solarwinds.com/trust-center/security-advisory/sunburst-supply-chain-attack
• Microsoft on Midnight Blizzard: https://www.microsoft.com/en-us/security/blog/2024/03/08/analyzing-midnight-blizzard-ongoing-cyberattacks/
• NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments: https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final
• ISO/IEC 27001 overview: https://www.iso.org/isoiec-27001-information-security.html
• ServiceNow SecOps: https://www.servicenow.com/products/security-operations.html