ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
It is tempting to treat AI security controls as additive: find a threat, add a defence, repeat. ISO/IEC 27090 makes a point that is easy to miss. Some AI defences make other defences weaker, some cost the model its accuracy, and many of them quietly lose their effect as the model and its data change. Stacking controls without testing them together can leave you less secure than you think.
This guide explains how AI security controls interfere with each other, why they decay, and a practical way to manage them as a portfolio rather than a pile.
A firewall rule does not change how a database works. Many AI security controls do change the thing they protect, because they act through training. Adversarial training, differential privacy, robust loss functions, pruning and watermarking all alter the model’s parameters. Once a defence changes the model, it can change everything else about the model too: its accuracy, its generalisation, and its response to other attacks.
ISO 27090 clause 7 therefore asks that mitigations be evaluated for conflicting interactions before deployment and throughout the life cycle, not judged one at a time.
Free AI risk assessment
Which of your AI systems could harm people, or you?
List your AI systems, models and data, pick from 54 AI risk scenarios, including the attacks on AI described in ISO 27090, rate them for the people affected and for you, and plan treatment with ISO 42001 Annex A controls. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free AI risk assessment → or View premium report sample
The standard cites three kinds of evidence that mitigations interfere:
The conclusion ISO 27090 draws is direct: mitigations that involve training can have unexpected harmful side-effects. Beyond the examples it cites, several trade-offs run through the rest of the standard.
| Control | What it helps | What it can cost or weaken |
|---|---|---|
| Adversarial training | Resistance to the evasion attacks it was trained on | Training cost, possible overfitting to known attacks, weaker generalisation, exposure to other attack types |
| Differential privacy in training | Formal protection against membership inference | Accuracy; for complex tasks, strong settings can make the model unusable |
| Random-transformation defences | Evasion resistance | Benign accuracy, unless the model is trained with the transformations in place |
| Defences that hide gradients | Some evasion attacks | A false sense of safety: they can be bypassed by attacks that approximate the gradients |
| Explainability | User trust, security assessment, spotting manipulation | Reveals which features matter most, which helps attackers target evasion |
| Transparency about the system | Calibrated trust; legal and contractual duties | Technical detail that helps attackers choose and tune attacks |
None of these is a reason to avoid the control. Each is a reason to measure what it does to the rest of the system before relying on it.
ISO 27090 notes that model performance deteriorates over time, and that when training is used as a mitigation, its efficacy can deteriorate too. A model adversarially trained against last year’s attacks, retrained on new data without the adversarial examples, may quietly lose that robustness.
The standard’s answer has three parts: monitor in operation for loss of mitigation effectiveness; retrain when needed, including on the data used for mitigation such as adversarial examples; and fully revalidate mitigation efficacy before the retrained model is redeployed.
Some threats need related controls at several stages. ISO 27090’s own example is membership inference: audit checks on training data, privacy-preserving training, and input and output filtering at inference. The standard asks that the alignment of such controls be evaluated so they actually work together. In practice:
Our guide to the membership inference attack works through that chain in detail.
ISO 27090 asks that resilience, durability, effectiveness and efficiency be weighed case by case, and is candid that some techniques are still emerging. Before adopting any AI-specific control, answer:
Where a conventional control treats the risk adequately, prefer it. Rate limiting, output minimisation, access control and data minimisation do not change the model and rarely interfere with anything.
The core recommendation of clause 7 is that whenever a mitigation is added or changed, the efficacy of the whole portfolio and the model’s performance are verified before deployment. A workable routine:
A one-page record of before-and-after results per change is enough to show an auditor, a customer or a regulator that the controls were tested together.
Here is what one change looks like when AI security controls are tested together. The figures are illustrative, not measurements from a real system.
A fraud-scoring model already uses input validation, per-user throttling and output that returns a decision rather than a score. The team adds adversarial training to resist evasion, then re-runs every measure:
| Measure | Before | After | Threshold | Result |
|---|---|---|---|---|
| Accuracy on clean data | 0.912 | 0.897 | 0.890 | Pass |
| Success rate of the evasion attack trained against | 31% | 9% | 15% | Pass |
| Success rate of a different evasion technique | 12% | 24% | 15% | Fail |
| Measured membership leakage | Low | Low | Low | Pass |
Tested alone, the change looks like a clear win. Tested as a portfolio, it has opened a new weakness. The team either adds training data for the second technique and re-tests, or records the trade-off as an accepted risk. Either way, the decision is made with the evidence in front of them rather than discovered after an incident.
EU AI Act Article 15 asks high-risk AI systems to perform consistently in accuracy, robustness and cybersecurity throughout their life cycle. A control that silently weakens another, or decays after retraining, works directly against that. Our guide to EU AI Act Article 15 covers the article in full, and NIST’s AI 100-2e2025 discusses the trade-offs between attributes of trustworthy AI and the theoretical limits of adversarial robustness.
No. It is one of the main defences against evasion. Use it with measurement: test the rest of the portfolio and model accuracy after adding it, and retrain with the adversarial data when the model is retrained.
Much less. Access control, throttling, output minimisation, logging and data minimisation act around the model rather than inside it, which is one reason ISO 27090 treats conventional controls as the starting point.
On every change to the model or its mitigations, and on a schedule in operation set by the system’s risk. Continuous validation against a protected test set covers much of the scheduled part.
Mostly. Teams using hosted models change fewer controls inside the model, but output filters, input classifiers and guardrails can still conflict, for example a strict input filter that blocks legitimate use and pushes users to work around it.
The lesson of ISO 27090 clause 7 is that AI security controls are a system, not a checklist. Choose them deliberately, test them together, and re-test them whenever anything changes. For the threats they defend against, see the ISO 27090 overview and our guides to data poisoning and prompt injection prevention.
Our ISO 27090 Toolkit includes a Mitigation Portfolio Management Procedure and a Mitigation Interaction and Efficacy Assessment workbook built for exactly this routine, alongside the per-threat standards whose controls it tests.
October 29, 2026
October 28, 2026
October 28, 2026
October 27, 2026
October 27, 2026