If you operate an AI system under any regulatory or standards-based framework, you face a risk management obligation. Not an optional best practice. A hard requirement. The specifics vary by framework, but the underlying structure is remarkably consistent: identify risks, assess their severity and likelihood, implement controls, test those controls, and keep doing it as the system evolves.
Most teams approach this per-framework, producing a separate risk artefact for each standard they need to satisfy. That is expensive, fragile, and unnecessary. A single continuous risk management process, wired into the engineering workflow, can cover all of them at once.
Six Frameworks, One Obligation
The following frameworks each contain a risk management requirement. The language differs; the obligation does not.
EU AI Act Article 9: Risk Management System
Article 9 of Regulation 2024/1689 requires providers of high-risk AI systems to establish, implement, document, and maintain a risk management system. The regulation specifies four mandatory components:
- Identification and analysis of known and foreseeable risks to health, safety, or fundamental rights (Article 9(2)(a))
- Estimation and evaluation of risks under intended use and reasonably foreseeable misuse (Article 9(2)(b))
- Adoption of risk management measures that must be implemented as technical controls in the system itself (Article 9(2)(c), Article 9(4))
- Testing to verify that risk management measures are effective before market placement (Article 9(9))
The critical word in Article 9 is "continuous." The risk management system "shall be a continuous iterative process run throughout the entire lifecycle" of the high-risk AI system. A risk register written in 2024 does not satisfy Article 9 in 2026 if your system has changed.
ISO 42001 Clause 6.1: AI Risk Assessment and Treatment
ISO 42001 (the AI Management System standard) requires organisations to determine risks and opportunities related to AI, conduct AI risk assessments, and apply risk treatment plans. Clause 6.1 mandates that the organisation:
- Consider internal and external issues, as well as interested parties, when identifying AI risks
- Define criteria for performing AI risk assessments
- Ensure that repeated risk assessments produce consistent, valid, and comparable results
- Apply risk treatment to address identified AI risks and retain documented information of the process
Like the EU AI Act, ISO 42001 does not permit a one-and-done assessment. The management system is expected to iterate through the Plan-Do-Check-Act cycle on an ongoing basis.
ISO 27001: Information Security Risk Assessment
ISO 27001 Clause 6.1.2 requires organisations to define and apply an information security risk assessment process. For AI systems that handle personal data, sensitive inputs, or critical outputs, this means:
- Identifying risks to the confidentiality, integrity, and availability of information processed by the AI system
- Assessing the likelihood and impact of those risks
- Selecting appropriate controls from Annex A or equivalent
- Producing a Statement of Applicability and a risk treatment plan
ISO 27001 also requires risk assessment to be repeated at planned intervals or when significant changes occur. AI systems, which evolve through retraining and data updates, trigger this change condition frequently.
ISO 13485 Clause 7.1: Risk Management per ISO 14971
For AI in medical devices, ISO 13485 Clause 7.1 requires the application of risk management throughout product realisation, referencing ISO 14971. This standard demands:
- Hazard identification for every reasonably foreseeable hazard associated with the medical device
- Risk estimation for each identified hazard
- Risk evaluation against defined acceptability criteria
- Risk control measures with verification of their effectiveness
- Evaluation of overall residual risk
- Production and post-production monitoring to detect emerging hazards
ISO 14971 explicitly requires that risk management continue into post-production. For AI-enabled medical devices, where model performance can degrade over time, this makes continuous monitoring an absolute requirement.
NIST AI RMF Map Function: Risk Framing and Identification
The NIST AI Risk Management Framework organises risk management into four functions: Govern, Map, Measure, and Manage. The Map function focuses on context establishment and risk identification:
- Understanding the AI system's intended purpose, users, and deployment context
- Identifying risks across reliability, safety, fairness, privacy, security, and explainability
- Considering risks to individuals, organisations, and ecosystems
- Mapping the AI lifecycle and identifying risk at each stage
NIST AI RMF is not prescriptive about frequency, but it treats risk management as an ongoing organisational practice. The framework explicitly states that "AI risks that are not properly managed can lead to consequences that can be difficult to reverse," reinforcing the need for proactive, continuous oversight.
GDPR Article 35: Data Protection Impact Assessment
Article 35 of the GDPR requires a Data Protection Impact Assessment (DPIA) for processing operations that are "likely to result in a high risk to the rights and freedoms of natural persons." AI systems that process personal data, perform profiling, or make automated decisions almost always trigger this requirement. The DPIA must include:
- A systematic description of the processing operations and their purposes
- An assessment of the necessity and proportionality of the processing
- An assessment of risks to the rights and freedoms of data subjects
- Measures to address those risks, including safeguards and security measures
The Article 29 Working Party (now EDPB) guidance states that a DPIA is not a one-time activity and must be reviewed when the risk changes. For AI systems that retrain on new data or are deployed to new populations, the processing risk changes regularly.
The Common Structure
Despite differences in terminology, scope, and legal force, these six frameworks share a common risk management structure:
| Step | EU AI Act Art. 9 | ISO 42001 | ISO 27001 | ISO 13485/14971 | NIST AI RMF | GDPR Art. 35 |
|---|---|---|---|---|---|---|
| Identify risks | Art. 9(2)(a) | Clause 6.1.1 | Clause 6.1.2 | Hazard identification | Map function | Art. 35(7)(c) |
| Assess risks | Art. 9(2)(b) | Clause 6.1.2 | Clause 6.1.2 | Risk estimation | Measure function | Art. 35(7)(c) |
| Implement controls | Art. 9(2)(c) | Clause 6.1.3 | Clause 6.1.3 | Risk control | Manage function | Art. 35(7)(d) |
| Test effectiveness | Art. 9(9) | Clause 9.1 | Clause 9.1 | Verification | Measure function | Art. 36 (prior consultation) |
| Monitor and iterate | "Continuous iterative process" | PDCA cycle | Clause 10.1 | Post-production monitoring | Ongoing practice | EDPB guidance |
This convergence is not coincidental. Risk management is a mature discipline. The frameworks differ on scope (AI-specific vs. information security vs. data protection) and on what counts as an acceptable risk, but the process itself is universal.
Why "Continuous" Is the Critical Word
Every one of these frameworks requires ongoing risk management. None of them accept a static document as sufficient. The reason is practical: AI systems change. They are retrained. Their data distributions shift. They are deployed into new contexts with new user populations. Each of these changes alters the risk profile.
- Every model retrain must trigger a fresh risk analysis
- Every change to training data must be assessed for distributional risk
- Every deployment to a new context or user group must be re-evaluated
- Post-market monitoring data must feed back into the risk management system
- Changes to regulatory guidance or new case law may redefine what counts as acceptable risk
A document written in 2024 does not satisfy any of these frameworks in 2026 if your AI system has changed since then. Continuous risk management is the only approach that scales across frameworks, because it catches drift before drift becomes non-compliance.
What Auditors and Regulators Will Ask For
Whether the audit comes from a market surveillance authority (EU AI Act), a standards auditor (ISO 42001, ISO 27001), a regulatory authority (medical devices), or a data protection authority (GDPR), the evidence they request follows the same pattern:
- Was risk assessed at each stage of the AI lifecycle, not just at launch?
- Did identified risks have documented mitigations with clear ownership?
- Were mitigations implemented as technical controls, not just policy statements?
- Were those controls tested, and is there evidence of the test results?
- Was the system monitored post-deployment, and did monitoring findings feed back into the risk process?
- Is all of this timestamped, version-controlled, and traceable to specific system versions?
A PDF risk assessment with no version history, no connection to the engineering pipeline, and no evidence of post-deployment review will not survive any of these audits.
Common Gaps in Current Practice
| What teams do | What the frameworks require |
|---|---|
| Annual risk review meeting with a slide deck | Continuous process triggered by every system change |
| Risk register in a spreadsheet | Documented system with version control and timestamps |
| Separate risk documents per framework | An integrated risk process that maps controls to multiple standards |
| General GDPR DPIA repurposed for AI | AI-specific risk analysis covering fairness, reliability, and safety |
| Risk mitigations in policy documents | Technical controls implemented and tested in the system |
| One-off pre-launch testing | Ongoing testing including post-deployment monitoring feedback |
The Engineering Implication
Multi-framework risk management is an engineering obligation that has been handed to legal and compliance teams. The only way to satisfy continuous lifecycle risk management at scale is to wire it into the engineering workflow: at the CI/CD level, where every release triggers a risk check, generates timestamped evidence, and produces a traceable record that maps to each framework's requirements.
Policy documents cannot satisfy regulations that require operational continuity. Spreadsheets cannot produce the timestamped, version-linked evidence that auditors demand. The process must be automated, or it will not be sustained.
This is precisely what Vigilens is built to do: continuous risk management that maps controls to every framework your AI system operates under, with evidence collected automatically from your engineering tools and an audit pack generated on demand.
Frequently Asked Questions
Do different AI compliance frameworks require separate risk management processes?
No. While the EU AI Act, ISO 42001, ISO 27001, ISO 13485, NIST AI RMF, and GDPR each frame risk management differently, they share a common structure: identify risks, assess severity and likelihood, implement controls, test effectiveness, and monitor continuously. A single well-designed continuous risk management system can satisfy all of them simultaneously.
How often must AI risk management be updated across these frameworks?
Every framework requires ongoing review, not annual snapshots. The EU AI Act mandates a continuous iterative process throughout the AI lifecycle. ISO 42001 requires risk assessment whenever significant changes occur. NIST AI RMF treats risk framing as an ongoing activity. In practice, any material change to an AI system (model retrain, new data source, new deployment context) should trigger a risk review to remain compliant across all frameworks.