One system, five assessments: the taxonomy
Lesson 1 of 5 in AI Risk and Impact Assessment Methodologies.
Your registry says the new credit-scoring model is tier one. Now someone has to actually assess it — and the first practical question is not how but which. A single high-stakes AI system in a European bank can trigger a DPIA (GDPR), a FRIA (EU AI Act Art 27), an internal AI impact assessment (ISO/IEC 42005, if you run a 42001 AIMS), a model validation (banking model-risk rules descended from Fed SR 11-7), and a security assessment (ISO 27001 / threat modelling). Five documents, five methodologies, five sign-offs — describing one system.
This module is the practitioner’s map of that terrain. The statutory texts live elsewhere on this site and we will not re-teach them: ISO/IEC 23894 and 42005 are covered in depth in the ISO domain, the AI Act’s high-risk articles in the EU domain, and NIST’s Map–Measure–Manage cycle in the US domain. Here the question is operational: which instrument fires when, what does each actually demand, and how do you run them without drowning your delivery teams?
Key terms: impact assessment, data protection impact assessment, fundamental rights impact assessment, algorithmic impact assessment, model validation, residual risk
Start by separating the instruments along three axes, because every confusion you will meet in practice collapses one of them:
Whose risk? A risk assessment protects the organisation — its objectives, its compliance, its reputation. An impact assessment protects other people — the applicants scored, the patients triaged, the neighbourhoods policed. A DPIA protects a specific slice of those people’s interests (their personal data); a FRIA protects a different slice (their fundamental rights). Model validation protects the decision itself — is the model fit for this purpose, on this population, at this moment?
What triggers it? Voluntary instruments fire on your own criteria (a new system, a significant change). Statutory instruments fire on legal tests: likely high risk to rights and freedoms (GDPR Art 35), high-risk system + captured deployer category (AI Act Art 27), automated decision system serving the public (Canada’s Directive on Automated Decision-Making), high-risk system making a consequential decision (Colorado’s AI Act, in force since 30 June 2026, which requires deployer impact assessments annually and within 90 days of an intentional and substantial modification).
Who sees the output? An internal risk register stays internal. A DPIA may reach the supervisory authority (Art 36 prior consultation). A FRIA’s completion is notified to the market surveillance authority. Canada publishes every AIA on the Open Government Portal — the public reads it. Publication discipline changes how honestly teams write, which is itself a governance design question.
| Instrument | Trigger | Primary lens | Output | Published? | Enforcement |
|---|---|---|---|---|---|
DPIA (GDPR Art 35) | Processing likely high risk to rights and freedoms — EDPB criteria; profiling, large-scale sensitive data, systematic monitoring | Data subjects: privacy and data-protection risks from processing personal data | Necessity/proportionality analysis, risk and mitigation record; Art 36 consultation if residual risk stays high | No (regulator may see it; some controllers publish summaries) | DPA fines up to 2% of worldwide turnover for skipping a required DPIA (Art 83(4)) |
FRIA (EU AI Act Art 27) | First use of an Annex III high-risk system by public bodies, private providers of public services, or credit/insurance deployers | Affected persons: fundamental rights — non-discrimination, dignity, social protection, due process | Deployer processes, usage period/frequency, affected categories, specific harm risks, oversight measures, remediation arrangements | No, but completion is notified to the market surveillance authority | AI Act administrative fines regime (deployer obligations tier) |
Canada AIA (Directive on ADM) | Any automated decision system used by federal government to make or recommend administrative decisions about clients | Scored questionnaire: impact on rights, health, economic interests, ecosystem sustainability | Raw impact score → mitigation deduction → Impact Level I–IV, each level attaching escalating obligations | Yes — mandatory publication on the Open Government Portal | Treasury Board policy consequences for non-compliant departments |
ISO/IEC 42005 impact assessment | Your AIMS criteria: new system; changed use, context, population, model, or data (42001 cl 6.1.4) | Individuals, groups, and societies — benefits and harms across fairness, safety, privacy, environment, wellbeing | Documented assessment feeding the risk register, DPIA, and FRIA; auditable within 42001 certification | No (internal; visible to certification auditors) | None directly — but certification nonconformity, and contract terms increasingly demand it |
NIST AI RMF Map + Measure | Voluntary; fires when your program adopts the RMF (or a US agency/contract requires alignment) | Context, capability, and measurable trustworthiness characteristics; GenAI Profile adds a 12-risk checklist | Context map, risk measurements, TEVV evidence feeding the Manage function | No | None — voluntary framework; procurement and policy increasingly reference it |
Model validation (SR 11-7 lineage) | Model used in decisioning at a regulated financial institution; internal MRM policy tiers | The model itself: conceptual soundness, data quality, performance, ongoing monitoring, effective challenge | Validation report with findings, limitations, approved use conditions | No (examiners review it) | Supervisory findings (MRAs), capital and usage restrictions |
Interactive sorting exercise: A question lands on your desk. Which instrument is it really asking about? Sort each fragment into the assessment where it belongs.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.