Lesson 9 of 10 · 14 min read
Mitigations and how controls interact (Clause 7)
Last updated:
Clause 7 of ISO/IEC 27090 states that the security of an AI system must be viewed as a coherent whole, because mitigations interact and can weaken one another. It expects controls to be evaluated together before deployment and monitored in production, since their effectiveness decays as attackers adapt and data drifts. The mitigation themes include logging and monitoring, a secure development environment, malicious input detection, rate limiting, limited confidence output and model size limits.
In this lesson you will learn to
- 01
Explain the holistic principle in clause 7 and the documented control conflict
- 02
List the mitigation themes the standard describes
- 03
Describe the monitor, retrain, revalidate loop and its triggers
- 04
Specify what to log for an AI system and the trade-offs of the heavier controls
Controls interact, so evaluate them together
The single most important idea in clause 7 is that AI security controls are not independent. The standard states that the security of an AI system must be viewed as a coherent whole rather than as a series of separate safeguards. One control can weaken another, and most controls lose effectiveness over time.
The documented example is the one from lesson 6: training on adversarial data improved resistance to evasion but increased vulnerability to patch attacks. A team that added adversarial training as a tick-box improvement made the system worse against a different threat. The standard therefore asks for combined evaluation before deployment, interaction analysis, and continued monitoring after.
Evaluate all controls together, not one by one
Test the combined effect of defences before deployment
Layer protection: data controls, model-level techniques, and input and output filtering across the life cycle
Expect effectiveness to decay: monitor continuously, retrain when needed, revalidate before returning to service
The mitigation themes
Ten themes summarise the mitigations clause 7 describes. Each is a familiar control adapted to AI.
| Theme | What it means for an AI system |
|---|---|
| Holistic evaluation | Assess all controls together and monitor them in production |
| Interaction testing | Test the combined effects of defences before deployment |
| Layered protection | Data, model and input/output controls across the life cycle; no single layer suffices |
| Drift and decay monitoring | Continuous monitoring, regular testing, retraining and revalidation |
| Logging and monitoring | Record inputs, outputs, users, time, model and prompt template versions |
| Secure development environment | Protect data, code, configuration, documentation and retrieval stores |
| Malicious input detection | Out-of-distribution, statistical and anomaly detection on inputs |
| Rate limiting | Cap request volume to limit scraping, probing and model reconstruction |
| Limited confidence output | Round or hide confidence scores to hinder inversion and theft |
| Model size and complexity limits | Smaller models retain less of their training data and leak less |
Controls decay: the monitor, retrain, revalidate loop
A control that worked at go-live will not work forever. Attackers adapt, data distributions shift, and vendor models change. The standard describes a loop: monitor accuracy, drift, anomalies and attack indicators in production; detect degradation when thresholds are breached or a new pattern appears; retrain or patch with clean data, an updated model or revised filters; revalidate by re-running security tests and the combined control evaluation; redeploy under controlled release with rollback.
Triggers for revalidation include any retraining or fine-tuning, a model or vendor version change, a new data source, a new tool or integration connected to an agent, an incident or near miss, and the scheduled review. The management implication is that AI security is a continuing operating cost with named owners, not a line in the project that built the system.
What to log
Most inference attacks look like ordinary use, so logging is what makes an incident reconstructable and automated probing visible. The standard lists what to record. The same requirements map onto the ISO/IEC 27002 controls for logging and monitoring activities.
| Record | Why it matters | Use in detection |
|---|---|---|
| Inputs and prompts | Reconstruct what the model was asked | Injection attempts, probing sequences |
| Outputs and confidence scores | Evidence of what was disclosed or decided | Sensitive output, inversion patterns |
| User or client identity and time | Attribution and rate analysis | Exfiltration, membership inference, abuse |
| Model version and prompt template version | Link behaviour to a specific build | Regression after change, tampering |
| Tool and action calls | Trace actions an agent took | Injection-driven unauthorised actions |
| Retrieval sources used | Which documents fed an answer | Data leakage through retrieval |
Logs that contain prompts and outputs are themselves sensitive. Classify them, protect them, limit retention, and agree logging with vendors before a contract is signed.
Secure development environment and retrieval data
Clause 7 observes that the sensitive material of an AI system usually sits in development environments: training and test data sets, pipeline code and notebooks, configurations and hyperparameters, documentation and model cards, model artefacts and checkpoints. It adds that retrieval databases used in production need the same protection as training data.
The controls it points to are the ISO/IEC 27002 development controls applied to these assets: access control and least privilege with separate roles for data, training and deployment; separation of environments with signed, versioned artefacts; verification of data provenance and integrity before use; and supplier and tool assessment for pre-trained models, purchased data, notebook platforms and MLOps tooling.
Trade-offs: security against performance
The standard is candid that some mitigations cost accuracy, usability or compute, and some need mature security practice. It suggests these suit high-risk systems rather than every system. The decision rule that follows is to tier every AI system by risk, apply the costly controls to the high tier and the baseline controls to all.
| Mitigation | Protects against | Cost or side effect | Suggested use |
|---|---|---|---|
| Differential privacy in training | Membership inference, inversion | Accuracy loss; privacy budget to manage | Models trained on personal data |
| Adversarial training | Evasion | Compute cost; can increase exposure to other attacks | High-risk predictive models, after combined testing |
| Rounded or hidden confidence scores | Inversion, exfiltration | Less useful output for legitimate users | External-facing endpoints |
| Rate limiting and quotas | Exfiltration, inference attacks, denial of service | Friction for heavy legitimate users | All external endpoints |
| Model size and complexity limits | Memorisation and leakage | Lower capability | Where sensitive data is in training |
| Human approval for agent actions | Prompt injection consequences | Slower automation | Any action with financial or access impact |
Key terms
- Holistic evaluation
- Assessing all security controls of an AI system together, because they interact and can weaken one another.
- Drift
- A change in the data a system sees in production relative to what it was trained and tested on, which degrades both accuracy and controls.
- Revalidation
- Re-running security tests and the combined control evaluation after a change, before a system returns to service.
- Out-of-distribution detection
- Identifying inputs that differ statistically from what the model was trained on, a signal for evasion and abuse.
- Risk tiering
- Classifying AI systems by the consequence of failure so that costly controls are applied where they are justified.
In one paragraph
Clause 7 of ISO/IEC 27090 treats the security of an AI system as a coherent whole: controls interact, a documented case shows one control weakening another, and effectiveness decays. The standard asks for combined evaluation before deployment, layered protection, continuous monitoring with a retrain-and-revalidate loop, detailed logging of prompts, outputs, identities, versions and tool calls, a secure development environment that also covers retrieval data, and risk-tiered application of the costlier controls.
Lesson 9 quiz
Five questions. Score 4 or more to mark the lesson complete. Each answer shows an explanation, so a wrong answer teaches as much as a right one.
Questions people ask
- What is the holistic principle in ISO/IEC 27090?
- That the security of an AI system must be viewed as a coherent whole. Mitigations can conflict, so they must be evaluated together before deployment and monitored in production rather than added one at a time.
- Which controls does ISO/IEC 27090 say may hurt model performance?
- Differential privacy, adversarial training, rounding or hiding confidence scores, limiting model size and adding human approval steps each carry an accuracy, usability or speed cost. The standard suggests they suit high-risk systems rather than every system.
- What should an AI system log?
- Inputs and prompts, outputs and confidence scores, user or client identity and time, model and prompt template versions, tool and action calls, and the retrieval sources used, with the logs themselves protected and retention limited.
Shahzad Asghar
Senior IT Strategy and Portfolio Officer at UNRWA, with more than twenty years building and securing data and AI systems across UN agencies. He holds the CISM and CISSP security certifications and writes on AI governance, AI security and assurance, and digital transformation. Connect on LinkedIn.
This course is an independent educational resource by Shahzad Asghar. It is not affiliated with, endorsed by or published by ISO or IEC. ISO/IEC 27090:2026 is copyrighted and is sold through the ISO Store and national standards bodies; this course summarises it and does not reproduce its text. Last reviewed: .