The Question Sophie Wasn't Asked
When Halstead & Cole's litigation team adopted GPT-4o for case chronologies six months ago, no one asked the question ISO 42001 Clause 6.1 requires every organisation to ask before deploying an AI system: what happens when this goes wrong, how likely is that, and what is the impact on a client? The tool was adopted because it was fast. That impression is not governance. When an AI-generated chronology contains a fabricated date, the absence of a prior risk assessment is an aggravating factor — not a mitigating one.
"A firm that deploys AI without a structured process for understanding what could go wrong is answering exactly the terms the questionnaire was designed to probe."
— UNUS London · Gap 4 Article · Pemberton Capital ImplicationsThe Ayinde standard-of-care implication
Ayinde v Haringey / Al-Haroun v Qatar National Bank [2025] EWHC 1383 (Admin) recorded 18 fabricated AI citations. Dame Victoria Sharp P's judgment establishes that submission of AI-generated content without verification is a matter of professional conduct, not merely a technology error. A risk assessment that identifies "hallucination in legal citation" as a known risk — and then documents a control (verification before filing) — is the paper trail that demonstrates the firm treated AI as a professional tool rather than an infallible search engine. The absence of that paper trail is the absence of that demonstration.
Two Obligations Law Firms Routinely Conflate
Clause 6.1 of ISO/IEC 42001:2023 creates two distinct but linked obligations, and law firms routinely satisfy neither. The standard requires consideration of risks and opportunities, planning of actions to address them, and evaluation of the effectiveness of those actions. Read with Annex A (controls A.2.2 through A.6.1.6), this produces a structured AI risk and impact register — the document that gives every other AIMS control its proportionality rationale.
Plain English definition
Clause 6.1 is the "think before you act" clause of ISO 42001. Before deploying an AI system, the firm must formally identify what could go wrong, evaluate how bad each thing would be, decide what controls will reduce the risk, and define how those controls will be checked for effectiveness. This is the same discipline a solicitor applies to a complex legal transaction — applied, by Clause 6.1, to AI deployment.
Risk Assessment (continuous)
An ongoing process for identifying and evaluating risks at the system level. For each AIMS-SYS entry, the firm maintains a current assessment that covers likelihood, impact, and existing controls. Output: Part A of REG-AIMS-RISK-001, updated quarterly. Without it, no other AIMS control can be calibrated proportionately — you cannot determine whether 100% human review or spot-check review is appropriate without knowing the risk level.
Impact Assessment (triggered)
An event-triggered deep dive required before (a) a new AI system is deployed for the first time, (b) an existing system is extended to a new use case or practice area, or (c) a material change occurs (model version, significant prompt change). Output: Part B of REG-AIMS-RISK-001, signed before deployment or change. Without it, Clause 6.1 is satisfied for ongoing systems but not for the most important moments — when something new enters production.
Risk assessment ≠ impact assessment — common conflation
Many ISO 42001 implementation guides treat these as synonymous. They are not. Risk assessment is the standing process — produces the risk register, updated quarterly. Impact assessment is the event-triggered deep dive — produces a per-system assessment document, completed before deployment or material change. A firm with a risk register but no impact assessment process fails Clause 6.1. A firm that runs impact assessments but has no standing risk register also fails. REG-AIMS-RISK-001 contains both instruments in one controlled document.
The SRA's 9 February 2026 AI guidance does not use the phrase "risk assessment." It uses the language of professional judgement: solicitors must consider the risks of using AI tools before adopting them in practice, including the risk of AI-generated errors going undetected. This is risk assessment under a different name.
"Solicitors should consider the risks of using AI tools before adopting them in practice, including the risk of AI-generated errors going undetected."
— SRA · Compliance Tips for Solicitors Regarding the Use of AI and Technology · 9 February 2026The pre-deployment obligation is what ISO 42001 Clause 6.1 codifies. A firm that has completed REG-AIMS-RISK-001 for each system can demonstrate to the SRA — and to Pemberton Capital's panel questionnaire — that it considered AI risks before deploying those systems in client work. The 30-day deadline now has a defensible answer.
Five Ways a Clause 6.1 Process Can Fail
Most firms don't fail because they ignored Clause 6.1 entirely — they fail because some form of "risk thinking" was in place without satisfying what the standard actually requires. Click each non-conformance category to see what an audit would flag.
The firm has adopted AI tools and has never formally assessed the risk of any of them. The risk register does not exist. This is the baseline state for the majority of law firms below 200 fee earners.
Audit finding: "No documented evidence of AI risk assessment process exists. Clause 6.1 obligations unaddressed."
Some firms maintain an IT or cyber risk register. This does not satisfy Clause 6.1 because it does not address AI-specific risk factors: hallucination and output accuracy, bias in AI-generated legal analysis, confidentiality of data processed by external models, the impact of model version changes on output quality, and the professional liability implications of AI-assisted advice.
Audit finding: "Existing risk register addresses generic IT risks but does not include the AI-specific risk factors required by ISO 42001 Annex A controls A.2.2 through A.6.1.6."
Even where firms have a risk register, the impact assessment is treated as optional or is conducted retrospectively. Clause 6.1 and Annex A.2.2 require the impact assessment before deployment. An assessment completed after a system has been in production for six months is evidence of a governance gap, not a governance process.
Audit finding: "Impact assessment for AIMS-SYS-XXX was completed in [month], six months after deployment commenced. Pre-deployment assessment obligation under Annex A.2.2 not met."
Some risk registers list controls — for example, "human review of output" — without verifying that the control is actually implemented, effective, and consistently applied. ISO 42001 Clause 6.1 requires the firm to plan "how to evaluate the effectiveness of these actions." A control that exists on paper but is not evidenced in practice is not a control for the purposes of the standard.
Audit finding: "Listed controls are not evidenced through review logs, sign-off records, or sampling. Effectiveness evaluation absent."
Model version updates from vendors (OpenAI, Microsoft, LEAP Legal) can materially change AI system behaviour. A risk register that was accurate for GPT-4o in January may not be accurate for the updated model released in March. The standard requires the risk assessment to be current — which means it must be reviewed and updated whenever a material change occurs to any registered system.
Audit finding: "Risk register last reviewed in [month]. Multiple model-version updates have occurred since. Currency of risk assessment under Clause 6.1 cannot be evidenced."
What Standard Risk Registers Miss About AI
Generic risk registers apply generic factors — likelihood, impact, severity. ISO 42001 Annex A and the legal sector's AI risk landscape require eight specific factors for AI in legal practice. REG-AIMS-RISK-001 scores each system against all eight. Each card below shows the factor, its plain-English description, and the weighting it carries in the firm's scoring framework.
Why these eight — and not the standard five
Generic enterprise risk registers score operational, financial, reputational, regulatory, and strategic risks. AI introduces failure modes that don't fit those buckets: model drift after a vendor update, hallucinated legal citations appearing in court submissions, undocumented bias in client advice, and the loss of legal professional privilege through third-party data processing. Each of the eight factors above maps to a specific ISO 42001 Annex A control — that is what makes the assessment auditable rather than merely thoughtful.
The 5×5 Risk Matrix — Click Any Cell to Explore
REG-AIMS-RISK-001 uses a 5×5 likelihood/impact matrix. Each of the eight risk factors is scored on both axes (1–5), and the product score determines the risk rating: Low (1–4), Medium (5–9), High (10–19), Critical (20–25). Controls reduce the likelihood score — not the impact. A catastrophic outcome remains catastrophic even if made less likely by a control. Click any cell to see its score interpretation and remediation expectations.
Negligible
Minor
Moderate
Major
Catastrophic
halluc.
How to read the matrix
Likelihood measures how often the risk is expected to materialise given the firm's specific use context — not the vendor's published hallucination rate. Impact measures the severity if the risk does materialise. The product is the inherent risk score (before controls). After controls are applied, only the likelihood score reduces — never the impact. A catastrophic outcome with strong controls can still produce a score of 15 or 20 if likelihood stays at Possible (3) or higher.
Building REG-AIMS-RISK-001 in Five Steps
The risk register closes Gap 4 and is the analytical foundation for Gaps 5, 6, 7, and 8. Without it, the controls in those gaps cannot be proportionately calibrated. Below are the five steps Halstead & Cole takes to build the register, followed by a worked assessment for AIMS-SYS-001 (GPT-4o in litigation).
The risk register operates system-by-system
Each AIMS-SYS entry becomes one risk assessment record in REG-AIMS-RISK-001. The register owner (IT Lead, per RACI-AIMS-001) leads the assessment; the COLP and AGL participate for any system touching client-facing work or privileged data. At Halstead & Cole, five AIMS-SYS records produce five Part A entries — with AIMS-SYS-005 blocked pending vendor assessment.
Score inherent risk before any controls are applied
For each factor, record the inherent likelihood (before controls) on a 1–5 scale and the impact on a 1–5 scale. The product is the inherent risk score. A score of 20+ (Critical) requires board-level sign-off and enhanced controls before deployment proceeds. This baseline score — before any controls — is what tells you whether the system is deployable at all.
For each High or Critical factor, document a concrete control
The control must be concrete — not "human review" but "fee earner review of every AI output against source documents before use in any client matter, with sign-off recorded in the matter file." After controls are applied, re-score the likelihood only. Residual risk must fall to Medium or below for the system to proceed to active deployment without enhanced oversight.
Complete Part B before each new deployment or material change
For any system being deployed for the first time, or extended to a new use case, complete Part B — the structured impact assessment. This covers: all categories of people potentially affected by the AI system's output (clients, counterparties, witnesses, courts), the impact on each group if the system produces an error, and whether a client disclosure obligation arises. Part B must be signed by the AGL before production.
The register is not static — it is a living document
Review is required: quarterly (full review in the AGL's performance report); on any model version change (re-assess the affected system); on any AI incident or near-miss (re-assess relevant factors); and on any new regulatory development. Each review creates a new version of the affected risk record, maintaining a full audit trail.
Below is the Part A risk assessment as it would appear in REG-AIMS-RISK-001 at initial issue — before controls are fully implemented. This represents the honest baseline: inherent risk elevated, controls partially in place, two risks remaining High until Gap 7 and Gap 8 remediation is complete.
Two unmitigated High risks remain at initial register issue
Transparency/Client Disclosure (score 15) and Human Oversight Adequacy (score 16) are unmitigated at initial register issue. These scores will remain at High until Gap 7 (DOC-AIMS-DISC-001) and Gap 8 (PROC-AIMS-HITL-001) are implemented. REG-AIMS-RISK-001 must record these as open risks with target remediation dates. An AI system with unmitigated High risks may continue in use if the AGL explicitly accepts the residual risk in writing and records a remediation timeline — but it may not continue in use as though the risk does not exist.
Module 05 Completion Checklist
Tick every box below before proceeding to Module 06. This is the analytical pivot of the AIMS programme — everything downstream (G5 to G8) is calibrated against the scores and residual risks recorded here.
Module 06 — Preview
Module 06 moves from assessment to lifecycle governance. With risk register in place and systems classified by tier, the lifecycle procedure PROC-AIMS-LIFE-001 provides the governance framework for what happens to those systems over time — pre-deployment approval, active monitoring, version-change review, model retirement. The procedure turns the static risk assessment into a dynamic control that responds to vendor changes, regulatory developments, and incident learnings. By the end of Module 06, Halstead & Cole will have answered Pemberton Capital Question 4 and have a defensible lifecycle model for every AI system on the register.