AI Models Augment Cyber Security Event Detection
Only AI models proven suitable (validated for detection efficacy, false-negative behaviour, provenance and adversarial robustness) are used to augment, not replace, the detection of cyber security events and the identification of incidents.
Plain language
This control lets you use artificial intelligence to help your monitoring tools spot suspicious activity faster and find incidents your analysts might miss, but only if the model is genuinely fit for the job. The key word is "suitable": before you trust a model in detection, you have to test how well it actually catches threats, measure how often it misses them, know where it came from, and check it cannot be easily fooled. AI here is an assistant to your monitoring, not a substitute for it, so a poor model must never become a single blind spot.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
June 2026
Control Stack last updated
19 June 2026
E8 maturity levels
N/A
Official control statement
Suitable AI models are used to augment the detection of cyber security events and the identification of cyber security incidents.
Why it matters
If an unsuitable or unvalidated AI model is wired into detection, it can silently produce false negatives (genuine intrusions, lateral movement or data exfiltration are scored as benign and never raised as events or incidents) while staff assume the AI has it covered. Equally, an over-tuned model floods analysts with false positives, causing alert fatigue so real detections are dismissed. Undetected model drift, or adversarial evasion crafted to slip past the model, then leaves attacks running for longer with no human catching the gap the AI created.
Operational notes
Treat the model as a monitored asset: continuously track detection precision and recall (especially the false-negative rate) against labelled and red-team-generated samples, and trigger retraining when performance decays past a defined threshold. Set a fixed retraining and revalidation cadence, and additionally revalidate whenever new threat types, log sources or attack techniques emerge so the model does not silently fall behind the threat landscape. Watch for model drift by comparing live input distributions and detection rates against the validated baseline, and test resilience to adversarial evasion (crafted inputs designed to be misclassified as benign). Always keep AI augmentation behind human-led monitoring and signature/heuristic detection so a model failure degrades coverage rather than eliminating it.
Implementation tips
- Define written suitability criteria for any AI model before it touches detection, including minimum recall (acceptable false-negative rate), maximum false-positive rate, supported log sources and the detection use cases it is approved for.
- Build a labelled validation dataset of true incidents and benign activity drawn from your own environment, then measure each candidate model's precision, recall and false-negative rate against it and reject models that miss the threshold.
- Capture model provenance for every model you deploy: record the vendor, version, training-data origin and documented limitations for sourced models, and maintain lineage and training records for any in-house models.
- Run adversarial robustness testing by feeding the model crafted and evasion-style inputs designed to be misclassified as benign, and only deploy models that hold up or have compensating controls for known weaknesses.
- Deploy the model to augment existing monitoring rather than replace it: keep signature, heuristic and human review in the detection path so AI scores enrich alerts instead of being the only gate on raising an event or incident.
- Instrument continuous drift monitoring against the validated baseline, wire drift breaches and a fixed retraining cadence to a revalidation run before promotion, and revalidate whenever new threat types, techniques or log sources appear.
Audit / evidence tips
- For each AI model in the detection pipeline, obtain its efficacy test report and confirm a measured false-negative rate (recall) and false-positive rate against a labelled dataset, with a documented acceptance threshold the model met before deployment.
- Trace one or more AI-raised detections and one AI-suppressed sample through the pipeline to confirm AI output augments human monitoring and existing signature/heuristic detection rather than being the sole arbiter of whether an event is raised.
- Inspect provenance and assurance evidence for each sourced model (model card, version, supplier attestation, training-data origin) and confirm in-house models have equivalent lineage documentation establishing suitability.
- Review adversarial robustness test results and confirm the model was evaluated against evasion or crafted-input attacks, with any identified weaknesses tracked to remediation.
- Examine drift-monitoring reports and the retraining log to confirm detection performance is measured continuously against the validated baseline and that retraining or revalidation was triggered on schedule and when new threat types appeared.
- Compare the model version currently in production against the latest revalidation record to confirm the deployed model is the one that passed suitability testing.
Cross-framework mappings
How ISM-2117 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| handshake Supports (1) expand_less | ||
| Annex A 8.16 | ISM-2117 requires suitable AI models to augment detection of cyber security events and identification of incidents | |
| extension Depends on (1) expand_less | ||
| Annex A 8.15 | ISM-2117 requires suitable AI models to augment detection of cyber security events and identification of incidents | |
E8
| Control | Notes | Details |
|---|---|---|
| handshake Supports (1) expand_less | ||
| E8-AH-ML2.15 | ISM-2117 requires suitable AI models to augment detection of cyber security events and identification of incidents | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.